Сутнісні елементи use case

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

Сутнісні елементи use case будуються на основі цілей і завдань користувача, а не на основі якихось конкретних механізмів або етапів, що ведуть до досягнення цих цілей. Деяким здається значущим включення цілей користувачів в моделі use case, але це не повинно бути пов'язане зі спрощеннями, властивими сутнісному моделювання.

При використанні підходу, орієнтованого на зручність використання, в сутнісних елементах use case, що є структурованим описом, можна виділити три частини: виклад загальних прагнень користувача, виражене в елементі use case, плюс складається з двох частин опис, що включає в себе модель користувальницьких устремлінь і модель зобов'язань системи. Сутнісні елементи use case іменуються, причому за допомогою цих імен намагаються висловити власні наміри в умовах даного варіанту використання. Відповідно до угоди, запропонованим Якобсоном, елемент use case зображується у вигляді еліпса з ім'ям елемента.

Опис варіантів використання

Функціональні вимоги до системи моделюються і документуються за допомогою варіантів використання (use case).

Варіант використання (use case) – зв'язний елемент функціональності, що надається системою при взаємодії з діючими особами.

Дійова особа (actor) – роль, узагальнення елементів зовнішнього оточення системи, які поводяться по відношенню до системи однаковим чином.

В контексті процесу управління вимогами варіанти використання трактуються таким чином (згідно Коберн [2]):

– варіант використання фіксує угоду між учасниками проекту щодо поведінки системи;

– варіант використання описує поведінку системи при різних умовах, коли система відповідає на запит одного з учасників, званого основною дійовою особою;

– основна дійова особа ініціює взаємодію з системою, щоб домогтися певної мети. Система відповідає, дотримуючись інтересів всіх учасників.

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

– назви варіантів використання повинні бути діловими (нетехнічними) термінами, що мають значення для замовника;

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

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

а) Опис варіанта використання за Коберн

Формат опису варіанта використання (за Коберн [2]) складається з:

1. Ім'я – мета у вигляді короткої активної дієслівної фрази.

2. Контекст використання – більш довгий опис мети.

3. Область дії.

4. Рівень точності.

5. Основна діюча особа.

6. Інші учасники і їхні інтереси.

7. Передумова (визначає, виконання якої умови гарантує система перед тим, як вирішити запуск варіанту використання).

8. Мінімальні гарантії (найменші обіцянки системи учасникам, зокрема, коли мета основної діючої особи не може бути досягнута).

9. Гарантії успіху (або постусловіем – postcondition – встановлює, що інтереси учасників задовольняються за успішне завершення варіанту використання в кінці основного сценарію).

10. Тригер (подія, яка запускає варіант використання).

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

– взаємодію двох діючих осіб (наприклад, "Клієнт вводить адресу");

– крок підтвердження для захисту інтересу учасника (наприклад, "Система підтверджує PIN-код");

– внутрішню зміну для задоволення інтересу учасника (наприклад, "Система виводить суму з балансу").

12. Розширення (запускаються при виникненні певної умови, містять послідовність кроків, що описують, що відбувається при цієї умови, і закінчується досягненням мети або відмовою від неї).

13. Список змін в технології і даних.

14. Допоміжна інформація.

б) Опис варіанта використання за RUP

Опис варіанта використання за шаблоном RUP [3] схожий на запропонований Коберн [2]. Він відрізняється тим, що альтернативні потоки описуються окремо від інших розширень.