7.3. Порядок выполнения
1. Изучить назначение элементов интерфейса RRдля построения диаграммы развёртывания. Рассмотреть типовой пример построения диаграммы.
2. Продолжить моделирование системы в соответствии с индивидуальным заданием в виде построения диаграммы развёртывания:
2.1. Активизировать окно диаграммы развёртывания.
2.2. Определить состав и добавить на диаграмму развёртывания необходимые узлы (процессоры и устройства) и соединения.
2.3. Добавить процессы и показать их на диаграмме развёртывания. Показать процедуры планирования процессов.
3. Сгенерировать с помощью RRотчёт о разрабатываемой модели.
4. Оформить отчёт по результатам выполнения лабораторной работы.
7.4. Содержание отчёта
Результаты выполнения лабораторной работы необходимо представить в виде отчёта, который должен содержать следующие разделы:
1. Постановка задачи.
2. Краткое описание составляющих диаграммы развёртывания.
3. Окончательный вид диаграммы развёртывания проектируемой системы.
Дополнить отчёт результатами генерации отчёта о модели с помощью RR.
7.5. Варианты заданий
Вариант индивидуального задания соответствует варианту, полученному при выполнении лабораторной работы №2.
7.6. Контрольные вопросы
1. Для чего предназначена диаграмма развертывания?
2. Что отображает диаграмма развертывания модели?
3. Сколько диаграмм развертывания может быть построено для разрабатываемой модели вRR?
4. Какое представление используется в браузере проекта для разработки и размещения диаграммы развертывания?
5. Каким образом на диаграмму развертывания добавляется процессор (устройство, соединение)?
6. Какие свойства можно специфицировать для процессора?
7. Как определить быстродействие и объем памяти процессора при создании диаграммы развертывания вRR?
8. В чем состоит спецификация процедуры планирования процессов процессора вRR?
9. Как отобразить планирование процессов на диаграмме развертывания вRR?
10. Как добавляется процесс для процессора в диаграмме развёртывания?
11. Каким образом назначаются приоритеты у процессов?
8. Дальнейшая работа с моделью
8.1. Цель работы
Целью данной работы является изучение и выполнение последовательности действий, необходимых для генерации отчёта о модели и программного кода в среде RRна основе построенной модели программной системы.
8.2. Общие сведения
Дальнейшая работа с моделью зависит от целей выполнения проекта.
Отчёт о модели
Если проект не предполагает реализацию, то можно ограничиться формированием проектной документации.
С этой целью следует выполнить операцию меню Report → SoDA Report(Отчёт → Отчет с помощьюSoDA), в результате чего будет открыто окно свойств для выбора шаблонов генерации отчёта. После выбора шаблонов будет автоматически сгенерирован отчёт о модели в форматеMS Wordс использованием специального средстваIBM Rational SoDA, если оно доступно в системе после инсталляцииRR.
Генерация кода
Если проект предполагает программную реализацию, то целесообразно воспользоваться возможностями генерации кода в среде RR.
Одним из важных свойств RRявляется возможность генерации кода на нескольких ЯП, которая может быть использована разработчиком после построения модели. Возможность генерации текста программы на том или ином ЯП зависит от установленной версииRR.
Общая последовательность действий, которые необходимо выполнить для генерации кода в среде RR, состоит из следующих этапов:
1. Проверка модели на отсутствие ошибок.
2. Создание компонентов для реализации классов и отображение классов на компоненты (может выполняться при создании диаграммы компонентов).
3. Выбор ЯП для генерации программного кода.
4. Установка свойств генерации программного кода.
5. Выбор класса, компонента или пакета.
6. Собственно генерация программного кода.
Особенности выполнения каждого из этапов могут изменяться в зависимости от выбора ЯП или схемы базы данных.
В среде RRпредусмотрено задание достаточно большого числа свойств, характеризующих как отдельные классы, так и проект в целом.
Проверка модели независимо от выбора языка генерации кода
В общем случае проверка модели может выполняться на любом этапе работы над проектом. Но после завершения разработки графических диаграмм она является обязательной, так как позволяет выявить целый ряд ошибок разработчика. К числу таких ошибок и предупреждений относятся, например, не используемые ассоциации и классы, оставшиеся после удаления графических элементов из диаграмм, а также операции, не являющиеся именами сообщений на диаграммах взаимодействия.
Для проверки модели следует выполнить операцию меню Tools → Check Model(Инструменты → Проверить модель). Результаты проверки модели на наличие ошибок отображаются в окне журнала.
Для обнаружения нарушений правил доступа, возникающих когда существует связь между двумя классами разных пакетов, но связи между самими пакетами отсутствуют, необходимо выбрать в меню Report → Show Access Violations.
Прежде чем приступить к генерации кода разработчику следует добиться устранения всех ошибок и предупреждений, о чём должно свидетельствовать чистое окно журнала.
Создание компонентов для реализации классов и отображение классов на компоненты
По существу эти этапы выполняются в ходе разработки диаграммы компонентов. Желательно переименовать компоненты, дав им англоязычные имена.
Для отображения классов на компоненты можно воспользоваться окном спецификации свойств компонента на вкладке Realizes. Для включения реализации класса в данный компонент следует выделить требуемый класс на этой вкладке и выполнить для него операцию контекстного менюAssign. В результате перед именем класса на этой вкладке появится специальная отметка.
Подобная операция должна быть выполнена для всех классов модели, которые предполагается реализовывать на выбранном ЯП. Другой способ установления реализации классов на компоненте: можно просто выделить класс в браузере проекта и перетащить его на нужный компонент диаграммы компонентов.
Выбор языка программирования и редактирование свойств генерации кода
Для выбора ЯП в качестве языка реализации модели следует выполнить операцию меню Tools → Options(Инструменты → Параметры), в результате чего будет вызвано окно настройки параметров модели. На вкладкеNotation(Нотация) в строкеDefault Language(Язык по умолчанию) из вложенного списка следует выбрать требуемый язык.
Если по какой-то причине необходимого языка не оказалось во вложенном списке, то следует убедиться в том, что этот ЯП установлен в качестве расширения RR. Для этого следует открыть окно установленных расширений, выполнив операцию менюAdd-Ins → Add-In Manager(Расширения → Менеджер расширений), и убедиться в том, что выставлена отметка в строке с именем необходимого языка. Если языка нет, то следует её добавить, после чего появится группа доступных операций этого языка в менюTools.
После выбора ЯП по умолчанию следует изменить язык реализации каждого из компонентов модели. С этой целью следует изменить язык в строке Language(Язык) на вкладкеGeneral(Общие) окна спецификации свойств компонента, для чего из вложенного списка следует выбрать необходимый язык. После выбора ЯП нужно привести в соответствие типы атрибутов, типы аргументов и результатов операций. С этой целью нужно просмотреть все классы диаграммы классов и изменить те типы данных, которые не являются синтаксически допустимыми в выбранном ЯП. Иначе соответствующие исправления придётся выполнять вручную после генерации программного кода.
Для каждого языка в RRпредусмотрен ряд свойств генерации кода. Перед генерацией рекомендуется их анализировать и вносить необходимые изменения. Для анализа свойств генерации кода выберитеTools → Options, а затем вкладку соответствующего языка. В окне списка можно выбрать класс, атрибут, операцию и другие элементы модели. Для каждого языка в этом списке указаны свои собственные элементы модели. При выборе разных значений на экране появляются разные наборы свойств. Любые изменения, вносимые в набор свойств в этом окне, воздействуют на все элементы модели, для которых используется данный набор.
Иногда нужно изменить свойства генерации кода для одного класса, атрибута, одной операции и т.д. Для этого отройте окно спецификации элемента модели. Выберите вкладку языка и измените свойства здесь. Все изменения, вносимые в окне спецификации элемента, оказывают влияние только на этот элемент.
Выбор класса или компонента и генерация для него программного кода
Генерация кода возможна для отдельного класса / компонента: необходимо выделить нужный элемент модели в браузере и выполнить операцию контекстного меню <Требуемый ЯП> → Generate Code(<Требуемый ЯП> → Генерировать код).
Сообщения об ошибках процесса генерации кода будут появляться в окне журнала. Если проектирование класса частично не завершено, то будут взяты значения по умолчанию, а в журнале появится предупреждение. Это важно при итеративном подходе разработки, когда класс не реализуется полностью в одной версии.
Сгенерированные файлы с текстом кода содержат минимум информации. Для включения дополнительных элементов в код следует изменить свойства генерации программного кода, установленные по умолчанию.
Эффект от использования RRпроявляется при разработке масштабных проектов в составе команды. Для таких проектов явно выявляется преимущество использованияRRиUMLдля документирования и реализации моделей.
Краткое описание кодогенератора Rose Delphi Link
Для совместного использования DelphiиRRнеобходимо использовать кодогенераторRose Delphi Link(RDL). После установкиRDLв средеRRпоявляется новый пункт меню в разделеTools(рис.8.1).
Рис.8.1. Пункты меню кодогенератора Delphi
Интерфейс основного окна RDLвключает в себя (рис.8.2): меню с командами для работы с проектом, настройки опций и вызова помощи; панели, на которых в виде деревьев отображаются иерархические структуры моделейRRиDelphi; кнопки обновления объектных деревьев, прямого и обратного проектирования.
Рис.8.2. Основное окно Rose Delphi Link
Пункт меню File → Open Project– служит для открытия вRDLсозданного проектаDelphi. При открытии проекта в окнеRDLотображаются объектные деревья открываемого проекта. При выборе пункта менюFile → New ProjectRDLпредлагает создать пустойDelphi-проект. Новый проект стоит создавать в случае, если программа не содержит графического пользовательского интерфейса (например, динамическая библиотека). Пункты менюViewиHelpстандартны.
Для отображения элементов модели в код RDLиспользуетCode Generation Properties(CGP) – набор специальных таблиц, которые связываются с каждым элементом моделиRRи содержат специфическую для Delphi информацию, используемую для кодогенерации. Набор этих таблиц (рис.8.3) доступен из главного меню (пунктTools → Options, вкладкаDelphi).
Рис.8.3. Таблица свойствCGPдля операций в кодогенераторе Delphi
Чтобы CGPдляDelphiбыли доступны из спецификации, необходимо установить значение поляDefault Language = Delphiво вкладкеNotationменюTools → Options. Для упрощения работы в менюTools → Ensemble Toolsесть вкладкаDelphi Property Editor, где можно настроить свойства элемента модели. При его использовании можно без кодогенерации просмотреть код элемента модели.
В целом RDLохватывает все перечисленные возможности кодогенератора:
– возможность преобразовывать классы RRв код определения классов на целевом языке (в данном случаеDelphi). При этом описание, связанное с конкретным классом, должно помещаться в соответствующее место кода;
– поддерживать для диаграммы классов стереотипы, связанные со специфическими особенностями языка (например, стереотип unit,interfaceилиpropertyс соответствующими определениями: модульDelphi,интерфейсDelphi, свойство компонентаDelphi);
– иметь описанный, очевидный и однозначный способ отображения диаграммы классов в код Delphi. При этом отображение должно быть настраиваемым;
– иметь возможность импорта актуальной объектной модели Delphi(желательно для различных версий библиотекиVCL);
– поддерживать генерацию кода для создания классов Delphi;
– уметь правильным образом отображать типовые виды связей между классами (обобщение, агрегацию и композицию);
– уметь отображать в программный код кардинальность связи;
– исходя из диаграммы компонентов RR, создавать проектDelphi, содержащий требуемые программные модули (forward engineering);
– на основе готового проекта Delphiстроить диаграмму компонентовRR, содержащую в виде компонентов все модули проектаDelphiи связанные с ними классы, полученные изDelphiв результате обратного проектирования (reverse engineering), диаграммы должны быть компактными и очевидными;
– обеспечивать автоматическое согласование модели RRиDelphiпосле внесения изменений в код модулейDelphi(round trip engineering);
– после внесения изменений в модель RRи повторной генерации кода не уничтожать фрагменты, написанные в средеDelphi;
– работать на реальных проектах (сотни классов и модулей) с приемлемой производительностью.
Основным недостатком RDLявляется то, что он не позволяет создавать формы. Для решения этой проблемы компанияEnsemble Systemsпредлагает следующую методологию проектирования, представленную на рис.8.4.
Основная идея такого подхода состоит в использовании обратного проектирования: все изменения, сделанные на уровне кода в Delphi, отображаются в объектной моделиRR, и, наоборот, при изменении классов, методов и т.п. в объектной моделиRR, соответственно, корректируется программный код.
Код, создаваемый RDL, не содержит реализации (для объектной модели обычно это тело метода). Когда модель обновляется из кода, модель не подгружает код, написанный в средеDelphi, для тел методов. Изменения в модели касаются только декларативных элементов: определений классов, интерфейсов, типов, записей и т.п. Но при повторной генерации кода изRRтела методов вDelphiтакже остаются неизменными, а меняются лишь декларативные элементы.
Р
Дистрибутив Rose Delphi Link можно скачать с сайта Ensemble Systems (URL: http://www.ensemblesystems.com/downloads.html).