Архитектурные описания в Capella в соответствии со стандартом 42010

Capella - это пример каркаса и языка архитектурного описания в одном флаконе, позволяющая выполнять архитектурные описания систем в соответствии со  стандартом 42010 по выполнению архитектурных описаний.

В стандартной модели Capella создаются несколько view, соответствующие точкам зрения: Operational Analysis, System Analysis, Logical Architecture, Physical Architecture, EPBS Architecture.

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

Созданные в модели представления (диаграммы, ...) можно просмотреть отсортированными по категориям. 

- View

   - Тип представления ((диаграмма, таблица, пользовательские представления)

         - Конкретное представление 

Состав viewpoints, доступных в Capella, а также средства языка моделирования могут расширяться с помощью технологий Sirius и Kitalpha. 

Архитектурные описания по стандарту 42010

Чтобы лучше понимать архитектуру моделей Capella необходимо познакомиться со стандартом
ISO/IEC/IEEE 42010:2011 Systems and software engineering - Architecture description.
В данном стандарте определяются правила как необходимо структурировать архитектурные описания систем и ПО, чтобы они были понятны и востребованы различными заинтересованными сторонами. Архитектурные описания, рассматриваемые в стандарте, применимы на уровне организационных систем, технически систем и ПО.

В этом стандарте четко даются такие определения, как
- архитектура
- архитектурное описание
- каркас архитектурных описаний (пример, DoDAF, ToGAF, Capella)
- язык архитектурного описания (пример UML, SysML, Capella)
- заинтересованная сторона (stakeholder)
- интерес (concern)
- точка зрения (viewpoint)
- view

У этих определений все связаны друг с другом. Архитектура - является свойством системы. Архитектурное описание выполняется с целью ее описания. У пользователей архитектурных описаний есть различные потребители (Stakeholders) со своим набором интересов (concerns). Архитектурные описания должны выполнять с учетом этих потребителей и их интересов. Каркас архитектурных описаний задает состав потребителей и их интересов, определяет набор их точек зрения на архитектуру (viewpoints). Каждый viepoint определяет некую точку зрения на архитектуру системы, которая интересна определенным потребителям архитектурных описаний, задает состав информации, которая должна быть представлена для данного viewpoint.  View - это часть архитектурного описания, выполненная в соответствии с одним viewpoint.  View содержит информацию о ВСЕЙ системе с определенной точки зрения (viewpoint). В случае геометрических моделей 2D View является проекцией 3D модели на выбранную плоскость, при этом может отображать только часть элементов 3D модели.

Информация во view может быть представлена с использованием формального архитектурного языка описания. Данные языки обычно имеют формальную мета-модель и визуальную нотацию. В этом случае viewpoint задает состав типов моделей (в стандарте model kinds) или в терминах Sirius - отдельных представлений (диаграмм, таблиц, деревьев), которые могут использоваться для архитектурного описания для данного viewpoint.

Для того чтобы архитектурная информация, представленная для различных точек зрения была согласована необходимо устанавливать соответствие между элементами различных view с помощью связей соответствия (correspondences). Эти связей позволяют поддерживать все view архитектурного описание в согласованном состоянии. При изменении элемента в одном из view благодаря этим связям можно найти все связанные элементы в других view и внести в них изменения, при необходимости.

Язык Capella одновременно включает и каркас архитектурного описания и язык. Чего нельзя сказать об UML/SyML, которые являются универсальными языками, которые можно использовать в рамках различных каркасов архитектурных описаний. В этой "универсальности" - их основной недостаток.

Пример модели для Capella

На этой неделе выложили первую модель для Capella под названием In-Flight Entertainment System. Модель  доступна со страницы Getting Started. (вкладка SAMPLE MODEL на странице).  Доступно также краткое и подробное описание модели в виде документов.

Генерация документации из Capella с помощью Acceleo

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

Удалось на практике использовать Acceleo для генерации документов и отчетов на основе моделей в Capella. Для использования Accelo необходимо описание мета-модели (схемы) языка в формате ecore. Эти мета-модели оказались доступны в составе исходного кода Capella в git репозитории (в составе 2 плагинов). Для обращения к элементам модели при разработке шаблонов генерации документов в Accello.  Тут осталось некая тонкость с зависимостями мета-модели от файлов Kitalpha (см. форум). Нужно еще немного времени, чтобы разобраться как правильно подключать мета-модели.

В ближайшее время должны выложить выложить плагин для Capella (для Eclipse), который публикует модель в виде интерактивного html документа. Но это не заменит Acceleo. Также есть потенциальная возможность использовать Eclipse Birt для генерации документации на основе Capella. Birt я ранее уже использовал для генерации отчетов с другими инструментами. Но пока не пробовал подключить его к Capella.

Расширение Capella с помощью Kitalpha

В предыдущем посте я писал, что у меня остался вопрос о возможности расширять мета-модель языка Capella, добавляя новые элементы к существующим. Все это оказалось возможным и даже больше с помощью инструмента Eclipse Kitalpha. Kitalpha позволяет добавлять новые определения к мета-модели языка, добавлять новые диаграммы к Capella, а также наследовать существующие определения диаграмм Capella, добавляя на них новые элементы.

Kapella позволяет описывать на текстовом DSL мета-модель языка, viewpoints и представления (диаграммы) для Sirius. Можно основывать свои расширения на существующих мета-моделях языка (например, Capella), а также на существующих определениях Viepoints и диаграмм. На существующие диаграммы можно добавлять новые элементы и связи, определенные в определенных расширениях мета-модели. На выходе Kitalpha генерируются расширения для Eclipse, которые можно обычным способом установить в Capella. Данные расширения используют технологию Sirius. Видео демонстрация на 5 минут доступна по ссылке.

Руками пока Kitalpha не попробовал. На форуме Capella мне рассказали, что в ближайшие дни выйдет вариант Kitalpha под названием Capella Studio. Именно данный инструмент демонстрируется в виде выше. С ним будет гораздо легче начать заниматься расширением Capella, чем используя текущую версию Kitalpha.

Создание инструментов моделирования на базе Eclipse Modeling Projects

Я давно смотрел в сторону проектов для создания инструментов моделирования в рамках Eclipse Foundation. Но как-то все было не досуг попробовать. Наконец время пришло и я все таки это сделал. Подтолкнул к этому тот факт, что инструмент Capella основан на технологической платформе для создания визуальных представлений для языков моделирования Eclipse Sirius. Было интересно как можно расширять возможности Capella. Но в результате пришло понимание, что с использованием технологических компонентов Eclipse Modeling Project можно создавать и свои инструменты моделирования, аналогичные Capella.

Eclipse Sirius - позволяет самостоятельно создавать (в режиме конфигурирования, а не программирования) визуальные представления (диаграммы, таблицы, деревья) для любого языка моделирования предметной области. Язык  и инструмент Capella для моделирования систем - это лишь один пример использования Sirius. Есть и другие примеры (см. Галерею ). Среди инструментов, реализованные на базе Sirius есть инструменты моделирования на UML и SysML. Но есть и более диковинные - например язык моделирования для разработки приложений под Arduino.

За последнее время я в первом приближении попробовал Sirius, а с ним и целый ряд инструментов-проектов Eclipse, которые его окружают. В результате удалось на практике проделать все основные шаги по созданию своего языка и тестового инструмента моделирования. Вот основные шаги, которые удалось проделать:
- формально задать свой язык моделирования в формате Ecore;
- сгенерировать плагины для Eclipse для базового редактирования модели в Eclipse с использованием нового языка моделирования;
- определить диаграммы и табличные представления с помощью Sirius для анализа и редактирования модели на новом языке визуальным образом;
- сгенерировать отчет в формате html на основе модели с помощью Acceleo

Для того чтобы все это проделать пришлось освоить следующие технологические компоненты Eclipse Modeling Platform. 

EcoreTools

Bнструмент для визуального создания мета-моделей. Позволяет с помощью урезанных диаграмм классов описывать сущности и отношения между элементами языка. На выходе метамодель языка моделирования в формате Ecore. Это аналог редактора XSD для XML. Есть возможность получать модель в формате Ecore на базе XSD.

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

Sirius
Позволяет создавать визуальные представлений (диаграммы, таблицы, деревья) для просмотра и редактирования формальных моделей. Это аналог редактора XSL для трансформации XML. На входе - плагины для Eclipse, сгенерированные EMF для базового просмотра модели. Позволяет к базовым возможностям просмотра модели в виде дерева добавить различные типы диаграмм, таблиц и деревьев для отображения и редактирования элементом модели.

Acceleo
Позволяет генерировать на базе EMF модели документацию и код. Шаблоны для генерации определяются с использованием языка OMG M2T, специально предназначенного для разработки шаблонов генерации на основе моделей (см. описание языка шаблонов)

OCL 

OMG OCL - язык для задания ограничений для элементов моделей. Используется в Acceleo для задания query к модели.

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

EMF Client Platform - для автоматической генерации клиентских приложений для редактирования EMF моделей. Позволяет создавать более продвинутый браузер для просмотра модели, а также продвинутые окна для редактирования свойств отдельных элементов модели.

EMF Store - позволяет организовать совместную работу с моделями, разместив их в общем хранилище. Позволяет управлять версиями, изменениями, делать commit/update и работать с моделями в offline.

Кроме создания своего языка и инструмента моделирования, попробовал расширить возможности Capella.  В результате удалось создать и добавить к Capella новые viepoints и представления (диаграммы и таблицы). Результат кастомизации оформляет в виде плагинов Eclipse, которые доставляются в Capella. После этого в Capella появляется возможность создавать новые представления для элементов модели.

Пока остался вопрос можно ли (вроде можно, но как) расширять язык моделирования Capella, добавляя в него новые сущности и отношения. Также остался вопрос по использованию Acceleo для генерации документов на основе модели в Capella (для этого необходима метамодель языка Capella в формате Ecore). Например, в Capella удалось сделать представления таблиц трассировки, которые отображают для элементом модели связанные с ними требования.

Пока не попробовал, но есть подозрение, что с помощью Sirius можно расширять возможности инструмента моделирования Eclipse Papyrus (UML, SysML). К стандартным диаграммам языков UML / SysML можно будет добавить любые дополнительные представления. Это нужно пробовать, но архитектурно пришло понимание, что это вроде как возможно.

Презентация по методу Thales Arcadia

Thales планирует в течении 2015 года вслед за инструментом Capella опубликовать целый ряд материалов по методу Arcadia, который поддержан в инструменте.
15 января выложили первую презентацию по Arcadia в виде pdf слайдов (107 страниц).
Материалы доступны по ссылке.

Решения для разработки систем на основе моделей от Thales

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

Язык моделирования и инструмент от Thales называются Capella (ранее Melody). Метод применения моделирования для разработки систем имеет название Arcadia. Утверждается, что данное решение активно используется во многих бизнес-юнитах Thales в реальных проектах. Количество пользователей достигает несколько сотен. Инструмент можно скачать по ссылке https://www.polarsys.org/capella/. На этой же странице приведено краткое описание языка и метода.

Thales пишет, что потратил много времени на создание профилей языка UML/SysML в попытках создать свой язык предметной области. Но в результате пришел к необходимости создания своего собственного DSL и своего собственного инструмента, которые не базируются на UML/SysML. Я думаю, что это связано с определенными ограничениями SysML, с которыми столкнулся Thales, а также с формальными ограничениями при разработке универсального стандарта, которые не позволяют быстро вносить в него улучшения.

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

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

В планах на 2015 год по развитию SysML прозвучала идея необходимости использовать пользовательские сценарии (по сути кусочки метода) для определения требований к языку. Разработчики SysML видно осознали, что оторвались от потребностей. Пользовательские сценарии - являются одной из составных частей любого метода на базе SysML. То что разработчики SysML только сейчас заговорили о необходимости использования пользовательских сценариев в очередной раз показывает, что сапожник - без сапог.

Решение Thales - является решением для разработки систем на основе моделей для конечного пользователя. При создании языка моделирования Thales использовал все лучшее из UML/SysML. Многие диаграммы действительно очень похожи, но есть и новые типы диаграмм. При этом утверждается, что сохранена возможность обмена моделями с SysML.

Инструментарий Thales базируется на Eclipse Modeling Framework. В рамках Eclipse Thales были переданы два технологических проекта Sirius и Kitalpha, которые позволяют меньшими усилиями создавать свои собственные инструменты моделирования для поддержки собственных DSL, в том числе создавать графические редакторы для редактирования визуальных диаграмм моделей.

В последние дни я сделал первое погружение в Capella и Arcadia. Общее впечатление положительное, желания отложить и забыть про инструмент не возникло. Пока можно сказать, что изучение Capella и Arcadia будет для меня чрезвычайно полезно. Как всегда изучение более производительно на практике. В качестве объекта моделирования продолжаю использовать системы дома. Постепенно буду выкладывать результаты моделирования с использованием Capella и Arcadia.

Метод Arcadia встроен в инструмент в виде автоматического методического руководства, которое определяет назначение и позволяет создавать различные диаграммы на всех стадиях применения метода.  Из существенных недостатков - пока нет подробного описания языка и метода. О их возможностях приходится отгадывать из методологических визардов в инструменте. При этом диаграммы Capella просты и интуитивно понятны. Несмотря на сложности общая картина языка и метода постепенно складывается в голове.