Лабораторная работа № 3 УПРАВЛЕНИЕ ТРЕБОВАНИЯМИ К

Лабораторная работа № 3
УПРАВЛЕНИЕ ТРЕБОВАНИЯМИ К АВТОМАТИЗИРОВАННЫМ СИСТЕМАМ
С ПОМОЩЬЮ IBM RATIONAL REQUISITE PRO.
СОЗДАНИЕ СЦЕНАРИЕВ ИСПОЛЬЗОВАНИЯ
Цель работы: разработка сценариев использования программного обеспечения на
основе запросов заинтересованных лиц и функциональных особенностей программы.
Задачи работы: получение навыков использования IBM Rational RequisitePro для
формализации описания сценариев использования программного обеспечения.
Теоретическая часть
Сценарий использования (use case) – это описание системы в терминах последовательности действий. Он должен иметь значимый результат или определенное значение для
лица, взаимодействующего с системой (actor – действующее лицо). Некоторые характеристики сценариев использования:
– Они инициируются действующим лицом.
– Они являются моделью взаимодействий между действующим лицом и системой.
– Они описывают последовательность действий.
– Они содержат в себе функциональные требования.
– Они должны иметь некоторое значение для действующего лица.
– Они предоставляют полный, имеющий смысл поток событии
Диаграммы сценариев использования отображают действующих лиц, сценарии использования и отношения между ними. Можно разрабатывать диаграммы с использованием
IBM Rational Rose, IBM Rational Software Architect, Microsoft Visio и многих других инструментов.
На диаграмме сценариев использования действующие лица схематично отображаются
фигурками человека, а сценарии использования – овалами. Сплошная стрелка показывает
путь связи между действующим лицом и сценарием использования (рис. 2).
Бронирование
рейса
Турист
Рисунок 2 – Действующее лицо и сценарий использования.
Диаграммы сценариев использования показывают отношения в виде модели сценариев использования. Для небольших систем вся модель сценариев использования может быть
представлена в виде одной диаграммы. Для больших систем мы должны поделить всю систему на несколько диаграмм. Не существует конкретных правил для того, как именно нужно
делить систему.
После создания начальной модели сценариев использования следует структурировать
ее. Основная цель структурирования модели – это удаление любой многословности, делающее сценарии использования более легкими для понимания и изменения. Первым делом
нужно проанализировать сценарии использования и найти части потоков, содержащие одинаковые шаги. Затем мы можно определить связь между сценариями использования с помощью отношений трех типов:
– Включения (Include).
– Расширения (Extend).
– Обобщения (Generalization).
Можно связать отношениями Обобщения как сценарии использования, так и действующие лица.
Если два сценария использования всегда выполняются в одной и той же последовательности, то мы можем их соединить. Например, т.к. сценарий использования Заказ билета
идет после Бронирования рейса, мы решили объединить их.
Если сценарий использования слишком сложный, то можно его разделить. Один из
способов определения того, когда именно сценарий использования должен быть разделен,
это рассмотрение альтернатив. Когда существует альтернативный путь для альтернативного
пути, как правило, это означает, что сценарий использования становится слишком сложным.
Это знак для того, что сценарий использования является кандидатом на разделение на два
различных сценария использования. Один сценарий использования будет расширением основного.
Отношение Включения (Include Relationship). Если важная часть потока используется в более чем одном сценарии использования, то ее можно считать хорошим кандидатом
на извлечение в отдельный сценарий использования, который будет связан с основным отношением включения (include relationship). Сценарий использования будет содержать основной и включенный сценарии использования. Включенный сценарий использования должен
быть самостоятельным, он не может содержать информации о том, в какой сценарий использования он включается.
Чтобы показать это отношение на диаграмме сценариев использования, следует создать зависимость между двумя сценариями использования (используя пунктирную стрелку)
и затем назначить тип включения этой зависимости, как показано на Рисунке 3. Направление
стрелки – от основного сценария использования к включенному.
Поиск заказа
Изменить заказ
Удалить заказ
Рисунок 3 – Отношение включения
Отношение Расширения (Extend Relationship). Если некоторая часть сценария является необязательной или зависит от выполнения какого-либо условия, то с целью уточнения
модели можно извлечь ее как отдельный сценарий использования, связанный отношением
расширения (extend relationship). Чтение сценария использования, являющегося расширением основного сценария использования, не обязательно для понимания назначения основного
сценария использования.
Чтобы показать отношение расширения на диаграмме сценариев использования, следует создать зависимость между двумя сценариями использования. Стрелка указывает на основной сценарий использования, как показано на Рисунке 4.
Удалить заказ
Процесс возмещения затрат
Рисунок 4 – Отношение расширения
Отношение Обобщения (Generalization Relationship). Если два или более сценариев
использования похожи, можно извлечь схожие элементы в один основной (родительский)
сценарий использования. Извлеченные сценарии использования (дочерние) могут изменить
поведение (или добавить новое поведение) родительского сценария использования. Родительский сценарий использования необязательно должен знать, какие дочерние сценарии использования являются его специализацией. Но т.к. этот способ может быть трудным в понимании для заинтересованных лиц, IBM Rational предлагает избегать использования этого типа отношений. Рисунок 5 показывает, как отношение обобщения (generalization relationship)
представляется на диаграмме сценариев использования.
Предоставление информации
Предоставление информации по гостинице
Предоставление информации по автомобилю
Предоставление информации по рейсу
Рисунок 5 – Отношение обобщения
Отношение Обобщения между Действующими Лицами. Обобщение может быть
использовано между действующими лицами. Особенно когда некоторое число действующих
лиц инициируют один и тот же сценарий использования.
Описание задачи
1. На основании документов Запросов Заинтересованного Лица и Концепции сформировать документы Спецификации сценариев использования и сформулировать сценарии использования.
2. На основе сценариев использования построить иерархии требований.
Методика выполнения работы
А. Определение сценариев использования
1. Определить перечень действующих лиц сценариев на основе списка заинтересованных лиц из предыдущей лабораторной работы. Например, руководитель бюро путешествий,
турист, пользователь, система бронирования и т.д.
2. Определить сценарии использования для каждого действующего лица. Например,
для туриста сценарий использования включает в себя:
– бронирование билетов
– заказ билета
– отмена заказа
– выбор места в салоне
– заказ DVD с записью полета и т. д.
Другой пример: сценарий использования состоит из следующих пунктов:
– регистрация в системе;
– вход в систему;
– выход из системы и т. д.
Б. Построение диаграмм сценариев использования
1. Запустить Microsoft Visio и создать новый документ:
Пуск → Программы → Microsoft Office → Microsoft Office Visio 2007 → окно Microsoft Visio | Файл → Создать → Программное обеспечение и базы данных → Схема модели
UML» → новый документ
2. Перейти к шаблону «Сценарии выполнения UML».
3. Создать действующее лицо «Турист»:
ф. Microsoft Visio | перенести в документ фигуру типа «Актер» | выделить фигуру →
конт. меню → Свойства → ф. Свойства актера UML | Имя ← Турист; кн. Ok
4. Создать сценарий выполнения «Бронирование билетов» для туриста:
ф. Microsoft Visio | перенести в документ фигуру типа «Сценарий выполнения» | выделить фигуру → конт. меню → Свойства → ф. Свойства сценария выполнения UML | Имя
← Бронирование билетов; кн. Ok
5. Ввести фигуру типа «Сообщение»
ф. Microsoft Visio | перенести в документ фигуру типа «Сообщение» | присоединить
одну конечную точку фигуры «Сообщение» к точке соединения фигуры «Актер» (Турист);
присоединить другую конечную точку к точке соединения фигуры «Сценарий выполнения»
6. Обозначить направление информационного потока:
выделить фигуру «Сообщение» → двойной клик → группа «Окончание ассоциаций»
→ Окончание «Конец 1» → уст. IsNavigable; кн. Ok;
выделить фигуру «Сообщение» → конт. меню → Свойства → ф. Параметры отображения фигуры… → ф. Параметры отображения фигуры UML | гр. Параметры окончаний |
снять «Имя первого окончания» и «Имя второго окончания», установить «Кратности окончаний», «Перемещаемости окончаний» и «Видимости окончаний»; кн. Ok.
7. Аналогичным образом создать остальные сценарии выполнения для действующего
лица «Турист» и соединить их с актером.
8. Переименовать страницу «Сценарий выполнения-1», изменив ее название на «Сценарий_Турист».
9. Создать новый сценарий выполнения для действующего лица «Пользователь»:
ф. «Сценарий_Турист» → конт. меню → Вставить схему UML… → ф. Добавление
схемы UML | выбр. «Сценарий выполнения», Имя ← Сценарий_Пользователь.
На новой странице построить сценарий выполнения для пользователя.
10. Аналогичным образом построить сценарии выполнения для всех остальных действующих лиц.
11. Структурировать полученные модели сценариев использования с использованием
отношений включения, расширения и обобщения.
В. Создание документа Спецификации Сценариев Использования
1. Создать документ Спецификации Сценариев Использования
Проводник | SpaceTravel | Use Cases | конт. меню New → Document… →
ф. Document Properties | Name ← Use Case Specification – Бронирование билетов; Description ← «Описание сценариев использования»; Document Type ← Use Case Specification;
кн. Ok → окно MS Word с шаблоном документа
2. Заполнение документа Спецификации Сценариев Использования
2.1. Заполнение свойств документа
Шаблон MS Word | кн. Office → Подготовить → Свойства →
ф. Свойства: Use Case Specification.UCS |
Название ← Спецификация сценариев использования; Тема ← Space Travel;
Автор ← Student (фамилии); Организация ← University; кн. Ok
2.2. Автозаполнение полей документа требований:
Окно «Use Case Specification.UCS – Microsoft Word» | колонтитул <Company Name> |
уст. курсор на серое поле → кн. F9 (в результате вместо Company Name должен появиться
текст University). Аналогичным образом заполнить поля <Project Name>, Use Case Specification <Use-Case Name>, <Company Name> (найдите их в документе).
2.3. Заполнить раздел Use Case Name:
2.3.1. Заменить на русскоязычное «Модель сценария бронирования билетов».
2.3.2. Заменить название «Brief Description» на русскоязычное «Краткое описание».
Изменить имеющийся англоязычный текст на следующий:
Документ предназначен для описания сценариев использования системы бронирования билетов в бюро космических путешествий Space Travel. Анализ предметной области
позволил составить перечень действующих лиц: пользователи, туристы, администраторы,
[продолжить самостоятельно].
2.4. Заполнить раздел Flow of Events:
2.4.1. Заменить на русскоязычное «Потоки событий».
2.4.2. Заменить Basic Flow на «Основной поток».
2.4.3. Изменить имеющийся англоязычный текст на описание последовательности
действий в основном потоке:
В1. Турист вводит URL сайта.
В2. Система отображает домашнюю страницу сайта.
В3. Турист вводит:
• Дату и время вылета.
• Дату и время прибытия.
• Число путешествующих взрослых и детей.
• Число путешествующих животных.
Турист выбирает «Поиск рейсов».
В4. Система отображает рейсы вылета, отсортированные по цене.
В5. Турист выбирает рейс.
В6. Система отображает рейс прибытия.
В7. Турист выбирает рейс прибытия.
В8. Система отображает детали рейса.
В9. Турист подтверждает рейс.
В10. Пользователь предоставляет Идентификатор и Пароль для покупки билета.
В11. Турист предоставляет информацию пассажира.
В12. Система отображает свободные места.
В13. Турист выбирает места.
В14. Система отображает доступное меню.
В15. Турист выбирает меню.
В14. Турист предоставляет информацию по кредитной карте и расчетный адрес.
В15. Система предоставляет номер подтверждения.
Дополнить приведенный основной поток не менее 10 этапами.
2.4.4. Заменить Alternative Flows на «Альтернативные потоки».
2.4.5. Изменить имеющийся англоязычный текст подраздела на описание последовательности действий в альтернативных потоках:
А1. Сохранение состояния.
А1.1. После шага В8 Турист выбирает сохранение состояния и выходит.
А1.2. Система возвращается на домашнюю страницу.
А1.3. Сценарий использования заканчивается.
А2. Возвращение к выбору рейсов вылета.
А2.1. После шага В8 Турист возвращается к выбору рейсов вылета.
А2.2. Поток возвращается на шаг В4 основного потока.
А3. Новый пользователь.
А3.1. После шага В9 турист выбирает опцию Новый Пользователь.
А3.2. Система запрашивает информацию пользователя.
А3.3. Турист регистрируется, вводя имя, фамилию, адрес, адрес электронной почты и
пароль.
А3.4. Система подтверждает, что адрес электронной почты уникален и будет рассматриваться в качестве идентификатора пользователя.
А3.5. Поток возвращается на шаг В11 основного потока.
А4. Новый идентификатор пользователя недействителен.
А4.1. После шага А3.3. альтернативного потока А3 система возвращает сообщение, что
предоставленный адрес электронной почты уже есть в системе.
А4.2. Турист предоставляет новый адрес электронной почты.
А4.3. Поток возвращается на шаг А3.4.
Самостоятельно придумать дополнительно не менее 5 альтернативных потоков.
2.5. Заполнить раздел Special Requirements:
2.5.1. Заменить название раздела на «Особые требования».
2.5.2. Если есть требования, не отраженные в основном и альтернативных потоках, записать их в текст раздела. В противном случае – поставить прочерк.
2.6. Заполнить раздел Preconditions
2.6.1. Заменить название раздела на «Предусловия».
2.6.2. Если есть что-то, что пользователь должен сделать перед началом работы сценария (например, запустить браузер), то указать это в тексте раздела.
2.7. Удалить разделы Post Conditions и Extension Points.
3. Сохранить документ:
Окно «Use Case Specification.UCS – Microsoft Word» | Вкл. Надстройки → RequisitePro
→ Document → Save; Закрыть MS Word
Г. Создание требований
1. Создать требование для основного потока:
Выделить текст этапов основного потока → вызвать конт. меню →
выбр. пункт New Requirement… → ф. Requirement Properties: UCpending1 |
Type ← UC: Use Case, Name ← Бронирование билетов – Основной потока; кн. Ok →
Соответствующее требование в тексте будет выделено зеленым цветом шрифта и помещено между прямыми скобками с индексом UCpending1.
2. Создать требование для первого альтернативного потока – Сохранение состояния:
2.1. Создать новое требование:
Выделить текст этапов альтернативного потока А1 → вызвать конт. меню →
выбр. пункт New Requirement… → ф. Requirement Properties: UCpending3 |
Type ← UC: Use Case, Name ← Сохранение состояния; кн. Ok →
2.2. Задать иерархию требований:
ф. Requirement Properties: UCpending3 | вкл. Hierarchy | Parent ← <choose parent…> → ф.
Parent Requirement Browser | выбр. UCpending1: Бронирование билета - Основной поток, кн.
Ok
2.3. Проверить созданную иерархию:
Текст основного потока → конт. меню → Requirement Properties…→ ф. Requirement
Properties | Children ← UC3.1: Сохранение состояния → закрыть форму.
Аналогичным образом создать требования из оставшихся альтернативных потоков.
3. Сохранить документ:
Окно «Use Case Specification.UCS – Microsoft Word» | Вкл. Надстройки → RequisitePro
→ Document → Save; Закрыть MS Word
4. Проверить наличие новых требований и их иерархии в проводнике RequisitePro:
5. Самостоятельно создать и заполнить документы для остальных сценариев использования.
Требования к отчету
Отчет должен содержать:
– название, цель и задачи лабораторной работы;
– краткую теоретическую часть;
– перечень действующих лиц;
– диаграммы сценариев использования;
– содержание документов Спецификаций Сценариев Использования;
– иерархию атрибутов;
– экранные формы работы с RequisitePro;
– выводы по результатам работы.