3. Теоретические основы, технические аспекты создания mda-приложений

Модель приложения является основой MDA-технологии. Модель содержит состав, структуру и элементы поведения разрабатываемого приложения [8].

1. Роль модели приложения в Borland mda

С точки зрения Bold for Delphi модель имеет следующее функциональное назначение:

• Определяет состав и тип классов и атрибутов классов;

• Фиксирует наличие связей между классами, определяет тип этих связей и их размерность;

• Определяет условия и ограничения, накладываемые на классы и их атрибуты: такие условия формируются на диалекте языка OCL, встроенного в Bold;

• Содержит информацию для адаптации к среде разработки Delphi в виде набора специальных тег-параметров;

• Содержит информацию для адаптации к СУБД, также в виде набора специальных тег-параметров.

В Bold, таким образом, отсутствует явное четкое разделение между PIM и PSM-моделями MDA, и вся необходимая информация содержится в одной общей модели. Функции PSM-модели в основном выполняет набор тег-параметров (tagged values). Кроме того, такие функции могут выполнять и некоторые компоненты Bold, являющиеся адаптерами СУБД.

Bold for Delphi использует модель для реализации следующих основных функций.

Генерация кода. Под генерацией кода понимается автоматическое создание модулей описаний (.inc-файлов) и функциональных модулей (.pas-файлов) на языке Object Pascal, содержащих полную реализацию классов модели приложения. Строго говоря, сам по себе Bold не нуждается в генерации кода. Можно создавать достаточно серьезные приложения, не используя генерации кода вообще. Однако в некоторых случаях она бывает необходимой. Общая стратегия здесь выглядит примерно так ­ если поддерживаемых Bold возможностей языка OCL недостаточно для реализации, например, желаемых методов или вычисляемых атрибутов на бизнес-уровне, то разработчик вправе «опуститься» на уровень программного кода. Кроме того, генерация кода необходима, если классы модели содержат операции. Ее можно произвести из встроенного редактора модели (Model Editor) на этапе разработки приложения. Кроме генерации кода Bold обеспечивает и возможность генерации интерфейсов, необходимых для функционирования распределенных DCOM-приложений.

Генерация схемы базы данных. Структура базы данных (набор описаний таблиц, полей, индексов и ключей) может быть сгенерирована автоматически как из встроенного редактора модели на этапе разработки, так и программно во время выполнения приложения. Bold также поддерживает синхронизацию структуры базы данных с изменяющейся во времени моделью приложения (Model Evolution ­ эволюция модели), при этом сохраняется уже имеющаяся в БД информация. Такая возможность в Bold носит специальное название ­ эволюция базы данных (Database Evolution). Необходимо иметь в виду, что между составом классов модели и составом таблиц генерируемой базы данных нет взаимно-однозначного соответствия. Во-первых, ряд таблиц БД Bold использует для своих собственных нужд и создает их автоматически. Во-вторых, не все классы модели требуют сохранения информации объектов в БД (persistent class), а могут быть временными (transient) классами; кроме того, даже в persistent-классах модели часто присутствуют вычисляемые (derived) атрибуты, которые не сохраняются в базе данных. И в-третьих, в ряде случаев принципиально невозможно в реляционной БД реализовать некоторые виды отношений. Так, если в UML-модели вполне допустимо соединять два класса ассоциацией, имеющей на обоих концах кратности больше 1, то в реляционной базе данных для реализации такого вида отношений («многие-ко-многим») требуется создание промежуточной связующей таблицы. Поэтому при генерации схемы базы данных в подобных случаях Bold «самостоятельно» и незаметно для пользователя способен генерировать такие таблицы.

Интерпретация модели во время выполнения для управления поведением приложения. Вся информация о модели сохраняется в компоненте TBoldModel и на этапе выполнения приложения используется для управления объектным пространством, для контроля его целостности, а также для управления взаимодействием бизнес-уровня с уровнем данных и графическим интерфейсом. Можно сказать, что объектное пространство (Object Space) в Borland MDA является экземпляром модели, по аналогии с тем, как объект является экземпляром класса в ООП. Управление каждым объектным пространством обеспечивается компонентом TBoldSystemHandle. Информацию о типах, содержащихся в модели, этот компонент получает из компонента TBoldSystemTypelnfoHandle [6].

2. Тег-параметры (tagged values)

Кроме UML-модели, BMDA для своего функционирования использует набор специальных переменных-параметров (tagged values), или тег-параметров. Они необходимы для взаимодействия со средой разработки и СУБД, а также для дополнительных настроек модели.

Появление тег-параметров не случайно. Если UML-модель можно рассматривать как платформенно-независимую PIM-модель, то совокупность тег-параметров можно рассматривать в качестве платформенно-зависимой PSM-модели. Будучи по этой причине связанными с PIM, тег-параметры классифицируются по принадлежности к элементам иерархической структуры модели. Таким образом, существуют отдельные наборы тег-параметров для следующих элементов иерархии модели:

• Модель в целом;

• Класс;

• Ассоциация;

• Атрибут;

• Роль;

• Операция.

С другой стороны, тег-параметры можно классифицировать и по функциональной принадлежности:

• Общие;

• Используемые для генерации кода и интерфейсов;

• Используемые для отображения на уровень данных (persistence mapping);

• Используемые для описания принадлежности к уровню данных (persistence).

Разработчик также может создавать собственные тег-параметры и использовать их для своих целей. Значения тег-параметров доступны как на этапе разработки приложения, так и во время его выполнения. Borland MDA описываемой версии содержит несколько десятков тег-параметров [17].