Model Driven Engineering: когда модель работает, а не украшает документацию

Картинка объясняет. Рабочая модель участвует в производстве

Нарисовали процесс, согласовали, положили в папку. Разработчики написали систему, потом несколько раз её изменили. Через полгода схема рассказывает, как всё когда-то предполагалось устроить.

Модель есть. Управления разработкой через модель нет.

Model Driven Engineering, MDE — подход, в котором модели становятся рабочими инженерными артефактами: их проверяют, преобразуют, используют для получения других моделей, кода, конфигураций и документации. Существенная часть устройства системы задаётся в форме, с которой могут работать инструменты.

Зачем? Чтобы одно решение не приходилось независимо воспроизводить в пяти местах. Если у заявки появился обязательный атрибут, это изменение должно согласованно отразиться там, где оно действительно нужно. Ручное копирование тоже возможно. Только тогда согласованность держится на внимательности людей.

Модель при этом не обязана быть картинкой. Она может выглядеть как текст на предметном языке, набор связанных объектов или структурированное описание. Важно не оформление, а достаточно точный смысл элементов и возможность выполнять над ними определённые операции.

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

Четыре механизма вместо обещания «код из картинки»

Рабочий контур MDE удобно разбирать через четыре механизма.

Метамодель определяет, из каких элементов можно строить модели и как эти элементы связаны. Для языка процессов это могут быть состояния, переходы, роли и условия. Конкретная модель говорит: «Заявка переходит из проверки в согласование». Метамодель задаёт, что вообще считается состоянием и какие связи допустимы. Это устройство языка моделирования, а не описание очередной заявки.

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

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

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

Откуда берётся недостающая конкретика? От людей, из правил преобразования, библиотек и выбранной платформы. Не из самого факта, что мы нарисовали прямоугольники.

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

MDE, MDD и MDA: похожие названия, разные акценты

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

MDE — Model Driven Engineering — обычно наиболее широкое обозначение инженерной работы, в которой модели играют центральную операционную роль. Речь может идти не только о получении кода, но и об анализе, проверках, согласованности и сопровождении изменений.

MDD — Model Driven Development — чаще акцент на разработке программного обеспечения с опорой на модели и получение реализации из них. На практике MDD и MDE иногда употребляют почти как синонимы. Жёсткую универсальную границу между ними проводить не стоит.

MDA — Model Driven Architecture — конкретный подход OMG. На официальной странице он описан через структурирование спецификаций в виде моделей и отделение бизнес- и прикладной логики от технологий платформы.

В объяснениях MDA используют три перспективы: CIM описывает предметную среду и требования без устройства вычислительной реализации; PIM — систему независимо от конкретной платформы; PSM — систему с учётом выбранной платформы. Это помогает обсуждать, какое знание добавляется при переходе к реализации. Но CIM → PIM → PSM — не обязательный конвейер всякого MDE.

MDE также не равно UML. UML — язык моделирования; его использование само по себе не делает модели рабочими артефактами. Можно рисовать UML исключительно для обсуждения. Можно строить MDE на собственном предметном языке.

И не нужно подменять MDE термином MBSE, model-based systems engineering. MBSE относится к модельному подходу в системной инженерии, включая системы с программными, аппаратными и другими составляющими. Подходы могут пересекаться, но это не два названия одной практики генерации программ.

Проверим на заявке: что действительно можно получить

Возьмём условный учебный процесс, не историю реального клиента.

В модели заданы состояния заявки: «Черновик», «На проверке», «Одобрена», «Отклонена». Передать заявку на проверку можно только с заполненным обоснованием. Одобрить её может сотрудник с ролью согласующего.

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

Но кто назначает согласующего? Может ли автор одобрить собственную заявку? Что происходит при двух одновременных решениях? Нужен ли неизменяемый журнал?

Этого в исходном описании нет. Значит, ответы придётся добавить в модель, правила реализации или платформенный контур. Написать код, который молча выбрал ответы за организацию, — ещё не значит решить её задачу.

Есть и вполне конкретные инструменты такой работы. Eclipse Modeling Framework, EMF — действующая технология моделирования и генерации кода на основе структурированной модели данных. В ней используется метамодель Ecore; из спецификации модели можно получать Java-классы, адаптеры и базовый редактор. Это пример работающего механизма, а не доказательство универсальной выгодности MDE.

Экономика моделей и место ИИ

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

Но генератор тоже нужно разрабатывать. Язык моделей — менять. Трансформации — сопровождать. Исключения — куда-то помещать. Если модель и код редактируются независимо, возникает задача синхронизации: какое представление является источником истины и как переносить изменения?

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

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

Поэтому проверки остаются: ограничения модели, тесты преобразований, проверка реализации и обратная связь от эксплуатации. Агент помогает готовить изменения; основания этих изменений всё равно нужно сделать доступными и проверяемыми.

В основном материале о бизнесе, ИТ и AI этот вопрос поставлен шире: между замыслом и исполнением добавляется знание. MDE позволяет часть такого знания оформить и воспроизводить. ИИ помогает с ним работать. Ни то ни другое не отменяет необходимости выяснить, как именно должен работать ваш бизнес.

Источники

• OMG — Model Driven Architecture: официальный подход MDA, разделение прикладной логики и платформенных технологий.
• Eclipse Modeling Framework: структурированные модели, Ecore и генерация Java-артефактов.