Архитектурный анализ

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

Включает:

· Используемые диаграммы и элементы модели;

· Правила их применения;

· Соглашения по именованию элементов;

· Организация модели (пакеты).

Пример соглашений моделирования:

· Имена вариантов использования должны быть короткими глагольными фразами.

· Для каждого варианта использования должен быть создан пакет Use‑Case Realization, включающий:

§ по крайней мере одну реализацию варианта использования;

§ диаграмму «View Of Participating Classes» (VOPC).

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

· Имена классов должны начинаться с заглавной буквы.

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

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

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

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

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

Идентификация ключевых абстракций

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

Рис. 3.4. Классы анализа системы регистрации

Упражнение 6. Создание структуры модели и классов анализа в соответствии с требованиями архитектурного анализа

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

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

1. Щелкните правой кнопкой мыши на логическом представлении браузера.

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

3. Назовите новый пакет Design Model.

4. Создайте аналогичным образом пакеты Use-Case Realizations, Use-Case Realization – Close Registration, Use-Case Realization – Login и Use-Case Realization – Register for Courses.

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

6.

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

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

1. Щелкните правой кнопкой мыши на пакете Design Model.

2. Выберите в открывшемся меню пункт New > Class. Новый класс под названием NewClass появится в браузере.

3. Выделите его и введите имя Student.

4. Создайте аналогичным образом классы Professor, Schedule, Course и CourseOffering.

5. Щелкните правой кнопкой мыши на пакете Design Model.

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

7. Назовите новую диаграмму классов Key Abstractions.

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

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

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

В потоках событий варианта использования выявляются классы трех типов:

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

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

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

Рис. 3.6. Классы, участвующие в реализации варианта использования Register for Courses

Упражнение 7. Создание классов, участвующих в реализации варианта использования Register for Courses, и диаграммы классов «View Of Participating Classes» (VOPC)

1. Щелкните правой кнопкой мыши на пакете Design Model.

2. Выберите в открывшемся меню пункт New > Class. Новый класс под названием NewClass появится в браузере.

3. Выделите его и введите имя RegisterForCoursesForm.

4. Щелкните правой кнопкой мыши на классе RegisterForCoursesForm.

5. В открывшемся меню выберите пункт Open Specification.

6. В поле стереотипа выберите Boundary и нажмите на кнопку ОК.

7. Создайте аналогичным образом классы CourseCatalogSystem со стереотипом Boundary и RegistrationController со стереотипом Control.

8. Назначьте классам Schedule, CourseOffering и Student стереотип Entity.

9. Щелкните правой кнопкой мыши на кооперации Register for Courses в пакете Use-Case Realization – Register for Courses.

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

11. Назовите новую диаграмму классов VOPC (classes only).

12. Откройте ее и перетащите классы на открытую диаграмму в соответствии с рис. 3.6.

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

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

· обработка ошибок;

· контроль времени выполнения;

· обработка неправильных вводимых данных.

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