Техническое задание на графический редактор блок-схем (диаграмм) "Дракон" Этапы выполнения работ: Этап 1. Формирование базовых иконов и макроиконов, параметризация иконов, создание структур данных Все элементы блок-схем (диаграмм) описаны в книге, предоставляемой в электронном виде. Примеры элементов приведены в:
http://www.smartsense.org/elements.zipРеализацию следует выполнить на C#, MS SQL Server 2005.
Элементы диаграммы следует различать не по названию элемента, а по типу. Т.е. следует от базового типа узла диаграммы создать ряд дочерних типов для каждого элементарного объекта диаграммы.
Возможные сочетания элементов следует хранить в таблице БД. Например, Start – Process, Start – End. Также со словесным описанием типа элемента, следует хранить полное название .NET типа.
Предварительная структура таблицы:
ID типа исходящего элемента;
ID типа входящего элемента.
Тип связи должен быть порождён от базовой связи в Syncfusion.
Основные отличия:
- наличие у связи визуальных областей, в которые можно добавлять элементы диаграммы; чёрная точка в центре связи;
- наличие свойств, с помощью которых можно определить, какие типы элементов можно вставить в указанную область.
Результаты этапа (этап реализован): 1.Базовые типы данных: элемент схемы (диаграммы), икон, макроикон, связь.
2.Механизм параметризации для элементов схемы (кол-во связей, типы связей).
3.Библиотека иконов и макроиконов (реализация соответствующих классов, с параметризацией).
4.Палитры с элементами библиотеки.
5.Тестовое приложение со следующей функциональностью: построение диаграммы с использованием библиотеки, сериализация диаграммы в xml-файл.
Этап 2. Реализация привязки layout к базе данных. Правила построения диаграмм:
1) Дракон-схемы выгодно отличаются от других аналогов тем, что в них всегда есть четкая регламентация расположения блоков. В любой схеме есть "шомпол", вертикальная линия на которую "насаживаются" элементы. Поэтому имеет смысл реализовать правила автоматического построения диаграмм, исходя из этого правила.
2) Дракон-схема всегда имеет начало и конец, поэтому даже в новую, создаваемую, пустую схему всегда можно автоматически добавить 2 элемента "Начало", "Конец" и связь между ними.
3) Так как, исходя из пункта 2, на схеме всегда присутствует хотя бы 2 элемента и их связь, то логично привязывать новые элементы к связям элементов. То есть, при вставке нового элемента, существующая связь разделяется на 2 и между ними автоматически вставляется новый элемент. Форматирование всей схемы после такой вставки значительно упрощено тем, что действует правило сохранения шомпола, то есть форматирование идет всегда по вертикали.
Правила графического построения схем вокруг шомполов значительно упрощают задачу оптимизации размещения (layout) их на листе. Получается, что оптимизацию можно сначала проводить по вертикали, а затем, выполнять горизонтальную оптимизацию, но только для сложных конструкций.
Результаты этапа (этап реализован): 1.Реализация layout-класса для Syncfusion, удовлетворяющего требованиям дракон-схем.
2.Модернизация тестовой программы для использования данного класса.
Этап 3. Организация работы пользователя с программой 3.1. Построение диаграмм, добавление, удаление элементов и пр. Перечислим набор действий (операций), доступных пользователю. Они делятся на две категории: общесистемные возможности, и возможности, специфичные для конкретного элемента (икона).
1.Системные возможности
1.Операции добавления/удаления/копирования/вставки элементов диаграммы.
2.Группировка элементов и применение к группе операций из п. 1.1.
3.Undo/Redo.
4.Overview.
5.Масштабирование.
6.Вывод на печать (оптимальная для печати толщина линий определяется автоматически).
7.Расширенные команды масштабизации: прошлый масштаб и обратно, колесико интэлимаус - вверх/вниз, с shift - вправо/влево, с ctrl - накат, откат; маленькое окошко, всегда показывающее всю схему, в выделенной и перемещаемой рамкой.
8.Расширенные команды печати: вывод большой схемы на листки малого формата с разбиением на страницы.
2.Операции над конкретными элементами:
1.Вставка текста
2.Форматирование текста (шрифт-гарнитура, размер, стиль начертания; выравнивание, цвет)
3.Вставка формул
3.Операции для макроиконов
1.Добавление/удаление/перегруппировка/копирование веток
Примеры сценариев действий пользователя при вставке новых элементов:
1) Пользователь тянет мышью новый элемент, автоматически подсвечивается ближайшая связь, в которую может быть вставлен этот элемент. Когда пользователь "отпускает" элемент, то он автоматически вставляется в подсвеченную связь и вся схема переформатируется. Может быть, подсвечивается связь над которой тащат объект. Если связь подсвечена и пользователь бросает объект, то он вставляется.
2) Пользователь щелкает по связи на схеме, затем щелкает по новому элементу в палитре. Элемент автоматически вставляется в указанную связь и схема переформатируется.
Автоматическое построение диаграмм: 1) При построении диаграммы следует автоматически предлагать пользователю типы элементов, которые можно вставить после текущего выделенного элемента.
2) После вставки объекта должна автоматически создаваться связь между элементом, который выделен и элементом, который вставляется в диаграмму. При этом должно произойти автоматическое форматирование схемы.
3) Перетаскивание элементов пользователем возможно не в любое место диаграммы, а только на связь между элементами. Соответственно связи можно подсвечивать при приближении к ним элементов. При этом должна осуществляться проверка на то, можно ли вставить перетаскиваемый элемент в указанное место или нет. Следовательно, при выборе пользователем элемента можно подсветить все связи, на которые он может быть установлен, а потом выделять ближайшую связь, в которую будет вставлен элемент. Также должна быть проверка того, возможно ли удаление перетаскиваемого элемента из исходного
места, например, нельзя удалить базовый элемент в системной сложной конструкции.
После перетаскивания в исходном месте не должно быть разрыва, а должна образоваться новая связь. Например, имеем схему с тремя элементами: A – B – C. При перетаскивании или удалении элемента B, автоматически должна образоваться связь A – C.
3.2. Работа с библиотекой, организация сохранения шаблонов К пользовательским конструкциям относится любая схема, созданная пользователями (набранная из системных конструкций). Причем такие схемы могут быть сохранены как "шаблоны" для создания на их основе новых схем.
Элементы в палитру можно загрузить программно на основе БД. Т.е. в БД нужно хранить и наполнение палитр для каждого пользователя.
Пользовательские конструкции отличаются от системных тем, что пользователи не могут составить схему, которая "выдает" какой-то новый код программ. Все коды программ зашиваются только на системном уровне. Таким образом, пользователь может строить свои конструкции только на основе заранее подготовленных системных элементарных или сложных конструкций.
Любую диаграмму можно сохранить и в последствии использовать в качестве подпрограммы любой другой диаграммы. При этом диаграмма должна быть представлена в виде элемента Insertion. При клике на этом элементе на отдельной вкладке должен открываться указанный алгоритм (если у пользователя есть право на его просмотр). Вставка возможна, если в текущей редактируемой диаграмме уже определены все параметры, которые необходимы вставляемой диаграмме в качестве входных параметров. Если вставка невозможна, следует это как-то подсвечивать в палитре (?). Также после вставки другой диаграммы, в диаграмме, в которую произошла вставка, появляется доступ ко всем выходным параметрам вставляемой диаграммы (эти параметры доступны ниже по ходу выполнения алгоритма).
Элемент не графический, а сборный (группа), состоящий из других объектов. Для упрощения предлагаю использовать не графическое представление этой группы, а элемент Подпрограмма, т.е. когда вставляем другую схему, то в схему добавляется именно этот элемент, в свойствах которого и указан ID дочерней диаграммы (подпрограммы). А в самом элементе Подпрограмма будет отображаться название диаграммы, которая подключена. Клик по ней и открываем диаграмму в новом окне (см. выше).
Любую часть диаграммы можно сохранить в виде шаблона (с названием и кратким описанием). При этом следует запомнить все возможные точки сопряжения. Это необходимо для того, чтобы в процессе ввода новой диаграммы у пользователя была возможность вставки не только базовых элементов, но и сохранённых шаблонов.
3.3. Реализация стандартных языковых конструкций Кроме простых элементов в Дракон-схемах могут быть составные конструкции. Различаются "системные" составные конструкции и "пользовательские" составные конструкции. Системные конструкции создаются разработчиками, это конструкции "вариантов", "циклов", if then else, case. Эти конструкции подразумевают под собой наличие их интерпретации в программный код в виде соответствующих операторов.
Это не "мертвые" конструкции, которые один раз сделал, а дальше просто вставляешь. Тут они могут расширяться (их части могут дублироваться), например, в схеме вариантов может быть различное количество собственно вариантов (вертикальных шомполов), в операторах if и case тоже может быть разное количество ветвлений. То есть тут речь уже идет о параметрическом графическом элементе, структура которого определяется параметром, например, количеством вариантов или ветвей. То есть, пользователь в любой момент может добавить или удалить какие-то варианты или ветки, или даже сразу несколько.
3.4. Редактирование формул (редактор формул уже разработан) Так как элементы схемы Дракона содержат в себе формулы, вводимые через редактор "вычислителя", то получается, что элементы характеризуются перечнем переменных, необходимых для выполнения вычислений и перечнем переменных, получаемых в результате вычислений. Эти списки переменных открывают возможность анализа совместимости схем при вставке одних схем в другие.
До того, как все элементы не заполнены формулами и эти формулы не имеют правильный синтаксис всю схему нельзя считать готовой к применению. То есть кроме добавления формул, нужны еще и кнопки редактирования формул. Для начала можно просто подключить текстовый редактор, после вызова которого он возвращает какой-то код проверки синтаксиса.
Необходимо разместить на панели инструментов и по правой кнопке вызов редактора.
3.5 Интеграция с вычислителем (вычислитель уже разработан)- подключить редактор формул к блок схемам, чтобы он открывался по команде пользователя и ссылка на созданную формулу сохранялась в блок схеме.
- вычислитель должен проверять вводимую формулу на корректность синтаксиса и сохранять эту информацию в схеме. Открыв схему, пользователь сразу должен видеть в каких блоках у него стоят неправильные формулы.
- синхронизировать работу интерпретатора схемы с вызовом вычислителя для расчета формул
- сохранять в логе результаты работы вычислителя, чтобы показать их пользователю прямо в схеме. То есть, после вычисления показать
пользователю, какие числовые значения принимали участие в вычислениях и какие результаты были получены.
Результаты этапа: 1.Законченное приложение для редактирования Дракон-схем (Дракон-программ).
Этап 4. Организация многопользовательского режима и версионности Права доступа на просмотр, редактирование, удаление диаграммы, а также на её использование в качестве подпрограммы другой диаграммы.
Необходимо, чтобы несколько пользователей могли одновременно редактировать схему, поэтому надо реализовать механизм "захвата" пользователем элементов схемы, а также блокирования удаления элементов, редактируемых другим пользователем.
Необходимо сделать версионность по сохранению. Промежуточные варианты не учитывать. Впоследствии нужно будет сделать возможность просмотра изменений между версиями: здесь 2 варианта: логические изменения и физические изменения. Логические изменения должен описать сам пользователь (например, добавлена проверка цикличности поставок чего-либо), физические изменения должна генерировать сама схема.
Учет версий будет выполняться через Систему Управления Версиями (сейчас разрабатывается). Она реализуется отдельно и подключается к объектам нашей системы по ссылкам. Изменения данных будут отслеживаться на уровне каждой записи. На мой взгляд так можно сделать и для Дракон-схемы - отслеживать изменение на уровне элементарных блоков, тогда будет достаточно сохранять только измененные блоки, а не всю схему. Но только, в отличие от текстовых данных, здесь ведь даже если элементы не изменились, но может поменяться лэйаут - их расположение. Надо ли это рассматривать как изменение схемы и сохранять новую версию?
Результаты этапа: 1.Многопользовательский режим работы редактора дракон-схем.
2.Система контроля версий для Дракон-схем. (?)
Этап 5. Написание генератора кода Настоящим ТЗ предполагается, что диаграмма представима в виде xml-файла, поэтому кажется логичной реализация генерации кода в виде XSLT-преобразования, что позволит сделать генерацию кода легко настраиваемой без модификации основной программы-редактора, а также реализовать поддержку произвольного синтаксиса выходной программы. При этом обеспечивается реализация нескольких вариантов кодогенератора (по выбору Заказчика).
Пользователю предоставляется возможность выбрать вариант генерации кода для загруженной диаграммы. При этом желательно, чтобы готовые элементы (системные и пользовательские) оформлялись в виде повторно используемых фрагментов кода (например, процедур и функций).
Возможные варианты правил генерации кода хранятся в БД, при этом пользователь может добавлять/удалять свои варианты правил, а также иметь доступ к правилам других пользователей и к системным вариантам правил.
Генерация кода таже должна поддерживать преобразование кода «вычислителя» формул в соответствии с правилами (синтаксисом) выходного языка. Для это предполагается реализация промежуточного компонента, преобразующего формулы вычислителя в xml-документ.
Этап 6. Написание интерпретатора Интерпретатор обеспечивает пошаговое или непрерывное (потоковое) исполнение дракон-программы. В состав интерпретатора входят исполняющий модуль и отладчик.
Предполагаемая функциональность исполняющего модуля: выполнение одного шага дракон-программы (обработка икона), выполнение готового блока целиком. При исполнении программы текущий икон (блок) визуально выделяется. Исполняющий модуль также обеспечивает интерактивный диалог с пользователем.
Отладчик предоставляет возможность установки точек останова, наблюдения и инспектирования параметров диаграммы или её частей.
На этом этапе также предполагается интеграция интерпретатора с «вычислителем» формул. Исполняющий модуль реализует протокол взаимодействия с «вычислителем» формул. Отладчик должен предоставлять возможность инспектирования/изменения переменных в формулах и результатов вычислений во время исполнения программы. Результаты выполнения можно просмотреть в самой Дракон-схеме, включив режим, когда исходные формулы в блоках заменяются на формулы с вычисленными значениями. Эти формулы берутся из лога вычислителя.
Этап 7. Локализация Модуль должен обеспечивать локализацию. Информацию о выбранном языке пользователя можно получить из базы данных. В ней для каждого пользователя сохраняется информация о том, каким языком пользуется пользователь. А именно, название языка в .NET, локализованное название и на английском языке, LCID, (например для английского языка: en-US, English (United States), 1033).
Следует локализовать следующие объекты:
•Все диалоги.
•Базовые элементы в палитре.
•Названия пользовательских схем, кусков схем и пр. будут сохраняться в глоссарии. Все пользовательские объекты блок-схем, которые имеют названия, должны ссылаться на глоссарий, а не хранить название в себе. Структура глоссария создана. Описание присутствует в БД - диаграмма Glossary.
http://docs.google.com/Doc?id=dfq3gh9w_35dhvqvhПрошу высказать мнения. Это серьезно?Кто это писал? Я не смог узнать.
Просьба! Если Вы сможете расшифровать URL или как-то иначе, в общем, помогите узнать, КТО ЭТО ПИСАЛ?Указанная мной ссылка немедленно исчезла. Чтобы сохранить ее для истории даю ссылку на сохраненную копию:
http://hghltd.yandex.net/yandbtm?url=ht ... FbB8XcY%3D