Алфимов Р.В. Золотухина Е.Б.
Интерфейс, Москва 2000 г.

В настоящее время Delphi является одним из наиболее популярных программных продуктов для создания информационных систем. На его основе создаются как небольшие программы, так и системы масштаба предприятия. Чем же так привлекателен Delphi с точки зрения разработчика? Прежде всего, это конечно великолепная среда визуального программирования, понятная, простая для изучения и, зачастую, не требующая знаний профессионального разработчика (которые, как известно, по крупицам накапливаются в течение многих лет и десятилетий и стоят неимоверно дорого). В среде Delphi можно создавать достаточно сложные программные системы практически с нуля, написав минимум программного кода. При этом язык, на котором пишется программа, знакомый многим (по крайней мере, в нашей стране) Object Pascal, изучается в настоящее время на младших курсах большинства отечественных технических институтов.

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

Принципиальным для систем подобного класса является наличие базовой архитектуры (неизменной в течение всего жизненного цикла разработки и эксплуатации системы), основные элементы которой закладываются на ранних стадиях проектирования. Базовая архитектура создается, как правило, с использованием ряда моделей, отражающих основные моменты, связанные со структурой системы и ее функциями. К сожалению, среда Delphi для решения подобных задач не применима.

Но давайте вернемся к достоинствам Delphi. Если отбросить среду визуального программирования, то, что же останется? Объектная модель. А вот это уже достоинство Delphi, привлекательное с точки зрения проектировщика системы и именно объектная модель (как бы это не показалось кому-то странным) во много определяет успех среды визуального программирования. Объектная модель Delphi охватывает широкий круг задач, обеспечивая высокоуровневые (но при этом исключительно гибкие, практически без ограничений) средства организации пользовательского интерфейса, управления ресурсами операционной системы, манипулирования данными БД, поддержки стандартов открытых систем, поддержку популярных технологий (включая CORBA и COM), многоуровневую архитектуру и, наконец, Internet/Intranet технологии. Базовая архитектура может использовать элементы объектной модели Delphi (зачем заново создавать все выше перечисленное), дополнив ее необходимыми составляющими, отражающими прикладную специфику конкретной системы.

Мы используем для проектирования систем продукт Rational Rose фирмы Rational Software Corporation. Rational Rose обладает всеми необходимыми характеристиками для создания базовой архитектуры системы любого масштаба. Имея достаточный опыт программирования в среде Delphi, для нас привлекательным является использование Rational Rose и Delphi совместно, в рамках единого технологического процесса.

Целью настоящей статьи является рассмотрение совместного использования Rational Rose и Delphi и точное (разумеется, с нашей точки зрения) указание места каждого продукта в процессе разработки. Для разработчиков, мы надеемся, это позволит составить мнение о том, насколько подобная технология применима для их собственных нужд, и сэкономить время на изучении деталей.

Методология, которой мы следуем при разработке ПО, это методология разработки программного обеспечения Rational Unified Process фирмы Rational Software Corporation. Методология с технологической точки зрения включает в себя следующие этапы (разумеется, в рамках каждой итерации): моделирование предметной области, определение требований к системе, анализ и проектирование, реализацию (кодирование и автономную отладку), тестирование и внедрение. Ниже приведена таблица, в которой представлено то, что мы ожидаем получить при помощи Rational Rose и Delphi на каждом этапе (см. Табл. 1.).

Табл. 1. Использование Rational Rose и Delphi
на различных этапах разработки ПО

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

Для обеспечения связи между Delphi и Rose используется промежуточное ПО называемое кодогенератором. Строго говоря, задачи этого ПО не ограничиваются только генерацией кода. Прежде, чем перейти к описанию конкретного кодогенератора перечислим, что, по нашему мнению он должен обеспечивать.

Итак, кодогенератор должен:

• иметь возможность преобразовывать классы Rational Rose в код определения классов на целевом языке, в данном случае Delphi, при этом описание, связанное с конкретным классом должно помещаться в соответствующее место программного кода;
• для диаграммы классов поддерживать стереотипы, связанные со специфическими особенностями языка (например, стереотип unit, interface или property, соответственно определяя, что конкретный пакет – есть модуль Delphi или класс - есть интерфейс Delphi, или атрибут - есть свойство для компоненты Delphi);
• иметь описанный, очевидный и однозначный способ отображения диаграммы классов в код Delphi, при этом отображение должно быть настраиваемым;
• иметь возможность импорта актуальной объектной модели Delphi (желательно для различных версий библиотеки VCL);
• поддерживать генерацию кода для создания компонент Delphi;
• уметь правильным образом отображать типовые виды связей между классами (хотя бы обобщение, агрегацию и композицию);
• уметь отображать в программный код кардинальность связи;
• исходя из диаграммы компонент Rose, создавать проект Delphi, содержащий требуемые программные модули (forward engeneering);
• на основе готового проекта Delphi строить диаграмму компонент Rose, содержащую в виде компонент все модули проекта Delphi и связанные с ними классы, полученные из Delphi в результате обратного проектирования (reverse engeneering). Диаграммы должны быть компактными и очевидными;
• обеспечивать автоматическое согласование модели Rose и Delphi после внесения изменений в код модулей Delphi (round trip engeneering);
• после внесения изменений в модель Rose и повторной генерации кода не уничтожать, фрагменты, написанные в среде Delphi;
• помимо генерации кода иметь способ отображения такого важного элемента Delphi, как формы;
• на реальных проектах (сотни классов и модулей) работать с приемлемой производительностью.

Кодогенератор Delphi от фирмы Ensemble Systems, Inc.

Компания Ensemble Systems, Inc. в настоящее время является одним из ведущих поставщиков дополнительных компонент (add ins) для Rational Rose. Эти компоненты поддерживают кодогенерацию для широкого спектра популярных систем программирования, в том числе и для Delphi. Рассмотрим работу кодогенератора Delphi в среде Rational Rose.

После установки компонента Delphi от фирмы Ensemble Systems, Inc. в среде Rational Rose появляется новый пункт меню в разделе Tools (рис. 1).

Рис. 1. Пункты меню кодогенератора Delphi

Кодогенератор носит название Rose Delphi Link (RDL). Как пользоваться RDL мы опишем в следующем разделе, когда будем рассматривать конкретный пример. Сейчас же мы сосредоточим наше внимание на основных возможностях RDL (не имея о них представления вряд ли можно использовать его эффективно).

Прежде всего, заметим, что код, создаваемый RDL не содержит реализацию (для объектной модели это, как правило, это тело метода). Когда модель обновляется из кода Delphi (reverse engeneering или round trip), модель не подгружает программный код, написанный в среде Delphi для тел методов. Изменения в модели касаются только декларативных элементов: определений классов, интерфейсов, типов, записей и т. п. Однако, при повторной генерации кода из Rose, тела методов в Delphi также остаются неизменными, а меняются только декларативные элементы. Таким образом “испортить” программный код при повторной генерации нельзя. Для отображения элементов модели в программный код RDL использует Code Generation Properties (CGP) – набор специальных таблиц, которые связываются с каждым элементом моделей Rational Rose и содержат специфическую для Delphi информацию, используемую для кодогенерации. Набор этих таблиц доступен из главного меню (пункт Tools/Options, закладка Delphi) (рис. 2).

Рис. 2. Таблица свойств CGP для операций в кодогенераторе Delphi.

Для того, что бы CGP для Delphi было доступно из спецификации необходимо установить значение поля Default Language = Delphi в закладке Notation пункта меню Tools/Options. Для упрощения работы в разделе меню Tools/Ensemble Tools появляется также закладка Delphi Property Editor, где можно настроить свойства выбранного элемента модели. Заметим, что использование CGP является типичным приемом для всех кодогенераторов от Ensemble Systems, Inc и для Rational Rose вообще. При использовании Delphi Property Editor можно, не выполняя кодогенерации, просмотреть код соответствующего элемента модели (например, класса), что часто бывает очень удобно.

Теперь рассмотрим, как отображаются RDL в программный код конкретные типовые приемы проектирования

type SampleClass1 = class (BaseClass, SampleInterface)
{...}
end;

Преобразуется в код:

type SampleClass3 = class 
private
ArrayRole1 : array of SupplierClass2;
ArrayRole2 : array [1..10] of SupplierClass5;
ArrayRole3 : array [SampleRange] of SupplierClass3;
ArrayRole4 : TItems;
end;

Заметим, что для представления ролей с кардинальностью связи не равной 1 используются массивы (либо фиксированной длины, либо динамические). Константа SampleRange в примере должна быть определена в свойстве Array_Range для роли ArrayRole. Обратите внимание, что для Role4 в коде определен не массив, а тип TItems, который должен представлять коллекцию.

Преобразуется в код:

SampleClass1 = class
Public
A : SampleClass2;
B : SampleClass3;
C : array of SampleClass4;
D : array of SampleClass5;
end;

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

4. Стереотипы для типовых элементов программного кода Delphi RDL имеет несколько стереотипов для представления типовых элементов программного кода Delphi: указателей, массивов, файлов, ссылок на класс и т.п. Правда, на наш взгляд, эти элементы малоупотребительны при высокоуровневом проектировании объектной модели. В заключение краткого описания особенностей RDL отметим следующее. Важным элементом проектирования является документация в спецификации для соответствующего элемента модели. RDL обеспечивает ее передачу в программный код. Так для операций (методов класса Delphi) значение поля documentation в спецификации вставляется в код перед определением метода. И обратно, комментарии в программном коде Delphi могут быть преобразованы в поля documentation в спецификации элементов модели Rose.

| Вперед >>

Дополнительную информацию Вы можете получить в компании Interface Ltd.

Обсудить на форуме Rational Software
Отправить ссылку на страницу по e-mail