Стоит ли для компонентной разработки использовать стандартный UML, его профили или предпочтительно использовать специализированный DSL?
Моделирование на чистом UML наиболее близко к чисто объектно-ориентированному подходу к разработке. Для реализации компонентного подхода на уровне моделирования, для UML могут быть созданы профили, которые определяют новые сущности и диаграммы для моделирования компонентов. Также возможно создание DSL для моделирования компонентов, не основанных на UML.
Наблюдается тенденция, когда в инструментах моделирования ПО присутствуют два типа моделей: модель компонентов (более абстрактная) и объектно-ориентированная модель (близкая к коду). При прямом проектировании для получения кода на базе модели компонентов путем трансформации компонентной модели сначала получается объектно-ориентированная модель, а затем уже программный код. При обратном проектировании из кода сначала получается объектно-ориентированная модель. На основе доп.информации в коде на основе такой модели может быть автоматически получена и компонентная модель.
Например на базе инструмента 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. Для пользователя это получается как единый инструмент, но с преимуществами обоих.
Комментариев нет:
Отправить комментарий