Деталізація прецедентів

Після побудови діаграми прецедентів, кожний прецедент детально описують. Важливо пам’ятати, що прецедент – це текстовий опис. Основною помилкою є нехтування текстовим описом прецедента і зосередження головної уваги на побудові діаграми прецедентів. Діаграма є лише додатковим наочним зображенням, навіть, необов’язковим. UML не визначає стандарт для опису прецедентів. Компанії самостійно обирають стандарт опису прецедентів.

Розрізняють кілька ступенів формалізації прецедента:

стислий – анотація на один абзац, зазвичай вона описує лише основний успішний сценарій

вільний – неформальний стиль: опис займає кілька абзаців і охоплює кілька сценаріїв.

розгорнутий – найбільш докладний стиль опису, містить всі сценарії, передумови, результати,…

Часто використовують наступну специфікацію:

12. ім’я прецедента;

13. ID прецедента;

14. котроткий опис;

15. актори, що задіяні в прецеденті (виконавці);

16. передумови;

17. постумови – результати, що отримують по закінченні прецедента;

18. основний потік (PD: Action Steps);

19. альтернативні потоки або розширення (PD: Extension Points).

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

Основний потік іноді називають основним сценарієм (primary scenario), а альтернативні потоки – другорядними сценаріями (secondary scenarios).

Основний потік відображає ситуацію, коли все проходить ідеально, без відхилень, помилок, переривань, тощо. Відхилення основного потоку моделюються двома способами:

прості відхилення – розгалуження основного потоку;

складні відхилення – альтернативні потоки.

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

1. Прецедент починається, коли <актор> <дія>.

Потік подій складається з послідовності коротких етапів, декларативних, пронумерованих і впорядкованих в часі. Кожний етап потоку прецеденту має бути виражений в наступній формі:

<номер> <хто?> <шо робить?>.

В розділі основного сценарію описуються три види дій:

4. Взаємодія між виконавцями та системою;

5. Верифікація (зі сторони системи);

6. Зміна стану системи (наприклад запис або модифікація сутностей).

Для опису простого розгалуження можна використовувати ключове слово «Якщо», для опису дій, що повторюються можна використовувати ключове слово «Повторити Для» (For) <чого?>, а також «Виконувати Поки» (While).

Основний потік:

1. Прецедент починається, коли Покупець вибирає опцію «знайти продукт».

2. Система запитує у Покупця критерій пошуку.

3. Покупець вводить запрошуваний критерій.

4. Система шукає продукти, відповідні критерію Покупця.

5. Якщо система знаходить відповідні продукти, тоді

5.1. Для кожного знайденого продукту

5.1.1. Система виводить на екран мініатюрне представлення продукту.

5.1.2. Система виводить на екран короткий опис продукту.

5.1.3. Система виводить на екран ціну продукту.

6. Інакше (Else)

6.1. Система повідомляє Покупця про те, що відповідні продукти не знайдені.

Деякі розробники вважають за краще всі розгалуження описувати в розширеннях (через альтернативні потоки). Для опису альтернативних потоків можна використовувати нумерацію літерами: 3а, 3б – позначають першу і другу альтернативу основного потоку, що розгалужуються від п. 3. І далі описувати як основний потік. Можна описувати кожний альтернативний потік окремо (тоді в специфікації прецедента задаються лише назви альтернативних потоків), задаючи йому наступні параметри:

1. ім’я <НазваПрецедента>:<НазваАльтернативногоПотоку>;

2. ID – можливе застосування ієрархічної нумерації;

3. актори, що приймають участь в потоці;

4. передумови та постумови;

5. кроки альтернативного потоку.

Альтернативні потоки не повинні містити альтернативні потоки.

Альтернативні потоки можуть бути ініційовані трьома різними способами:

1. Альтернативний потік може бути ініційований замість основного потоку. Він ініціюється головним актором і повністю заміщає весь прецедент.

2. Альтернативний потік може бути ініційований після певного етапу основного потоку. Він повинен починатися таким чином:

1. Альтернативний потік починається після кроку X основного потоку.

3. Альтернативний потік може бути ініційований у будь-який момент в ході виконання основного потоку (PD: Exceptions). Починати його треба таким чином:

1. Альтернативний потік починається у будь-який момент часу.

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

Щоб виявити альтернативні потоки, потрібно уважно вивчити основний потік. На кожному кроці основного потоку необхідно шукати:

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

• помилки, які можуть виникнути в основному потоці;

• переривання, які можуть трапитися в конкретній точці основного потоку;

• переривання, які можуть відбутися в будь-якій точці основного потоку.

Основний принцип в моделюванні прецедентів – забезпечити необхідний мінімум інформації. Для розуміння функціонування системи може виявитися цілком достатнім короткий опис альтернативних потоків у вигляді одного рядка. Необхідно пам'ятати, що прецеденти виявляються, щоб зрозуміти необхідну поведінку системи, а не з метою створення повної моделі прецедентів.