Пример выполнения лабораторной работы

Архитектурный анализ подразумевает собой принятие соглашений по моделированию, которое включает:

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

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

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

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

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

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

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

· Use-Case Realization, включающий по крайней мере одну реализацию варианта использования диаграмму «View Of Participating Classes» (VOPC);

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

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

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

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

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

Рисунок 2.6 – Реализация варианта использования

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

Для создания пакетов и диаграммы 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», который задается в спецификации варианта использования), для этого используйте пункт меню Tools -> Creat -> Use case;

6) создайте в пакете Use-Case Realizations новую диаграмму вариантов использования с названием Traceabilities и постройте ее в соответствии с рисунком 2.8.

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

Рисунок 2.7 – Структура логического представления

Рисунок 2.8 – Диаграмма Traceabilities

Рисунок 2.9 – Классы анализа системы регистрации

Создание классов анализа и соответствующей диаграммы 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) чтобы расположить вновь созданные классы на диаграмме классов, откройте ее и перетащите классы на открытую диаграмму мышью. Диаграмма классов должна выглядеть как на рисунке 2.9.

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

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

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

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

Пример набора классов, участвующих в реализации варианта использования Register for Courses, приведен на рисунке 2.10.

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

Последовательность действий создания классов, участвующих в реализации варианта использования 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) откройте ее и перетащите классы на открытую диаграмму в соответствии с рисунком 2.10.

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

Примеры:

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

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

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

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

2.3 Лабораторная работа №3. Создание диаграмм
последовательности

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

Задачи работы: освоить приемы построения диаграммы последовательности, создания компонентов диаграммы.

Содержание работы:

1) выполнение предварительной настройки;

2) создание диаграммы последовательности;

3) выполнение соответствия между сообщениями и операциями;

4) нанесение примечаний.

Не нашли, что искали? Воспользуйтесь поиском: