Совместное использование Delphi и Rational Rose при проектировании пользовательского интерфейса

Роман Алфимов, Елена Золотухина

Введение

Что мы хотим от Rational Rose и Delphi

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

Что не умеет RDL

Пример совместного использования Delphi и Rational Rose

Заключение

Введение

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

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

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

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

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

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

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

Что мы хотим от Rational Rose и Delphi

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

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

Как можно заметить из таблицы, основное взаимодействие 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).

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

Прежде всего заметим, что код, создаваемый RDL, не содержит реализации (для объектной модели это, как правило, — тело метода). Когда модель обновляется из кода Delphi (reverse engeneering или round trip), модель не подгружает программный код, написанный в среде Delphi, для тел методов. Изменения в модели касаются только декларативных элементов: определений классов, интерфейсов, типов, записей и т.п. Однако, при повторной генерации кода из Rose, тела методов в Delphi также остаются неизменными, а меняются лишь декларативные элементы.  Следовательно, невозможно «испортить» программный код при повторной генерации. Для отображения элементов модели в программный код RDL использует Code Generation Properties (CGP) — набор специальных таблиц, которые связываются с каждым элементом моделей Rational Rose и содержат специфическую для Delphi информацию, используемую для кодогенерации. Набор этих таблиц (рис. 2) доступен из главного меню (пункт Tools/Options, закладка 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 отображает типовые приемы проектирования в программный код.

1. Наследование от класса и реализация интерфейса

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

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

2. Ассоциативные связи с ролями и различной кардинальностью связи

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

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, который должен представлять коллекцию.

3. Агрегация и композиция

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

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.

Что не умеет RDL

Ранее мы определили, что, по нашему мнению, должен обеспечивать кодогенератор Delphi. В целом RDL охватывает все перечисленные возможности, пожалуй, за одним исключением — он не позволяет создавать формы. Вы можете представить себе среду Delphi без форм? Мы тоже не можем. Основная парадигма визуального программирования в среде Delphi состоит в задании значений соответствующих свойств (значений атрибутов классов) и в написании кода обработчиков событий. И  в этом, к сожалению, RDL нам не помощник. Но действительно ли это столь серьезное ограничение? Здесь могут существовать различные мнения.

Один из путей создания приложения таков: проектируется пользовательский интерфейс в среде Delphi (а где это сделать быстрее и проще?) и выполняется преобразование программного кода в модели Rational Rose. Несмотря на то что формы получаются достаточно громоздкими, их можно «причесать», но главное — не отображать в них несущественные детали. В Rational Rose проектируются собственно объектная модель, модель данных, компонентная модель, то есть архитектурно существенные элементы. В сочетании с моделью пользовательского интерфейса системы они образуют такую структуру системы, которая может быть отслежена средствами управления конфигурациями, включается в документацию, легко анализируется на предмет наличия принципиальных ошибок и является основой для функционального тестирования, то есть может быть использована на любом этапе жизненного цикла (ЖЦ) разработки ПО. RDL при этом обеспечивает полное согласование моделей и программного кода в течение всего ЖЦ ПО. Мы стараемся придерживаться именно такого подхода.

Пример совместного использования Delphi и Rational Rose

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

В качестве примера мы выбрали фрагмент системы, обеспечивающей отображение показателей состояния пациента для лечащего врача. Функциональные требования к системе представлены в виде диаграммы (рис. 3).

На диаграмме отражены три действующих объекта: администратор, прибор, врач. Функции системы, связанные с прибором, мы рассматривать не будем. В отношении прибора для нас существенно, что показатель получается с определенной периодичностью и что система предоставляет интерфейс для его сохранения в базе данных. Все оставшиеся функции системы связаны с пользовательским интерфейсом и обеспечением хранения информации в БД или ее выборкой.

В основу системы мы закладываем следующие архитектурные решения:

• пользовательский интерфейс (GUI) системы строится на основе объектной модели Delphi;
• интерфейс с СУБД строится на основе объектной модели Delphi;
• в качестве СУБД используется реляционная СУБД.

При проектировании системы мы должны определить: классы для представления пользовательского интерфейса (boundary classes); управляющие классы, реализующие логику работы системы (control classes); классы-сущности для отображения структуры хранения информации (entity classes).

Классы-сущности, спроектированные нами, представлены на рис. 4.

Из объектной модели классов-сущностей мы получили физическую модель данных для реляционной СУБД и обеспечили ее генерацию для конкретной СУБД. Подробности того, как это можно сделать в среде Rational Rose, здесь мы опускаем.

Поскольку мы планируем построение GUI на основе объектной модели Delphi, разумно предположить, что классы для представления пользовательского интерфейса (boundary classes) можно получить при прототипировании пользовательского интерфейса в среде Delphi. Классы пользовательского интерфейса (boundary classes) проектируются для формы, представленной на рис. 5.

Окно, представленное на рис. 6, является основным при согласовании объектных моделей Delphi и Rose. При его использовании реализуется любая из трех технологий совместной работы: прямое проектирование, обратное проектирование и согласование (round trip). Левая панель на экране содержит дерево проекта в Rational Rose (в части Component View), правая панель — дерево проекта в Delphi. Для обновления информации о проектах нужно нажать кнопку Refresh, а для выполнения согласования моделей в ту или иную сторону (из Rational Rose в Delphi или из Delphi в Rational Rose) — кнопки Update All. С целью удобства работы рассогласованные элементы в моделях помечены восклицательным знаком. Для выбора требуемого проекта в Delphi следует воспользоваться главным меню окна.

Мы выполнили согласование моделей с помощью данного окна и при этом получили следующее:

1. Каждому модулю проекта в Delphi сопоставлен компонент со стереотипом <Unit> в разделе Component View дерева проекта Rose. Нашему проекту patient.dpr сопоставлен компонент со стереотипом <Program>.
2. Для каждого модуля Delphi в разделе Logical View образовался пакет со стереотипом <Unit>, а внутри пакета содержится диаграмма классов, соответствующая данному модулю. У нас получился один такой модуль — main. Рядом в дереве проекта находится ссылка на файл main.pas, и посредством единственного щелчка мышью мы можем перейти к нему в среде Delphi и посмотреть на внешний вид формы. Это принципиально важно, поскольку какими бы изобразительными возможностями ни обладал язык UML, внешний вид формы с его использованием описать затруднительно (да и зачем?). Фактически мы обеспечиваем представление модуля в двух срезах: с точки зрения внешнего представления интерфейса пользователя и с точки зрения объектной модели. На наш взгляд, отсутствие одного из этих срезов давало бы неполную картину.

Диаграмма классов для модуля main представлена на рис. 7.

На диаграмме классов мы убрали атрибуты и операции для всех классов объектной модели Delphi: поскольку этих атрибутов и операций в каждом классе несколько десятков, то диаграмма в таком случае стала бы необозримой. Диаграмма наглядным образом демонстрирует, какие именно классы объектной модели Delphi используются для представления элементов пользовательского интерфейса и что именно они представляют. Из представления модели сразу  же следует исключить TGroupBox и TLabel как архитектурно несущественные элементы. Диаграмма классов для формы табличного редактирования представлена на рис. 8.

Кроме главного окна нам также потребуется интерфейс (GUI) для ведения базы данных пациентов, типов показателей и единиц измерения. Мы планируем использовать для этого типовую форму табличного редактирования на основе стандартных компонентов Delphi. Нарисуем эту форму в Delphi и преобразуем в модель Rational Rose (рис. 9).

Все остальные экранные формы при помощи механизма наследования получим от табличной формы редактирования. Пример того, как будет выглядеть справочник типов наблюдений, представлен на рис. 10.

Итак, с внешним видом пользовательского интерфейса мы полностью определились, и теперь можно сосредоточиться на реализации логики работы приложения. Для удобства (но не надо воспринимать это как типовую практику!) будем использовать в качестве управляющего класса уже существующий интерфейсный класс TMainForm.

TMainForm класс должен обеспечивать:

• навигацию между экранами, обработку событий нажатия кнопок для отображения других форм;
• заполнение выпадающих списков, пациентов, показателей, единиц измерения;
• автоматический расчет единицы измерения по типу показателя;
• выбор пациента по номеру карты;
• выбор номера карты по пациенту;
• расчет и отображение последнего значения показателя.

Создадим в среде Rational Rose операции для реализации описанных выше функций класса TMainForm (рис. 11).

Операции класса TMainForm следует разделить на две группы: расчеты и реакции на события. Операции, заканчивающиеся на Click или Change, а также FormShow — реакции на события, остальное — расчеты.

Операции должны реализовать следующее:

• FillPatientList — заполнение выпадающего списка пациентов;
• FillMeasureList — заполнение выпадающего списка единиц измерения;
• FillObservList — заполнение выпадающего списка типов наблюдений;
• CalcObservVal — расчет последней наблюдаемой величины;
• ChPatientByCard — поиск пациента по номеру карты;
• ChCardByPatient — поиск номера карты по пациенту;
• ChMeasureByObserv — вернуть единицу измерения для заданного типа наблюдений;
• CardValChange — реакция на изменение номера карты;
• PatientChComboChange — реакция на выбор нового пациента в списке;
• ObservTypeComboChange — реакция на выбор типа наблюдения;
• GetValueButtonClick — реакция на нажатие кнопки расчета значения;
• PatientDictClick — реакция на нажатие кнопки Пациенты;
• ObservTypeDictClick — реакция на нажатие кнопки Типы наблюдений;
• MeasureDictClick — реакция на нажатие кнопки Единицы измерения;
• FormShow — обработка при первом отображении формы на экране.

И последнее, что необходимо для завершения проектирования, — управляющие классы для реализации взаимодействия с базой данных. Без них невозможны ни заполнение базы данных, ни реализация расчетных операций управляющего класса TMainForm. Как и в случае интерфейсных классов, воспользуемся средой Delphi для проектирования управляющего класса взаимодействия с базой данных — TDataModule1, а затем выполним согласование моделей. Новый модуль взаимодействия с базой данных представлен на рис. 12.

На основе объектов QueryPatient, QueyObType, QueryMeasures и PatientDataSource, ObTypeDataSource, MeasureDataSource реализуется работа с базой данных пациентов, типов наблюдений и единиц измерения — стандартным для Delphi способом, основанным на использовании пары объектов классов TQuery, TDataSource и их взаимодействием с классами GUI. ObservDataSource используется для доступа к информации о сделанных наблюдениях. Для описания взаимодействия управляющих классов TDataModule1 и TMainForm следует создать несколько диаграмм взаимодействия, связанных с выполнением требуемых запросов к базе данных (в виду ограниченного объема статьи эти диаграммы мы опускаем).

Заметим, что в процессе добавления в систему новых модулей и классов и согласования моделей мы автоматически получили компонентную модель системы (рис. 13).

Итак, подведем краткие итоги. В результате совместного использования Rational Rose и Delphi мы получили:

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

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

Заключение

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

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

Во-вторых, это создание управляющих классов в моделях Rational Rose с последующей генерацией кода в Delphi. Управляющие классы представляются в среде Rational Rose при использовании UML более наглядно (в Delphi они могут быть «размыты» среди значительных по объему интерфейсных классов).

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

КомпьютерПресс 4'2001