Информационные модели устройств для IoT с Eclipse Vorto

Изучая стек технологических проектов Eclipse для направления Internet of Things (IoT) (http://iot.eclipse.org/), наткнулся на проект Eclipse Vorto. Это инструмент для создания информационных моделей разнообразных устройств в направлении IoT и генерации кода на их основе для различных платформ.

Vorto изначально разработан компанией Bosh

 Vorto = DSL + ToolChain + Model Repository + Code generators

 Технологический стек : Eclipse, ЕMF, XText, 

 

Eclipse Vorto решает задачу interoperability для IoT, направлении в котором 

должны взаимодействовать различные устройства на базе различных платформ.

 

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

вот в таком виде

Информационные модели устройств создаются с помощью Vorto ToolChain (на базе Eclipse) и публикуются в репозиторий Vorto. Таким образом создается репозиторий информационных моделей устройств, которые можно использовать в новых проектах. Пример репозитория Vorto доступен по ссылке

http://vorto.eclipse.org/#/

 

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

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

Кодо-генераторы также хранятся в репозитории Vorto. Для каждого устройства 

есть свой доступный список кодо-генераторов

http://vorto.eclipse.org/#/details/examples.functionblockmodels/Accelerometer/1.0.0

 

Идея создания платформенной-назависимых моделей с последующим приземлением на платформы за счет кодо-генерации стандартна. В случае с Eclipse Vorto интересно именно ее применение для направления Internet of Things.

Язык и инструмент для компонентной разработки ПО на основе моделей

Стоит ли для компонентной разработки использовать стандартный UML, его профили или предпочтительно использовать специализированный DSL?

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

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

http://wiki.eclipse.org/Papyrus_Software_Designer

 

Например на базе инструмента Papyrus для UML моделирования  есть целый ряд проектов для компонентного описания ПО 

- Papyrus Software Designer (http://wiki.eclipse.org/Papyrus_Designer), ранеe Papyrus Qompass

- Papyrus-RT (https://eclipse.org/papyrus-rt/)

- Papyrus RobotML (https://eclipse.org/papyrus/components/robotml/1.2.0/)

 

Для создания компонентной модели в этих инструментах используется профили UML: MARTE, UMLrt, RobotML и т.д. Это подход, когда обе модели создаются с помощью одного инструмента (например, Papyrus) и основаны на UML и его профилях. 

Для объектно-ориентированной модели чистый UML, наверное, лучший выбор. Он наиболее близок к объектно-ориентированному подходу современных объектно-ориентированных языков программирования. 

Но стоит задаться вопросом, а является ли обязательным использование профилей UML и инструментов моделирования на UML для создания компонентных моделей ПО. Или это может быть некий DSL для компонентной модели со специализированным инструментом для его редактирования?Такие инструменты часто разрабатываются для конкретной предметной области и поддерживают работу со специализированным DSL, а потому более удобны пользователям. Они также могут быть более просты и понятны для пользователей, чем универсальные инструменты моделирования.

 

Язык моделирования ROOM (из прошлого поста) можно восприниматься как специализированный инструмент с собственным DSL для описания компонентных моделей. Другие примеры инструментов с собственными DSL, разработанных на базе технологии Sirius, можно посмотреть в галерее на сайте проекта Sirius.

Технологии Eclipse EMF, GMF, Sirius, XText позволяют достаточно легко разрабатывать инструменты моделирования для работы со специализированными DSL.  Эти технологии гораздо эффективнее, чем инструменты кастомизации инструментов моделирования UML под конкртеный DSL.

Технология Sirius родилась в компании Thales по результатам попыток создания специализированного профиля UML и кастомизации инструмента (это была IBM Rational Rhapsody) для его поддержки. Спустя несколько лет в Thales пришли к выводу, что для создания специализированных языков моделирования лучше использовать не UML, а специализированную технологию. Так родился проект Sirius (позднее Eclipse Sirius).

 

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

Текстовый DSL для создания моделей

Использование текстовых DSL (Domain Specific Language - язык предметной области) для создания моделей может сделать инструменты моделирования ближе для программистов. Создаваемые модели могут анализироваться в графическом виде с использованием автоматического построения диаграмм.

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

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

Использование текстовых DSL для создания высокоуровневых моделей - для программиста
выглядит как использование более высоко-уровневого языка программирования.
Если DSL делает программистов более эффективными, а разрабатываемое ПО
более качественным, то почему бы и нет?

Разговоры о использовании текстовых DSL для создания формальных моделей
не прекращаются. Технология Xtext для создания текстовых DSL прокладывает
себе дорогу в жизнь.

Вот и в проекте Eclipse Papyrus идет разговор о целесообразности включения текстового DSL для создания UML моделей. Вот пост об этом
https://papyrusuml.wordpress.com/2016/09/16/me-as-text/

В рамках Eclipse есть еще один проект для создания формальных моделей,
который изначально был основан на текстовом DSL
Это проект Eclipse eTrice - Real time modeling tool
http://www.eclipse.org/etrice/

В качестве языка моделирования в eTrice выступает ROOM
(Real-Time Object Oriented Modeling).
https://en.wikipedia.org/wiki/Real-Time_Object-Oriented_Modeling
Это язык моделирования до эры UML, из которого в UML
перекочевали многие концепции.

ROOM более прост, чем UML, что делает его интересным в новом свете попыток
упрощения UML для реального использования. Данный язык также интересен
для создания более высокоуровневых компонентных моделей, для сущностей которых не всегда есть прямое соответствие в языке программирования (например для портов).
См. краткое описание сущностей ROOM и элементов DSL для их создания по ссылке
http://www.eclipse.org/etrice/documentation/release/room-concepts.html

Например, вот так выглядит описание следующей структуры на DSL в eTrice

Диаграммы в eTrince автоматически строятся на базе полученных
моделей. Для построения диаграмм используется проект
KIELER, который недавно превратился в Eclipse Layout Kernel (см. пост об этой технологии по ссылке ) Диаграммы могут использоваться не только для анализа, но и для создания моделей.

eTrice Getting Started C++
http://www.eclipse.org/etrice/documentation/release/tutorials.html#getting-started-c-

Автоматическое построение диаграмм Papyrus и Sirius (GMF)

Я писал ранее о технологии автоматического лэйоута диаграмм (http://trip-to-mbsd.blogspot.ru/2016/10/blog-post.html), которая появилась в Eclipse Modeling Project. Данную технологию уже интегрировали в Eclipse Papyrus - open source инструмент моделирования на UML и SysML. По аналогии, я тут же интегрировал данную возможность и в проект на базе Sirius. Диаграммы Papyrus и Sirius основаны на проект Eclipse GMF, для которых в ELK есть стандартная интеграция.

Это важное событие, так как на форматирование диаграмм уходит куча времени.

Для примера я попробовал создать в Papyrus диаграмму внутренней структуры

И применил к ней автоматический лэйоут. Вот результат.

И тоже самое я проделал для диаграммы определения блоков SysML

Автоматический layout можно настраивать с помощью представления Layout

Ниже инструкция как попробовать автоматический layout диаграмм в Papyrus

1. Установить Papyrus 2.0.1
http://www.eclipse.org/papyrus/download.html

2. Установить ELK в Papyrus
используя update site
http://download.eclipse.org/elk/updates/releases/0.1.0/

3. Установить интеграцию ELK с Papyrus
используя update site
http://download.eclipse.org/modeling/mdt/papyrus/updates/releases/neon/extra

4.Для применения автоматического layout из контекстного меню на диаграмме выбрать команду
Layout selection

5. Для настройки layout из контекстного меню на диаграмме выбрать команду
Show layout view

По аналогии с интеграцией ELK в Papyrus (см плагин https://git.eclipse.org/c/papyrus/org.eclipse.papyrus.git/tree/extraplugins/elk ) я достаточно просто подключил автоматический layout с помощью ELK к разрабатываемому нами инструменту моделирования на базе Sirius. Теперь будет достаточно просто добавить эту возможность и в Capella.

В общем не успел я написать о будущем, как оно наступило.

Xtext как механизм сериализиации EMF моделей

И наконец, хочется сказать о связи Xtext с EMF моделями. 

У каждой EMF модели есть класс serializer, который определяет как загружается и как сохраняется модель в виде файла на диске. 

 

Xtext реализует serializer (XTextResource) для EMF модели, который в себя включает парсинг текста и генерацию 

 

https://eclipse.org/Xtext/documentation/308_emf_integration.html#xtext-resource

 

Serializer XText на основе анализа текстового файла с DSL создает модель в формате EMF.

При этом, сам dsl файл - получается представлением EMF модели на диске.

 

С помощью такого механизма можно заменить формат хранения 

любой EMF модели на какой-нибудь текстовый DSL, вместо стандартно используемого XML.

После этого EMF модель будет спокойно загружаться модели из

этого DSL, производя в фоне парсинг DSL с помощью Xtext и даже не будет это знать.

 

Доступ к EMF модели для DSL из Java полностью аналогичен доступу к EMF модели для xml файла. Вот так это примерно выглядит.

 

    ResourceSet resSet = new ResourceSetImpl();
    Resource resource = resSet.getResource(URI.createURI("model/List.xmi"), true);
    EObject EMFroot = resource.getContents().get(0);

EMFroot - корневой элемент EMF модели. Его можно привести к определенному пользовательскому типу и работать с ним на уровне модели. При изменении EMF модели из программного кода изменения будут отражаться и в тексте DSL.

К данной модели EMF могут получать доступ различные редакторы:

- стандартный иерархический редактор, генерируемый EMF

- визуальные редакторы (диаграммы GMF, Sirius, ...)

- текстовый редактор Xtext

- инструменты автоматического построения диаграмм

- программные расширения через Java API EMF модели

Пользователь сам выбирать какие средства ему удобны для работы с формальной моделью.

XText основан на ANTLR

Еще немного про XText и его связи с проектом ANTLR (ANother Tool for Language Recognition).

Парсинг текста в XTEXT основан на проекте ANTLR, который используется во многих известных проектах
http://www.antlr.org/about.html
Например ANTLR используется в NetBeans IDE для парсинга C++.

Для ANTLR доступны определения грамматик для многих стандартных языков программирования
https://github.com/antlr/grammars-v3
https://github.com/antlr/grammars-v4

Вот, например, так выглядит грамматика C++ для ANTLR
https://github.com/antlr/grammars-v3/blob/master/cpp/CPP_grammar_.g

Определение грамматики языка состоит из определения различных правил (аля регулярных выражений).

Наличие грамматики позволяет парсить файлы языка и получать в памяти модель кода (Abstract Syntax Tree ) для языка и далее работать с моделью кода через API.

XTEXT делает удобным использование ANTLR в JAVA мире (за счет представления результатов парсинга в формате модели EMF) и делает возможным генерацию инфраструктуры для работы с новыми языками в Eclipse.

В случае с XTEXT модель кода представляет из себя EMF Ecore модель.
На основе определения грамматики языка XTEXT автоматически генерирует API для работы с этой моделью из Java. Она генерируется на основе parse tree, получаемых ANTLR.

Для XText нет такого разнообразия доступных грамматик.
К сожалению, формат определения грамматики для XText отличачается от ANTLR.
И пишут, что портирование грамматики ANTLR в XTEXT не всегда тривиальная задача.

Для Xtext есть грамматика для языка XTend (улучшенная модификация Java)
Также есть базовая грамматика XBase, части которой можно наследовать и использовать
для более легкого определения своих грамматик.

XTEXT - Language Engineering for Everyone

Раз уж зашел разговор (см предыдущий пост) о трудоемкости создания моделей с помощью построения визуальных диаграмм, нельзя не упомянуть про проект XText. Сторонники этого проекта всегда упоминают про эту проблему и говорят о том, что создавать формальные модели гораздо проще с использованием текстовых описаний. А уж анализировать и визуализировать модели можно с помощью визуальных диаграмм. Именно такой подход был продемонстрирован в в предыдущем посте про автоматическое построение диаграмм.

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

XText позволяет определять для любого языка моделирования предметной области (далее DSL) текстовую грамматику и сгенерировать для данного DSL Eclipse редактор с подсветкой синтаксисам и подсказками.

При создании\редактировании модели в редакторе, сгенерированном XText,

"за кадром" строится EMF модель. С этой моделью можно оперировать через API 

из Java (генерируется на основе описания грамматики DSL), просматривать и 

редактировать модель с помощью графических редакторов (в том числе Sirius),

просматривать/редактировать в иерархическом редакторе.

Пример редактора DSL, сгенерированного XText

Ссылки по теме

XTEXT - Language Engineering for Everyone

https://eclipse.org/Xtext/

5 minutes tutorial (Hello World)

https://eclipse.org/Xtext/documentation/101_five_minutes.html

15 minutes tutorial

https://eclipse.org/Xtext/documentation/102_domainmodelwalkthrough.html

https://eclipse.org/Xtext/documentation/104_jvmdomainmodel.html

Свой DSL можно интегрировать со стандартными языками моделирования. Например, в DSL делать references на элементы UML модели. Немного о скрещивании DSL с UML я писал в ранее.

Автоматическое построение диаграмм на основе моделей

Как не пародоксально, но одной из трудоемких операций при создании формальных моделей является создание визуальных диаграмм. Особенно это имеет место, когда модель получена из каких либо других источников (например путем Reverse Engineering из программного кода или импорта данных из какой-либо ИТ системы). На создание, редактирование и форматирование диаграмм уходит кучу времени. Данную работу нужно автоматизировать путем автоматического построения диаграмм на основе моделей. 

Этому вопросу и посвящен этот достаточно длинный пост. В нем я приведу начальную информацию о проекте Eclipse ELK/KIELER, предоставляющего технологию, которую можно интегрировать в другие инструменты моделирования для реализации автоматического построения диаграмм на основе моделей.

KIELER – проект университета ….

http://rtsys.informatik.uni-kiel.de/confluence/display/KIELER/Home

В данный момент проект переносится под зонтик Eclipse.

https://www.eclipse.org/elk/

И хотя сам проект KIELER стабильный, в новом виде под зонтиком Eclipse он еще пока молодой. Сейчас идет активное переименование API, какие-то переработки по ходу и т.п.  На странице проекта на сайте явным текстом сказано, что если вам нужно использовать автоматический layout сейчас, то нужно использовать исходный проект KIELER

Благо, что исходный проект тоже интегрирован с Eclipse, а именно с диаграммами на базе технологии GMF (Graphical Modeling Framework), на которых основаны и Sirius и Papyrus.

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

Ни виде по ссылке показано как работает автоматическое построение диаграмм для моделей

http://rtsys.informatik.uni-kiel.de/~kieler/videos/klighd/InstantModelBrowsingAnnotated.mp4
http://rtsys.informatik.uni-kiel.de/~kieler/videos/klighd/TextualModeling.mp4
http://rtsys.informatik.uni-kiel.de/~kieler/videos/klighd/SCT.mp4 (textual modeling continued)
http://rtsys.informatik.uni-kiel.de/~kieler/videos/klighd/SCG.mp4
http://rtsys.informatik.uni-kiel.de/~kieler/videos/ptolemyViewer/PtolemyViewerHQ.mp4

Автоматическое построение диаграмм

Ниже пример, описанный в getting started, по описанию конечного автомата в текстовом редакторе (dsl на базе xtext). Диаграмма справа строится полностью автоматически на базе текстового описания конечного автомата. При добавлении элемента в текстовом представлении, он тут же появляется в графическом представлении.  При выборе любого графического элемента, он тут же автоматически подсвечивается в текстовом описании.

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

А можно выбрать для построения диаграммы любой другой алгоритм из списка

Проект KIELER реализует как собственные алгоритмы для автоматического layout диаграмм, так и интегрирует с EMF моделями алгоритмы, реализуемые в Graphviz и OGDF (http://www.ogdf.net/doku.php)

KIELER позволяет настраивать каждый отдельный элемент диаграммы на применение одного из доступных алгоритмов и параметров. Это можно делать через API. Эти параметры можно просматривать и редактировать из Eclipse View с названием Layout.

Построение диаграмм аля блок-схем

А вот пример построения автоматической блок схемы на основе модели EMF (иерархический редактор модели слева на рисунке). У меня пока не было сложной модели, поэтому привожу диаграмму для простой модели

Ниже пример диаграммы аля блок-схема с отображением неких зависимостей (их можно отключать).

Генерация тестовых графов

В KIELER реализована возможность построения рандомизированных графов, вид которых можно гибко настраивать.  Это очень удобно для тестирования различных алгоритмов автоматического построения диаграмм.

Создание нового графа реализовано в виде создания нового файла модели типа Random KGraph

Описание графов генерируется в текстовом представлении в виде XMI или DSL (на базе xtext). Ниже пример иерархического графа, сгенерированного в формате текстового DSL и построенной для него иерархической диаграммы.

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

А вот так выглядит автоматическая диаграмма из 100 блоков разного размера и с большим количеством связей.

Это фрагмент

А это вся диаграмма

Использование KIELER в инструментах моделирования

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

Все диаграммы в этом документе – это диаграммы на базе GMF из Eclipse.

Но KIELER не ограничен использованием в ECLIPSE. Архитектура решения трех-уровневая, что позволяет использовать KIELER и просто из Java. Но и Java-ой не ограничено применение. Есть возможность использовать всех этих алгоритмов через веб сервисы.

http://rtsys.informatik.uni-kiel.de/confluence/pages/viewpage.action?pageId=328093

Интеграция KIELER с диаграммами по смыслу очень простая. Коннетору между диаграммой и алгоритмом нужно уметь перегнать элементы диаграммы в структуру KIELER и после выполнения алгоритма применить параметры размеров/размещения  элементов из структур KIELER к элементам диаграммы. Как я писал, вроде как для GMF это уже сделано.

Остается только подключить коннектор KIELER к своим диаграммам на уровне пользовательского интерфейса  и к механизму Arrange All (который есть на диаграммах GMF). Это делается с помощью точек расширения Eclipse. Как сделать примерно понятно, но нужно еще будет повозиться и попробовать. 

Инструменты моделирования на базе EMF

В этом посте хочу сказать о роли EMF в создании различных инструментов моделирования.

Я писал ранее о технологическом стеке Eclipse Modeling Projects, используемом для создания инструментов моделирования. Одним из центральных компонентов этого стека является EMF (Eclipse Modeling Framework).

EMF позволяет на базе модели сущностей генерировать Java классы двух видов:
- Java классы для манипулирования сущностями в Java
- Java классы, реализующие иерархический редактор для сущностей в Eclipse

Модель сущностей на входе EMF - это модель в формате Ecore, очень похожая на модель классов и их отношений в UML. Модель в формате Ecore может быть создана вручную с помощью визуального редактора Ecore Tools. Либо с помощью этого же редактора модель сущностей может быть получена путем импорта из UML или XSD.
моделирования.

Технологии EMF (Eclipse Modeling Framework) является основой целого ряда инструментов моделирования. Вот перечень инструментов, которые в первую очередь приходят мне на ум.

Инструменты Open Source:
- Polarsys Capella (Obeo)
- Eclipse Papyrus
- UML Designer (Obeo)
- Archi (язык Archimate)

Коммерческие инструменты
- NoMagic Magic Draw
- IBM Rational Software Architect
- Esterel SCADE System

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