Модельные точки зрения и модели MDA

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

Точка зрения, независимая от вычислительных особенностей Computation Independent Viewpoint (CIV), нацелена на анализ системной среды и системных требований. Логика работы пока что не рассматривается — возможно, она еще не определена. В CIV учитываются программные, аппаратные и другие технологические ограничения, которые не связаны напрямую с внутренней архитектурой разрабатываемой программы.

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

Точка зрения, зависящая от платформы Platform Specific Viewpoint (PSV), задает детали реализации, зависящие от используемых платформ и язы ков программирования. Она сочетает платформенно-независимую логику с дополнительными особенностями, вызванными использованием конкретной платформы или системы.

Каждая из этих точек зрения предлагает разные средства построения соответствующих моделей. Бизнес-аналитики, не знакомые с особенностями программной разработки, вырабатывают свои требования к системе на уровне CIV — с помощью так называемых вычислительно-независимых моделей (Computation Independent Model, CIM). Модели CIM задают основные требования к проекту и включают словари предметной области. Никакие технические характеристики в этих моделях не фиксируются.

Методология MDA описывает не столько моделирование, сколько метамоделирование, предусматривающее большую гибкость в конкретных, прикладных походах к моделированию.

Метамоделирование — способ описания моделей, определяющий механизмы построения конкретных моделей программных систем с помощью базового словаря и набора ограничений, налагаемых на создаваемые модели. Сегодня вместо термина BMDA корпорация Borland применяет новый термин ЕСО. Технология ECO {Enterprise Core Objects) — ключевые корпоративные объекты, — реализующая концепцию MDA, стала наиболее важным улучшением последних версий среды Delphi. Она представлена в Delphi 2006 в виде третьей версии ЕСО III. Каждый компонент ЕСО представляет собой своеобразную программную «обертку» положений концепции MDA. Он является промежуточным слоем между средствами визуального проектирования программных моделей и их конкретной реализацией на языках программирования Delphi и С#.

Практика перевода требований заказчика напрямую в программный код на языке программирования почти всегда страдает неполноценностью. Заказчик мыслит одними понятиями, программист — совсем другими. Поэтому они не подозревают о множестве потенциально возможных проблем. Так, заказчику какие-то моменты автоматизации выбранных процессов могут казаться очевидными. Он о них и не упоминает, считая, что программа выполнит определенный набор действий «сама». Программист, наоборот, подходит к созданию системы с узких технических позиций, программируя только очевидный набор функций, заданный в техническом задании, и редко учитывает все множество взаимосвязей между большим числом требований. В результате в середине проекта выясняется, что архитектуру решения невозможно пополнить новыми требованиями, которые заказчику кажутся простыми, естественными и подразумевавшимися с самого начала. В итоге приходится заново переделывать почти весь проект.

Технология ЕСО переводит процесс согласования требований на модельный уровень. Диаграммы UML обычно хорошо воспринимаются и заказчиком, и исполнителем. Поэтому, хотя использование визуального языка моделирования в MDA не обязательно, почти 100% проектов MDA создаются с применением языка UML.

Построение готового приложения происходит в несколько этапов. Сначала строятся модели PIM, затем выполняется их перенос в модели PSM. Доступные па сегодняшний день продукты автоматизируют эти шаги на 50-70%. Перенос моделей PSM в код конкретного языка программирования автоматизирован почти на 100%.

Еще один подход, настоятельно рекомендуемый группой OMG при использовании подхода MDA, заключается в выделении логики приложения в отдельную, по возможности платформно-независимую структуру. Достигается это использованием языка объектных ограничений OCL, который сегодня считается частью языка UML. Команды OCL встраиваются непосредственно в модель UML, описывая и уточняя аспекты ее работы. Удобство OCL еще и в том, что его выражения напоминают естественный язык (предложения, записанные на английском). Это позволяет сохранять при построении моделей контакт с людьми (например, представителями заказчика), не являющимися специалистами в области программирования.

При реализации сложной логики далеко не всегда удается обойтись стандартными возможностями языков OCL и UML. Всевозможные манипуляции с наборами объектов, их фильтрация и сортировка решают до 70-90% потребностей современных проектов. Такие задачи характерны для многих задач автоматизации деятельности организаций. Технология ЕСО позволяет быстро создавать работающие прототипы, но 10-30% требований все равно приходится программировать нручную5. Для этого используется исходный код на языке Delphi, в который отображается модель UML, сформированная в среде Delphi. Можно выполнить и обратное преобразование: на основе измененного исходного текста получить готовую модель UML.

Физические объекты, структура которых описана с помощью языка UML, a особенности существования — с помощью языка OCL, функционируют в процессе работы приложения в специально выделенной области оперативной памяти, так называемом объектном пространстве. Технология ЕСО способна автоматически отображать модель не только в программный код, но и в код на языке SQL. Он генерируется для построения схемы базы данных, хранящей копию объектного пространства. Поддержка разных СУБД является в ЕСО одной из ключевых технологий. С ее помощью удается сохранять текущее состояние объектного пространства приложения в базе данных и затем, после перезапуска приложения, загружать его и продолжать работу с прерванного места.

Среда Delphi на основе подготовленной модели автоматически формирует схему базы данных с учетом версии и специфики конкретной СУБД. Она автоматически создает в ней все таблицы, нужные для хранения объектного пространства и взаимосвязей между классами, даже если это требует введения дополнительных таблиц. По мере совершенствования модели следует периодически синхронизировать схему базы данных с внесенными в модель модификациями — для этого достаточно нажать одну кнопку. Такой процесс называется в технологии ЕСО эволюционным развитием базы данных.

Стыковка объектного пространства с пользовательским интерфейсом реализуется в ЕСО с помощью дескрипторов. Дескриптор ЕСО — это стыковочная точка (компонент промежуточного уровня), связывающая с помощью выражений OCL элементы модели UML (классы) с программным кодом и внутренней структурой обычного приложения Delphi. Дескрипторы задают способы формирования наборов объектов в объектном пространстве по критериям, заданным выражениями OCL. Они также обеспечивают доступ к ним элементов пользовательского интерфейса, а программному коду предлагают ссылки на объекты ЕСО.