Спеціалізація

Деякі елементи use case можуть бути спеціалізованими версіями інших елементів.

Наприклад, при розробці програми «Банкомат» елементи use case «Отримання Грошей», «Розміщення Вкладу» і «Запит Стану» є субклассами, або спеціалізованими варіантами абстрактного класу взаємодій, який може бути названий «Використання Банкомату». Що стосується відносини між елементами «Отримання Грошей» і «Використання Банкомату», то його можна охарактеризувати як класифікацію, або спеціалізацію. Такий тип ставлення означає, що один елемент use case «є» («is-a») спеціалізацією іншого. В об'єктно-орієнтованому аналізі і проектуванні таке ставлення відповідає відношенню клас-підклас.

Спеціалізація дає можливість спростити загальну модель use case шляхом відділення загальних чи універсальних форм взаємодії від специфічних форм, адаптованих для більш вузького застосування. Таким чином, немає необхідності переписувати заново найзагальніші патерни застосування. Достатньо написати їх один раз, а потім лише «повторно використовувати» («reuse»), посилаючись на них. Як видно з рисунку 1, для відображення відносини спеціалізації використовується подвійна стрілка. Поруч зі стрілкою можна зустріти підпис «is-a» або «specialize», залежно від контексту.

Рисунок 1 – Відносини спеціалізації на карті елементів use case

Розширення

Однією з інновацій в об'єктно-орієнтованої програмної інженерії, навіяних ідеями Якобсона, стало визнання розширення одним з можливих відносин між елементами use case. Кажуть, що один елемент «розширює» інший, коли він містить вставляються або альтернативні патерни взаємодії, які увійдуть до розширюваний елемент. Наприклад, при відпрацюванні елемента use case для зміни зовнішнього вигляду якоїсь частини екрана користувачеві необхідно займатися пошуком по всій системі файлу, що містить потрібну картинку або піктограму. Нормальне, або очікуване, розвиток подій (забезпечується базисом, або базисним елементом use case) проте зовсім не передбачає пошук якихось додаткових графічних файлів.

Розширення – це вдала концепція, що дозволяє значно спростити сутнісні моделі use case. На мапі елементів use case відношення розширення зображується у вигляді пунктирної лінії зі стрілкою і має підпис «extend», як показано на рисунку 2. Якщо для розширення дається додатковий опис, в нього може бути включено примітка, що показує, які елементи use case розширюються.

Композиція

Елементи use case можна декомпозувати на складові частини, або піделементи, які є підлеглими або включені паттернами взаємодії.

Відношення композиції позначається на карті елементів use case пунктирною стрілкою, що вказує на піделементи use case і має позначку «include», як показано на рисунку 3.

Рисунок 2 – Відношення розширення Рисунок 3 – Відношення композиції

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

Наприклад, елемент use case під назвою «Початок Протоколювання Завдання», створений для програми, що відстежує хід виконання завдань, може використовувати елементи «Авторизація Доступу» і «Введення Параметрів Завдання». Такий спосіб моделювання взаємодій дозволяє розділити незалежні і майже ніяк не пов'язані між собою підзадачі «Авторизація Доступу» і «Введення Параметрів Завдання».