Функциональные особенности Rational Rose

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

Наиболее богатая возможностями модификация позволяет осуществлять:

· Интеграцию с MS Visual Studio 6 с поддержкой прямой и обратной генерации кодов и диаграмм VB 6, Visual C++ 6, Visual J++ 6, PowerBuilder (ATL-Microsoft Active Template Library, Data Connections, DHTML, Web-Classes).

· Поддержку технологий ADO (ActiveX Data Objects) и MTS (Microsoft Transaction Server) на уровне шаблонов и исходного кода, а также элементов стратегической технологии Microsoft - СОМ+ (DCOM).

· Выпуск проектной документации, генерацию программного кода стандарта MS Visual C++, HTML-форматирование проекта для Web-публикации и интеграцию с другими инструментариями ООРП, базами данных и компонентами MS Office.

· Непосредственную работу с библиотеками форматов DLL, OCX, TLB и исполняемыми модулями EXE.

· Поддержку CORBA 2.2 с технологией компонентной разработки приложений CBD (Component-Based Development), языками определения данных DDL (Data Definition Language) и интерфейса IDL (Interface Definition Language).

· Поддержку среды разработки Java-приложений JDK 1.2 с прямой и обратной генерацией классов Java формата JAR и работой с файлами форматов CAB и ZIP.

С помощью Rational Rose можно выполнять следующие функции:

· Разработать функциональную модель системы.

· Создать структурную схему системы или её топологию.

· Разработать модель поведения системы, т.е. динамику.

· Разработать создавать логическое представление системы, на основе которого создается исходный код описанных классов.

· Спроектировать модель компонент системы, представляющих собой модель проектируемых подпрограмм программной системы.

· Сгенерировать на одном из наиболее используемых языков программирования программный код, представляющий собой описание набора классов, описывающих проектируемую систему. Rational Rose не генерирует полностью исполняемый код, а генерируети расписанные классов на выбранном языке программирования.

· Сформировать модели программной системы на основе уже написанного кода.

· Смоделировать WEB-систему.

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

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

Работа с графическими элементами на диаграмме аналогична реализованной в других средах визуального программирования. Удаление элемента с диаграммы дополнительно требует его удаления из модели проекта.

Для удаления элемента не только из любой диаграммы, но и из модели в целом необходимо выделить удаляемый элемент на диаграмме и воспользоваться пунктом меню Edit-»DeIete from Model.

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

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

Разработка диаграммы вариантов использования нужна для:

· определения границ и контекста моделируемой предметной области в начале проектирования системы;

· формулировки требований к функционалу системы;

· создания концептуальной исходной модели системы для детализации далее в виде логических и физических моделей;

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

В этой диаграмме проектируемая система состоит из множества сущностей (актеров), взаимодействующих с системой при помощи т.н. вариантов использования. Действующее лицо (актер, actor) - любая сущность, извне взаимодействующая с системой: человек, аппарат, программа, другая система. Актер служит источником воздействия на модель системы по опредению разработчика. Вариант использования (use case) описывает сервисы, предоставляемые актеру системой, т.е. каждый вариант использования определяет набор действий системы в диалоге с актером. При этом реализация взаимодействия актеров с системой еще не определяется.

Диаграмма вариантов использования - высокоуровневое представление модели, и она не содержит много актеров и вариантов использования. Далее новые элементы можно добавить или удалить из диаграммы. Среда сообщит разработчику, если для пары элементов выбран недопустимый вид связи; такая связь на диаграмму добавлена не будет.

Диаграмма классов (class diagram) представляет статическую структуру модели системы в терминологии классов ООП. Эта диаграмма отражает взаимосвязи между сущностями предметной области (объектами и подсистемами), описывает их внутреннюю структуру и типы отношений. На ней не указывают информацию о временных аспектах работы системы. Итак, диаграмма классов - развитие концептуальной модели системы.

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

Рис. 5.1. Графическое изображение диаграммы классов в Rational Rose.

Пиктограммы стоят перед именем атрибута или операции и имеют смысл:

Открытый (Public) - устанавливается по умолчанию (атрибут 1 в классе 1) и виден всем остальным классам модели, которые могут видеть и менять его значение. В нотации UML открытому атрибуту соответствует знак "+".

Защищенный (Protected, атрибут 2 в классе 1), который можно просмотреть и изменить из самого класса или из его потомков; такому атрибуту соответствует знак "#".

Закрытый (Private, атрибут 3 в классе 1) виден только классу, в котором он определен, и ему соответствует знак "-".

Пакетный (Implemented) атрибут является общим только в своем пакете и не имеет пиктограммы в UML.

Аналогичные пиктограммы имеются и для операций класса.

Через пункт контекстного меню Open Specification (Открыть спецификацию) можно назначить стереотип и задать тип данных и начальные значения отдельных атрибутов класса - в раскрывающемся списке предлагается выбор соответствующих значений. Во вкладке Operations (Операции) для операций класса задают тип результата (возвращаемого класса), добавляют аргументы, назначают стереотип, определяют протокол и размер, задают исключительные ситуации и прочие свойства.

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

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

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

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

Эта диаграмма, главным образом, нужна для описатния возможных последовательностей состояний и переходов, совместно характеризующих поведение элемента модели в его жизненном цикле. Диаграмма состояний исходя из спецификации реакции сущностей на восприятие некоторых конкретных событий представляет их динамическое поведение. Системы, реагирующие на внешние действия, называют реактивными, а если действия происходят в случайные моменты времени, то поведение модели асинхронно. Диаграммы состояний также применяют для спецификации функциональности вариантов использования, актеров, подсистем, операций, методов и других компонент моделей. Примитивный пример представления состояний и переходов на базе автоматов – работоспособность технического устройства. В нем рассматривают два состояния:: "исправно" и "неисправно" и два перехода: "выход из строя" и "ремонт", что и изображено на диаграмме состояний (рис. 5.2).

Рис. 5.2. Диаграммы состояний технического устройства.

Рассмотрим диаграмму состояний на примере моделирования процесса работы телефонного аппарата (рис. 5.3).

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

Рис. 5.3. Диаграмма состояний работы телефонного аппарата.

Аппарат, находясь в состоянии «тоновый сигнал»; последний будет непрерывно издаваться до момента появления события-триггера «набор цифры (п)», но не более 15 секунд с момента поднятия трубки. В первом случае аппарат окажется в состоянии «набор номера», иначе - в состоянии «Конец времени ожидания». Это нужно для снятия нагрузки на сеть.

Если при наборе номера происходит событие-триггер «набор цифры (п)» с условием-сторожем «номер неполный», то, при отсутствии в набранном номере необходимого количества цифр, продолжается набор цифр в состоянии «набор номера». В случае полноты набранного номера идет переход в состояние «неверный номер» или «соединение». В первом случае (условие-сторож «неверный» истинно) составное состояние покидается, иначе происходит попытка соединения по набранному номеру.

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

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

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

Рассмотрим часть алгоритма вычисления действительных корней квадратного уравнения канонического вида: а*х*х + b*х + с = 0. Если его дискриминант отрицателен, уравнение не имеет действительных решений, и процесс прекращается; иначе корни можно получить по конкретной формуле.

Фрагмент процедуры вычисления корней можно представить диаграммой деятельности с тремя состояниями действия и ветвлением (рис. 5.4). Каждый переход из состояния "Вычислить дискриминант" условие-сторож определяет по знаку дискриминанта.

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

Диаграммы взаимодействия используют при моделировании взаимодействия объектов в UML.

Взаимодействия объектов происходят во времени; для описания процессов приема и передачи сообщений между объектами применяют диаграмму последовательности.

Рассмотрим диаграммы последовательности при моделировании телефонного разговора по обычной телефонной сети. Объекты в этом примере - два абонента а и b, два телефонных аппарата c и d, коммутатор и сам разговор как процесс; коммутатор и разговор суть анонимные объекты.

Сначала объекты располагают на предполагаемой диаграмме (рис. 5.5.). Абоненты рассматриваются как актеры, причем первый (а) активен, а второй (b) - пассивен. Первый получает фокус управления с появлением в системе, а у второго есть только линия жизни. Коммутатор тоже постоянно активен, что показано его фокусом управления. Объект разговора появляется после установки соединения и исчезает с его прекращением, почему он будет изображен на этой же диаграмме позже.

Рис 5.5. Первая часть диаграммы последовательности для модели телефонного разговора.

Взаимодействия в системе начинаются с поднятия трубки аппарата первым абонентом. Это сообщение активизирует аппарату «c», и вызывает тоновый сигнал в трубку первого абонента. Второе действие, инициируемое первым абонентом - набор цифр номера, что представлено итеративным сообщением со знаком "*" слева от имени.

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

Анонимный объект "разговор" получает фокус активности и посылает сообщение аппарату «d» для выполнение звонка вызова. При этом второй абонент снимает трубку (это асинхронное сообщение), и устанавливается прямое соединение между абонентами «а» и «b2. Объект "разговор" уничтожается после опускания трубок абонентами. Диаграмма последовательности может включать временные ограничения и комментарии (рис. 5.7.).

Рис. 5.6. Дополнение диаграммы последовательности для модели телефонного разговора.

Рис. 5.7. Диаграмма последовательности для модели телефонного разговора.

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

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

Диаграмма компонент разрабатывается для:

• Визуализации общей структуры системы.
• Спецификации реализуемого варианта системы.
• Обеспечения многократного использования отдельных фрагментов модели.
• Представления концептуальной и физической схем информационных структур.

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

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

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

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

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

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

1. Проверяется модель.

2. Создаются компоненты реализации классов.

3. Отображаются классы на компоненты.

4. Устанавливают свойства генерации программного кода.

5. Выбирают класс, компоненту или пакет.

6. Генерируют программный код.

Каждый из этапов может изменяться в зависимости от языка.

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

Для обратного проектирования в Rational Rose введен модуль Analyzer, анализирующий файл (на ADA, Basic, С, С++, COM, DDL, XML и др.) и преобразующий его в файл визуальной модели с расширением mdl. Далее файл открывается в визуальном режиме для модификации из Rational Rose.