Cемейства программных продуктов. DSM-подход

Технология Eclipse/GMF.

Среда Eclipse - это кросс-платформенная интегрированная среда разработки программного обеспечения с открытыми исходными кодами. Главный язык разработки, поддерживаемый этой средой, - Java, хотя имеется также поддержка C++, Perl, Fortran и др. На базе этой среды создаются различные дополнительные технологии, одна из которых - Eclipse Graphical Modeling Framework ( GMF ) [10.14], первая версия которой появилась в середине 2006 года.

Технология GMF предназначена для быстрой разработки графических средств, главным образом, интегрируемых в Eclipse. Она является Open Source разработкой и развивается, в основном, специалистами компаний IBM и Borland. GMF интегрирует две широко используемые и известные Eclipse-библиотеки - Eclipse Modeling Framework ( EMF ) и Graphical Editing Framework ( GEF ). Архитектура DSM-пакета с применением GMF строится на основе MVC-шаблона. Для создания уровней представления и контроллеров используется технология GEF, для создания моделей - технология EMF.

Библиотека GEF состоит из двух частей: модуля org.eclipse.draw2d (далее - OED^{3Эта аббревиатура не является стандартной, а предложена нами для удобства ссылок в тексте лекции на этот модуль.} ), встраиваемого в Eclipse, и самой базовой библиотеки GEF. Модуль OED предоставляет средства программного создания и обработки графических объектов. В его состав входят менеджеры размещения графических объектов, механизм событий, палитра стандартных объектов, средства их комбинирования для создания более сложных композитных графических объектов, средства установления соединений между графическими объектами, функциональность Drag & Drop, средства работы со слоями изображений и пр. Данный модуль может использоваться автономно, как графическая библиотека.

Графические редакторы, как правило, визуализируют некоторую информацию, существующую и обрабатываемую отдельно (уровень модели шаблона MVC ) - например, визуализация параллельных процессов, каких-нибудь других сложных структур данных. Эта визуализируемая область в понимании модуля OED представляется как модель объектов - экземпляров Java-классов. Чтобы созданный с помощью OED графический редактор мог эффективно с ними взаимодействовать, между ними должна существовать "прослойка", отвечающая за их синхронизацию. Такие "прослойки" создаются при помощи библиотеки GEF. Для создания классов-контроллеров GEF предоставляет набор базовых классов, которые должны быть использованы разработчиками при реализации слоя синхронизации.

Графические редакторы на основе GEF можно создавать для любых моделей, однако наибольшей эффективности в смысле DSM-подхода можно достичь, используя технологию GEF в паре с EMF.

Библиотека EMF предназначена для создания приложений, использующих различные модели бизнес-объектов, в частности, объектов предметной области визуального моделирования - например, абонент телефонной станции, концентратор, коммутатор и пр. (вспомните лекцию про системы реального времени). Эти бизнес-объекты моделируют некий срез реальности, инкапсулируют в себе определенные свойства и связи, а также собственное поведение. Еще они должны уметь сохранять себя (т. е. обладать свойством персистентности - вспомните лекцию про базы данных) и обратно - загружать себя в оперативную память.

Внутренняя реализация таких моделей (исходный код для их run-time классов) производится с помощью средств генерации EMF по схеме модели, описанной с помощью библиотеки Ecore^{4Ecore - библиотека Eclipse для описания метамоделей.}. Схема модели может также импортироваться из XMI^{5XMI (XML Metadata Interchange) - стандарт OMG, описывающий обмен метаданными в формате XML} -документа (как созданного "вручную", так и сгенерированного другими средством, например, при экспорте UML-модели из пакета IBM Rational Rose), из набора аннотированных Java-интерфейсов, из XML-схемы. Механизм генерации рассчитан на то, что сгенерированный код будет расширяться "вручную", с сохранением пользовательских изменений при последующих повторных генерациях. Сгенерированные таким образом модели имеют ряд важных функций: механизм сохранения/загрузки в формате XMI , базовые средства ("заглушки") для реализации механизма валидации моделей, удобный программный интерфейс для манипуляции объектами модели. Дополнительно, с помощью входящего в состав EMF модуля EMF.Edit, может быть сгенерирован уровень адаптеров (аналог контроллеров GEF ) для связи с элементами пользовательского интерфейса, обеспечивающими редактирование EMF-моделей.

Процесс разработки DSM-пакетов на основе GMF изображен на рис. 10.3 и состоит из следующих шагов.

1. Разработка доменной модели (domain model) - модели целевой предметной области, для которой предназначается создаваемый графический редактор. Эта модель является метамоделью нового DSL. В случае разработки UML-редактора элементами доменной модели будут класс, случай использования, ассоциация и т.д. Доменная модель разрабатывается с помощью графического редактора GMF Ecore. Выходной файл с описанием модели - *.ecore.
2. Разработка графической модели (graphical definition) - описания графической нотации создаваемого языка. Например, для UML-редактора и элемента доменной модели "класс" элементом графической модели будет прямоугольник с меткой-строкой для имени класса, секциями для атрибутов и операций, иконкой и прочими графическими деталями. Выходной файл с описанием этой модели - *.gmfgraph.
3. Разработка модели инструментов (tool definition) - описания элементов панели инструментов будущего редактора (палитры графических объектов, списка действий, меню графических объектов и пр.). Например, для UML-ассоциаций можно использовать несколько различных кнопок на панели инструментов или одну, но с выпадающим меню. Выходной файл с описанием этой модели - *.gmftool.
4. Разработка модели соответствия (mapping model). Все предыдущие модели являются независимыми, формально никак не связаны друг с другом, каждая из них располагается в одном или нескольких отдельных файлах. В них определяется то, что может использоваться при построении диаграммного редактора, а что и как именно будет использоваться определяется в модели соответствия. Для элементов доменной модели определяются связи с графическим представлением, а также соответствующими инструментами. Например, для UML-класса будет указано, что для его отображения используется масштабируемый прямоугольник, который создается с помощью кнопки с именем "UML Class". Не все элементы из доменной модели могут попасть в модель соответствия, некоторые же могут использоваться по нескольку раз. Выходной файл этой модели - *.gmfmap.
5. Создание модели генератора (generator model) - описания, по которому производится генерация целевого графического редактора. Данная модель является промежуточным представлением будущего редактора. Она автоматически генерируется по модели соответствия и дополняется разработчиками "вручную". Примеры информации, содержащейся в ней: свойства редактора (его имя, расширение диаграммных файлов), настройки генератора редакторов GMF. Выходной файл модели - *.gmfgen.
6. Генерация кода целевого DSM-пакета.

Рис. 10.3. Схема работы с технологией Eclipse/GMF

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

Данная DSM-платформа является самой мощной из рассматриваемых в этой лекции. Фактически все, что умеют делать другие, умеет и она. Возможно, менее удобным образом, но умеет. Однако ее использование существенно затруднено отсутствием документации, громоздкостью и сложностью, а также частым выходом новых версий. Фактически, GMF находится еще в стадии интенсивного развития. Однако тем, кто желает создавать многофункциональные средства визуального моделирования, независимые от конкретных платформ разработки типа Microsoft Visual Studio и не "тянущие" за собой другие пакеты типа Microsoft Visio, можно смело рекомендовать технологию GMF.

В последней версии Together Control Center, вышедшей в октябре 2007 года, представлены созданные на базе GMF средства быстрой разработки графических редакторов, подобные Microsoft DSL Tools.

Технология Microsoft DSL Tools

Инициатива Microsoft под названием Software Factories является попыткой индустриализации процесса разработки ПО. Суть инициативы заключается в создании и использовании "фабрик" по разработке ПО для ускорения процесса разработки, придания процессу большей гибкости и минимизации затрат. В общем случае под фабрикой понимается комплекс средств на базе расширяемой среды разработки (например, Microsoft Visual Studio), который включает в себя DSM-инструменты, поддержку шаблонов проектирования и повторного использования компонентов, а также другие средства, облегчающие применения лучших практик для разработки определенного класса программных средств, в частности, семейств программных продуктов.

В рамках данной инициативы для реализации DSM-пакетов в среде Visual Studio 2005 был создан пакет Microsoft DSL Tools, входящий в Visual Studio SDK.

В состав платформы Microsoft DSL Tools входят: мастер проектов, создающий пустой проект нового DSL, средства описания и генерации моделей языков и их графических редакторов, а также средства поддержки.

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

Рис. 10.4. Пример метамодели в Microsoft DSL Tools

По описанной выше модели средствами Microsoft DSL Tools генерируется набор классов на языке C#, задающий новый графический редактор. Новый редактор может быть открыт в режиме отладки в новом экземпляре Microsoft Visual Studio или собран в инсталляционный пакет.

Дополнительная функциональность, такая как процедуры валидации моделей, создается программистом в "ручном" режиме в виде частичных классов (partial classes) .Net, расширяющих функциональность сгенерированных классов. Использование частичных классов гарантирует, что последующие изменения модели предметной области и перегенерация кода не уничтожат дополнительного кода, добавленного программистом.

Процесс разработки редактора может быть цикличным (итерация цикла представлена на рис. 10.5): изменение модели и настроек, генерация кода, добавление кода программистом, отладка, повтор цикла.

Рис. 10.5. Схема работы с пакетом Microsoft DSL Tools

Созданный DSM-пакет имеет полноценный пользовательский интерфейс. Он также умеет создавать и редактировать визуальные модели, имеет механизм сохранения моделей, процедуры валидации и возможность генерации различных артефактов (исходного кода, отчетов, конфигурационных файлов и т. д.) по моделям.

Данный пакет является надстройкой к Microsoft Visual Studio и бесплатно "скачивается" с сайта компании. Он позволяет создавать лишь надстройки к Microsoft Visual Studio. Реализовать с его помощью независимый от Visual Studio графический редактор невозможно. Однако если вы работаете в Microsoft Visual Studio и нуждаетесь в небольшом графическом редакторе, то лучшего средства, чем Microsoft DSL Tools, вам не найти.