Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла

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

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

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

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

В материалах рассмотрены принципы построения модели анализа. Приведены методы создания диаграммы классов и последовательностей в среде 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 приведена диаграмма последовательностей для кооперации «Просмотр каталога».

Характеристики

Тип файла документ

Документы такого типа открываются такими программами, как Microsoft Office Word на компьютерах Windows, Apple Pages на компьютерах Mac, Open Office - бесплатная альтернатива на различных платформах, в том числе Linux. Наиболее простым и современным решением будут Google документы, так как открываются онлайн без скачивания прямо в браузере на любой платформе. Существуют российские качественные аналоги, например от Яндекса.

Будьте внимательны на мобильных устройствах, так как там используются упрощённый функционал даже в официальном приложении от Microsoft, поэтому для просмотра скачивайте PDF-версию. А если нужно редактировать файл, то используйте оригинальный файл.

Файлы такого типа обычно разбиты на страницы, а текст может быть форматированным (жирный, курсив, выбор шрифта, таблицы и т.п.), а также в него можно добавлять изображения. Формат идеально подходит для рефератов, докладов и РПЗ курсовых проектов, которые необходимо распечатать. Кстати перед печатью также сохраняйте файл в PDF, так как принтер может начудить со шрифтами.

Список файлов лабораторной работы