Rational Rose. 3

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. идентификация архитектурных решений и механизмов, необходимых для проектирования системы.

Вводятся глобальные пакеты:

1. базисные (foundation) классы (списки, очереди и т.д.);
2. обработчики ошибок (error handling classes);
3. математические библиотеки:
4. утилиты;
5. библиотеки других поставщиков.

Определяются проектные  классы (design classes):

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

Примеры возможных  подсистем:

1. классы, обеспечивающие сложный комплекс услуг (например, обеспечение безопасности и защита);
2. граничные классы, реализующие сложный пользовательский интерфейс, или интерфейс с внешними системами;
3. различные продукты: коммуникационное ПО (middleware, поддержка COM/CORBA), доступ к базам данных, типы и структуры данных (стеки, списки, очереди), общие утилиты (математические библиотеки), различные прикладные продукты.

Принятие решения о  преобразовании класса в подсистему определяется опытом и знаниями архитектора проекта.

Соглашения по проектированию интерфейсов:

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

 Вся эта информация объединяется в специальный пакет со стереотипом «subsystem», который содержит элементы, образующие подсистему, диаграммы последовательности и/или кооперативные диаграммы, описывающие взаимодействие элементов при реализации операций интерфейса, и другие диаграммы;

класс «subsystem proxy» непосредственно реализует интерфейс и управляет реализацией его операций;

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

Выделение архитектурных  уровней:

Application Layer - содержит элементы прикладного уровня (пользовательский интерфейс);

Business Services Layer - содержит элементы, реализующие бизнес-логику приложений (наиболее устойчивая часть системы);

Middleware Layer - обеспечивает сервисы, не зависимые от платформы.

Пример выделения архитектурных  уровней и объединения элементов 

 

 

 

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

Данное представление  отражает следующие решения, принятые архитектором:

1. выделены три архитектурных уровня (созданы три пакета со стереотипом «layer»);
2. в пакете Application создан пакет Registration, куда включены граничные и управляющие классы;
3. граничный класс CourseCatalogSystem преобразован в подсистему (пакет CourseCatalogSystem со стереотипом «subsystem»);
4. в пакет Business Services, помимо подсистемы CourseCatalogSystem, включены еще два пакета: пакет External System Interfaces включает интерфейс с подсистемой CourseCatalogSystem (класс ICourseCatalogSystem со стереотипом «Interface»), а пакет University Artifacts - все классы - сущности.

Структура и диаграммы  пакета (подсистемы) CourseCatalogSystem показаны на рис.(23 – 27).

 

 

Рис.15. Структура пакета CourseCatalogSystem

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Рис.16. Зависимости между подсистемой и другими пакетами (диаграмма классов CourseCatalogSystem и Dependencies)

 

 

 

 

Рис.17. Классы, реализующие интерфейс подсистемы

(диаграмма классов ICourseCatalogSystem)

 

 

Рис.18. Диаграмма последовательности

 

Рис.19. Диаграмма последовательности

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

Нажмите кнопку Dependency панели инструментов.

Проведите линию зависимости  от зависимого пакета к тому, от которого он зависит.

Класс DBCourseOffering отвечает за взаимодействие с БД каталога курсов (рис. 26, 27).

Моделирование распределенной конфигурации системы

Распределенная конфигурация системы моделируется с помощью диаграммы размещения. Ее основные элементы:

1. узел (node) - вычислительный ресурс (процессор или другое устройство, дисковая память, контроллеры различных устройств и т.д.). Для узла можно задать выполняющиеся на нем процессы;
2. соединение (connection) - канал взаимодействия узлов (сеть).

 

 

Распределение процессов  по узлам сети производится с учетом следующих факторов:

1. используемые образцы распределения (трехзвенная клиент-серверная конфигурация, «толстый» клиент, «тонкий» клиент, равноправные узлы (peer-to-peer) и т.д.);
2. время отклика;
3. минимизация сетевого графика;
4. мощность узла;
5. надежность оборудования и коммуникаций.

 

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

Для того чтобы поместить  на диаграмму процессор:

1. На панели инструментов диаграммы нажмите кнопку Processor.
2. Щелкните по диаграмме размещения в том месте, куда хотите поместить процессор.
3. Введите имя процессора.

В спецификациях процессора можно ввести информацию о его стереотипе, характеристиках и планировании. Стереотипы применяются для классификации процессоров (например, компьютеров под управлением UNIX или ПК).

Характеристики  процессора - это его физическое описание. Оно может, в частности, включать скорость процессора и объем памяти.

После планирования (scheduling) процессора содержит описание того, как осуществляется планирование его процессов:

Preemptive (с приоритетом). Высокоприоритетные процессы имеют преимущество перед низкоприоритетными.

Non preemptive (без приоритета). У процессоров не имеется приоритета. Текущий процесс выполняется до его завершения, после чего начинается следующий.

Cyclic (циклический). Управление передается между процессами по кругу. Каждому процессу дается определенное время на его выполнение, затем управление переходит к следующему процессу.

Executive (исполнительный). Существует некоторый вычислительный алгоритм, который и управляет планированием процессов.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

4. Проектирование классов

 

Классы анализа преобразуются  в проектные классы:

1. Проектирование граничных классов - зависит от возможностей среды разработки пользовательского интерфейса (GUI Builder).
2. Проектирование классов-сущностей - с учетом соображений производительности (выделение в отдельные классы атрибутов с различной частотой использования).
3. Проектирование управляющих классов - удаление классов, реализующих простую передачу информации от граничных классов к сущностям.
4. Идентификация устойчивых (persistent) классов, содержащих хранимую информацию.

Обязанности классов, определенные в процессе анализа, преобразуются в операции. Каждой операции присваивается имя, характеризующее ее результат. Определяется полная сигнатура операции: operationName (parameter: class, ...): returnType. Создается краткое описание операции, включая смысл всех ее параметров. Определяется видимость операции: public, private, protected. Определяется область действия (scope) операции: экземпляр или классификатор.

Определяются (уточняются) атрибуты классов:

1. Кроме имени, задаются тип и значение по умолчанию (необязательное): attributeName:Type = Default.
2. Учитываются соглашения по именованию атрибутов, принятые в проекте и языке реализации.
3. Задается видимость атрибутов: public, private, protected. При необходимости определяются производные (вычисляемые) атрибуты.

Пример определения операций и атрибутов.

 

Определение состояний  для классов: моделируется с помощью  диаграмм состояний.

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

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

 

 

 

Рис.20. Диаграмма состояний для класса CourseOffering

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Список используемой литературы

 

1. Quatrani. T. Visual Modeling with Rational Rose and UML.  Addison-Wesley?       1998. 222 h. (Русский перевод 2-го изд. Кватрани Т.  Rational Rose 2000  и UML. Визуальное моделирование. М.: ДМК Пресс, 2001, 176 с.
2. Орлов С.А. Технология разработки программного обеспечения. Учебник для вузов. СПб,: Питер, 2004, 527 с.
3. Леоненков А. UML 2-е издание, Санкт-Петербург: БХВ-Петербург, 2004,432 с.
4. Вендров А.М. Проектирование программного обеспечения экономических информационных систем. Учебник. М.: Финансы и статистика, 2003, 352 с.
5. Вендров А.М. Практикум по проектированию программного обеспечения экономических информационных систем. М.: Финансы и статистика, 2002,192 с.