exam06 2

Реферат к лекции 6. Инженерия в разработке, управляемая моделями (MDD).

Выполнил: Легистаев Егор ИДБ-18-08

Проверила: Трунина Полина ИДБ-18-08

Архитектура, управляемая моделью (Model Driven Architecture, MDA) — создаваемая консорциумом OMG разновидность концепции «Разработка, управляемая моделями»: модельно-ориентированного подхода к разработке программного обеспечения. Его суть состоит в построении абстрактной метамодели управления и обмена метаданными (моделями) и задании способов ее трансформации в поддерживаемые технологии программирования (Java, CORBA, XML и др.). Создание метамодели определяется технологией моделирования MOF (Meta Object Facility), являющейся частью концепции MDA. Название концепции не совсем удачно, так как она определяет вовсе не архитектуру а именно метод разработки программного обеспечения.

OMG UML принес парадигму множественности методов/групп описаний в мейнстрим программной инженерии. Его 5 типов диаграмм позволили связно отражать различные аспекты программных систем. Более того, UML расширяем стандартным способом, и системная инженерия с десятилетним лагом (как обычно) к программной инженерии получила средство для описания этого множества методов/групп описаний в форме SysML, являющегося расширением UML. ISO 42010 (стандарт рекомендованной практики архитектурных описаний) получил язык для своей поддержки.

UML вместе с MOF является основным языком MDA консорциума по стандартизации OMG. MDA уже переосмысливается, чтобы ее предмет был расширен с программной инженерии на системную инженерию.

Достоинства MDA

• множество уровней абстракции (иерархия уровней метамоделирования);
• множество обеспечиваемых метамоделями методов описания с прописанными правилами соответствия методов описаний (viewpoint correspondence rules).

Недостаток MDA

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

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

В классической модели MDA действует схема. С учетом потребностей доменов эта схема модифицируется.

Фактически спецификация ПС соответствует подходу MDD (см. рис. 4.7, а) и определяет модель семейства ПС из приложений, члены которого имеют общие функции, но различаются платформами реализации. Это видно на рис. 4.8, где показаны два способа реализации информационного взаимодействия прикладных приложений.

а — централизованный доступ; б — взаимодействие парами

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

Преимущество применения MDD для построения члена семейства заключается в том, что «управление» точкой вариантности платформ выполняется через трансформацию PIM <=> PSM.

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

Выбор разных концепций из модели (ПрО) предусматривает появление разных прикладных моделей ПС, которые трансформируются автоматически в соответствии с подходом MDD.

Разработка, управляемая моделями, (англ. model-driven development) — это стиль разработки программного обеспечения, когда модели становятся основными артефактами разработки, из которых генерируется код и другие артефакты.

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

Основная цель MDD— минимизация затрат, связанных с привязкой к конкретным системным платформам и программным инфраструктурам. Ведь основная бизнес-логика содержится в диаграммах и не сковывает нас рамками выбора языка программирования и инструментов разработки.

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

Идея MDD не нова ‑ она использовались с переменным успехом и раньше. Причиной возросшего внимания к ним в настоящее время является то, что автоматизации поддается значительно больше процессов, чем раньше. Это развитие отражается в появлении MDD-стандартов, что ведет к унификации соответствующих средств. Одним из таких стандартов является пересмотренная версия Unified Modeling Language – UML 2.0.

По стандартам Object Management Group (OMG) создание приложения состоит из следующих шагов:

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

Классический пример применения MDD, который используется уже давно, — моделирование баз данных. На основе одной концептуальной модели данных вы можете поддерживать несколько связанных с ней физических моделей для различных СУБД.

Преимущества 👍

• ускоряется вывод минимального жизнеспособного продукта (Minimum Viable Product) на рынок;
• сокращается время на: генерацию каркаса приложения, модели классов, базы данных;
• постоянно обновляемая документация;
• для участников проекта диаграммы намного нагляднее кода.

Минусы 👎

• для внедрение MMD потребуется использовать специальные программные решения, такие как Rational Software Architect, Simulink или Sirius;
• от программистов требуются внушительные знания проектирования диаграмм;
• значительные финансовые затраты на интеграцию данной методологии.

Источники

TDDx2, BDD, DDD, FDD, MDD и PDD, или все, что вы хотите узнать о Driven Development