Рис. 6. Окно согласования моделей Rational Rose и Delphi

Это окно является основным при согласовании объектных моделей 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.

Рис. 7. Диаграмма классов для модуля main

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

Рис. 8. Диаграмма классов для формы табличного редактирования

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

Рис. 9. Табличная форма редактирования.

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

Рис. 10. Справочник типов наблюдений

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

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

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

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

Рис. 11. Класс TMainForm.

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

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

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

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

Рис. 12. Организация взаимодействия с БД

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

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

Рис. 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 они могут быть размыты среди значительных по объему интерфейсных классов).

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

<< Назад |

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

Отправить ссылку на страницу по e-mail