Разработка, управляемая моделями (MDD)

Существует формализованная связь модели с соответствующей программной её реализацией через одно или несколько автоматизированных преобразований модели. Возможно, наилучшим и наиболее успешным примером этого является компилятор, который преобразует язык программирования высокого уровня в эквивалентную реализацию на машинном языке. Моделью в этом случае является программа, написанная на языке высокого уровня, которая, как и все полезные модели, скрывает несущественные детали об индивидуальных особенностях нижележащей технологии вычислений (такие как внутренний размер слова, количество аккумуляторов и индексных регистров, тип ALU и т.д.).

Потенциал, скрытый мощной комбинацией абстракции и автоматизации, ведет к появлению новых технологий моделирования и соответствующих методов разработки: ‑ Model-Driven Engineering (MDE) и Model-Driven Development (MDD), которые в переводе на русский означают одно и то же – управляемая моделями разработка.

Определяющей особенностью MDD является то, что основными артефактами этапа проектирования программы становятся модели, перемещая, таким образом, фокус с соответствующего кода программы на её модель. Они выступают в качестве своеобразных «чертежей», из которых различные автоматизированные и полуавтоматизированные процессы извлекают программы и соответствующие модели. Степень автоматизации, используемая сегодня в MDD, варьируется от извлечения простого скелетного кода до генерирования полного автоматического кода (что сравнимо с традиционной компиляцией). Очевидно, что чем выше уровни автоматизации, тем более адекватными являются модели и тем большими преимуществами обладает MDD.

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

В качестве примера объектно ориентированной методики моделирования рассмотрим он-лайновую систему выполнения заказов некоторого гипотетического Интернет-магазина, [25]. Для описания требований к системе, ее проектирования и разработки можно рассматривать динамические и статические модели на различных уровнях абстракции: уровне контекста, концептуальном, логическом и физическом уровнях.

Вначале строися динамическая модель для концептуального уровня абстракции. Она должна отражать взаимодействия между клиентом (объект Клиент) и магазином (объект Система). клиент и сотрудники магазина выступают как внешние по отношению к системе исполнители (Actors). Весь процесс рассматривается с точки зрения Клиента и Сотрудника. Клиент осуществляет заказ через Интернет. Оплата выполняется с помощью кредитной карты. Заказ посылается по указанному адресу. Уведомление о выполнении заказа посылается по электронной почте. Модель на самом высоком уровне описывает бизнес-процессы продавца и содержит простой сценарий использования (use case), описывающий взаимодействия между системой и исполнителями (справа на рис. 7.6).

Рис. 7.6. Динамическая концептуальная модель процесса закупки товара, [25]

Статическая модель на этом уровне абстракции отражает структуру классов и связи между объектами, необходимость в которых становится очевидной при анализе динамической модели. Другими словами, она отвечает на вопрос: " Какие объекты должен использовать (и понимать) Клиент для того, чтобы выполнить транзакцию, связанную с покупкой? "

На рис 7.7 показана диаграмма классов, которая является статической концептуальной моделью данной системы (Интернет-магазина).

Рис. 7.7. Статическая модель процесса закупки товара в магазине (Диаграмма классов UML), [25]

Клиент является конкретной реализацией класса Человек. Связи между клиентом и магазином обеспечены наличием Учетной записи клиента. Все Заказы ассоциированы с Учетной записью. Заказ ассоциирован со всеми приобретаемыми Элементами заказа. Каждый элемент заказа является специфическим Продуктом, где Продукт сам по себе является классом. Наконец, каждый Платеж ассоциирован с некоторым Заказом.