Часть 2
Оглавление
Borland MDA
В первой части статьи был дан обзор MDA-архитектуры, во второй мы ознакомились с практической реализацией этой технологии на примере создания приложения с использованием программного инструментария Bold for Delphi. Прежде чем двигаться дальше, целесообразно сообщить некоторую дополнительную информацию о текущем состоянии и особенностях реализации технологии MDA в Borland Delphi.
Как уже говорилось, компания BoldSoft была приобретена фирмой Borland и в последнее время название продукта Bold for Delphi все чаще заменяется на Borland MDA. Более того, предыдущие версии Bold for Delphi в настоящее время недоступны для разработчиков, и поэтому единственным продуктом реализации MDA в Delphi сейчас является Borland Delphi 7 Studio Architect (существует также возможность обновления версии Borland Delphi 7 Studio Enterprise). Все текущие и последующие обновления Borland MDA осуществляет Borland (недавно вышла последняя обновленная версия Bold for Delphi 4.0.0.21, доступная на Web-сайте компании Borland зарегистрированным пользователям).
С большой долей вероятности можно утверждать, что в ближайшее время технология Bold будет полностью интегрирована в новые версии продуктов Borland. С учетом приобретения фирмой Borland компании TogetherSoft можно прогнозировать интеграцию продуктов этих компаний, что должно привести к весьма впечатляющим результатам.
Однако необходимо отметить, что на пути практического овладения технологией Borland MDA разработчик может столкнуться с некоторыми трудностями.
Во-первых, Borland MDA - это сложная и объемная программная система. В простом примере, рассмотренном в предыдущей части статьи, из всего арсенала ее возможностей был использован только весьма незначительный процент. На самом деле Borland MDA включает около 1700 новых классов, содержащих тысячи атрибутов и методов. Достаточно сказать, что встроенная справка по продукту насчитывает порядка 10 тыс. статей.
Во-вторых, в настоящее время технической информации о Borland MDA явно недостаточно. Несмотря на большой объем встроенной справки, она, к сожалению, весьма лаконична. Практически единственным полезным источником конкретной информации о продукте в настоящее время являются Интернет-конференции на новостном сервере Borland (<forums.borland.com>), где размещены две основные группы новостей по Borland MDA: borland.public.delphi.modeldrivenarchitecture.general и borland.public.delphi.modeldrivenarchitecture.thirdpary. Кроме того, полезная коллекция ссылок по данной теме собрана на сайте www.boldbox.com. Остается надеяться, что в дальнейшем ситуация изменится к лучшему.
И наконец, в-третьих, Borland MDA - это качественно новая технология разработки, можно сказать, целый новый мир, и переход на нее возможен лишь при перестройке мировоззрения разработчика. Здесь все непривычно, если отталкиваться от традиционных методов и средств. Поэтому на практике вполне возможна довольно парадоксальная ситуация: чем меньше у разработчика опыта создания приложений баз данных, тем легче ему будет освоиться в Borland MDA.
Далее в этой и в последующих частях статьи будут рассмотрены (с возможной степенью детальности, ограниченной рамками журнальных публикаций) основы Borland MDA. И начнем, в полном соответствии с названием технологии - Model Driven Architecture, с модели приложения.
Роль модели в Bold
Как уже говорилось, модель приложения является основой MDA-технологии. Она содержит состав, структуру и элементы поведения разрабатываемого приложения. С позиции Bold модель имеет следующее функциональное назначение:
- определяет состав и тип классов и атрибутов классов;
- фиксирует наличие связей между классами, определяет тип этих связей и их размерность;
- определяет условия и ограничения, накладываемые на классы и их атрибуты; такие условия формируются на диалекте языка OCL, встроенного в Bold;
- содержит информацию для адаптации к среде разработки Delphi в виде набора специальных тэг-параметров;
- содержит информацию для адаптации к СУБД - также в виде набора специальных тэг-параметров.
В Bold, таким образом, отсутствует четкое разделение между PIM (Platform Independent Model)- и PSM (Platform Specific Model)-моделями MDA (см. первую часть статьи), а вся необходимая информация содержится в одной общей модели. Функции PSM-модели в основном выполняет набор тэг-параметров (tagged values), которые будут описаны ниже. Кроме того, такие функции могут выполнять и некоторые компоненты Bold, являющиеся адаптерами СУБД (вопросам взаимодействия Borland MDA и СУБД будет посвящена отдельная часть данной статьи).
Bold использует модель для реализации следующих основных функций:
1. Генерация кода. Под генерацией кода понимается автоматическое создание модулей описаний (*.inc-файлов) и функциональных модулей (*.pas-файлов) на языке Object Pascal, содержащих полную реализацию классов модели приложения. Строго говоря, сам по себе Bold не нуждается в генерации кода. Как мы уже видели на примере простого приложения и увидим в дальнейшем, можно создавать достаточно серьезные приложения, вообще не используя генерацию кода. Однако в некоторых случаях она бывает необходимой. Общая стратегия здесь выглядит примерно так: если поддерживаемых Bold возможностей языка OCL недостаточно для реализации, например, желаемых методов или вычисляемых атрибутов на бизнес-уровне, то разработчик вправе опуститься на уровень программного кода. Кроме того, генерация кода необходима, если классы модели содержат операции. Генерацию кода можно произвести из встроенного редактора модели (Model Editor) на этапе разработки приложения. Кроме генерации кода, Bold обеспечивает и возможность генерации интерфейсов, необходимых для функционирования распределенных DCOM-приложений.
2. Генерация схемы базы данных. Структура базы данных (то есть набор описаний таблиц, полей, индексов и ключей) может быть сгенерирована автоматически как из встроенного редактора модели на этапе разработки, так и программно во время выполнения приложения. Bold также поддерживает синхронизацию структуры базы данных с изменяющейся во времени моделью приложения (Model Evolution - эволюция модели), при этом сохраняется уже имеющаяся в БД информация. Такая возможность в Bold носит специальное название - эволюция базы данных (DataBase Evolution). В дальнейшем эти вопросы мы рассмотрим подробнее. Необходимо иметь в виду, что между составом классов модели и составом таблиц генерируемой базы данных нет взаимно-однозначного соответствия. Во-первых, Bold использует ряд таблиц БД для собственных нужд и создает их автоматически. Во-вторых, не все классы модели требуют сохранения информации объектов в БД (persistent class), а могут быть транзиентными (transient) классами, кроме того, даже в persistent-классах модели часто присутствуют вычисляемые (derived) атрибуты, которые не сохраняются в базе данных. И в-третьих, в ряде случаев принципиально невозможно в реляционной БД реализовать некоторые виды отношений (см. следующий раздел).
3. Интерпретация модели во время выполнения для управления поведением приложения. Вся информация о модели сохраняется в компоненте TBoldModel и на этапе выполнения приложения используется для управления объектным пространством, для контроля его целостности, а также для управления взаимодействием бизнес-уровня с уровнем данных и графическим интерфейсом. Объектное пространство (Object Spase) в Borland MDA является экземпляром модели по аналогии с тем, как объект является экземпляром класса в ООП. Управление каждым объектным пространством обеспечивается компонентом TBoldSystemHandle. Информацию о типах этот компонент получает из компонента TBoldSystemTypeInfoHandle.
В основе создания модели приложения лежит унифицированный язык моделирования (UML), а более конкретно - диаграмма классов. Понимание основ создания диаграммы классов является необходимым условием практического применения MDA. Для полного понимания диаграмм классов необходимо знание UML, систематическое описание которого выходит за рамки данной публикации, однако, с учетом того обстоятельства, что для понимания основ работы с Bold вполне достаточно начальных сведений о диаграмме классов, ниже очень кратко описаны базовые элементы и правила, на основе которых можно будет в дальнейшем формировать модели приложений.
Основы создания диаграммы классов
В состав стандарта UML входит восемь типов основных диаграмм, исчерпывающим образом описывающих моделируемое приложение. Bold использует только один из них - диаграмму классов (class diagram).
Диаграмма классов является основным источником платформенно-независимой информации (PIM) для формирования модели приложения в Borland MDA. Она занимает центральное место в объектно-ориентированном анализе и проектировании (ООАП) программных систем. Диаграмма классов описывает статическую структуру системы, то есть состав элементов (классов), состав их атрибутов и операций, а также связи между классами (отношения). В ней не содержится информация о развитии системы во времени.
В основе диаграммы классов лежит понятие класса. Не углубляясь сейчас в детали, будем считать, что понятие класса знакомо разработчикам, использующим методологию объектно-ориентированного программирования. Итак, класс изображается в UML-модели в виде прямоугольника, разделенного на две или три части (рис. 1). В верхней части отображается имя класса - это обязательный параметр. Во второй сверху части отображаются атрибуты класса, возможно - с указанием их типа и значения по умолчанию. В нижней части класса отображаются названия операций и, возможно, списки аргументов и тип возвращаемого результата. Атрибутов и операций у класса может быть несколько. С точки зрения программиста атрибуты и операции аналогичны соответственно свойствам и методам в объектно-ориентированном программировании (ООП). Класс, который не может иметь ни одного объекта (экземпляра), является абстрактным. В этом случае его название отображается курсивом.
Рис. 1
Отношения (relationship) между классами в UML сводятся к четырем базовым типам:
- зависимость (dependency);
- ассоциация (association);
- обобщение (generalization);
- реализация (realization).
Рассмотрим сейчас только два из них - ассоциацию и обобщение.
Ассоциация указывает на наличие некоторой связи между классами, например, «отдел-сотрудники». Она отображается сплошной линией (рис. 2). Линия ассоциации может соединять два (бинарная ассоциация) или более (N-ассоциация) классов. В последнем случае место соединения нескольких ассоциаций обозначается ромбом (на рис. 2 представлена бинарная ассоциация). Ассоциация может иметь имя, в этом случае оно располагается над линией ассоциации (на рис. 2 имя отсутствует). Концам линии ассоциации - ролям - даются названия. В данном случае ассоциация обладает ролями «Включает» и «Работает в». Кроме того, концы линии ассоциации имеют обозначения размерности, которые указывают на кратность отношения. Так, из рис. 2 можно сделать следующие выводы относительно описываемой модели (то есть восстановить заложенные в нее бизнес-правила):
Рис. 2
- каждый отдел включает одного или несколько сотрудников (размерность «1..n»);
- каждый сотрудник работает только в одном отделе (размерность «1»).
Легко заметить кажущуюся аналогию между ассоциацией в UML и реляционными отношениями типа «один ко многим» и «многие ко многим» в СУБД. Однако далеко эту аналогию провести не удастся. Во-первых, в реляционной БД связь «многие ко многим» не может соединять две таблицы - для этого обязательно требуется еще одна промежуточная таблица. В UML же это вполне допустимо. Во-вторых, кратность в UML в принципе может быть любой, в том числе и нулевой. Так, если бы мы на конце ассоциации, указывающей на сотрудника, написали «0..n», то это означало бы, что могут существовать отделы, не имеющие ни одного сотрудника. А если бы мы задали кратность «15..50», то это говорило бы о том, что численность сотрудников в отделе не может быть меньше 15 и больше 50.
Нельзя не упомянуть и еще об одном важном варианте использования ассоциации. Рассмотрим UML-модель, изображенную на рис. 3. В ней оба конца ассоциации подключены к одному и тому же классу и определяют следующие бизнес-правила:
Рис. 3
- каждый сотрудник может находиться в подчинении только у одного сотрудника (например, в подчинении у руководителя) либо не подчиняться ни одному из сотрудников (если он сам является руководителем);
- каждый сотрудник может руководить несколькими сотрудниками (если он является руководителем) либо не руководить ни одним (если он является рядовым сотрудником).
Использование ассоциаций в таком варианте нередко встречается при создании моделей приложений.
Вторым типом рассматриваемых отношений является обобщение, или генерализация. Данный тип отношения указывает, что между классами существует связь типа «предок-потомок», аналогичная отношению наследования в ООП. Такая связь отображается линией со стрелкой в форме пустого треугольника, причем треугольник-стрелка указывает на «предка», то есть на родительский класс. Так, на рис. 4 показано отношение обобщения между родительским классом «Человек» и дочерним классом «Гражданин». При этом необходимо учитывать, что все атрибуты класса-родителя автоматически принадлежат и классу-потомку, хотя в нем не отображаются. Поэтому класс «Гражданин», кроме представленных в нем атрибутов «Гражданство» и «Номер удостоверения личности», будет включать и атрибуты «Имя», «Вес» и «Рост». Отношения обобщения довольно часто используются при построении моделей, при этом в качестве класса-родителя нередко выступает какой-нибудь абстрактный класс.
Рис. 4
Итак, мы ознакомились с базовыми понятиями, используемыми при построении диаграмм классов. В дальнейшем мы поговорим и о некоторых других возможностях и свойствах UML.
Тэг-параметры (tagged values)
Для функционирования Bold кроме UML-модели используется набор специальных переменных-параметров (tagged values), или тэг-параметров. Они необходимы для взаимодействия со средой разработки и СУБД, а также для дополнительных настроек модели.
Появление тэг-параметров не случайно. Если UML-модель можно рассматривать как платформенно-независимую PIM-модель, то совокупность тэг-параметров можно считать элементом платформенно-зависимой PSM-модели. Будучи по этой причине связанными с PIM, тэг-параметры классифицируются по принадлежности к элементам иерархической структуры модели. Таким образом, существуют отдельные наборы тэг-параметров для следующих элементов иерархии модели:
- модель в целом;
- класс;
- ассоциация;
- атрибут;
- роль;
- операция.
Тэг-параметры можно также классифицировать и по функциональной принадлежности:
- общие;
- используемые для генерации кода и интерфейсов;
- используемые для отображения на уровне данных (Persistence Mapping);
- используемые для описания принадлежности к уровню данных (Persistence).
Разработчик также может создавать собственные тэг-параметры и использовать их для своих целей. Значения тэг-параметров доступны как на этапе разработки приложения, так и во время его выполнения.
Bold включает несколько десятков тэг-параметров. Мы рассмотрим их, когда речь пойдет о технологии разработки моделей приложений для Bold в UML-редакторах. Этой теме будет посвящена следующая часть данной публикации.