Создание режима быстрого прототипирования в CASE-системе QReal

Также следует отметить, что технология Eclipse GMF очень тесно связана с платформой разработки Eclipse и требует для своей работы многочисленных библиотек периода исполнения.

MS DSL Tools

Пакет DSL Tools входит в состав Visual Studio SDK. Он устанавливается в виде надстройки к Visual Studio и используется исключительно как составная часть этой среды разработки. При создании solution автоматически создаются два проекта - Dsl и DslPackage. Dsl предназначен для хранения информации о метамодели, а DslPackage - для хранения настроек пользовательского интерфейса создаваемого редактора.

Рассмотрим, как происходит создание предметно-ориентированного визуального языка с точки зрения пользователя:

1.       Создание метамодели нового предметно-ориентированного языка.

o         Разработка концептуальной метамодели с помощью диаграмм классов UML. На этом этапе определяются основные концепции нового языка. Для создания диаграммы классов можно использовать любой UML-инструмент. Теоретически, DSL Tools предоставляет возможность создавать с его помощью диаграммы классов, но графический редактор DSL Tools не сильно удобен для использования и имеет ряд недостатков. Так, к примеру, все связи обозначаются специальными классами, что резко увеличивает объем спецификации.

o         Перенос концептуальной модели в DSL Tools. Пользователь получает метамодель будущего редактора, выполненную в DSL Tools.

2.       Разработка редактора

o         Дополнение созданной на предыдущем этапе метамодели необходимыми свойствами, определяющими наш будущий редактор. Задаются настройки пользовательского интерфейса. С помощью вставок на C# можно определить дополнительные свойства редактора тогда, когда не хватает стандартных средств DSL Tools.

o         Задание собственных правил валидации новых визуальных моделей.

o         Создание генерационного модуля, который будет выполнять генерацию по моделям в созданном редакторе.

3.       Валидация и генерация

o         Валидация. Проверяется согласованность и корректность элементов метамодели и их атрибутов.

o         Генерация кода целевого редактора. Код генерируется в тексты на языке C#. После компиляции этого кода средствами Visual Studio пользователь получает готовый редактор.

Как и в случае с Eclipse GMF, при использовании MS DSL Tools пользователь будет вынужден совершать достаточно много трудоемких действий, если появится необходимость изменить уже созданный редактор.

MetaEdit+

MetaEdit+ разрабатывался в рамках научно-исследовательских проектов Syti и MetaPHOR в University of Jyväskylä в период с 1988 по 1995 год. Коммерческая версия программы доступна с 1993 года[11][12].

Благодаря использованию подхода, основанного на интерпретации метамоделей, а не на генерации, технология MetaEdit+ позволяет вносить изменения в метамодель во время работы системы.

Процесс создания нового редактора выглядит так:

1.       Определение концепций предметной области.

2.       Создание соответствующих графических представлений (с помощью встроенного графического редактора), задание свойств.

3.       Задание связей между элементами.

4.       Генерация DSL-редактора.

Существенное отличие от рассмотренных выше технологий заключается в том, что для внесения изменений в метамодель не требуется закрывать приложение и проходить все этапы создания редактора снова. По сути, пользователь имеет в распоряжении два открытых приложения, одно из которых - метаредактор, другое - используемый DSL-редактор. Изменения, внесенные в метамодель, автоматически отобразятся в редакторе. Пользователь имеет возможность как добавлять новые элементы, так и изменять их внешний вид.

Подобное решение уже очень близко к тому, что хотелось бы получить в итоге. В текущей версии QReal эта функциональность уже реализована. Но есть ряд недостатков, которые необходимо учесть.

1.       Платформа MetaEdit+ использует свой собственный формат файлов (MXT) для экспорта моделей.

2.       Пользователь по-прежнему вынужден работать отдельно с моделью и метамоделью. Несмотря на то, что изменения подхватываются автоматически, от пользователя требуется мыслить в рамках двух отдельных понятий: модели и метамодели.

В рамках данной дипломной работы ставится цель объединить редактирование модели и метамодели, тем самым избавив пользователя от необходимости разделять эти два уровня абстракции.

MetaLanguage

В 2008 году в межвузовском сборнике научных статей “Математика программных систем” была опубликована статья Л.Н.Лядовой и А.О.Сухова “Языковой инструментарий системы MetaLanguage”. В статье был подробно описан визуальный метаязык и его составляющие[4][7].

Процесс создания предметно-ориентированного языка с помощью технологии MetaLanguage описывается следующим образом:

1.       Создание/модификация метамодели

o         Задание конструкций языка

o         Задание соотношений между конструкциями языка

o         Задание ограничений на элементы метамодели

2.       Создание/модификация модели

o         Создание сущностей предметной области

o         Создание отношений между сущностями

3.       Валидация

o         Проверка ограничений, налагаемых на сущности

o         Проверка ограничений, налагаемых на отношения

4.       Генерация

o         Сохранение модели в формате XML

o         Генерация документации

Авторы статьи утверждают, что платформа MetaLanguage так же, как и MetaEdit+, позволяет динамически обновлять модель после внесения изменений в метамодель. К сожалению, в открытом доступе средство MetaLanguage отсутствует, поэтому оценить на практике его достоинства и недостатки не представилось возможным. Однако эта статья является ценной и заслуживающей внимания, так как она свидетельствует о том, что исследовании в данном направлении велись, и эта тема вызывала интерес.

Встроенный метаредактор в QReal

              На момент написания диплома в системе QReal уже был реализован встроенный метаредактор. Он предоставлял пользователю богатый инструментарий для внесения изменений в существующие метамодели и создания новых. Созданные в нем метамодели по команде автоматически генерировались в код на С++ - плагин, в котором хранилась вся информация о метамодели, и который использовался при загрузке и в процессе работы редактора. Процесс создания метамодели с помощью встроенного метаредактора удобен и нагляден для пользователя.

              Использование метаредактора удобно в том случае, если пользователь решает задачу, требования к которой полно сформулированы к моменту начала решения. В таком случае требуется лишь формализовать и оформить решение. Предполагается, что еще до начала работы над задачей известно, какие сущности понадобятся, и какими свойствами они будут обладать. В таком случае в метаредакторе создается полный язык описания будущего редактора и генерируется соответствующий плагин. После этого пользователь может начинать работу с редактором. При внесении изменений в метамодель потребуется перегенерация редактора.

              Однако на практике чаще приходится сталкиваться с задачами, условия которых могут изменяться в процессе их решения. В таком случае разработчики сначала пытаются подойти к решению задачи неформально, определив общие направления и примерные способы ее решения. В связи с отсутствием четкого представления об условиях задачи, разработчику тяжело сразу определить необходимые сущности, которые могут быть использованы  для решения и ему легче мыслить абстрактно. Позже, по мере уточнения условий и оформления решения, создаваемый метаязык будет уточняться и дополняться. Использование метаредактора в таких задачах будет замедлять работу, так как пользователю придется постоянно переключаться между редактором и метаредактором, а также потребуется постоянная перегенерация метамодели. Внесение большого количества мелких изменений будет требовать от разработчика усилий, не пропорциональных получаемому результату.

              Использование для решения подобного вида задач метамоделирования «на лету» и режима быстрого прототипирования может значительно сократить время работы и позволить разработчику при использовании системы сконцентрироваться на самой задаче, а процесс создания инструментария сделать максимально быстрым и легким.

Предлагаемое решение             

Создание интерпретируемых метамоделей

Генерация моделей в QReal

Как и в большинстве современных MetaCASE-средств, метамодель в QReal хранится в текстовом виде в формате XML. В метамодели содержится полная информация о будущей модели:

        набор свойств элемента

        графическое представление элемента

        свойства отображения элемента

        соотношения между элементами

        свойства, необходимые для валидации моделей

Пользователь имеет возможность изменять метамодель либо путем внесения изменений в соответствующий xml файл метамодели, либо используя реализованный в QReal метаредактор. Метаредактор позволяет загрузить существующую метамодель, внести необходимые изменения (есть возможность изменить все имеющиеся в xml свойства) и сохранить полученную метамодель в формате xml.

Для задания графического представления элемента можно использовать любое средство, позволяющее работать с векторной графикой и, как следствие, способное сохранять рисунок в формате SVG (к примеру, Corel Draw). Также можно воспользоваться встроенным в QReal редактором фигур. Редактор позволяет как загружать имеющиеся рисунки в формате SVG (XML), так и создавать новые. Пользовательский интерфейс редактора интуитивно понятен и схож с пользовательским интерфейсом приложения Paint. Готовый рисунок можно сохранить в формате SDF и использовать при редактировании метамодели.

Информация о графическом представлении элемента хранится в файле метамодели в формате SDF. Этот формат был создан в рамках одной из курсовых работ, как расширение имеющегося формата SVG. Он позволяет задавать дополнительные графические свойства элемента, такие как масштабируемость, список доступных для редактирования текстовых элементов и пр.

Во время компиляции приложения с помощью xml-парсера из файла метамодели генерируется исходный код на С++ – плагин. В плагине присутствует вся информация, имеющаяся в метамодели, в том числе и информация о графическом представлении.

Во время запуска приложения библиотечные файлы плагинов используются для загрузки редакторов. Редактор запрашивает у загруженного плагина информацию о списке диаграмм, элементов диаграммы, типов и свойств элементов, графическом представлении элементов. Эта информация используется для загрузки палитры и редактора свойств:

        палитра элементов представляет собой список элементов с иконками, которые можно с помощью мыши переместить на сцену. При этом создается новый элемент с заданным типом, которому присваивается логический и графический идентификатор

        редактор свойств элемента представляет собой список свойств выбранного на сцене элемента. Свойства могут быть доступными для редактирования (имя элемента, комментарий, и.т.д.) и неизменяемыми (графический и логический идентификатор, тип)

Информация о графическом представлении элементов используется для рисования иконок и отображения элементов на сцене.

Существенным недостатком использования плагинов является то, что при изменении метамодели требуется перегенерация плагинов. А так как генерация происходит в момент компиляции, пользователю требуется исходный код приложения. После перегенерации обновленные файлы плагинов будут содержать все изменения.

Для того чтобы предоставить пользователю возможность работать в режиме быстрого прототипирования, а также избавить его от необходимости использования исходного кода, было принято решение перейти к концепции интерпретируемых метамоделей.

Интерпретируемые метамодели

Основное отличие концепции интерпретируемых метамоделей от концепции генерируемых метамоделей заключается в том, что интерпретация моделей происходит непосредственно во время работы приложения, в то время как генерация обязана завершиться до начала работы. В результате анализа архитектуры QReal было выяснено, что существующую систему плагинов можно использовать и для интерпретации метамоделей. Новый “метаплагин” должен полностью повторять реализацию генерирующихся плагинов, только информация должна получаться не во время компиляции, а при загрузке приложения. С точки зрения пользователя это выглядит так: после загрузки приложения, пользователь получает возможность загрузить определенную метамодель в режиме быстрого прототипирования. Пользователь выбирает xml файл метамодели, в этот момент происходит разбор файла метамодели, и вся информация из него загружается в  соответствующий метаплагин. Графическое представление элементов также генерируется во время разбора файла метамодели. Далее этот метаплагин используется так, как использовались сгенерированные плагины в стандартном режиме работы.

Таким образом, мы решим часть задачи - избавим пользователя от необходимости использовать исходный код приложения для генерации новых плагинов. Теперь в любой момент времени пользователь имеет возможность загрузить текущую версию плагина. Если плагин будет изменен - достаточно будет перегрузить редактор.