Узагальнення прецедентів

Узагальнення класу – це відношення, направлене від класу до його базового класу, тобто відношення, зворотнє успадкуванню. Узагальнення прецедентів (generalization) аналогічно узагальненню класів, тобто це відношення дочірнього прецеденту до його батьківського (базового) прецеденту. Позначення наведені на рис.2.3.3.

Рис.3.5. Позначення відношення узагальнення між прецедентами

Приклад. Нехай ми проектуємо книжковий Інтернет-магазин. На рис.3.6 представлені три різні варіанти пошуку, доступні покупцю. Кожний варіант використовує базову техніку пошуку, описану у прецеденті Пошук.

Рис.3.6. Приклад множинного узагальнення прецедентів

Пакети прецедентів

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

Рис.3.7. Позначення для пакету прецедентів

Рис.3.8. Приклад пакету прецедентів Візок покупця для книжкового Інтернет-магазину

Прецеденти з пакету Візок покупця тісно пов’язані між собою. Інші можливі пакети прецедентів для цього проекту:

Таблиця 3.3.1. Деякі пакети прецедентів для книжкового Інтернет-магазину

Заключні зауваги стосовно прецедентів

· Прецеденти дуже корисні під час швидкого створення прототипів для „перевірки концепції”.

· При побудові моделі існуючої системи часто прецеденти можна визначити на основі будь-яких доступних керівництв користувача. Процедурна структура цих документів дуже нагадує спосіб опису прецедентів.

· Прецеденти корисні для визначення набору тестів. Тестувальник може взяти пакет прецедентів і перевірити основний або альтернативний хід подій.

Актори

Актори діляться на три основні типи: користувачі системи, інші системи, що взаємодіють з даною, і час.

· Користувачі системи — це фізичні особи. Вони найбільш типові і є практично в кожній системі. У системі АТМ, наприклад, до цього типа відносяться клієнти і обслуговуючий персонал. Називаючи дійових осіб, краще використовувати їх ролеві імена, а не посади. Напр., певний працівник, який відповідає за підтримку сервера банкоматів (нехай це буде роль), в обід зніме гроші і, таким чином, виступить у ролі користувача.

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

· Третій найбільш поширений тип актора — час. Час стає дійовою особою, якщо від нього залежить запуск певних подій у системі. Наприклад, система АТМ може кожного дня опівночі виконувати певні службові процедури.

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

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

Рис.3.10. Комунікація акторів з прецедентами

Коли виконується варіант використання "Виконати оплату", система АТМ ініціює комунікацію з Кредитною системою, щоб завершити транзакцію. Інформація при цьому рухається в обох напрямах: від АТМ до Кредитної системи і назад; стрілка показує лише, хто ініціює комунікацію.

Актори зображаються у вигляді людських фігурок. Можна вводити загальні типи акторів, такі як Customer, і спеціалізувати їх (наприклад, створити різновид CommercialCustomer - комерційний клієнт), визначивши зв'язки узагальнення.

Рис.3.11. Успадкування між акторами

Управління вимогами

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

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

Найчастіше модель вимог розділяють на дві моделі:

· модель функціональних вимог - містить вимоги і властивості, що визначають очікувану функціональну поведінку системи;

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

В першому наближенні вимогами можуть бути виявлені прецеденти, до яких слід додати нефункціональні вимоги.

Контрольні питання

1. Яким чином множина вимог до системи відрізняється від множини прецедентів?

2. Що означає зв'язок асоціації між актором і прецедентом?

3. Чому в разі браку ресурсів на проект необхідно з самого початку розбити вимоги по пріорітетах?

4. Які існують ознаки безнадійного проекту?

Поиск по сайту: