Виноградова М.В.

МГТУ им. Н.Э. Баумана

Построение модели анализа в инструментальной среде

Учебно-методические материалы «Построение модели анализа в инструментальной среде» представляют собой методические указания к лабораторной работе по дисциплинам «Технологии разработки программного обеспечения» (по направлению магистерской подготовки) и «Технологии проектирования» (по направлению инженерной подготовки).

В материалах рассмотрены принципы построения модели анализа. Приведены методы создания диаграммы классов и последовательностей в среде Rational Software Architect. Рассмотрены примеры построения моделей. В заключительной части методических указаний приведены контрольные вопросы, список рекомендуемой литературы и пример задания.

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

Исходные данные

• проект Rational Software Architect, содержащий модель требований (был создан в ЛР2);

• набор актеров и прецедентов (созданы в ЛР2),

• спецификации прецедентов (созданы в ЛР2),

• прототип пользовательского интерфейса (создан в ЛР2).

Оглавление

Исходные данные 1

Теоретическая часть 3

Унифицированный процесс разработки ПО (RUP) 3

Рабочий процесс «Определение требований» 3

Рабочий процесс «Анализ требований» 4

Модель анализа 4

Шаг 1. Анализ архитектуры - определение коопераций 5

Шаг 2. Анализ архитектуры - определение классов сущностей 5

Шаг 3. Анализ архитектуры - определить граничные и управляющие классы 6

Шаг 4. Анализ кооперации – определить классы-участники кооперации 7

Шаг 5. Анализ кооперации – построить диаграмму последовательностей 8

Шаг 7. Анализ кооперациий 10

Шаг 8. Анализ классов 13

Шаг 9. Анализ пакетов — построить «обзорную» диаграмму всех классов 14

Шаг 10. Анализ пакетов — распределение классов по пакетам 15

Создание диаграмм в среде Rational Software Architect 17

Создание RUP-модели 17

Диаграммы и элементы модели Анализа 17

Создание обзорной диаграммы коопераций 18

Добавление в модель кооперации, пакета или класса 18

Создание обзорных диаграмм классов 20

Добавление атрибутов и связей между классами 20

Анализ кооперации 21

Создание диаграммы последовательностей (циклограммы) 22

Распределение классов по пакетам 24

Действия при анализе требований (итог) 26

Задание 27

Требования к отчету 28

Контрольные вопросы 28

Литература 29

Теоретическая часть

Унифицированный процесс разработки ПО (RUP)

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

Итерация состоит из пяти рабочих процессов: определение требований, анализ, проектирование, реализация и тестирование.

Рабочий процесс «Определение требований»

Рабочий процесс определения требований начитает итерацию. Он состоит из шагов:

• перечислить кандидаты в требования;

• осознать контекст системы (построить модель предметной области и бизнес-модель);

• определить функциональные требования;

• определить нефункциональные требования.

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

• актеры – соответствуют группам пользователей системы;

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

• прототип пользовательского интерфейса;

• модель прецедентов – содержит систему прецедентов из множества актеров, прецедентов и связей между ними;

• глоссарий (словарь) терминов.

Пример: АСУ магазина. Диаграмма прецедентов на рис.1

Рис.1 Диаграмма прецедентов

Рабочий процесс «Анализ требований»

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

• анализ архитектуры системы;

• анализ прецедентов;

• анализ классов;

• анализ пакетов.

В результате выполнения анализа требований будут получены артефакты:

• модель анализа - содержит систему анализа из множества пакетов, классов и коопераций анализа;

• классы анализа – представляют начальное разбиение системы на классы;

• анализ коопераций – показывает реализацию прецедентов в терминах классов и связей между ними;

• пакеты анализа – логические контейнеры классов анализа;

• сервисные пакеты – содержат классы для выполнения сервисных функций.

Далее действия и артефакта анализа рассмотрены подробно.

Модель анализа

Модель анализа создается на основе модели требований (ее прецедентов).

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

Реализация прецедента называется кооперацией и имеет две составляющие: статическую и динамическую. Статическая составляющая задается диаграммой классов, необходимых для выполнения прецедента. Динамическая составляющая определяет алгоритм выполнения прецедента и задается диаграммами взаимодействия.

Шаг 1. Анализ архитектуры - определение коопераций

В начале анализа следует добавить кооперации для реализации основных прецедентов. Для каждого прецедента одну кооперацию. Название кооперации совпадает с названием прецедента. Составляем «обзорную» диаграмму коопераций, содержащую прецеденты и реализующие их кооперации, связь между ними типа «реализации» со стереотипом трассировки (отображения) <<trace>>. См. пример на рис.2

Рис.2 Обзорная диаграмма коопераций и прецедентов

Шаг 2. Анализ архитектуры - определение классов сущностей

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

Построить «обзорную» диаграмму классов сущностей (Domain Model) на основе модели предметной области. Определить для них атрибуты, связи ассоциации, роли, множественность и арность. Классы сущностей имеют стереотип <<entity>>. Пример на рис.3.

Рис.3. Обзорная диаграмма классов сущностей.

Шаг 3. Анализ архитектуры - определить граничные и управляющие классы

Классы анализа бывают трех типов: граничный, управляющий или сущности.

Классы сущностей рассмотрены выше.

Граничный класс – выделяют для моделирования взаимодействия между системой и актерами: получение и передача информации или запроса. Граничный класс соответствует пользовательскому интерфейсу, интерфейсу внешних устройств или коммуникационному протоколу, библиотеке АРI на высоком уровне абстракции без физической реализации. Граничный класс обозначается стереотипом <<boundary>>.

Управляющий класс – выполняет координацию, последовательность, взаимодействие и управление другими объектами для прецедента. Обрабатывает и координирует действия и потоки управления, реализует бизнес-логику. Управляющий класс обозначается стереотипом <<control>>.

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

Принципы выделения классов анализа (для нескольких или всех прецедентов):

• определить по одному основному граничному классу на каждого актера – человека. Это будет прототипом главной формы его пользовательского интерфейса. Основной граничный класс может быть набором простых граничных классов, соответствующих формам его пользовательского интерфейса;

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

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

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

Рис.4 - «обзорная» диаграмма управляющих классов

На рис. 5 приведена «обзорная» диаграмма граничных классов (UI)

Рис. 5. «обзорная» диаграмма граничных классов.

Шаг 4. Анализ кооперации – определить классы-участники кооперации

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

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

• Определить ассоциации между классами в соответствии с их взаимодействием для реализации прецедента.

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

• граничный класс, соответствующий актеру (актерам), которые вызывают данный прецедент (кооперацию),

• управляющий класс, соответствующий данной кооперации,

• классы сущностей, используемые в данной кооперации.

Возможно добавление других управляющих классов (сервисов), если для данной кооперации ее прецедент включает другой прецедент (<<include>>).

Классы, участвующие в кооперации, выбираются из определенных ранее классов анализа. На рис. 6 диаграмма классов – участников кооперации Просмотр каталога.

Рис.6. Диаграмма классов – участников кооперации «Просмотр каталога».

Классы – участники соединяются направленными ассоциациями. Направление ассоциаций соответствует вызовам между классами:

• от актера к его граничному классу (ввод и вывод через пользовательский интерфейс),

• от граничного – к управляющему (передача вызова функции),

• от управляющего – к сущностям (обращение к хранилищу данных),

• от управляющего - к другому управляющему (если есть вызов сервиса).

Шаг 5. Анализ кооперации – построить диаграмму последовательностей

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

На диаграмму последовательностей помещают актера, инициирующего кооперацию, и объекты классов, участвующих в кооперации, и добавляют сообщения, которыми обмениваются объекты при реализации прецедента. Линии и направления сообщений соответствуют ассоциациям на диаграмме классов - участников. Последовательность сообщений определяется порядком взаимодействия объектов. Начинается кооперация всегда сообщением от актера – инициатора. Сообщения указываются без сигнатур, только названием ответственности.

На рис. 7 приведена диаграмма последовательностей для кооперации «Просмотр каталога».