V Международная студенческая научная конференция Студенческий научный форум - 2013

Введение

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

Чаще всего при разработке программного обеспечения используются универсальные языки моделирования, такие как язык UML [1]. Однако у всех универсальных языков моделирования есть ряд недостатков. Так, они оперируют сильно ограниченным набором элементов. Например, UML использует термины «класс», «ассоциация», «агрегация» и т.п. [1]. Но в реальных областях существует множество понятий, которые не всегда можно адекватно отобразить на термины языка.

Эти недостатки привели к появлению нового подхода к моделированию. Этот подход предполагает разработку специфического (предметно-ориентированного) языка (DSL) моделирования для каждой конкретной предметной области [6]. Такой язык может разрабатываться в виде модели (которая будет называться метамоделью или формализмом) на некоем универсальном языке моделирования (метаязык). При разработке метамодели достаточно лишь описать используемые в области понятия и связи между ними. Логику работы с этими объектами нужно описывать уже в рамках разработки модели. Причем использование в качестве языка моделирования предметно-ориентированного языка позволяет без проблем привлечь к этому процессу экспертов. Однако, для работы даже в рамках одной задачи часто необходимо использовать несколько моделей, описанных на разных DSL. Разработчик вынужден изучать несколько языков вместо одного универсального.

Существует ряд средств (DSL-инструментариев), позволяющих строить модели предметной области и модифицировать их, причем не только вручную, но и автоматически. Но все такие средства имеют свои недостатки [4]. Таким образом, встает задача разработки DSL-инструментария, в котором были бы устранены эти недостатки.

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

Согласно определению комитета IEEE POSIX 1003.0 [17],

«Открытая система – это система, реализующая открытые спецификации на интерфейсы, службы и форматы данных, достаточные для того, чтобы обеспечить:

• возможность переноса (мобильность) прикладных систем, разработанных должным образом, с минимальными изменениями на широкий диапазон систем;

• совместную работу (интероперабельность) с другими прикладными системами на локальных и удаленных платформах;

• взаимодействие с пользователями в стиле, облегчающем последним переход от системы к системе (мобильность пользователей).»

Открытость системы – важное свойство, наличие которого позволяет разработчику переиспользовать уже существующие программные продукты (интероперабельность) и переносить свой продукт на другие платформы, а пользователю – постепенно обновлять компоненты системы, не утрачивая работоспособности системы в целом. Для разработки нового DSL-инструментария необходимо проанализировать открытость существующих решений и определить те их свойства, которые делают эти системы открытыми или закрытыми. Если окажется, что какие-то функции существующих систем можно использовать в своей, то нет необходимости реализовывать этот функционал. Достаточно лишь сделать свою систему поддерживающей интерфейсы существующих систем и воспользоваться имеющимися возможностями.

В этой статье рассматриваются наиболее мощные и популярные DSL-инструментарии с точки зрения открытости. Обычно выделяют следующие основные свойства открытых систем [2]:

• расширяемость/масштабируемость (extensibility/scalability),

• мобильность (или переносимость – portability),

• интероперабельность (interoperability) и интегрируемость (т.е. возможность комплексирования новых программных систем на основе использования готовых компонентов со стандартными интерфейсами и способность к взаимодействию с другими системами).

Мы рассмотрим следующие DSL-инструментарии: AToM3, VIATRA2, MetaEdit+, Microsoft Tools for Domain-Specific Languages и Eclipse Graphical Modeling Framework.

Функциональность этих инструментариев сильно пересекается. Все они имеют в своей структуре редакторы графов-моделей, загрузчики моделей и ядро трансформаций моделей. Рассмотрим эти элементы с позиций наличия/отсутствия вышеперечисленных свойств открытой системы.

Расширяемость

Расширяемость – это такое свойство программной системы, позволяющее с легкостью повысить возможности системы, не нарушая ее работоспособности [2].

Рассмотрим ряд DSL-инструментариев с позиции их расширяемости.

AToM3

AToM3 – DSL-инструментарий, позволяющий производить разработку в различных формализмах[9,10]. Для этого система использует методику метамоделирования. Сначала пользователь описывает метамодель (формализм), а за тем строит на ее основе модель предметной области. Среди встроенных формализмов есть ER-диаграммы, диаграммы классов UML, сети Петри, конечные автоматы и другие. Так же, этот инструментарий позволяет модифицировать построенные модели при помощи графовых грамматик [10].

AToM3 полностью написан на Python, его исходный код открыт. Это, теоретически, позволяет вносить любые изменения в работу системы. Однако такой подход весьма неэффективен и небезопасен.

Разработчики AToM3 снабдили систему специальным API, позволяющим как управлять разработкой сложных (мета)моделей и графовых грамматик, так и дополнять систему своими плагинами. Такие плагины должны быть написаны на Python. Предоставленный API позволяет модифицировать как реакцию системы на редактирование модели, так и алгоритм применения графовой грамматики путем изменения порядка правил.

В целом, AToM3 API предоставляет богатые возможности для расширения системы.

VIATRA2

VIATRA2 – фреймворк, предназначенный для предоставления поддержки в создании и модификации моделей на всем протяжении разработки [7,13]. Этот фреймворк предоставляет пользователю редактор моделей, язык описания трансформаций и высокопроизводительный движок трансформации моделей. Фреймворк позволяет выполнять вертикальные трансформации моделей и генерировать код на Java.

VIATRA2 является частью системы Eclipse и при необходимости может использовать плагины этой системы.

Фреймворк VIATRA2 предоставляет обширный API [11], предоставляющий доступ ко многим Java-методам фреймворка. По словам разработчиков, чаще всего этот API используется для описания на Java алгоритма выполнения ряда рутинных операций, таких как открытие модели, исполнение трансформации и сохранение результатов.

Но мощность API такова, что с его помощью можно расширить количество поддерживаемых системой формализмов. Так, изначально система поддерживала лишь UML, но сейчас существуют плагины для работы с UML2, BPEL и других языков описания бизнес-процессов, а так же различные DSL, базирующиеся на XML или EMF.

MetaEdit+

Коммерческая технология MetaEdit+ разрабатываемая финской компанией MetaCase является набором средств, предназначенных для создания DSL [14].

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

Средство MetaEdit+ предоставляет свой API (MetaEdit+ API) [15]. Он позволяет программно обращаться к данным модели и функциям MetaEdit+.

Типичные сценарии использования включают:

• симуляцию, т.е. изменение моделей при выполнении кода;

• трансформацию моделей, т.е. применение к нескольким моделям одних и тех же изменений,

• сравнение моделей,

• импорт/экспорт моделей,

• проверку и сопровождение моделей (генерацию документации).

Microsoft Tools for Domain-Specific Languages

Microsoft Tools for Domain-Specific Languages (DSL Tools) – это удобное средство для создания, изменения и использования DSL. Является дополнением к MS Visual Studio [8,16].

Являясь продуктом Microsoft, не позволяет пользователям вносить какие-то изменения в свою работу – у этого средства нет ни API, ни еще какой-либо возможности писать и подключать свои плагины.

Eclipse Graphical Modeling Framework

Eclipse Graphical Modeling Framework (EGFM) – технология, предоставляющая возможность создавать и трансформировать графовые модели, основанная на Eclipse Modeling Framework (EMF) и Graphical Editing Framework (GEF) [18]. Технология GEF отвечает за визуализацию моделей, а EMF предназначена для проектирования приложений, использующих модели сложно устроенных БП. Изначально эти технологии разрабатывались независимо друг от друга, для их объединения и был создан фреймворк EGFM.

И EMF, и GEF имеют свой API [12,18], что дает возможность расширять эту систему. С использованием этого API можно автоматизировать работу с моделями, добавлять свои функции в редакторы моделей и модифицировать алгоритмы трансформации моделей.

Существует отдельный проект Graphiti, расширяющий возможности системы по созданию графических редакторов. Этот проект позволяет отделить создание редактора от самого фреймворка, сводя к минимуму необходимый уровень подготовки разработчиков – им не обязательно разбираться во всем EGFM. Так же, он позволяет реализовывать свои алгоритмы укладки графов [18], если это необходимо.

Как и в VIATRA2, в EGFM можно добавлять поддержку новых формализмов и форматов файлов – для этого необходимо реализовать сервисы импорта/экспорта.

Мобильность

Мобильность подразумевает под собой возможность переноса системы на другую платформу с сохранением опыта и наработок пользователя [2].

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

• AToM3 написан на Python[9], для запуска системы необходим интерпретатор с этого языка. Таким образом, система AToM3 будет работать везде, где установлен такой интерпретатор. Пользователь даже не заметит, что что-то изменилось.

• VIATRA2 является дополнением к Eclipse [7] и требует для своей работы установленный Eclipse, а так же Java версии не ниже 1.6. Так как и Eclipse, и Java являются мультиплатформенными, перед разработчиками VIATRA2 даже не стояло задачи обеспечения мобильности своей системы – это получилось автоматически.

• Система MetaEdit+ является мультиплатформенной, существуют версии этой системы, которые поставляются под Windows, Linux и Mac OS X.

• DSLTools, являясь частью MS Visual Studio, может использоваться только на компьютерах под управлением Windows.

• Eclipse Graphical Modeling Framework, как и VIATRA2 является дополнением к Eclipse [12] и требует для своей работы установленный Eclipse. Соответственно, эта система является полностью платформонезависимой.

Интероперабельность

Интероперабельность — это способность продукта или системы, интерфейсы которых полностью открыты, взаимодействовать и функционировать с другими продуктами или системами без каких-либо ограничений доступа и реализации [2]. Рассмотрим DSL инструментарии с позиций использования с разными IDE и с разными программами создания моделей (в том числе и друг с другом), а так же в свете интегрирования разрабатываемого инструментария.

AToM3

Интероперабельность DSL-инструментария AToM3 весьма невысока. Разработчики инструментария не предоставили каких-либо средств интеграции продукта с другими системами. Единственное, что можно получить от инструментария – сгенерированный по модели код [10].

Однако в теории возможно самостоятельное расширение возможностей инструментария за счет наличия API и открытого формата хранения моделей.

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

VIATRA2

Являясь дополнением к Eclipse [7], система VIATRA2 очень тесно интегрирована с этой IDE. VIATRA2 интегрируется в Eclipse на уровне интерфейса – работа с моделями происходит так же как и с кодом в IDE. Но поддержка других IDE отсутствует.

VIATRA2 может взаимодействовать с другими средами разработки моделей (возможен импорт/экспорт моделей), если те поддерживают форматы, используемые в VIATRA2. Такими форматами являются UML, UML2, BPEL, а так же целый ряд DSL, хранимых в соответствии со стандартами XML [11,13]. Таким образом, можно загрузить созданную где-либо модель, трансформировать ее с использованием движка VIATRA2 и выгрузить обратно. Так же, по словам разработчиков, их система часто применяется как мощный визуализатор моделей – некоторые системы, позволяющие строить лишь текстовые модели, устанавливают с собой VIATRA2 и пользуются ее визуализатором [7].

Разработчики системы оценивают ее возможности в плане интероперабельности как весьма высокие [11].

Для интеграции VIATRA2 и разрабатываемого инструментария необходимо использовать в своем инструментарии формат, поддерживаемый VIATRA2. Наиболее адекватным будет использование стандартов XML – инструментарий должен позволять создавать разные DSL и нельзя гарантировать, что какой-то универсальный формат подойдет для любого языка.

MetaEdit+

Наличие MetaEdit+ API [13] позволяет интегрировать эту систему с другими, например, с редакторами моделей и средствами тестирования.

Разработчики MetaEdit+ так же предоставляют ряд плагинов к внешним системам, позволяющим тесно связать их с MetaEdit+. Так, плагин для MS Visual Studio позволяет связать модели в MetaEdit+ с сгенерированным кодом в MS Visual Studio [14]. При изменении кода – обновляется модель и наоборот. Из среды MS Visual Studio можно просматривать иерархии моделей, редактировать графы-модели, запускать различные генераторы и трансформировать модели. Из среды MetaEdit+ можно генерировать код в проект Visual Studio и запускать и отлаживать полученный проект.

Аналогичный плагин предлагается для IDE Eclipse.

MetaEdit+ использует закрытый формат моделей. Однако, существует ряд плагинов, позволяющих системе читать модели других форматов, в том числе, описанных на XML. Для интегрирования разрабатываемого инструментария и MetaEdit+, как и в случае с VIATRA2, необходимо использовать такой формат.

DSLTools

Данное средство может интегрироваться лишь с одной IDE, а именно с MS Visual Studio.

Построенные модели DSLTools сохраняет в XML файл [8]. Это дает возможность настроить, например, VIATRA2 так, чтобы построенные в VIATRA2 модели открывались в DSLTools. Однако, в DSLTools в модель включается код на C# [16], другие системы не смогут адекватно обработать его и будут вынуждены проигнорировать.

Таким образом, интероперабельность этой системы крайне низка.

Eclipse Graphical Modeling Framework

Аналогично VIATRA2, EGFM является дополнением к Eclipse [12]. EGFM интегрируется в Eclipse на уровне интерфейса – работа с моделями происходит так же как и с кодом в IDE. Поддержка других IDE отсутствует.

Интеграция с другими системами создания моделей обеспечивается путем создания сервисов экспорта/импорта. Изначально же система понимает только модели, описанные в тех форматах, которые поддерживает EMF, а именно [12,18]:

• аннотированным Java-кодом,

• UML,

• XML-схемой,

• моделью формата Rational Rose.

По словам разработчиков, это достаточно широкий спектр моделей, мало какое средство моделирования не позволяет сохранять модель ни в один из этих форматов.

Как и предыдущие системы, EGFM поддерживает XML-описания моделей. Это означает, что при разработке собственного инструментария необходимо использовать такой формат.

Описание архитектуры инструментария с точки зрения открытости

В работе [3] была предложена архитектура инструментария, представленная на рисунке 1. Так же в этой работе описан созданный прототип инструментария.

Рис. 1. Архитектура инструментария

Система содержит следующие компоненты:

• Загрузчик графов, загрузчик грамматик – служат для сохранения и загрузки данных (хост-графа и графовой грамматики) во внешней памяти. Информация хранится в типизированных файлах в сериализованном виде.

• Редактор графов, редактор грамматик – служат для создания и изменения модели и графовой грамматики пользователем. В качестве редактора графов использован компонент MindFusion.

• Интерпретатор – применяет загруженную в память грамматику к хост-графу.

Для обеспечения открытости инструментария необходимо перевести загрузчики графов и грамматик на использование общепринятых открытых форматов, основанных на XML. Это позволит взаимодействовать с другими системами путем переоткрытия файлов, созданных в одном инструментарии в рамках другого.

Возможно организовать переиспользование в своем инструментарии редакторов графов-моделей, реализованных в других системах, например, в VIATRA. Однако, в работе [5] показано, что наиболее адекватным способом представления моделей является не просто аппарат графов, а аппарат метаграфов. Редакторы существующих систем ориентированы на создание графов, их придется дорабатывать для применения в нашей задаче. Учитывая наличие своего прототипа, у которого нам полностью доступен исходный код, намного проще доработать редактор, реализованный в нем.

Для удовлетворения требованиям открытости, в инструментарии необходимо реализовать API. Этот API должен предоставлять возможность модифицировать следующие функции инструментария:

• LoadModel/SaveModel и LoadGrammar/SaveGrammar загрузчиков для организации расширения числа поддерживаемых форматов файлов;

• ApplyGrammar (функция, производящая трансформацию модели на основе грамматики) для полной замены алгоритма трансформации;

• BuildEditor – за счет этого пользователь сможет создать свой редактор, адаптированный для предметной области.

API должен также позволять назначать свои обработчики следующих событий инструментария:

• открытие/закрытие файла – в этот момент возможно модифицировать модель с тем, чтобы расширить число поддерживаемых формализмов;

• различные действия по редактирования моделей и грамматик в редакторах для автоматизации процесса построения;

• выбор подграфа, к которому будет применяться правило и

• начало применения правила грамматики к модели для модификации процесса трансформации.

Такой API позволит инструментарию быть расширяемым и повысит его потенциальную интероперабельность.

Заключение

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

По итогам анализа было выявлено, что некоторые возможности существующих систем могут быть доступны извне. Наиболее открытой из рассмотренных систем в этом плане является система VIATRA. Есть возможность воспользоваться имеющимися в ней редакторами и механизмом трансформации. Однако она позволяет производить только вертикальные трансформации, а использование ее редакторов привязывает нас к использованию IDE Eclipse. Вдобавок, редакторы VIATRA необходимо дорабатывать с тем, чтобы можно было создавать метаграфы-модели. Это является достаточно значительными недостатками.

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

Список литературы

1. Буч Г., Рамбо Д., Джекобсон А. Язык UML. Руководство пользователя, 2-е издание.: пер. с англ. М.: Издательство «ДМК Пресс», 2007. – 496 с.

2. Лядова Л.Н., Ланин В.В., Шаврин С.М. Стандарты и технологии создания открытых информационных систем: учеб.-метод. пособие / Перм. ун-т. – Пермь, 2007.

3. Лядова Л.Н., Серый А.П., Сухов А.О. Методы и средства разработки языков описания трансформаций предметно-ориентированных языков // Технологии разработки информационных систем ТРИС-2012. III Международная научно-техническая конференция. Материалы конференции.

4. Серый А.П. Методы и средства разработки инструментария для создания языков описания трансформаций предметно-оринетированных языков : [Электронный документ] (http://rae.ru/forum2012/219/2705). Проверено 28.12.2012.

5. Сухов А.О. АНАЛИЗ ФОРМАЛИЗМОВ ОПИСАНИЯ ВИЗУАЛЬНЫХ ЯЗЫКОВ МОДЕЛИРОВАНИЯ // Современные проблемы науки и образования. – 2012. – № 2; URL: www.science-education.ru/102-5655 (дата обращения: 10.11.2012).

6. Фаулер М. Предметно-ориентированные языки программирования.— М.: Изд. дом «Вильямс», 2011.

7. Balogh A., Varro D. Advanced Model Transformation Language Constructs in the VIATRA2 Framework: [Электронный документ] (http://static.inf.mit.bme.hu/pub/varro/2006/sac2006_vtcl.pdf). Проверено 28.12.2012.

8. Creating Domain-Specific Languages [Электронный документ] (http://msdn2.microsoft.com/en-us/library/bb126259(VS.90).aspx). Проверено 28.12.2012.

9. De Lara J. AToM3 programming tutorial: the AToM3 Python API: [Электронный документ] (http://atom3.cs.mcgill.ca/tutorials.dtml). Проверено 28.12.2012.

10. De Lara J., Vangheluwe H., Alfonseca M. Meta-modelling and graph grammars for multi-paradigm modelling in AToM 3 // Software and Systems Modeling. – 2004. – №3. – с.194-209.

11. Gönczy L., Kovács M., Varró D., Modeling and Verification of Reliable Messaging by Graph Transformation Systems // Electronic Notes in Theoretical Computer Science Volume 175, Issue 4, 9 July 2007, Pages 37–50 // Proceedings of the Workshop on Graph Transformation for Concurrency and Verification (GT-VC 2006)

12. Graphical Modeling Framework: [Электронный документ] (http://www.eclipse.org/gmf). Проверено 28.12.2012.

13. Horváth A., Varró D., "Dynamic constraint satisfaction problems over models" // Software and Systems Modeling, vol. 11, issue 3, pp. 385-408, 2012.

14. IMPORTING MODELS WITH METAEDIT+ API: [Электронный документ] (www.metacase.com/papers/importing_API.pdf). Проверено 28.12.2012.

15. Juha-Pekka T., Matti R. MetaEdit+: defining and using domain-specific modeling languages and code generators: [Электронный документ] (http://portal.acm.org/citation.cfm?id=949365). Проверено 28.12.2012.

16. MSDN Documentation for VMSDK (DSL Tools) [Электронный документ] (http://msdn.microsoft.com/library/bb126259.aspx). Проверено 28.12.2012.

17. Open System Handbook. A Guide To Building Open System. Digital Equipment Corporation (USA). 1991.

18. Volker A., Wegert V. Integrating EMF and GMF Generated Editors

Научный руководитель: Доцент кафедры математического обеспечения ВС, к.ф.-м. н., доцент Л.Н. Лядова

Код для цитирования: Скопировать