Rational Rose

1. Rational Rose

 

Rational Rose – семейство  объектно-ориентированных Case-средств, предназначенных для автоматизации процессов анализа и проектирования ПО, для генерации кодов на различных языках программирования и выпуска проектной документации.

Назначение элементов экрана интерфейса Rose:

Браузер (browser) - используется для быстрой навигации по модели. C помощью браузера можно добавлять к модели элементы, просматривать существующие элементы модели и связи между ними, перемещать и переименовывать элементы модели, добавлять элементы модели к диаграмме,  группировать элементы в пакеты, связывать элемент с файлом или адресом Интернета, работать с детализированной спецификацией элемента,  открывать диаграмму. Браузер поддерживает четыре представления (view): представление вариантов использования, компонентов, размещения и логическое представление.

Окно документации (documentation window) – применяется для работы с текстовым описанием элементов модели. C его помощью можно документировать элементы модели Rose. Например, можно сделать краткое описание каждого действующего лица. При документировании класса все, что будет написано в окне документации, появится затем как комментарий в сгенерированном коде. Документация будет выводиться также в отчетах, создаваемых в среде Rose.

Панели инструментов (toolbars) - применяются для быстрого доступа к наиболее распространенным командам. Панели инструментов Rose обеспечивают быстрый доступ к наиболее распространенным командам. B этой среде существуют два типа панелей инструментов: стандартная панель и панель диаграммы. Стандартная панель видна всегда, ее кнопки соответствуют командам, которые могут использоваться для работы с любой диаграммой. Панель диаграммы своя для каждого типа диаграмм UML.

Все панели инструментов могут быть изменены и настроены пользователем. Для этого используется пункт меню Tools > Options, затем вкладку Toolbars.

Окно диаграммы (diagram window) - используется для просмотра и редактирования одной или нескольких диаграмм UML. B нем показано, как выглядит  диаграммы UML-модели. При внесении в элементы диаграммы изменений Rose автоматически обновит браузер. Аналогично при внесении изменений в элемент с помощью браузера Rose автоматически обновит соответствующие диаграммы. Это помогает поддерживать модель в непротиворечивом состоянии.

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

                       

                                      Рис.1. Интерфейс Rose

 

Четыре представления  модели Rose

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

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

Представление вариантов использования содержит:

1. Действующих лиц.
2. Варианты использования.
3. Документацию по вариантам использования, описывающую происходящие в них процессы (потоки событий), включая обработку ошибок. Эта пиктограмма соответствует внешнему файлу, прикрепленному к модели Rose.
4. Диаграммы вариантов использования. Обычно у системы бывает несколько таких диаграмм, каждая из которых показывает подмножество действующих лиц и/или вариантов использования.
5. Пакеты, являющиеся группами вариантов использования и/или действующих лиц.

 

Рис.2. Представление вариантов использования

 

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

Рис. 3 Логическое представление системы

 

Действующие лица:

Student (Студент) - записывается на курсы.

Professor (Профессор) - выбирает курсы для преподавания.

Registrar (Регистратор) - формирует учебный план и каталог курсов, ведет все данные о курсах, профессорах и студентах.

Billing System (Расчетная система) - получает от данной системы информацию по оплате курсов.

Course Catalog (Каталог курсов) - передает в систему информацию из каталога курсов, предлагаемых университетом.

 

 

Исходя из потребностей действующих лиц выделяются следующие варианты использования:

Login (Войти в систему).

Register for Courses (Зарегистрироваться на курсы).

View Report Card (Просмотреть табель успеваемости).

Select Courses to Teach (Выбрать курсы для преподавания).

Submit Grades (Проставить оценки).

Maintain Professor Information (Вести информацию о профессорах).

Maintain Student Information (Вести информацию о студентах).

Close Registration (Закрыть регистрацию).

 

Диаграмма вариантов  использования

Создаем диаграмму вариантов использования для системы регистрации..

 

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

 

 

 

 

 

 

 

 

2. Архитектурный анализ проектируемой системы.

 

Принятие соглашений по моделированию включает:

1. Используемые диаграммы и элементы модели;
2. Правила их применения;
3. Соглашения по именованию элементов;
4. Организацию модели (пакеты).

 

Реализация  варианта использования (Use-Case Realization)

Описывает реализацию конкретного  варианта использования и представляется с помощью набора диаграмм (диаграмм классов, реализующих вариант использования, и диаграмм взаимодействия, диаграмм последовательности и кооперативных диаграмм), отражающих взаимодействие объектов в процессе реализации варианта использования. Кооперация представляет собой вариант использования со стереотипом «use-case realization», который задается в спецификации варианта использования (рис.5).

 

Рис.5.Реализация варианта использования

 

Идентификация ключевых абстракций. Заключается в предварительном определении классов системы (классов анализа). Источники - знание предметной области, требования к системе, глоссарий. Классы анализа для системы регистрации показаны на рис. 6

 

 

.

 

 

 

 

 

 

 

 

Рис.6. Классы анализа для системы регистрации (Key Abstractions)

 

 

 

Создание пакетов и  диаграммы Traceabilities:

Выбераем пункт New > Package в открывшемся меню.

Называем новый пакет Design Model, правой кнопкой мыши по пакету  Design Model и  создайте аналогичным образом пакеты Use-Case Realizations, Use-Case Realization - Close Registration, Use-Case Realization - Login и Use-Case Realization - Register for Courses.

В каждом из пакетов типа Use-Case Realization создаем соответствующие кооперации Close Registration, Login и Register for Courses (каждая кооперация представляет собой вариант использования со стереотипом «use-case realization», который задается в спецификации варианта использования).

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

 

Рис.7. Структура логического представления браузера

1. Создаем в пакете Use-Case Realization новую диаграмму вариантов использования с названием Traceabilities и постройте ее в соответствии с рис.8

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Рис.8. Диаграмма Traceabilities

 

Создаем класс анализа и соответствующей диаграммы Key Abstractions:

Анализ вариантов  использования

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

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

классы-сущности (Entity) - представляют собой ключевые абстракции (понятия) разрабатываемой системы. Источники выявления классов-сущностей: ключевые абстракции, созданные в процессе архитектурного анализа, глоссарий, описание потоков событии вариантов использования;

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

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

1. обработка ошибок:
2. контроль времени выполнения;
3. обработка неправильных вводимых данных.

Нецелесообразно описывать  тривиальные потоки событий (например, в потоке участвует только один объект).

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Рис. 9

 

Диаграмма классов VOPC

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

3. Создание диаграмм взаимодействия

Создадим диаграммы  последовательности и кооперативные  диаграммы для основного потока событии варианта использования Register.

Настройка

В меню модели выбераем пункт Tools > Options.

Перейдем на вкладку диаграмм.

Контрольные переключатели Sequence Numbering, Collaboration Numbering должны быть помечены, а Focus of Control - нет.

Создание диаграммы  последовательности. Правой кнопкой мыши по кооперации Register for Courses в пакете Use-Case Realization - Register for Courses.

Выбераем пункт New > Sequence Diagram в открывшемся меню.

Назовем новую диаграмму Register for Courses - Basic Flow. Открываем ее.

Добавление  на диаграмму действующего лица, объектов и сообщений

Перетащим действующее лицо Student из браузера на диаграмму.

Перетащим классы RegisterForCoursesForm и Registration Controller из браузера на диаграмму.

На панели инструментов нажимаем на кнопку Object Message (Сообщение объекта).

Проводим мышью от линии жизни действующего лица Student к линии жизни объекта RegisterForCoursesForm.

Выделив сообщение, введите  его имя: // register for courses. Поместить на диаграмму остальные сообщения, как показано на рис.13, (для рефлексивного

 

 

 

 

 

 

 

 

 

 

 

 

Рис.10. Диаграмма последовательности Register for Courses – Basic Flow

For Courses.

 

 

 

 

 

 

 

 

 

Рис.11. Диаграмма последовательности Register for Courses – Basic Flow (Create Schedule)

 

 

 

 

 

 

 

 

Рис.12. Диаграмма последовательности Register for Courses – Basic Flow (Update Schedule)

 

 

 

 

 

 

 

Рис.13. Диаграмма последовательности Register for Courses – Basic Flow (Delete Schedule)

Рис.14. Диаграмма последовательности Register for Courses – Basic Flow (Submit Schedule)

 

 

 

Проектирование архитектуры системы.

Цели проектирования архитектуры системы:

1. анализ взаимодействий между классами анализа, выявление подсистем и интерфейсов;
2. уточнение архитектуры с учетом возможностей повторного использования;
3. идентификация архитектурных решений и механизмов, необходимых для проектирования системы.