Скрещиваем DSL с UML

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

Недостатком UML является отсутствие глобальной мета-модели.  Про UML часто произносится такая фраза, что это универсальный язык, а не процесс. Как вы будете его использовать должно быть определено в процессе. В результате UML - это набор островков из различных мета-моделей, без привязки к способу их использования. А разработка языка UML - это разработка снизу, без учета потребностей пользователя (это ведь прямо говорится - универсальный, не привязан к процессу...)

Начиная создавать какой-либо стандартный документ, автор очень сильно выигрывает, если у него заранее есть структура документа: названия и порядок разделов и т.п. Отсутствие стандартной структуры заставляет автора вместо того чтобы писать документ, заниматься разработкой структуры.

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

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

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

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

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

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

Постепенно подхожу к цели этого поста - возможности совмещение DSL и языка UML в одной модели. DSL может определять глобальную структуру модели, а UML определяет ее отдельные "мелкие" элементы. DSL изначально разрабатывается под определенный процесс. А включение кубиков мета-модели UML позволяет более быстро и легко реализовывать различные предметно-ориентированные языки моделивания (DSL).

Технология Ecore для описания языков моделирования позволяет создавать описания новых DSL, строя их на основе существующих мета-моделей. Наличие ecore мета-модели для UML2 позволяет использовать элементы языка UML при определении своего DSL.

Важно уметь внедрять не только элементы UML в свой DSL, но и переиспользовать определения диаграмм UML, используемых для анализа и создания этих элементов. И такая возможность тоже есть благодаря Eclipse Sirius. Эта технология предназначена для создания визуальных представлений для моделей, основанных на EMF. А также благодаря инструменту моделирования UML Designer, основанному на Sirius. В UML Designer реализованы стандартные UML диаграммы, которые можно переиспользовать как есть или адаптируя, при создании своего DSL. Также можно использовать мета-модель Capella и диаграммы языка Capella, так как они тоже основаны на этих технологиях (Ecore, EMF, Sirius)

Мне кажется, что с наличием таких технологий наступает новая эра по использованию подхода к разработке на основе моделей. Эра, когда языки/инструменты моделирования разрабатываются под потребности конкретных пользователей и это делается минимальными усилиями благодаря повторном использованию существующих наработок. Мне хочется надеяться, что это наконец сделает возможным реальное и более широкое применение данного подхода.  Этот шаг можно сравнить с уходом от Excel к специализированным информационным системам, поддерживающим конкретные бизнес процессы. А вот с Excel можно сравнить стандартные средства моделирования аля UML, которые все же лучше чем просто Word, но все же не решают поставленных перед ними задач, ибо слишком универсальны.