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

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

Таблица 8.1. Таблица в 2 колонки:
Актор		Действие
Пользователь		Формирует запрос на поиск заказов
Система		Отображает список заказов
Пользователь		Выбирает требуемый заказ
Система		Показывает подробную информацию по заказу
Таблица 8.2. Таблица в 3 колонки:
№ шага	Пользователь		Система
1	Делает запрос на поиск заказов		Отображает список заказов
2	Выбирает требуемый заказ		Показывает подробную информацию по заказу

Шаблон варианта использования rup

С шаблоном описания варианта использования RUP и примерами можно ознакомиться в интерактивной версии RUP¹⁾.

Ниже приведен краткий обзор его разделов.

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

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

2.1. Основной поток событий

Так же, как в "Основной сценарий".

2.2. Альтернативные потоки событий

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

3. Специальные требования

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

4. Предусловия

События, описываемые предусловиями или постусловиями, должны быть состояниями, которые пользователь может наблюдать [8.3]. Предусловие описывает состояние, в котором система должна находиться до начала исполнения прецедента.

5. Постусловия

Постусловие RUP по сути описывает то же, что и минимальная гарантия у Коберна. Л.Новиков [8.3] акцентирует внимание на том, что корректно сформулированное постусловие должно быть истинным при любом возможном сценарии прецедента, а не описанном в основном потоке.

6. Точки расширения

Данный параграф определяет положение точек, расширяющих поток событий.

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

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

• Размеры проекта,

• Важность проекта и варианта использования,

• Традиции, сложившиеся в коллективе "Заказчик-Разработчик".

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

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

• опасности для жизни людей,

• невосполнимым финансовым потерям,

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

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

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

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

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