Общая характеристика инструментария IBM Rational Rose

 

CASE-средство IBM Rational Rose позволяет построить все канонические UML-диаграммы в рамках единой модели, проверить модель на наличие ошибок и осуществить экспорт в виде кодов программ.

Спроектированная модель сохраняется в файле с расширением MDL, резервные копии – в файлах с расширением MD~. Одновременно можно работать только с одной моделью – при загрузке новой предыдущая автоматически закрывается.

Работа начинается с выбора будущей среды реализации (рис. 59). Если среда пока точно не определена, рекомендуется выбрать «Rational unified process».

 

Рисунок 59 – Окно выбора среды реализации

Интерфейс IBM Rational Rose оформлен по аналогии с интерфейсами большинства Windows-приложений, поэтому нет смысла останавливаться на пунктах главного меню и подробном перечислении содержания панели инструментов (рис. 60).

 

 

Рисунок 60 – Рабочий интерфейс среды IBM Rational Rose

 

В левой части экрана располагается окно браузера проекта, в котором можно видеть проектируемую систему в виде иерархической структуры, верхними уровнями которой являются «Концептуальное представление» (use case view), «Логическое представление» (logical view), «Компонентное представление» (component view) и «Представление развертывания» (deployment view).

В правой части экрана располагается окно диаграммы, где, собственно, и происходит процесс проектирования. Между окном браузера и окном диаграммы располагается специальная панель инструментов, содержание которой зависит от выбранной диаграммы. Состав этой панели можно изменять (пункт Customize контекстного меню).

Внизу экрана находится окно журнала, куда выводится служебная информация о выполненных действиях.

Переключение между диаграммами осуществляется либо нажатием соответствующего значка на панели инструментов, либо выбором из главного меню (Browse).

Остальные особенности работы в среде IBM Rational Rose будут понятны в дальнейшем при рассмотрении примера разработки модели простейшей информационной системы.

 

Пример разработки модели информационной системы

В среде IBM Rational Rose

 

Согласно RUP (рациональному унифицированному процессу) проектирование системы должно начинаться с построения концептуальной модели – то есть с диаграммы вариантов использования.

Выберем в главном меню пункт «Browse / Use Case Diagram» (или выберем слева «Use Case View / Main») – на экране появится новая диаграмма вариантов использования с размещенными по умолчанию пакетами (рис. 61).

После удаления пакетов поместим на диаграмму актера (размещение компонентов осуществляется стандартным приемом «выдели и щелкни на поле»), при этом сразу введем его имя (в нашем примере – Admin) – рис. 62. Аналогично поместим второго актера (User).

Наша модель предполагает два основных варианта использования – «Ввод и модификация данных» и «Работа с данными» (то есть их извлечение и анализ). Помещение варианта использования происходит подобно помещению актера (рис. 63).

Первый вариант использования предлагается администратору, второй – пользователю, поэтому свяжем их ассоциациями (рис. 64).

Поскольку предполагается два пользователя (Admin и User), системе необходимо их предварительно идентифицировать. Для этого поместим еще один вариант использования «Аутентификация», связав его с двумя остальными отношением зависимости типа «Включение» (рис. 65).

Рисунок 61 – Начало построения диаграммы вариантов использования

 

Вид зависимости определяется двойным щелчком мыши и выбором «Stereotype» в появившемся окне (рис. 66).

 

Рисунок 62 – Помещение актера на диаграмму вариантов использования

Рисунок 63 – Помещение варианта использования на диаграмму

Рисунок 64 – Добавление связей между компонентами

Рисунок 65 – Новый вариант использования

Рисунок 66 – Изменение стереотипа связи

 

Последнее изменение на диаграмме – добавление варианта использования «Формирование отчета» и связывание его с «Работой с данными» отношением зависимости типа «Расширение» (рис. 67).

 

Рисунок 67 – Вариант использования «ReportForming»

 

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

Следующий этап – построение диаграммы классов. Выберем в главном меню пункт «Browse / Class Diagram» (или выберем слева «Logical View / Welcome») – на экране появится новая диаграмма. Присвоенное по умолчанию название «Welcome» лучше изменить при помощи контекстного меню (пункт «Rename») на более подходящее по смыслу (рис. 68). Построение диаграммы начинается с размещения нового класса.

Рисунок 68 – Начало построения диаграммы классов

 

Нам будет предложен выбор: ввести имя нового класса или воспользоваться существующим (актеры из диаграммы вариантов использования автоматические предлагаются в качестве классов). Сначала введем класс Admin, основой которого является соответствующий актер (рис. 69).

После создания классов, описывающих обоих наших актеров, введем новый класс – программу. В окне спецификации класса напишем его имя (Program) и выберем стереотип (control), поскольку класс является управляющим (рис. 70). В результате диаграмма примет вид, показанный на рис. 71. Неудобство такого представления управляющего класса скажется при добавлении атрибутов и операций, поэтому посредством контекстного меню («Options / Stereotype Display / Label») придадим ему стандартный вид.

Добавление атрибутов и операций класса можно либо в окне спецификации класса («Attributes» и «Operations»), либо с помощью контекстного меню («New attribute» и «New operation»).

Рисунок 69 – Размещение нового класса - Admin

 

Рисунок 70 – Окно спецификаций класса

 

Рисунок 71 – Специальное изображение управляющего класса

 

Введение атрибутов главной программы в нашем примере нецелесообразно, а вот операцию «Авторизация пользователя» добавить необходимо. Тип возвращаемого значения укажем логическим (Boolean), видимость – «доступно для всех» (public). Результат действий приведен на рис. 72.

Теперь остается добавить два новых класса – «База данных» (атрибут – «Данные», операции – «ввестиДанные()», «изменитьДанные()» и «извлечьДанные()») и «Отчет» (атрибут – «Данные», операции – «сформировать()», «распечатать()» и «экпортировать()»), а также связи между ними (рис. 73).

После окончания работы с диаграммой классов приступаем к построению диаграмм взаимодействия, а именно – к диаграмме кооперации. Рассмотрим только один пример работы системы – работу пользователя. Сначала тот проходит авторизацию в программе, затем должен извлечь информацию из базы данных, сформировать и распечатать отчет.

Рисунок 72 – Стандартное изображение управляющего класса

с операцией

 

Создание диаграммы происходит в следующей последовательности: пункт главного меню пункт «Browse / Interaction Diagram», «New / Ok», ввод имени («Диаграмма кооперации») и выбор типа диаграммы («Diagram type: Collaboration») – рис. 74.

 

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

Рисунок 74 – Начальный вид диаграммы кооперации

 

Поместим в окно диаграммы новый объект и выберем в его окне спецификации интересующий нас тип – User (рис. 75). Поскольку собственное имя пользователя нам в данном случае совершенно неважно, строчку «Name» оставим пустой (анонимный объект). Аналогичное действие осуществим по отношению к объекту класса «Программа» (менять внешний вид объекта здесь нет необходимости) и соединим два объекта линией («Object Link») – рис. 76.

Поместить на линию связи сообщение можно двумя способами. Первый – вызвав двойным щелчком мыши на линии окно ее спецификации, в разделе «Messages» при помощи контекстного меню добавить сообщение (выбрать при этом пункт «Insert To: Program», то есть явно указать направление). При этом доступные операции будут показаны в виде выпадающего меню (рис. 77).

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

 

Рисунок 75 – Окно спецификации объекта

Рисунок 76 – Два объекта на диаграмме кооперации

 

 

Рисунок 77 – Добавление сообщения в окне спецификации связи

Рисунок 78 – Сообщение на диаграмме кооперации

 

Теперь поместим на диаграмму два оставшихся объекта (анонимные объекты классов «База Данных» и «Отчет») и свяжем их с программой (рис. 79).

 

Рисунок 79 – Все размещенные объекты на диаграмме кооперации

Вторым сообщением работающей системы будет, очевидно, запрос от программы к «Базе данных» – вызов операции «извлечьДанные()», третьим – запрос от программы к «Отчету» – вызов операции «сформировать()», четвертым – запрос к тому же объекту вызова операции «печать()». Окончательный вид диаграммы кооперации представлен на рис. 80.

Диаграмма последовательности формируется на основании диаграммы кооперации пунктом меню «Browse / Create Sequence Diagram» или просто нажатием клавиши F5. Как видно на рис. 81, в окне браузера проектов теперь расположились две «Диаграммы кооперации», что, по сути, неверно; присвоить диаграмме новое имя можно при помощи контекстного меню (пункт «Rename»).

Рисунок 80 – Окончательный вид диаграммы кооперации

 

Рисунок 81 – Автоматически сформированная диаграмма

последовательности

Необходимо выполнить еще несколько корректировок диаграммы последовательности, большая часть которых носит «косметический» характер. Окончательный вид см. на рис. 82.

 

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

 

Диаграмма состояний создается пунктом меню «Browse / State Machine Diagram» (или нажатием клавиш Ctrl+T), «New / Ok», затем нужно ввести имя диаграммы («Диаграмма состояний») и ее тип («Diagram Type: Statechart»). В браузере проектов новая диаграмма разместится в ветви «Logical View / State-Activity Model» (рис. 83).

Очевидно, что наша система может находиться в семи различных состояниях (не считая начального и конечного): «Ожидание ввода пароля», «Проверка пароля», «Выбор данных для отчета», «Формирование отчета», «Ожидание выбора» (куда направлять отчет), «Печать отчета» и «Экспорт отчета».

 

Рисунок 83 – Начальный вид диаграммы состояний

 

Поместим на диаграмму начальное (черный кружок) и первое состояния (рис. 84); очевидно, что его следует назвать «Ожидание ввода пароля» (имя вводится двойным щелчком мыши или посредством окна спецификации состояния).

Рисунок 84 – Добавление нового состояния

Соединим начальное и первое состояние линией связи (State Transition), в окне спецификации перехода укажем название события (General / Event) – «Загрузка программы» (рис. 85).

 

Рисунок 85 – Добавление первого перехода и первого события

 

Переход в новое состояние – «Проверка пароля» – может осуществиться при наступлении события «Пароль введен» (рис. 86).

Отсюда возможны сразу три перехода: если введен правильный пароль – на «Выбор данных для отчета», неправильный пароль – возврат в предыдущее состояние, неправильный пароль вводится подряд три раза – выход. Собственно событием здесь могут считаться «Три неправильных попытки», остальные условия введем как сторожевые в окне спецификации перехода (Detail / Guard Condition) (рис. 87).

Переход, вызванный тремя неправильными попытками, можно конкретизировать в окне его спецификации: кроме непосредственного названия, в разделе «Detail / Action» можно явно задать действие («Выход») (рис. 88).

 

Рисунок 86 – Добавление нового состояния и перехода

 

Рисунок 87 – Добавление сторожевого условия в окне спецификации

перехода

 

Рисунок 88 – Добавление новых состояний и переходов

 

Осталось добавить оставшиеся четыре состояния и переходы между ними (рис. 89).

 

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

Диаграмма деятельности создается тем же пунктом меню «Browse / State Machine Diagram», что и диаграмма состояния, но выбирается другой тип («Diagram Type: Statechart»). В браузере проектов новая диаграмма также разместится в ветви «Logical View / State-Activity Model» (рис. 90).

 

Рисунок 90 – Начальный вид диаграммы деятельности

 

Начальное состояние в модели может быть только одно, поэтому попытка взять его со специальной панели инструментов ни к чему не приведет: начальное состояние нужно найти в окне браузера проекта (черный кружок сразу после названия диаграммы состояний) и «перетянуть» в окно диаграммы.

Логика построения диаграммы деятельности практически полностью повторяет логику построения диаграммы состояний (строго говоря, в данном примере эта диаграмму можно было и опустить). Первое действие – ввод пароля – выбираем на специальной панели инструментов (пункт Activity), размещаем в окне диаграммы и присваиваем имя (рис. 91).

Рисунок 91 – Добавление нового действия

 

Соединяем начальное состояние с первым действием; имени события на переходе указывать не нужно. Далее на диаграмме начинается ветвление: добавляется знак «Decision», из которого возможны два перехода со сторожевыми условиями «Пароль правильный» и «Пароль неправильный». Во втором случае сразу можно добавить переход к действию «Выход из программы» и окончанию работы (рис. 92).

В случае правильности пароля добавим действия «Извлечение данных для отчета», «Создание отчета» и «Вывод отчета» (ветвление для разделения случаев «Печать отчета» и «Экспорт отчета» опустим). Окончательный вид диаграммы деятельности представлен на рис. 93.

Диаграмма компонентов создается пунктом меню «Browse / Component Diagram», в правом окне появится заготовка новой диаграммы (рис. 94). Расположенный там по умолчанию пакет «Implementation model» можно удалить (окно браузера проекта, контекстное меню, пункт «Delete»).

 

Рисунок 92 – Добавление ветвления и последних действий

 

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

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

 

Поместим на диаграмму новый компонент, назовем его «Главная программа» (рис. 95).

 

Рисунок 95 – Добавление нового компонента

Теперь можно изменить тип нового компонента: в окне спецификации выберем стереотип «EXE» (рис. 96).

Рисунок 96 – Окно спецификации компонента

Чтобы результат изменений был явно виден на диаграмме, выберем в контекстном меню компонента пункт «Stereotype Display / Decoration» (рис. 97).

К исполняемому файлу отнесем два файла: с одной стороны, это файл Delphi-проекта (DPR), с другой – база данных. Файлу проекта можно присвоить стереотип «Main Program», изменив его изображение на «Decoration», а базу данных со стереотипом «Database» оставим в неизменном виде. Добавим связи-зависимости (dependency) между исполняемым файлом, файлом проекта и базой данной (рис. 98).

Файл проекта будет связан с тремя файлами – модулями исходных текстов программы (наличие файлов форм и тому подобное подразумевается) – Unit1.pas, Unit2.pas и Unit3.pas (рис. 99). Стереотип этих файлов можно выбрать произвольно – пусть будет Subprogram.

Рисунок 97 – Компонент со стереотипом «исполняемый файл»

 

Рисунок 98 – Новые компоненты и связи между ними

Рисунок 99 – Добавление компонентов с исходным текстом программы

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

Диаграмма развертывания создается пунктом меню «Browse / Deploument Diagram», в правом окне появится заготовка новой диаграммы (рис. 101). Расположенный там по умолчанию комментарий можно удалить, а два находящихся узла – оставить.

Предположим, что наша система может работать в клиент-серверном режиме. Со стороны сервера будут расположены ресурсоемкий узел – компьютер с серверной частью программы, выполняющей авторизацию пользователя, и базы данных. Со стороны клиента расположится любой компьютер, имеющий доступ к сети. В окне спецификации ресурсоемкого узла («процессора») укажем его собственное имя (например, Сервер) и стереотип – «processor», в окне спецификации узла устройства – имя «База данных» и соответствующий стереотип (рис. 102).

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

 

Рисунок 101 – Начальный вид диаграммы развертывания

 

Рисунок 102 – Два узла на диаграмме развертывания

 

Ненужные в нашем случае строки с именами процессов или нитей управления можно убрать с экрана с помощью контекстного меню (отмена пунктов «Show Processes» и «Show Scheduling»).

Новый ресурсоемкий узел на диаграмме – клиент. Изобразим его в виде анонимного экземпляра класса «Клиент» (рис. 103), причем стереотип «processor» можно не указывать, его ресурсоемкость очевидна по внешнему виду.

Сеть, являющуюся, по сути, промежуточным устройством между серверной и клиентской частями системы, изобразим в виде обычного узла (device) со стереотипом «Net» (рис. 104).

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

 

Рисунок 103 – Новый узел – анонимный экземпляр класса

 

Рисунок 104 – Новое устройство «Сеть»

 

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