Табличні подання варіанту використання

Іноді представляється зручним розмістити сценарії варіантів використання у таблиці, як це показано нижче. Інформація при цьому набирає більше структурованого вигляду.

Таблиця у 2 колонки:

Актор	Дія
Користувач	Формує запит на пошук замовлень
Система	Відображає список замовлень
Користувач	Вибирає необхідне замовлення
Система	Показує детальну інформацію за замовленням

Таблиця у 3 колонки:

№ кроку	Користувач	Система
1	Робить запит на пошук замовлень	Відображає список замовлень
2	Вибирає необхідне замовлення	Показує детальну інформацію за замовленням

Шаблон варіанту використання rup

З шаблоном опису варіанту використання RUP і прикладами можна ознайомитися у інтерактивній версії RUP.

Нижче наведений стислий огляд його розділів.

1. Найменування і короткий опис. У цьому розділі вказується: найменування варіанту використання, актори варіанту використання, короткий (у один абзац) опис варіанту використання.

2. Потік подій

2.1. Основний потік подій

Так само, як в «Основний сценарій».

2.2. Альтернативні потоки подій

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

3. Спеціальні вимоги

Тут перераховуються нефункціональні вимоги, що мають безпосереднє відношення саме до цього варіанту використання.

4. Передумови

Події, що описуються передумовами або постумовами, мають бути станами, які користувач може спостерігати [3]. Передумова описує стан, в якому система повинна знаходитися до початку виконання прецеденту.

5. Постумови

Постумова RUP по суті описує те ж, що і мінімальна гарантія у Коберна. Л.Новіков [3] акцентує увагу на тому, що коректно сформульована постумова має бути істинною при будь-якому можливому сценарії прецеденту, а не описаному в основному потоці.

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

Цей параграф визначає положення точок, що розширюють потік подій.

При виборі форми і міри деталізації варіанту використання слід враховувати такі чинники, як:

• Розміри проекту;

• Важливість проекту і варіанту використання;

• Традиції, що склалися в колективі «замовник–розробник».

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

Ступінь деталізації залежить також від критичності проекту в цілому і критичності варіанту використання в цьому проекті. А.Коберн поділяє усі програмні проекти за рівнем критичності на 4 категорії, виходячи з ціни помилок: «проекти, помилки в яких можуть привести до»:

• небезпеки для життя людей,

• непоправним фінансовим втратам,

• фінансовим втратам в обмеженому обсязі,

• зниженню комфортності кінцевого користувача.

Очевидно, що військові системи, або ПЗ для управління складними технічними об'єктами вимагають більш прискіпливого документування, у тому числі - і на рівні опису варіантів використання.

Крім того, в одному і тому ж проекті можуть зустрічатися більш та менш важливі прецеденти з позицій частоти і масовості використання, складності для розуміння, технічних ризиків тощо. У цьому випадку для різних прецедентів одного і того ж проекту цілком припустимий опис з різною мірою деталізації.

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