6.4 Заключение
Данная глава обсуждает, каким образом можно извлекать функциональные особенности из требований заинтересованных лиц и затем представлять их в документе Концепции (Vision). Описана структура документа. Эта глава также рассмотрела понятие трассировки (установки связей) и то, как можно представить ее с использованием RequisitePro.
Ссылки
[RUP04] Rational Unified Process, Version 2003.06.13, IBM, 2003.
Глава 7
Создание
Сценариев Использования
(Use Cases)
Сценарий использования (use case) – это описание системы в терминах последовательности действий. Он должен иметь значимый результат или определенное значение для лица, взаимодействующего с системой (actor - действующее лицо). Некоторые характеристики сценариев использования:
Они инициируются действующим лицом.
Они являются моделью взаимодействий между действующим лицом и системой.
Они описывают последовательность действий.
Они содержат в себе функциональные требования.
Они должны иметь некоторое значение для действующего лица.
Они предоставляют полный, имеющий смысл поток событий.
Назначение сценариев использования - способствовать соглашению между разработчиками, заказчиками и пользователями на тему того, что именно система должна делать. Сценарий использования становится своего рода контрактом между разработчиками и заказчиками. Он также является основой для реализации сценариев использования, которые играют большую роль в проектировании системы. Более того, из сценариев использования Вы можете получать пользовательскую документацию. Сценарии использования могут также быть полезны в планировании формального содержания итераций и позволяют разработчикам системы лучше понять назначение системы.
При разработке сценариев использования мы также будем определять сценарии (алгоритмы, scenarios) – особые пути прохождения сценария использования. Из сценариев использования Вы можете создавать диаграммы последовательностей, диаграммы связей и диаграммы классов. Они также используются как исходные данные для тестовых сценариев (test cases).
В показанной на Рисунке 7.1. пирамиде требований сценарии использования находятся одним уровнем ниже функциональных особенностей, а сценарии (алгоритмы) – одним уровнем ниже сценариев использования.
Сценарии использования – это хороший способ выражения функциональных требований системы. Модель сценариев использования содержит все сценарии использования, действующие лица (кто взаимодействует со сценариями использования), а также отношения между ними. Модель определяет взаимоотношения системы и действующих лиц.
Рисунок 7.1. Сценарии использования в пирамиде требований.
7.1 Определение Действующих Лиц
Действующее лицо (actor) – это некто или нечто, взаимодействующее с системой. Им может быть как человек, так и другая система. Несколько примеров действующих лиц:
Пользователи системы.
Администраторы.
Управление.
Лица, предоставляющие информацию для системы.
Внешние системы, предоставляющие данные.
Внешние системы, получающие уведомления.
Все заинтересованные лица также являются кандидатами в действующие лица. Глава 5 «Сбор Требований» определяет следующих заинтересованных лиц:
Владелец Бюро Путешествий.
Пользователь 1 (из США).
Пользователь 2 (из Франции).
Разработчик.
Контент-Менеджер.
Представитель Отдела Обслуживания Клиентов.
Администратор.
Представитель Гостиницы, Агент по Найму Автомобиля, Представитель Авиалиний.
Посмотрим, кто из них может быть действующим лицом:
Владелец Бюро Путешествий (Travel Agency Owner) – может быть действующим лицом, если он предоставит несколько сценариев использования, специфичных только для него. Это зависит от того, есть ли у владельца бюро путешествий особые привилегии, и есть ли некая функциональность, доступная только для владельца. Если он обладает доступом к той же функциональности, что и Администратор, то создавать действующего лица для Владельца Бюро Путешествий нет смысла, т.к. Администратор покрывает его функциональность.
Пользователь 1 и Пользователь 2 могут быть соединены в одного. Так как слово «пользователь» слишком общее, назовем его Турист (Traveler). Действующее лицо определяет роль, а не определенное лицо, так что существует только одно действующее лицо для всех лиц, имеющих одинаковую роль.
Нам также нужна роль с названием Пользователь (User), под которым мы будем понимать всех лиц, имеющих доступ к системе. С этим действующим лицом будут связаны такие сценарии использования, как Регистрация или Вход в Систему. Многие действующие лица унаследуют функциональность от Пользователя.
Разработчик не является действующим лицом, т.к. после создания системы, разработчики не взаимодействуют с ней.
Контент-Менеджер (Content Manager) - это действующее лицо, отвечающее за содержание сайта.
Представитель Отдела Обслуживания Клиентов (Customer Service Representative - CSR) - это действующее лицо, имеющее специальный доступ к системной информации.
Администратор (Administrator) - это действующее лицо, выполняющее различные задачи по администрированию системы.
Представитель Гостиницы, Агент по Найму Автомобиля, Представитель Авиалиний могут рассматриваться как отдельные действующие лица, либо же как одно действующее лицо под названием Служба Предоставления Услуг (Service Provider). Это зависит от того, насколько различны их сценарии использования. Это решение может быть принято позже.
Дополнительным действующим лицом является Airline Reservation System (Система Бронирования). Она не инициирует никаких сценариев использования, но получает информацию, генерируемую в процессе оформления заказа билетов.
Некоторые сценарии использования могут быть инициированы не лицом, а по определенному расписанию (например, batch-программа, запускающаяся раз в сутки в определенное время). В данном случае мы можем показать на диаграмме действующее лицо Таймер, инициирующие этот сценарий использования. Вы также можете дать этому действующему лицу такое название, как Системные Часы (System Clock), Время (Time), или другое название, которое ясно отражает факт того, что сценарий использования начнется в определенный момент времени.
7.2 Определение Сценариев Использования
Несколько вопросов, которые могут помочь в определении сценария использования:
Какую функциональность каждой действующее лицо ожидает от системы?
Должны ли действующие лица быть информированы о происходящих в системе событиях?
Какую информацию действующие лица должны предоставлять системе?
Какую информацию действующие лица должны получать от системы?
О каких событиях, происходящих вне системы, система должна быть уведомлена?
Сценарии использования могут быть определены в течение семинара по требованиям.
Несколько рекомендаций по созданию сценариев использования:
Каждый сценарий использования должен взаимодействовать, по крайней мере, с одним действующим лицом.
Каждый сценарий использования должен инициироваться действующим лицом.
Названия сценариев использования должны быть смысловыми. Используйте Поиск Заказа и Поиск Туриста вместо Поиск 1 и Поиск 2. Никогда не называйте сценарии использования одинаковыми названиями. Названия должны быть понятны не только команде разработчиков, но также заказчикам и пользователям.
Сценарии использования должны описывать функциональность, а не реализацию. Создание компоненты сессии - не совсем хороший сценарий использования.
Должно быть понятно, кто именно инициирует сценарий использования.
Не забывайте, что сценарии использования не могут быть слишком маленькими или слишком большими. Например, Предоставление информации по кредитной карте является некорректным сценарием использования, т.к. он не описывает полный поток событий и не предоставляет никакого значения для действующего лица. В сценарии использования Заказ билета - только один шаг. Если у сценария использования только один или два шага, то возможно, что это некорректный сценарий использования.
Другой пример – Выполнение задач по администрированию. Этот сценарий использования слишком общий и может быть разделен на несколько сценариев использования, имеющие более точный смысл, например Генерация отчетов или Обновление информации пользователя.
В нашем проекте для действующих лиц были определены следующие сценарии использования:
|
|
Airline Reservation System не инициирует ни один сценарий использования.
7.3 Диаграммы Сценариев Использования
Диаграммы сценариев использования отображают действующих лиц, сценарии использования и отношения между ними. Вы можете разработать диаграммы с использованием IBM Rational Rose, IBM Rational Software Architect, Microsoft Visio и многих других инструментов.
На показанной на Рисунке 7.2. диаграмме сценариев использования действующие лица схематично отображаются фигурками человека, а сценарии использования – овалами. Сплошная стрелка показывает путь связи между действующим лицом и сценарием использования.
Бронирование
рейса
Турист
Рисунок 7.2. Действующее лицо и сценарий использования.
Диаграммы сценариев использования показывают отношения в виде модели сценариев использования. Для небольших систем вся модель сценариев использования может быть представлена в виде одной диаграммы. Для больших систем мы должны поделить всю систему на несколько диаграмм. Не существует конкретных правил для того, как именно нужно делить систему.
Несколько вариантов опций, которые могут быть собраны в одну диаграмму:
Все сценарии использования, инициированные одним действующим лицом или группой действующих лиц.
Сценарии использования, которые обычно выполняются в данном контексте.
Сценарии использования, относящиеся к одному типу задач (например, задачи по администрированию).
Рисунки 7.3. - 7.5. представляют начальные диаграммы сценариев использования для проекта Он-лайн Агентства Путешествий.
Рисунок 7.3. Сценарии использования, инициированные действующими лицами Турист и Пользователь.
Рисунок 7.4. Сценарии использования для Представителя Отдела Обслуживания Клиентов и Администратора.
Рисунок 7.5. Сценарий использования, инициированный Службой Предоставления Услуг и Контент-Менеджером.
7.4 Структурирование Модели Сценариев Использования
После создания начальной модели сценариев использования мы можем структурировать ее. Основная цель структурирования модели – это удаление любой многословности, делающее сценарии использования более легкими для понимания и изменения. Первым делом мы должны проанализировать сценарии использования и найти части потоков, содержащие одинаковые шаги. Затем мы можем определить связь между сценариями использования с помощью отношений трех типов:
Включения (Include).
Расширения (Extend).
Обобщения (Generalization).
Мы можем связать отношениями Обобщения как сценарии использования, так и действующие лица.
Если два сценария использования всегда выполняются в одной и той же последовательности, то мы можем их соединить. Например, т.к. сценарий использования Заказ билета идет после Бронирования рейса, мы решили объединить их.
Если сценарий использования слишком сложный, мы можем его разделить. Один из способов определения того, когда именно сценарий использования должен быть разделен, это рассмотрение альтернатив. Когда существует альтернативный путь для альтернативного пути, как правило, это означает, что сценарий использования становится слишком сложным. Это знак для того, что сценарий использования является кандидатом на разделение на два различных сценария использования. Один сценарий использования будет расширением основного.
Тем не менее, если у сценария использования много шагов, которые всегда выполняются вместе в одной и той же последовательности, он не должен быть разделен на два сценария использования.
Отношение Включения (Include Relationship)
Если важная часть потока используется в более чем одном сценарии использования, то ее можно считать хорошим кандидатом на извлечение в отдельный сценарий использования, который будет связан с основным отношением включения (include relationship). Сценарий использования будет содержать основной и включенный сценарии использования. Включенный сценарий использования должен быть самостоятельным, он не может содержать информации о том, в какой сценарий использования он включается.
Чтобы показать это отношение на диаграмме сценариев использования, Вы должны создать зависимость между двумя сценариями использования (используя пунктирную стрелку) и затем назначить тип включения этой зависимости, как показано на Рисунке 7.6. Направление стрелки – от основного сценария использования к включенному.
Рисунок 7.6. Отношение включения (include relationship) между двумя сценариями использования.
Отношение Расширения (Extend Relationship)
Если некоторая часть сценария является необязательной или зависит от выполнения какого-либо условия, то с целью уточнения модели мы можем извлечь ее как отдельный сценарий использования, связанный отношением расширения (extend relationship). Чтение сценария использования, являющегося расширением основного сценария использования, не обязательно для понимания назначения основного сценария использования.
Чтобы показать отношение расширения на диаграмме сценариев использования, создайте зависимость между двумя сценариями использования. Стрелка указывает на основной сценарий использования, как показано на Рисунке 7.7.
Рисунок 7.7. Отношение расширения (extend relationship) между двумя сценариями использования.
Отношение Обобщения (Generalization Relationship)
Если два или более сценариев использования похожи, мы можем извлечь схожие элементы в один основной (родительский) сценарий использования. Извлеченные сценарии использования (дочерние) могут изменить поведение (или добавить новое поведение) родительского сценария использования. Родительский сценарий использования необязательно должен знать, какие дочерние сценарии использования являются его специализацией. Но т.к. этот способ может быть трудным в понимании для заинтересованных лиц, IBM Rational предлагает избегать использования этого типа отношений.
Рисунок 7.8. показывает, как отношение обобщения (generalization relationship) представляется на диаграмме сценариев использования.
Рисунок 7.8. Отношение обобщения (generalization relationship) между двумя сценариями использования.
Отношение Обобщения между Действующими Лицами
Обобщение может быть использовано между действующими лицами. Особенно когда некоторое число действующих лиц инициируют один и тот же сценарий использования. Рисунок 7.9. показывает, как отношение обобщение между действующими лицами показывается на диаграмме сценариев использования.
Рисунок 7.9. Отношение обобщения (generalization relationship) между действующими лицами.
7.5 Документ Спецификации Сценариев Использования
Эта книга использует следующий формат документа Спецификации Сценариев Использования (Use Case Specification):
1. Brief description (Краткое описание)
2. Basic flow (Основной поток)
3. Alternative flows (Альтернативный поток)
3.1 Alternative flow 1 (Альтернативный поток 1)
3.2 Alternative flow 2 (Альтернативный поток 2)
4. Special requirements (Особые требования)
5. Preconditions (Предусловия)
6. Postconditions (Постусловия)
7. Extension points (Точки расширения)
8. Context diagram (Контекстная диаграмма)
9. Activity diagram (Диаграмма активности)
10. State machine diagrams (Диаграмма состояний)
11. Scenarios (Сценарии, Алгоритмы)
Этот шаблон содержит несколько отличий по сравнению с шаблоном сценариев использования, включенным в RequisitePro:
Основной и Альтернативные потоки разделены в разные пункты, чтобы избежать трехуровневой нумерации.
Добавлены диаграммы активности, состояний и контекстная диаграмма.
Добавлены Сценарии (Алгоритмы)
Дальнейшие пункты рассматривают все части документа сценариев использования.
Краткое описание (Brief Description)
Краткое описание (Brief Description) должен понятно объяснять назначение документа. Вы также должны указать всех действующих лиц, взаимодействующих с системой.
Основной Поток (Basic Flow)
Основной поток (Basic flow) содержит наиболее важную последовательность действий – шагов, определяющих корректное поведение системы. В нашем проекте Он-лайн Агентства Путешествий, основной поток сценария использования Бронирование рейса может выглядеть следующим образом:
В1. Турист вводит URL сайта.
В2. Система отображает домашнюю страницу сайта.
В3. Турист вводит:
Аэропорт вылета, дату, время.
Аэропорт прибытия, дату, время.
Число путешествующих взрослых и детей.
Турист выбирает «Поиск рейсов».
В4. Система отображает рейсы вылета, отсортированные по цене.
В5. Турист выбирает рейс.
В6. Система отображает рейс прибытия.
В7. Турист выбирает рейс прибытия.
В8. Система отображает детали рейса.
В9. Турист подтверждает рейс.
В10. Пользователь предоставляет Идентификатор и Пароль для покупки билета.
В11. Турист предоставляет информацию пассажира.
В12. Система отображает свободные места.
В13. Турист выбирает места.
В14. Турист предоставляет информацию по кредитной карте и расчетный адрес.
В15. Система предоставляет номер подтверждения.
Альтернативный Поток (Alternative Flow)
Альтернативные потоки (Alternative, Alternate flows) представляют собой вариации потоков, включая наименее вероятные сценарии использования и ошибочное поведение системы. Следующие вопросы помогут найти альтернативные потоки:
Какие другие действия могут быть выполнены на каждом шаге основного потока?
Какие ошибки могут возникнуть на каждом шаге (неверные данные, пропущенная информация, проблемы соединения)?
Существует ли такое поведение системы, которое может возникнуть в любое время (такое как выход, печать, помощь)?
Могут ли условия (такие как определенные комбинации вводимых данных) существенно изменить поток?
Данная книга использует следующие правила для обозначения потоков
Основной поток (Basic flow): В.
Альтернативный поток (Alternative flows): А1, А2, А3…
Шаги в основном потоке: В1, В2, В3…
Шаги в альтернативном потоке 1: А1.1, А1.2, А1.3…
Шаги в альтернативном потоке 2: А2.1, А2.2, А2.3…
Не существует универсального стандарта для нумерации этих шагов в сценарии использования. Некоторые используют последовательную нумерацию 1,2,3…, а другие используют 2.1, 2.2, 2.3… (т.к. они находятся в пункте 2 документа). Некоторые вообще не используют нумерованные шаги. Но я не рекомендую применять этот подход, т.к. далее будет трудно ссылаться на конкретные шаги.
Несколько альтернативных потоков для сценария использования Бронирование рейса:
А1. Сравнение рейсов в близлежащих аэропортах.
А1.1. На шаге В3 Турист выбирает «Сравнить близлежащие аэропорты».
А1.2. Система показывает список аэропортов в пределах 100 миль от аэропорта вылета и прибытия.
А1.3. Турист выбирает, какой аэропорт должен быть рассмотрен.
А1.4. Поток возвращается на шаг В4 основного Потока.
А2. Сортировка рейсов.
А2.1. После шага В4 Турист изменяет порядок сортировки рейсов.
А2.2. Система отображает рейсы, отсортированные по выбранному критерию.
А2.3. Поток возвращается на шаг В5 основного потока.
А3. Сохранение состояния.
А3.1. После шага В8 Турист выбирает сохранение состояния и выходит.
А3.2. Система возвращается на домашнюю страницу.
А3.3. Сценарий использования заканчивается.
А4. Возвращение к выбору рейсов прибытия.
А4.1. После шага В8 Турист возвращается к выбору рейсов прибытия.
А4.2. Поток возвращается на шаг В6 основного потока.
А5. Возвращение к выбору рейсов вылета.
А5.1. После шага В8 Турист возвращается к выбору рейсов вылета.
А5.2. Поток возвращается на шаг В4 основного потока.
А6. Новый пользователь.
А6.1. После шага В9 турист выбирает опцию Новый Пользователь.
А6.2. Система запрашивает информацию пользователя.
А6.3. Турист регистрируется, вводя имя, фамилию, адрес, адрес электронной почты и пароль.
А6.4. Система подтверждает, что адрес электронной почты уникален и будет рассматриваться в качестве идентификатора пользователя.
А6.5. Поток возвращается на шаг В11 основного потока.
А7. Новый идентификатор пользователя недействителен.
А7.1. После шага А6.3. альтернативного потока А6 система возвращает сообщение, что предоставленный адрес электронной почты уже есть в системе.
А7.2. Турист предоставляет новый адрес электронной почты.
А7.3. Поток возвращается на шаг А6.4. основного потока.
А8. Неверный пароль.
А8.1. После шага В10 основного потока система возвращает сообщение об ошибке, что пароль неверен.
А8.2. Турист предоставляет корректную комбинацию адреса электронной почты и пароля.
А8.3. Поток возвращается на шаг В11 основного потока.
Альтернативные потоки должны иметь уникальную последовательность действий. Они не могут быть различными только в данных. Например, если бы в альтернативном потоке А1 не было бы дополнительного шага выбора Туристом аэропорта, то он не был бы хорошим кандидатом на альтернативный поток:
А1. Сравнение рейсов в близлежащих аэропортах.
А1.1. На шаге В3 Турист выбирает «Сравнить близлежащие аэропорты».
А1.2. Система показывает список аэропортов в пределах 100 миль от аэропорта вылета и прибытия.
А1.4. Поток возвращается на шаг В5 основного потока.
Этот сценарий не должен извлекаться как отдельный альтернативный поток, т.к. последовательность шагов такая же, как в основном потоке. Разница лишь только в данных. На экране ввода выбирается дополнительная опция, а на экране вывода отображаются дополнительные рейсы. Однако данный случай должен рассматриваться как отдельный тестовый сценарий (test case) в процессе извлечения тестовых сценариев из этого сценария использования - см. Главу 9 «Создание Тестовых Сценариев (Test Cases) из Сценариев Использования (Use Cases)».
При структурировании модели сценариев использования мы можем сделать два изменения:
Так как функциональность входа в систему может использоваться в других сценариях использования, шаг В10 и альтернативный поток А8 могут быть извлечены в отдельный сценарий использования Вход в систему.
Так как у альтернативного потока (А6) существует свой альтернативный поток (А7), структура сценария использования становится достаточно сложной. Чтобы от этого уйти, мы можем извлечь функциональность А6 и А7 в отдельный сценарий использования Регистрация.
Особые Требования (Special Requirements)
Пункт Особые требования (Special requirements) содержит все требования, относящиеся к сценарию использования, которые не были покрыты потоком событий. Обычно это нефункциональные требования. Однако если требование довольно общее и встречается во многих сценариях использования, оно должно быть описано в Дополнительной Спецификации.
Предусловия (Preconditions)
Предусловие (Precondition) – это состояние, в котором должна находиться система перед началом сценария использования. Например, предусловием для сценария использования Поиск заказа может быть: «Администратор должен выполнить вход в систему».
Постусловия (Postconditions)
Постусловие (Postcondition) – это состояние, в котором должна находиться система после окончания сценария использования. Пока постусловие не указано в каждом конкретном потоке, оно должно быть одинаковым для всех альтернативных потоком, а не только для основного.
Точки Расширения (Extension Points)
Точка расширения (Extension points) – это место, откуда может быть извлечен расширенный сценарий использования. Например, сценарий использования Удаление заказа может иметь следующее расширение:
Название: Процесс возмещения затрат.
Местоположение: После шага В5 основного потока.
Контекстная Диаграмма (Context Diagram)
Показанная на Рисунке 7.10. Контекстная диаграмма (Context diagram) – это часть диаграммы сценариев использования, отражающая отношения этого сценария использования с действующими лицами и другими сценариями использования. Все сценарии использования, имеющие отношения включения, расширения или обобщения с данным сценарием использования, также должны быть показаны на контекстной диаграмме.
Airline
Reservation System
Пользователь
Бронирование
рейса
Рисунок 7.10. Контекстная диаграмма (Context diagram) для сценария использования Бронирование рейса.
Контекстная диаграмма и диаграмма активности не являются обязательными, но они помогают Вам визуально представить сценарий использования и его позицию в проекте.
Рисунок 7.11. Диаграмма активности (Activity diagram) для сценария использования Бронирование рейса (см. продолжение ниже).
Рисунок 7.11. Диаграмма активности (Activity diagram) для сценария использования Бронирование рейса (продолжение).
Диаграмма Активности (Activity Diagram)
Показанная на Рисунке 7.11. Диаграмма активности (Activity diagram) - схожа с диаграммой потока. Она может быть использована для графического представления потоков в сценариях использования. Прямоугольники с закругленными краями изображают состояния активности, стрелки - переходы, а ромбы изображают ответвления сценариев. Одна диаграмма активности должна содержать основной поток и все альтернативные потоки. Шаги, не имеющие ответвлений между собой, могут быть скомбинированы в один.
Хорошей практикой считается представлять основной поток прямой линией, а альтернативные - в виде исходящих из нее ответвлений или циклов.
Диаграмма активности может быть легко создана с использованием различных инструментов моделирования, таких как Rational Rose, Rational Software Architect, Rational Data Architect, Rational Software Modeler.
Диаграмма Состояний(State Machine Diagram)
Иногда нам нужно описать поведение объектов, различное в зависимости от их состояния. В этом случае мы можем использовать UML2 Диаграммы состояний (State machine diagram) [AMB04]. В предыдущей версии UML эти диаграммы назывались State chart diagrams, а в других языках моделирования они называются State – transition diagrams или просто State diagrams.
Диаграммы cсостояний UML2 отображают разные состояния, в которых может находиться объект, а также переходы между этими состояниями. Например, объект Рейс может находиться в состоянии Забронирован или Зарезервирован.
Прямоугольники с закругленными краями изображают состояния. Стрелки - переходы из одного состояния в другое, вызванные каким-либо событием. Черные круги изображают начальное и конечное состояние.
Этот пункт документа сценариев использования не обязателен.
Сценарии (Scenario, Алгоритмы)
Сценарий (Scenario, Алгоритм) – это часть сценария использования. Он описывает один определенный путь по потоку событий. Важно определить все корректные сценарии для каждого сценария использования. Они будут использованы для анализа и проектирования, также как и для извлечения тестовых сценариев (test cases) из сценариев использования (use cases). Следующий пункт главы описывает, как найти все сценарии.
7.6 Сценарии (Scenario, Алгоритмы)
Чтобы найти все сценарии (алгоритмы), нужно определить все пути по данному сценарию использования. Рисунок 7.12. показывает гипотетический граф, представляющий сценарий использования с основным потоком В и альтернативными потоками А1, А2, А3 и А4. Чтобы найти все алгоритмы, нарисуем все возможные линии через этот граф.
Рисунок 7.12. Поиск сценариев (алгоритмов) в сценарии использования.
Существует один сценарий для основного потока, один сценарий для каждого альтернативного потока и один сценарий для каждой комбинации альтернативных потоков. Получается больше сценариев, чем альтернативных потоков, т.к.: один - А1, другой - А2, а третий сценарий будет комбинацией этих двух альтернативных потоков.
Простейший способ описать сценарий - это предоставить последовательность альтернативных потоков. Например:
SC5: A3, A4.
Нам не нужно добавлять В, показывающее основной поток, т.к. почти все сценарии в любом случае начинаются с основного потока.
Другой способ описания сценария – это перечислить все его шаги, но это более сложно и содержит ненужные детали:
SC5: В1, В2, A3.1, А3.2, А3.3, A4.1, А4.4, А4.3
Что Вы должны делать, если у Вас присутствуют бесконечные циклы (постоянно возвращающиеся назад)? Теоретически, это будет генерировать бесконечное число сценариев. Рисунок 7.13. показывает бесконечный цикл.
Рисунок 7.13. Бесконечный цикл.
Разумный подход в данной ситуации – это пройти по основному потоку один раз, а затем по циклу пару раз. Если система работает для обоих случаев прохождения цикла, Вы можете полагать, что она будет работать и для многочисленных запусков цикла.
Сценарий использования Бронирование рейса содержит основной поток и восемь альтернативных потоков, как показано на Рисунке 7.1. Рисунок 7.14. был получен из показанной на Рисунке 7.11. диаграммы активности. Пять альтернативных потоков возвращаются назад, а другие три идут дальше. Если Вы хотели описать все возможные комбинации альтернативных потоков, Вы бы получили несколько тысяч сценариев. Очевидно, что Вам не нужно составлять все их комбинации.
Таблица 7.1. Потоки в Сценарии Использования Бронирование Рейса.
ID Потока |
Название |
В |
Основной поток |
А1 |
Сравнение рейсов в близлежащих аэропортах |
А2 |
Сортировка рейсов |
А3 |
Сохранение состояния |
А4 |
Возвращение к выбору рейсов прибытия |
А5 |
Возвращение к выбору рейсов вылета |
А6 |
Новый пользователь |
А7 |
Новый идентификатор пользователя недействителен |
А8 |
Неверный пароль |
Рисунок 7.14. Диаграмма, показывающая основной поток и альтернативные потоки.
Выберите самый рациональный набор сценариев из подмножества девяти тысячи сценариев. Обычно лучше всего выбрать основной поток, один сценарий, покрывающий каждый альтернативный поток, и несколько комбинаций альтернативных потоков. Используя потоки из Таблицы 7.1., возможно, нет смысла добавлять сценарий, содержащий оба потока А1 и А8. На диаграмме они расположены настолько далеко, что никак не влияют друг на друга. Но это имеет смысл для А1 и А2, т.к. они выполняются сразу один за другим, и поэтому могут быть соединены.
Таблица 7.2. показывает выбранные сценарии: один представляет основной поток, восемь представляют каждый альтернативный поток, а 13 относятся к некоторым комбинациям потоков.
Таблица 7.2. Сценарии, Выбранные для Тестирования в Сценарии Использования Бронирование рейса.
Номер |
Последовательность Потоков |
Описание |
Сценарий 1 |
В |
|
Сценарий 2 |
А1 |
Близлежащие аэропорты |
Сценарий 3 |
А2 |
Сортировка |
Сценарий 4 |
А3 |
Сохранение и выход |
Сценарий 5 |
А4 |
Возвращение к выбору рейсов прибытия |
Сценарий 6 |
А5 |
Возвращение к выбору рейсов вылета |
Сценарий 7 |
А6 |
Новый пользователь |
Сценарий 8 |
А6, А7 |
Новый идентификатор пользователя недействителен |
Сценарий 9 |
А8 |
Неверный пароль |
Сценарий 10 |
А1, А2 |
Близлежащие аэропорты, затем сортировка |
Сценарий 11 |
А1, А5 |
Возвращение к выбору рейсов вылета с близлежащими аэропортами |
Сценарий 12 |
А1, А4 |
Возвращение к рейсам прибытия с близлежащими аэропортами |
Сценарий 13 |
А2, А2 |
Двойное изменение порядка сортировки |
Сценарий 14 |
А4, А3 |
Возвращение к рейсам прибытия, затем сохранить |
Сценарий 15 |
А4, А5 |
Возвращение к рейсам прибытия, затем вернуться в начало |
Сценарий 16 |
А5, А4 |
Изменить рейс вылета, затем изменить рейс прибытия |
Сценарий 17 |
А5, А3 |
Изменить рейс вылета, затем сохранить |
Сценарий 18 |
А4, А4 |
Дважды изменить рейс прибытия |
Сценарий 19 |
А5, А5,А4 |
Дважды изменить рейс вылета, один раз – рейс прибытия |
Сценарий 20 |
А5, А5,А3 |
Дважды изменить рейс вылета, затем сохранить |
Сценарий 21 |
А6, А7,А7 |
Двойной ввод недопустимого идентификатора |
Сценарий 22 |
А8, А8 |
Двойной ввод недопустимого пароля |
7.7 Сценарии Использования (Use Cases) в RequisitePro.
Документ Спецификации Сценариев Использования (Use Case Specification) создается из шаблона, содержащего рассмотренные в предыдущее главе пункты. Если у Вас нет доступа к RequisitePro, Вы можете создать этот документ в Microsoft Word. Однако использование RequisitePro предлагает Вам больше функциональности, такой как создание требований типа сценариев использования, установка трассировки (связи) и генерация соответствующих отчетов.
Вам не нужно заканчивать весь документ за один раз. Создание сценариев использования – это итеративный процесс. Как только сценарий использования определен, Вы можете создавать соответствующий документ с кратким описанием его назначения. На следующей итерации Вы можете добавить содержание, затем все шаги и в конце – детальное описание каждого шага. Детальный анализ всех стадий жизненного цикла сценариев использования представлен в книге Use Case Modeling, авторами которой являются Kurt Bittner и Ian Spence [BIT02].
Создание Спецификации Сценариев использования (Use Case Specification)
Для создания документа Спецификации Сценариев Использования (Use Case Specification) в RequisitePro, Вы должны выполнить действия, аналогичные действиям при создании документа Требований Заинтересованных Лиц (Stakeholder Request) и Концепции (Vision).
В Explorer (Проводнике), выберите папку Use Cases.
Выберите File> New>Document (Файл>Новый>Документ).
Заполните поля в диалоговом окне Document Properties (Свойства Документа), как показано на Рисунке 7.15. Нажмите ОК.
Эскиз документа откроется в Microsoft Word.
Рисунок 7.15. Диалоговое окно Document Properties (Свойства Документа) для сценария использования Бронирование рейса.
Заполните все пункты документа, как было рассмотрено в пункте 7.5.
Для визуального представления некоторых шагов в документ можно включить экранные формы прототипа. Тем не менее, назначение этих экранных форм – не дизайн пользовательского интерфейса, а пояснение того, какие объекты взаимодействуют с действующим лицом. Экранная форма также может показывать примерные значения для ввода.
Один из наиболее быстрых способов создания таких экранных форм – использование Microsoft Excel для создания таблиц, а затем копирование и вставка в документ сценариев использования, как показано на Рисунке 7.16.
Рисунок 7.16. Прототип экранной формы.
Более наглядные и сложные прототипы экранных форм могут быть созданы с использованием Visio, Microsoft PowerPoint, Visual Basic и многих других инструментов.
Для облегчения обновления Вы можете отделить прототипы экранных форм от потока сценариев использования. В этом случае Вам лучше создать отдельный пункт в документе (например, Экранная Форма - Prototype Screen) и сделать ссылки из шагов сценариев использования на соответствующий пункт документа.
Создание Требований
Перед созданием требований в RequisitePro Вы должны решить, что будет пониматься под одним требованием:
Целый сценарий использования.
Каждый альтернативный поток.
Группа соответствующих шагов.
Каждый шаг.
Это решение зависит от уровня желаемой Вами детализации в трассировке (установки связи). Единственным преимуществом сохранения целых сценариев использования является ограничение затрат в целом, но такой подход может быть не совсем хорошим для отслеживания корректного назначения всех заданий. Сохранение каждого шага в качестве отдельного требования обеспечит хорошую трассировку (связь), но это требует огромных затрат и может затмить основную функциональность и многие детали. Наиболее лучшим подходом является хранение основного и альтернативных потоков в качестве отдельных элементарных требований. Тем не менее, это решение может меняться для разных проектов.
Процесс создания требований сценария использования – тот же, который был использован нами для требований STRQ и FEAT.
Выделите название сценария использования.
Правой кнопкой мышки нажмите на названии и выберите New Requirement (Новое Требование), или выберите RequisitePro>Requirement>New (Требование>Новое), или нажмите на иконку New Requirement (Новое Требование).
Появится диалоговое окно Requirement Properties (Свойства Требования). На закладке General (Общее) Вам не нужно ничего вводить. Тип показывается по умолчанию: «UC: Use Case». Вам не нужно вводить Name (Название), т.к. для определения требования может использоваться Text (Текст).
Нажмите ОК на диалоговом окне Requirement Properties (Свойства Требования).
Вместо выделения названия сценария использования Вы можете включить в требование весь поток. Это позволит автоматическое отслеживание изменений, если кто-то добавит, удалит или изменит любой шаг. Любые изменения будут отображены в подозрительных связях. Для требования Вы можете использовать заголовок в качестве имени, а поток в качестве описания. Если Вы будете использовать заголовок в качестве требования, тогда при изменении описания потока Вам понадобится вручную обозначать связи как подозрительные.
RequisitePro предоставляет возможность установки иерархии требований. Это очень удобно, особенно при структурировании требований сценариев использования. Вы можете определить каждый сценарий использования как родительский и присоединить все альтернативные потоки как дочерние требования. Для создания дочернего требования выполните следующие действия:
Выделите название альтернативного потока, как показано на Рисунке 7.17.
Правой кнопкой мышки нажмите на названии и выберите New Requirement (Новое Требование), или выберите RequisitePro>Requirement>New (Требование>Новое), или нажмите на иконку New Requirement (Новое Требование).
Появится диалоговое окно Requirement Properties (Свойства Требования).
Рисунок 7.17. Выделение текста требования.
Выберите закладку Hierarchy (Иехархия).
В списке Parent (Родительский), выберите «choose parent» («выбрать родительский»).
Появится диалоговое окно Parent Requirement Browser (Обзор Родительского Требования), как показано на Рисунке 7.18.
Выберите родительское требование.
Рисунок 7.18. Выбор названия сценария использования в диалоговом окне Parent Requirement Browser (Обзор Родительского Требования).
Нажмите ОК в диалоговом окне Parent Requirement Browser (Обзор Родительского Требования).
Нажмите ОК в диалоговом окне Requirement Properties (Свойства Требования), как показано на Рисунке 7.19.
Рисунок 7.19. Закладка Hierarchy (Иерархия) в диалоговом окне Requirement Properties (Свойства Требования).
После сохранения документа, RequisitePro назначает уникальный номер требованию. В случае дочернего требования номер состоит из номера родительского требования, точки и номера дочернего требования, как показано на Рисунке 7.20. Иерархия требований может быть просмотрена из Explorer (Проводника), как показано на Рисунке 7.21.
Рисунок 7.20. Нумерация дочерних требований.
Рисунок 7.21. Иерархия сценариев использования в Explorer (Проводнике).
7.8 Создание Нового Типа Требований в RequisitePro.
В зависимости от того, насколько точно Вы хотите отслеживать трассировку (связь) в RequisitePro, Вы можете ввести все сценарии (алгоритмы) в систему, либо установить трассировку прямо из сценариев использования в тестовые сценарии. Преимущество ввода сценариев - это предоставление более детальной трассировки. Недостатком является то, что это создает лишние расходы. Данный пункт использует подход ввода всех сценариев.
Сценарий не является стандартным типом требований в RequisitePro, так что Вам необходимо добавить его как новый тип требований, выполняя следующие действия:
В Explorer (Проводнике), правой кнопкой мышки нажмите на проекте и выберите Properties (Свойства).
Выберите закладку Requirements Type (Тип Требований).
Нажмите Add (Добавить).
Заполните соответствующие поля, как показано на Рисунке 7.22:
Name (Название): Scenario.
Requirement Tag Prefix (Префикс Требования): Может быть любым, но лучше если со смыслом, например SC.
Requirement Color (Цвет Требования): Оставьте по умолчанию Синий (Blue) или выберите другой.
Requirement Style (Стиль Требований): Оставьте по умолчанию Двойное Подчеркивание (Double Underline) или выберите другой.
Рисунок 7.22. Добавление типа требований Scenario (Сценарий).
Нажмите ОК. Сценарий появится на закладке Requirements (Требования), как показано на Рисунке 7.23.
Рисунок 7.23. Тип требований Scenario (Сценарий), добавленный в список типов требований.