Свободный формат

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

Пример: Менеджер запросил у системы список заказов за период. Системы отображает на экран найденные заказы данного менеджера с указанием их основных атрибутов.

Свободный стиль допускает использование конструкций «Если, то».

3.2 Шаблон полного описания вариантов использования.

Название /краткая фраза в виде глагола в неопределенной форме совершенного вида, отражающая цель/

Контекст использования /уточнение цели, при необходимости – условия её нормального завершения/

Область действия /ссылка на рамки проекта/ (Пример: подсистема бухгалтерского учета)

Уровень /один из 3: обобщенный, цели пользователя, подфункции/ (Автор задает предопределенную трехуровневую классификацию требований, в целом соответствующую классификации требований на бизнес-требования, требования пользователя и функциональные требования.)

Участники и интересы /описание других актеров-участников прецедента с указанием их интересов/

Предусловие /то, что ожидается, уже произошло/

Минимальные гарантии /что точно гарантируется актерам-участникам/ (Например, в случае транзакции все данные, имевшиеся в системе до её начала, сохраняются неизменными/

Гарантии успеха /то, что получат актеры в случае успешного достижения целей/ (Пример: то, что запускает вариант использования, обычно – событие во времени.)

Основной сценарий /тут перечисляются шаги основного сценария, начиная от триггера и вплоть до достижения гарантии успеха/ (Формат описания: /№шага/ /описание действия/)

Расширения /тут последовательно описываются все альтернативные сценарии, каждая из которых привязана к шагу основного сценария/ (Формат описания: /№шага/ /№расширения/

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

Любой из шагов основного сценария может иметь более одного ветвления.

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

/№шага/ /№расширения/ /№шага расширения/ /действие/

Описание расширения заканчивается описанием выхода из расширения. Основные варианты выхода из расширения:

- возврат к очередному шагу основного сценария;

- переход к другому шагу основного сценария)

Вспомогательная информация /дополнительная информация, полезная при описании варианта использования/

3.3 Табличные представления варианта использования.

Иногда представляется удобным помещать сценарии вариантов использования в таблицу, как это показано ниже.

Преимущества: информация становится структурированной.

Актер	Действие
Пользователь	Формирует запрос на поиск заказов
Система	Отображает список заказов
Пользователь	Выбирает требуемый заказ
Система	Показывает подробную информацию о заказе

Второй вариант:

№ шага	Пользователь	Система
	Делает запрос на поиск заказов	Отображает список заказов
	Выбирает заказ	Показ. подробную инф. о заказе

3.4 Шаблон варианта использования RUP.

Приведем краткий обзор разделов шаблона описания варианта использования с помощью RUP.

1. Наименование и краткое описание. В этом разделе указывается: наименование варианта использования, актеры, краткое описание.

2. Поток событий.

2.1 Основной поток событий – аналогично основному сценарию из 3.2

2.2 Альтернативные потоки событий. Каждый из альтернативных сценариев описывается в отдельном параграфе, в том же стиле, что и основной поток событий. Альтернативные сценарии описывают поведение системы при любом отклонении от основного сценария.

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

4. Предусловие – состояние, в котором должна находиться система до начала прецедента.

(События, описывающие предусловия или постусловия, должны быть состояниями, которые пользователь может наблюдать.)

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

6. Точки расширения – положение точек, расширяющих поток событий.

3.5 Выбор формы описания варианта использования.

При выборе формы и степени подробности описания варианта использования следует учитывать такие факторы, как:

- размеры проекта;

- важность проекта и варианта использования;

- традиции, сложившиеся в коллективе.

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

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

Степень подробности зависит также от критичности проекта в целом и критичности варианта использования в данном проекте.

А. Коберн делит программные проекты по степени критичности на категории, исходя из цены ошибки – проекты, ошибки в которых могут привести к...:

-опасности для жизни;

- невосполнимым финансовым потерям;

- финансовым потерям в ограниченном объеме;

- снижению комфортности конечного пользователя.

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

Кроме того, в одном и том же проекте может встречаться разные по важности прецеденты с позиции:

- частоты и массовости использования, технических рисков;

- сложности для понимания,...

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

Наконец, спецификация вариантов использования в стиле Коберна, стиле RUP, табличном стиле, с использованием псевдокодов или графических конструкций во многом определяется субъективно выбором автора прецедентов и сложившимся опытом работы с заказчиком проекта.