24. Определение «вариантов использования»

Разработку спецификаций ПО начинают с анализа требований к функциональности, указанных в техническом задании. В процессе анализа выявляют внешних пользователей разрабатываемого ПО и перечень отдельных аспектов его поведения в процессе взаимодействия с конкретными пользователями. Аспекты поведения ПО были названы «вариантами использования» или «прецедентами» (use cases).

Варианты использования основаны на неформальном описании сценариев функционирования проектируемых программных систем, применяемом многими разработчиками ПО в 1980-1990 годах. Айвар Джекобсон расширил содержание вариантов использования, повысил их значимость, что позволило превратить варианты использования в основной элемент разработки и планирования проекта.

Сценарий представляет собой последовательность шагов, описывающих взаимодействие между пользователем и системой. Таким образом, если мы рассмотрим реализованный на веб-технологии интернет-магазин, то можно представить следующий сценарий покупки товаров в этом магазине:

Покупатель просматривает каталог и помещает выбранные товары в корзину. При желании оплатить покупку он вводит информацию о кредитной карточке и совершает платеж. Система проверяет авторизацию кредитной карточки и подтверждает оплату товара тотчас же по электронной почте.

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

Вариант использования представляет собой множество сценариев, объединенных вместе некоторой общей целью пользователя. В нашем случае вы можете построить вариант использования «Покупка товара», который охватывает оба сценария – как успешной оплаты, так и неудачной авторизации. Для вариантов использования могут быть и другие альтернативные пути продолжения сценариев. Часто вариант использования представляет самую общую ситуацию, которая включает множество альтернатив как заканчивающихся неудачей, так и приводящих к успешному завершению.

Сценарии являются для варианта использования почти тем же, чем являются экземпляры для класса. Говорят, что сценарий — это экземпляр варианта использования.

Ниже представлен простой формат для записи варианта использования, в котором исходный сценарий описан в виде последовательности нумерованных шагов, а альтернативы могут изменять эту последовательность (рис. 39.3).

Рисунок 39.3. Текст примера варианта использования

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

Приведем важный пример того, как могут уточнятся варианты использования. Рассмотрим другой сценарий покупки в интернет-магазине, при котором покупатель уже известен системе как постоянный покупатель. Некоторые аналитики будут рассматривать эту ситуацию как третий сценарий, в то время как другие выделят его в отдельный вариант использования.

Приведем пример еще одного из способов записи содержания вариантов использования. Представим описание варианта использования «Покупать авиабилет» для модели информационной системы авиакассы (понятие «элемент Use Case » и «вариант использования» являются синонимами).

Предусловие: перед началом этого элемента Use Case должен быть выполнен элемент Use Case «Заполнить базу данных авиарейсов».

 

Главный поток

Этот элемент Use Case начинается, когда покупатель регистрируется в системе и вводит свой пароль. Система проверяет, правилен ли пароль (Е-1), и предлагает покупателю выбрать одно из действий: СОЗДАТЬ, УДАЛИТЬ, ПРОВЕРИТЬ, ВЫПОЛНИТЬ, ВЫХОД.

Если выбрано действие СОЗДАТЬ, выполняется подпоток S -1: создать заказ авиабилета.

Если выбрано действие УДАЛИТЬ, выполняется подпоток S -2: удалить заказ авиабилета.

Если выбрано действие ПРОВЕРИТЬ, выполняется подпоток S -3: проверить заказ авиабилета.

Если выбрано действие ВЫПОЛНИТЬ, выполняется подпоток S -4: реализовать заказ авиабилета.

Если выбрано действие ВЫХОД, элемент Use Case заканчивается.

 

Подпотоки

S-1: создать заказ авиабилета. Система отображает диалоговое окно, содержащее поля для пункта назначения и даты полета. Покупатель вводит пункт назначения и дату полета (Е-2). Система отображает параметры авиарейсов (Е-3). Покупатель выбирает авиарейс. Система связывает покупателя с выбранным авиарейсом (Е-4). Возврат к началу элемента Use Case .

S-2: удалить заказ авиабилета. Система отображает параметры заказа. Покупатель подтверждает решение о ликвидации заказа (Е-5). Система удаляет связь с покупателем (Е-6). Возврат к началу элемента Use Case .

S-3: проверить заказ авиабилета. Система выводит (Е-7) и отображает параметры заказа авиабилета: номер рейса, пункт назначения, дата, время, место, цену. Когда покупатель указывает, что он закончил проверку, выполняется возврат к началу элемента Use Case .

S-4: реализовать заказ авиабилета. Система запрашивает параметры кредитной карты покупателя. Покупатель вводит параметры своей кредитной карты (Е-8). Возврат к началу элемента Use Case .

 

Альтернативные потоки

Е-1: введен неправильный ID -номер покупателя. Покупатель может повторить ввод ID -номера или прекратить элемент Use Case .

Е-2: введены неправильные пункт назначения/дата полета. Покупатель может повторить ввод пункта назначения/даты полета или прекратить элемент Use Case .

Е-3: нет подходящих авиарейсов. Покупатель информируется, что в данное время такой полет невозможен. Возврат к началу элемента Use Case .

Е-4: не может быть создана связь между покупателем и авиарейсом. Информация сохраняется, система создаст эту связь позже. Элемент Use Case продолжается.

Е-5: введен неправильный номер заказа. Покупатель может повторить ввод правильного номера заказа или прекратить элемент Use Case .

Е-6: не может быть удалена связь между покупателем и авиарейсом. Информация сохраняется, система будет удалять эту связь позже. Элемент Use Case продолжается.

Е-7: система не может вывести информацию заказа. Возврат к началу элемента Use Case .

Е-8: некорректные параметры кредитной карты. Покупатель может повторить ввод параметров карты или прекратить элемент Use Case .