Что мы хотим от Rational Rose и Delphi. Эльф не может без любви, но и его не любить невозможно

Роза Эльф плетистая крупноцветковая была выведена в 2000 году немецкой компанией Tantau в серии «Ностальгические розы». Селекционерам удалось создать в этом растении изысканное сочетание нежного романтизма ностальгических с элегантным силуэтом чайно-гибридных роз.

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

Общая характеристика

Согласно официально принятой классификации Американского общества розоводов, которую используют многие цветоводы во всем мире, повторноцветущий Elfe является Modern Roses — современной садовой розой, относящейся к виду плетистых крупноцветковых (Large-Flowered Climber (LCI)). Роза Эльф плетистая образует прямостоячий сильнорослый куст, побеги которого могут вырастать до 3-4 метров в длину. Благодаря этому она прекрасно подойдет для стен домов и различных построек, украсит перголы и беседки. Рост длинных цветущих побегов можно направить как вверх, так и вниз опоры. В последнем случае они под тяжестью цветов и бутонов будут каскадом спускаться к земле. Сорт довольно устойчив к типичным заболеваниям и незначительным холодам, но в условиях средней полосы лучше зимует под укрытием.

Роза Эльф плетистая: описание цветков

Кроме необычного светло-желтого оттенка, этот сорт отличается большим размером махровых цветков, диаметр которых может варьироваться от 10 до 14 см. К достоинствам Elfe можно отнести и то, что на протяжении всего лета на сильных побегах образуется и расцветает множество бутонов в зонтиковидных соцветиях. В зависимости от состава и на которой она произрастает, окраска лепестков может незначительно варьироваться. К сожалению, роза Эльф плетистая (отзывы садоводов об этом свидетельствуют) достаточно сильно выгорает на солнце, цветы также могут пострадать от сильного дождя. Аромат у Elfe очень нежный, с мягкими фруктовыми нотками.

Куда посадить?

Роза Эльф плетистая предпочитает слабокислые или нейтральные плодородные легкие почвы, а также места, хорошо прогреваемые солнцем и проветриваемые, но защищенные от сильных ветров. Именно поэтому большинство специалистов по рекомендуют высаживать Elfe на приподнятых или высоких южных площадках. Благодаря такому размещению прирост будет развиваться активно и сможет зацвести уже на следующий год после посадки. Эти южные красавицы не выносят застоя влаги, поэтому не рекомендуют их высаживать на участках с высоким залеганием Важно помнить, выбирая место, где «обоснуется» плетистая роза Эльф: посадка и уход за ней требуют вокруг довольно много пространства. Продумайте заранее, как и куда вы будете укладывать куст на зиму, сможете ли вы закрыть все побеги.

Как подготовить саженец?

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

Высаживаем

Приступая к посадке любой плетистой розы, в том числе и Elfe, следует помнить, что расстояние между растением и любым строением должно быть не менее 0,5 метра. В противном случае будет перегреваться и пересыхать, а сам куст станет развиваться медленно и может погибнуть.

Для саженца необходимо подготовить лунку глубиной около 50-60 см. Ширина и глубина посадочной ямы зависят от того, насколько развита корневая система растения. Копая яму, нужно помнить, что корни должны располагаться в ней свободно. После того как лунка будет готова, в нее вносят 3-4 кг перепревшего компоста, перемешанного с садовой землей, или коровьего навоза, и хорошо проливают водой.

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

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

Как ухаживать?

Уже на следующий год после посадки роза Эльф плетистая ухода и внимания требует значительно меньше.

Достаточно своевременно удалять и обрезать куст, поливать и подкармливать растение удобрениями. Подрезают розовые кусты, прореживая внутренний объем, а также формируя растение в соответствии с дизайном сада или творческим замыслом цветовода. Поливать розы нужно нечасто, один раз в 7-10 дней, но обильно. Внесенного при посадке навоза или перегноя хватит на первые годы роста, а вот в дальнейшем королеву цветов нужно подкармливать как органическими, так и минеральными удобрениями не менее 5 раз за сезон.

Компания Rational Software уже несколько лет является лидером в области создания инструментальных средств для проектирования, разработки, тестирования и сопровождения программного обеспечения. Основным продуктом в линейке Rational является CASE-средство Rational Rose. Rational Rose поддерживает визуальное объектно-ориентированное моделирование (UML), поддерживает генерацию кода и обратное проектирование (построение модели по программному коду) для многих языков программирования, позволяет строить объектную модель разрабатываемой программной системы, определять спецификации классов, объектов, атрибутов и операций (подробнее см. "Программист" №№ 2, 3, 5/6 за 2001 год).

Так как Rational Rose обладает всеми необходимыми характеристиками для проектирования архитектуры системы любого масштаба, напрашивается идея использования Rose с такой мощной и популярной системой программирования, как Delphi. В стандартной поставке Rational Rose не предусмотрена возможность работы с Delphi, но Rational Software ведет программу по поддержке сторонних производителей программ-мостов (Links) между Rose и другими средствами разработки. В рамках этой программы фирмой Ensemble Systems была разработана программа-мост Rose Delphi Link (RDL), связывающая Rational Rose и Delphi. Основные функции RDL - генерация кода и обратное проектирование. Следует помнить, что генерируемый RDL код не содержит реализацию функциональности! Генерируются только декларативные элементы: определения классов, интерфейсов, записей, типов, директивы видимости и т.д.


Рисунок 1. Пункт меню RDL

Прежде чем переходить к рассмотрению Rose Delphi Link, напомню основные этапы работы в среде Rational Rose. Как правило, используется следующий подход:

  1. Определение требований к системе и построение модели взаимодействия элементов системы (Use Case Diagram и Collaboration Diagram). Для детализации Use Case используются Sequence Diagram. На этих диаграммах отображаются объекты предметной области, участвующие в бизнес-процессах. Эти диаграммы не влияют на генерируемый код.
  2. Построение аппаратной модели системы (Deployment Diagram). На этой диаграмме отображается модель системы в аппаратной реализации. Диаграмма не влияет на код, генерируемый RDL.
  3. Разработка объектной модели системы (определение классов, их взаимодействий, атрибутов, операций). Параллельно с разработкой диаграммы классов, как правило, разрабатывается диаграмма компонентов (Component Diagram), которая отображает взаимодействие файлов, модулей, дополнительных библиотек, использующихся в системе. Диаграмма компонентов также не влияет на генерацию кода.
  4. Генерация кода программы.
    На генерацию кода влияют только диаграммы классов, поэтому в рамках данной статьи мы будем рассматривать только диаграммы секции Logical View. Особенности построения других диаграмм опущены. Перечисленные этапы проектирования в среде Rational Rose применяются для разработки модели и генерации кода на различных языках, поддерживаемых средой Rose. Но в Delphi есть особенность, существенно отличающая разработку в Delphi от разработки в других средах программирования: программирование пользовательского интерфейса. Не секрет, что в Delphi разработка большей части программ начинается именно с проектирования интерфейса пользователя, а при дальнейшем программировании - его существенного изменения. Поэтому использовать стандартный подход Rational Rose не совсем удобно. Для решения этой проблемы компания Ensemble Systems предлагает следующую методологию проектирования:


Рисунок 2. Методология проектирования с использованием RDL

Основная идея такого подхода состоит в использовании обратного проектирования (Round-trip engineering): все изменения, сделанные на уровне программного кода в Delphi, отображаются в объектной модели, построенной в Rose, и наоборот, при изменении классов, методов и т.п. в объектной модели Rose, соответственно, корректируется программный код. Обратите внимание на пару стрелок, которые соединяют третий и четвертый блок. Как раз эти стрелки и отображают процесс обратного проектирования.
Рассмотрим основное окно Rose Delphi Link (рис. 3). Интерфейс достаточно прост, он содержит:

  • меню, содержащее команды для работы с проектом, настройки опций и вызова помощи;
  • панели, на которых в виде деревьев отображаются иерархические структуры моделей Rose и Delphi;
  • кнопка обновления объектных деревьев, кнопки обратного проектирования (Update All) и прямого проектирования, т.е. генерации кода (Update All->).


Рисунок 3. Основное окно Rose Delphi Link

Основное окно RDL является дочерним по отношению к главному окну Rational Rose и постоянно находится поверх этого окна, сворачивается так же как дочернее окно, что, несомненно, очень удобно.
Перед тем как разбирать конкретный пример, рассмотрим подробнее пункты меню Rose Delphi Link.
File -> Open Project - служит для открытия в RDL созданного проекта Delphi. При открытии проекта в окне RDL отображаются объектные деревья открываемого проекта.
File -> New Project - при выборе этого пункта меню RDL предлагает создать пустой Delphi-проект. Файл проекта, создающийся в этом случае, содержит только декларативные элементы, необходимые для минимальной программы Delphi (program, begin, end). Новый проект стоит создавать в случае, если программа не содержит графического пользовательского интерфейса, например, динамическая библиотека. Правда, в этом случае в генерируемый код нужно будет внести корректировку - заменить program на library. С помощью контекстного меню можно создавать модули (unit) и дополнительные директории для модулей. Создаваемые таким образом модули также содержат только минимальную реализацию (uses, interface, implementation, end). После создания модуля, при последующей генерации кода, в секцию uses файла проекта добавляется объявление нового модуля.
Пункты меню View и Help стандартны, и в описании в рамках данной статьи не нуждаются.

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

  • Заполнять массивы случайными числами в пределах от 1 до 10;
  • Вычислять сумму элементов каждого массива;
  • Определять среднее арифметическое значение элементов;
  • Очищать массивы (инициализировать их нулями).

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


Рисунок 4. Интерфейс разрабатываемой программы

Сохраним этот проект с именами модулей, предлагаемыми Delphi по умолчанию, откроем новый проект Rational Rose, и запустим Delphi Rose Link. Выберем пункт меню Open Project, и откроем только что сохраненный в Delphi проект. В окне RDL отобразятся деревья объектов модели Rose и проекта Delphi (рис. 5).


Рисунок 5. Проект Delphi, открытый в RDL

Левое дерево объектов - это объекты модели Rose, правое дерево - это объекты, объявленные в исходном коде Delphi. Обратите внимание на красные восклицательные знаки слева от значков, обозначающих объекты. Они обозначают различия между кодом Delphi и моделью Rose. Сейчас отмечены все значки, так как модели в Rose пока еще вообще не существует.
Следующий шаг - генерация модели Rose по исходному коду. Для начала генерации нужно нажать кнопку Update All. В случае успешной генерации восклицательные значки у объектов исчезают, что означает, что модель Rose для каждого объекта соответствует исходному коду Delphi. Чтобы посмотреть историю сообщений генерации, надо выбрать пункт меню View -> Messages. В открывшемся окне будет отображен достаточно подробный лог сообщений RDL, выводимых при генерации модели или исходного кода.
Свернем Rose Delphi Link, и в браузере объектов Rose выберем ветку Logical View. Видим два появившиеся пакета: <>Unit1, который содержит объектную модель кода из модуля Unit1.pas, и External References, содержащий объекты Delphi, которые объявлены в модулях вне текущего проекта (объекты библиотеки VCL).
Теперь откроем в среде Rose диаграмму классов, соответствующую модулю Unit1 (Logical View -> Unit1 -> Overview). В первоначальном виде на диаграмме представлена немножко запутанная объектная модель, которую мы приведем в порядок, аккуратно расположив объекты согласно их иерархии (рис. 6).


Рисунок 6. Модель объектов модуля Unit1

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

Создадим новый модуль. Сделать это можно и в Delphi, и в Rose, и в RDL, но для чистоты эксперимента создавать все будем только в RDL. В Rose активизируем окно RDL и щелкнем правой кнопкой мыши по корневому элементу в дереве объектов модели Rose - в нашем случае это Model1.mdl. В контекстном меню выберем New -> Unit. Откроется окно редактора компонента (Component Editor) (рис. 7). На вкладке General указывается имя модуля (Unit2), и комментарий к создаваемому модулю, который при кодогенерации будет вставлен в модуль как комментарий. На вкладке Detail указывается вид (kind) компонента, и путь к исходному файлу. На вкладке Code Preview можно посмотреть код, который будет сгенерирован RDL для данного модуля. Выключение переключателя Allow Code/Model Updates запрещает генерацию кода и обновление модели для выбранного элемента.


Рисунок 7. Редактор компонента

После нажатия кнопки Ok видим, что в окне RDL появился значок, обозначающий новый модуль, и рядом с ним восклицательный знак, сигнализирующий о том, что модель Rose и код Delphi не синхронизированы. Обновим код Delphi, нажав кнопку Update All->. Теперь нужно переключиться на Delphi. Видим окно, предупреждающее, что модуль был изменен (рис. 8). Для загрузки обновленного модуля нажмем Ok.


Рисунок 8. Сообщение Delphi об изменении файла проекта

Теперь откроем только что сгенерированный модуль Unit2.pas. Можно убедиться, что генерация кода прошла успешно - объявлены все необходимые ключевые слова, вставлен комментарий. Следующий шаг - моделирование классов и их методов в этом модуле. Перейдем в Rose, и активизируем окно RDL. В дереве объектов выведем контекстное меню на объекте Unit2 и выберем пункты New -> Class. Появляется окно редактора класса (Class Editor) (рис. 9). На вкладке General нужно указать имя класса (Name), вид (Kind), видимость (Visibility) и комментарий к классу (Documentation). В нашем случае класс будет называться TMassiv, область видимости для него - Public.


Рисунок 9. Редактор класса

Для создания всех методов и атрибутов класса будем пользоваться пунктом меню New в контекстном меню класса в дереве объектов RDL. Редакторы атрибутов и методов в основном аналогичны редактору класса, поэтому подробности создания опустим. Создадим следующие атрибуты и методы (все методы с директивами видимости Public, атрибут M имеет видимость Private):
M: array of Integer; procedure Init; // Инициализация массива procedure FillMassiv; // Заполнение массива случайными числами procedure CalcSum; // Подсчет суммы элементов массива procedure CalcSr; // Подсчет среднего значения элементов массива function GetElement(X, Y: integer): Integer; // Получение элемента массива (x,y) Также создадим метод для класса TForm1, который будет заполнять компоненты TMemo, расположенные на форме, элементами из массивов:

Procedure GetMassiv;

В создании методов с параметрами есть некоторая особенность. Сначала метод создается обычным способом, затем, в дереве объектов RDL, в контекстном меню на методе, для которого предлагается указать параметр, выбирается пункт New -> Parameter и указывается имя параметра, его тип и комментарий к нему. После создания класса обратите внимание на диаграмму классов для модуля Unit2 в Rose - наш класс отображен в соответствии со спецификацией UML (рис. 10).


Рисунок 10. Диаграмма классов с созданным классом

Итак, класс создан, точнее его оболочка, пока без реализации. Теперь в основном модуле Unit1 создадим два экземпляра этого класса. Объявим их как M1 и M2 в секции Public класса TForm1. Это делается выбором нужных пунктов в контекстном меню дерева объектов и указанием параметров в редакторе атрибутов. Измененная диаграмма, где в классе TForm1 показаны объявленные экземпляры класса, изображена на рис. 11.


Рисунок 11. Экземпляры класса, объявленные в секции public класса TForm1

Итак, модель построена, и теперь нужно сгенерировать окончательный код. В окне RDL жмем Refresh, Update All-> и переходим в среду Delphi. Теперь надо написать код, реализующий функциональность, и откомпилировать программу. При заполнении методов кодом иногда требуется добавить локальные или глобальные переменные. Это можно сделать в RDL, но лучше реализовать эти переменные в коде, а затем обновить модель Rose по исходному коду Delphi (Update All). Если в модели были удалены некоторые элементы, а в коде они уже реализованы, этот код заключается между директивами компилятора {$IFDEF DELETED} и {$ENDIF}. После реализации всего исходного кода в Delphi вернемся в RDL и еще раз выполним обратное проектирование, нажав Refresh и Update All. Класс TForm1 изменился - в нем появились методы - обработчики событий кнопок (рис. 12). В нашем случае это окончательный вариант диаграммы классов и всей модели в целом.


Рисунок 12. Окончательный вариант диаграммы классов для модуля Unit1

Окончательный исходный код программы и построенную модель Rose можно .

В рассмотренном примере мы следовали методике разработки приложений, предложенной разработчиком Rose Delphi Link, и в результате получили объектную модель системы. Все классы и диаграммы, описывающее деятельность системы были спроектированы в Rational Rose с помощью программы Rose Delphi Link. Итак, выделим основные преимущества совместного использования RDL и Rational Rose:

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

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

Литература:

  1. Вендров А.М. Проектирование программного обеспечения экономических информационных систем. - М.: Финансы и статистика, 2000 г.
  2. Трофимов С.А. CASE-технологии: практическая работа в Rational Rose - "Издательство БИНОМ", 2001 г.
  3. Буч Г., Рамбо Д., Джекобсон А. Язык UML. Руководство пользователя: Пер. с англ. - М.

Материал был опубликован в мартовском
номере журнала "Программист" за 2002 год

Компания

Rational Software уже несколько лет является лидером в области создания инструментальных средств для проектирования, разработки, тестирования и сопровождения программного обеспечения. Основным продуктом в линейке Rational является CASE-средство Rational Rose. Rational Rose поддерживает визуальное объектно-ориентированное моделирование (UML), поддерживает генерацию кода и обратное проектирование (построение модели по программному коду) для многих языков программирования, позволяет строить объектную модель разрабатываемой программной системы, определять спецификации классов, объектов, атрибутов и операций (подробнее см. “Программист” №№ 2, 3, 5/6 за 2001 год). Rational Rose обладает всеми необходимыми характеристиками для проектирования архитектуры системы любого масштаба, напрашивается идея использования Rose с такой мощной и популярной системой программирования, как Delphi. В стандартной поставке Rational Rose не предусмотрена возможность работы с Delphi, но Rational Software ведет программу по поддержке сторонних производителей программ-мостов (Links) между Rose и другими средствами разработки. В рамках этой программы фирмой Ensemble Systems была разработана программа-мост Rose Delphi Link (RDL), связывающая Rational Rose и Delphi. Основные функции RDL - генерация кода и обратное проектирование. Следует помнить, что генерируемый RDL код не содержит реализацию функциональности! Генерируются только декларативные элементы: определения классов, интерфейсов, записей, типов, директивы видимости и т.д.

Дистрибутив

Rose Delphi Link можно бесплатно скачать с сайта Rational Software (http://ftp.rational.com/public/rose/Links/RoseDelphiLink3Setup.exe ), размер – около 8 МБ. Установка RDL стандартная, никаких сложностей не вызывает. После инсталляции программы в Rational Rose в меню Tools появляется новый пункт Ensemble Tools ® Rose Delphi Link (рис.1).

1. Пункт меню RDL

Прежде чем переходить к рассмотрению

Rose Delphi Link, напомню основные этапы работы в среде Rational Rose. Как правило, используется следующий подход:
  1. Определение требований к системе и построение модели взаимодействия элементов системы (
Use Case Diagram и Collaboration Diagram). Для детализации Use Case используются Sequence Diagram. На этих диаграммах отображаются объекты предметной области, участвующие в бизнес-процессах. Эти диаграммы не влияют на генерируемый код.
  • Построение аппаратной модели системы (
  • Deployment Diagram). На этой диаграмме отображается модель системы в аппаратной реализации. Диаграмма не влияет на код, генерируемый RDL.
  • Разработка объектной модели системы (определение классов, их взаимодействий, атрибутов, операций). Параллельно с разработкой диаграммы классов, как правило, разрабатывается диаграмма компонентов (
  • Component Diagram), которая отображает взаимодействие файлов, модулей, дополнительных библиотек, использующихся в системе. Диаграмма компонентов также не влияет на генерацию кода.
  • Генерация кода программы.
  • На генерацию кода влияют только диаграммы классов, поэтому в рамках данной статьи мы будем рассматривать только диаграммы секции

    Logical View. Особенности построения других диаграмм опущены.

    Перечисленные этапы проектирования в среде

    Rational Rose применяются для разработки модели и генерации кода на различных языках, поддерживаемых средой Rose. Но в Delphi есть особенность, существенно отличающая разработку в Delphi от разработки в других средах программирования: программирование пользовательского интерфейса. Не секрет, что в Delphi разработка большей части программ начинается именно с проектирования интерфейса пользователя, а при дальнейшем программировании – его существенного изменения. Поэтому использовать стандартный подход Rational Rose не совсем удобно. Для решения этой проблемы компания Ensemble Systems предлагает следующую методологию проектирования:

    Рисунок 2. Методология проектирования с использованием

    RDL

    Основная идея такого подхода состоит в использовании обратного проектирования (

    Round-trip engineering): все изменения, сделанные на уровне программного кода в Delphi, отображаются в объектной модели, построенной в Rose, и наоборот, при изменении классов, методов и т.п. в объектной модели Rose, соответственно , корректируется программный код. Обратите внимание на пару стрелок, которые соединяют третий и четвертый блок. Как раз эти стрелки и отображают процесс обратного проектирования.

    Рассмотрим основное окно

    Rose Delphi Link (рис. 3). Интерфейс достаточно прост, он содержит:
    • меню, содержащее команды для работы с проектом, настройки опций и вызова помощи;
    • панели, на которых в виде деревьев отображаются иерархические структуры моделей
    Rose и Delphi;
  • кнопка обновления объектных деревьев, кнопки обратного проектирования (¬
  • Update All ) и прямого проектирования, т.е. генерации кода (Update All® ).

    Рисунок 3. Основное

    окно Rose Delphi Link

    Основное окно

    RDL является дочерним по отношению к главному окну Rational Rose и постоянно находится поверх этого окна, сворачивается так же как дочернее окно, что, несомненно, очень удобно.

    Перед тем как разбирать конкретный пример, рассмотрим подробнее пункты меню

    Rose Delphi Link.

    File ® Open Project – служит для открытия в RDL созданного проекта Delphi. При открытии проекта в окне RDL отображаются объектные деревья открываемого проекта.

    File ® New Project – при выборе этого пункта меню RDL предлагает создать пустой Delphi-проект. Файл проекта, создающийся в этом случае, содержит только декларативные элементы , необходимые для минимальной программы Delphi (program, begin, end). Новый проект стоит создавать в случае, если программа не содержит графического пользовательского интерфейса, например, динамическая библиотека. Правда, в этом случае в генерируемый код нужно будет внести корректировку – заменить program на library. С помощью контекстного меню можно создавать модули (unit) и дополнительные директории для модулей. Создаваемые таким образом модули также содержат только минимальную реализацию (uses, interface, implementation, end). После создания модуля, при последующей генерации кода, в секцию uses файла проекта добавляется объявление нового модуля.

    Пункты меню View и Help стандартны, и в описании в рамках данной статьи не нуждаются.

    Теперь воспользуемся приведенной выше методикой проектирования и разработаем программу и соответствующую ей модель

    Rose. Для примера возьмем программу, заполняющую два числовых массива размером 5 на 5 случайными числами, а также реализующую некоторые математические функции по их обработке. Программа должна выполнять следующие функции:
    • Заполнять массивы случайными числами в пределах от 1 до 10;
    • Вычислять сумму элементов каждого массива;
    • Определять среднее арифметическое значение элементов;
    • Очищать массивы (инициализировать их нулями).

    Начнем с разработки пользовательского интерфейса в

    Delphi. В результате незамысловатых действий мышкой у меня получилась вот такая программа, которая пока еще не выполняет никаких действий (рис. 4).

    Рисунок 4. Интерфейс разрабатываемой программы

    Сохраним этот проект с именами модулей, предлагаемыми

    Delphi по умолчанию, откроем новый проект Rational Rose, и запустим Delphi Rose Link. Выберем пункт меню Open Project, и откроем только что сохраненный в Delphi проект. В окне RDL отобразятся деревья объектов модели Rose и проекта Delphi (рис. 5).

    Рисунок 5. Проект

    Delphi, открытый в RDL

    Левое дерево объектов – это объекты модели

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

    Следующий шаг – генерация модели

    Rose по исходному коду. Для начала генерации нужно нажать кнопку ¬ Update All. В случае успешной генерации восклицательные значки у объектов исчезают, что означает, что модель Rose для каждого объекта соответствует исходному коду Delphi. Чтобы посмотреть историю сообщений генерации, надо выбрать пункт меню View ® Messages . В открывшемся окне будет отображен достаточно подробный лог сообщений RDL, выводимых при генерации модели или исходного кода. Rose Delphi Link, и в браузере объектов Rose выберем ветку Logical View. Видим два появившиеся пакета: <>Unit1 , который содержит объектную модель кода из модуля Unit1.pas, и External References, содержащий объекты Delphi, которые объявлены в модулях вне текущего проекта (объекты библиотеки VCL).

    Теперь откроем в среде

    Rose диаграмму классов, соответствующую модулю Unit1 (Logical View ® Unit1 ® Overview ). В первоначальном виде на диаграмме представлена немножко запутанная объектная модель, которую мы приведем в порядок, аккуратно расположив объекты согласно их иерархии (рис. 6).

    Рисунок 6. Модель объектов модуля

    Unit1

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

    RDL кода.

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

    Создадим новый модуль. Сделать это можно и в

    Delphi, и в Rose, и в RDL, но для чистоты эксперимента создавать все будем только в RDL. В Rose активизируем окно RDL и щелкнем правой кнопкой мыши по корневому элементу в дереве объектов модели Rose - в нашем случае это Model1.mdl. В контекстном меню выберем New ® Unit. Откроется окно редактора компонента (Component Editor) (рис. 7). На вкладке General указывается имя модуля (Unit2), и комментарий к создаваемому модулю, который при кодогенерации будет вставлен в модуль как комментарий. На вкладке Detail указывается вид (kind) компонента, и путь к исходному файлу. На вкладке Code Preview можно посмотреть код, который будет сгенерирован RDL для данного модуля. Выключение переключателя Allow Code/Model Updates запрещает генерацию кода и обновление модели для выбранного элемента.

    Рисунок 7. Редактор компонента

    После нажатия кнопки

    Ok видим, что в окне RDL появился значок, обозначающий новый модуль, и рядом с ним восклицательный знак, сигнализирующий о том, что модель Rose и код Delphi не синхронизированы. Обновим код Delphi, нажав кнопку Update All® .

    Теперь нужно переключиться на

    Delphi. Видим окно, предупреждающее, что модуль был изменен (рис. 8). Для загрузки обновленного модуля нажмем Ok.

    Рисунок 8. Сообщение

    Delphi об изменении файла проекта

    Теперь откроем только что сгенерированный модуль

    Unit2.pas. Можно убедиться, что генерация кода прошла успешно – объявлены все необходимые ключевые слова, вставлен комментарий. Следующий шаг – моделирование классов и их методов в этом модуле. Перейдем в Rose, и активизируем окно RDL. В дереве объектов выведем контекстное меню на объекте Unit2 и выберем пункты New ® Class . Появляется окно редактора класса (Class Editor) (рис. 9). На вкладке General нужно указать имя класса (Name), вид (Kind), видимость (Visibility) и комментарий к классу (Documentation). В нашем случае класс будет называться TMassiv, область видимости для него – Public.

    Рисунок 9. Редактор класса

    Для создания всех методов и атрибутов класса будем пользоваться пунктом меню

    New в контекстном меню класса в дереве объектов RDL. Редакторы атрибутов и методов в основном аналогичны редактору класса, поэтому подробности создания опустим. Создадим следующие атрибуты и методы (все методы с директивами видимости Public, атрибут M имеет видимость Private):

    M: array of Integer;

    ; // Инициализация массива

    procedure FillMassiv

    ; // Заполнение массива случайными числами

    procedure CalcSum

    ; // Подсчет суммы элементов массива

    procedure CalcSr

    ; // Подсчет среднего значения элементов массива

    function GetElement(X, Y: integer): Integer; //

    Получение элемента массива (x,y)

    Также создадим метод для класса

    TForm1, который будет заполнять компоненты TMemo, расположенные на форме, элементами из массивов:

    procedure GetMassiv;

    В создании методов с параметрами есть некоторая особенность. Сначала метод создается обычным способом, затем, в дереве объектов

    RDL, в контекстном меню на методе, для которого предлагается указать параметр, выбирается пункт New ® Parameter и указывается имя параметра, его тип и комментарий к нему.

    После создания класса обратите внимание на диаграмму классов для модуля

    Unit2 в Rose – наш класс отображен в соответствии со спецификацией UML (рис. 10).

    Рисунок 10. Диаграмма классов с созданным классом

    Итак, класс создан, точнее его оболочка, пока без реализации. Теперь в основном модуле

    Unit1создадим два экземпляра этого класса. Объявим их как M1 и M2 в секции Publicкласса TForm1. Это делается выбором нужных пунктов в контекстном меню дерева объектов и указанием параметров в редакторе атрибутов. Измененная диаграмма, где в классе TForm1 показаны объявленные экземпляры класса, изображена на рис. 11.

    Рисунок 11. Экземпляры класса, объявленные в секции

    public класса TForm1

    Итак, модель построена, и теперь нужно сгенерировать окончательный код. В окне

    RDL жмем Refresh, Update All® и переходим в среду Delphi. Теперь надо написать код, реализующий функциональность, и откомпилировать программу. При заполнении методов кодом иногда требуется добавить локальные или глобальные переменные. Это можно сделать в RDL, но лучше реализовать эти переменные в коде, а затем обновить модель Rose по исходному коду Delphi (¬ Update All ). Если в модели были удалены некоторые элементы, а в коде они уже реализованы, этот код заключается между директивами компилятора {$IFDEF DELETED} и {$ENDIF} .

    После реализации всего исходного кода в

    Delphi вернемся в RDL и еще раз выполним обратное проектирование, нажав Refresh и ¬ Update All . Класс TForm1 изменился – в нем появились методы – обработчики событий кнопок (рис. 12). В нашем случае это окончательный вариант диаграммы классов и всей модели в целом.

    Рисунок 12. Окончательный вариант диаграммы классов для модуля

    Unit1

    Окончательный исходный код программы и построенную модель

    Rose можно скачать с сайта журнала.

    В рассмотренном примере мы следовали методике разработки приложений, предложенной разработчиком

    Rose Delphi Link, и в результате получили объектную модель системы. Все классы и диаграммы, описывающее деятельность системы были спроектированы в Rational Rose с помощью программы Rose Delphi Link.

    Итак, выделим основные преимущества совместного использования

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

    Таким образом, при периодическом согласовании на основе технологии обратного проектирования обеспечивается соответствие модели

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

    Литература:

    1. Вендров А.М. Проектирование программного обеспечения экономических информационных систем. – М.: Финансы и статистика, 2000 г.
    2. Трофимов С.А.
    3. CASE-технологии: практическая работа в Rational Rose – “Издательство БИНОМ”, 2001 г.
    4. Буч Г., Рамбо Д., Джекобсон А. Язык
    5. UML. Руководство пользователя: Пер. с англ. – М.

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

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

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

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

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

    Мы используем для проектирования систем продукт Rational Rose фирмы Rational Software Corp oration . Этот продуктобладает всеми необходимыми характеристиками для создания базовой архитектуры системы любого масштаба. При наличии достаточного опыта программирования в среде 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 и элементов компонентов Delphi
    Реализация Реализуются в виде программных модулей диаграммы классов, разрабатываются диаграммы компонентов и диаграммы размещения Реализуется программный код, обеспечивается однозначное соответствие проекта в Rose и Delphi. Документирование кода в Delphi отражается в 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 (CG P) - набор специальных таблиц, которые связываются с каждым элементом моделей 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 of SupplierClass5; ArrayRole3: array 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.

    Что не умеет 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 .

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

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

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

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

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

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

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

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

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

    • FillPatientLis t - заполнение выпадающего списка пациентов;
    • 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 , T DataSource и их взаимодействием с классами 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