Конструкція або стандартний елемент мови UML варіант використання застосовується для специфікації загальних особливостей поводження системи або будь-якої іншої сутності предметної області без розгляду внутрішньої структури цієї сутності. Кожний варіант використання визначає послідовність дій, які повинні бути виконані проектованою системою при взаємодії її з відповідним актором. Діаграма варіантів може доповнюватися пояснювальним текстом, що розкриває зміст або семантику складових її компонентів. Такий пояснювальний текст одержав назву примітки або сценарію.
Окремий варіант використання позначається на діаграмі еліпсом, усередині якого втримується його коротка назва або ім'я у формі дієслова з пояснювальними словами.
Ціль варіанта використання полягає в тім, щоб визначити закінчений аспект або фрагмент поводження деякої сутності без розкриття внутрішньої структури цієї сутності. Як така сутність може виступати вихідна система або будь-який інший елемент моделі, що має власне поводження, подібно підсистемі або класу в моделі системи.
Кожний варіант використання відповідає окремому сервісу, що надає моделюємо сутність або систему по запиті користувача (актора), тобто визначає спосіб застосування цієї сутності. Сервіс, що ініціалізується по запиту користувача, являє собою закінчену послідовність дій. Це означає, що після того як система закінчить обробку запиту користувача, вона повинна вернутися у вихідний стан, у якому готова до виконання наступних запитів.
Варіанти використання описують не тільки взаємодії між користувачами й сутністю, але також реакції сутності на одержання окремих повідомлень від користувачів і сприйняття цих повідомлень за межами сутності. Варіанти використання можуть містити в собі опис особливостей способів реалізації сервісу й різних виняткових ситуацій, таких як коректна обробка помилок системи. Безліч варіантів використання в цілому повинне визначати всі можливі сторони очікуваного поводження системи. Для зручності безліч варіантів використання може розглядатися як окремий пакет.
Із системно-аналітичної точки зору варіанти використання можуть застосовуватися як для специфікації зовнішніх вимог до проектованої системи, так і для специфікації функціонального поводження вже існуючої системи. Крім цього, варіанти використання неявно встановлюють вимоги, що визначають, як користувачі повинні взаємодіяти із системою, щоб мати можливість коректно працювати з надаваними даною системою сервісами!
Кожний виконуваний варіантом використання метод реалізується як неподільна транзакція, тобто виконання сервісу не може бути перервано ніяким іншим екземпляром варіанта використання.
Застосування варіантів використання на всіх рівнях діаграми дозволяє не тільки досягти необхідного рівня уніфікації позначень для подання функціональності підсистем і системи в цілому, але і є потужним засобом послідовного уточнення вимог до проектованої системи на основі полурівневого спуска від пакетів системи до операцій класів. З іншого боку, модифікація окремих операцій класу може вплинути на уточнення сервісу відповідного варіанта використання, тобто реалізувати ефект зворотного зв'язка з метою уточнення специфікацій або вимог на рівні пакетів системи.
У метамодели UML варіант використання є підкласом класифікатора, що описує послідовності дій, виконуваних окремим екземпляром варіанта використання. Ці дії включають зміни стану й взаємодії із середовищем варіанта використання. Ці послідовності можуть описуватися різними способами, включаючи такі, як графи діяльності й автомати.
Прикладами варіантів використання можуть бути наступні дії: перевірка стану поточного рахунка клієнта, оформлення замовлення на покупку товару, одержання додаткової інформації про кредитоспроможність клієнта, відображення графічної форми на екрані монітора й інші дії.
Актори
Актор являє собою будь-яку зовнішню стосовно моделюємої системи сутність, що взаємодіє із системою й використовує її функціональні можливості для досягнення певних цілей або рішення приватних завдань. При цьому актори служать для позначення погодженої безлічі ролей, які можуть грати користувачі в процесі взаємодії із проектованою системою. Кожний актор може розглядатися як якась окрема роль щодо конкретного варіанта використання. Стандартним графічним позначенням актора на діаграмах є фігурка "чоловічка", під якою записується конкретне ім'я актора.
У деяких випадках актор може позначатися у вигляді прямокутника класу із ключовим словом "актор" і звичайними складовими елементами класу. Імена акторів повинні записуватися заголовними буквами й додержуватися рекомендацій використання імен для типів і класів моделі. При цьому символ окремого актора зв'язує відповідний опис актора з конкретним ім'ям. Імена абстрактних акторів, як і інших абстрактних елементів мови UML, рекомендується позначати курсивом.
Ім'я актора повинне бути досить інформативним з погляду семантики. Цілком підходять для цієї мети найменування посад у компанії (наприклад, продавець, касир, менеджер, президент). Не рекомендується давати акторам власні імена (наприклад, "О.Бендер") або моделей конкретних пристроїв (наприклад, "маршрутизатор Cisco 3640"), навіть якщо це з очевидністю треба з контексту проекту. Справа в тому, що одна й та сама особа може виступати в декількох ролях і, відповідно, звертатися до різних сервісів системи. Наприклад, відвідувач банку може бути як потенційним клієнтом, і тоді він затребує один з його сервісів, а може бути й податковим інспектором або слідчим прокуратури. Сервіс для останнього може бути зовсім винятковим за своїм характером.
Прикладами акторів можуть бути: клієнт банку, банківський службовець, продавець магазина, менеджер відділу продажів, пасажир авіарейса, водій автомобіля, адміністратор готелю, стільниковий телефон і інші сутності, що мають відношення до концептуальної моделі відповідної предметної області.
У метамоделі актор є підкласом класифікатора. Актори можуть взаємодіяти з безліччю варіантів використання й мати безліч інтерфейсів, кожний з яких може представляти особливості взаємодії інших елементів з окремими акторами.
Актори використовуються для моделювання зовнішніх стосовно проектованої системи сутностей, які взаємодіють із системою й використовують неї як окремих користувачів. Як акторів можуть виступати інші системи, підсистеми проектованої системи або окремі класи. Важливо розуміти, що кожний актор визначає деяку погоджену безліч ролей, у яких можуть виступати користувачі даної системи в процесі взаємодії з нею. У кожний момент часу із системою взаємодіє цілком певний користувач, при цьому він грає або виступає в одній з таких ролей. Найбільш наочний приклад актора - конкретний користувач системи зі своїми власними параметрами аутентифікації.
Будь-яка сутність, що погодиться з подібним неформальним визначенням актора, являє собою екземпляр або приклад актора. Для моделюємої системи акторами можуть бути як суб'єкти-користувачі, так і інші системи. Оскільки користувачі системи завжди є зовнішніми стосовно цієї системи, то вони завжди представляються у вигляді акторів.
Тому що в загальному випадку актор завжди перебуває поза системою, його внутрішня структура ніяк не визначається. Для актора має значення тільки його зовнішнє подання, тобто те, як він сприймається з боку системи. Актори взаємодіють із системою за допомогою передачі й прийому повідомлень від варіантів використання. Повідомлення являє собою запит актором сервісу від системи й одержання цього сервісу. Ця взаємодія може бути виражене за допомогою асоціацій між окремими акторами й варіантами використання або класами. Крім цього, з акторами можуть бути зв'язані інтерфейси, які визначають, яким образом інші елементи моделі взаємодіють із цими акторами.
Два й більше актори можуть мати загальні властивості, тобто взаємодіяти з тим самим безліччю варіантів використання однаковим образом. Така спільність властивостей і поводження представляється у вигляді розглянутого нижче відношення узагальнення з іншим, можливо, абстрактним актором, що моделює відповідну спільність ролей. Сукупність відносин, які можуть бути присутнім на діаграмі варіантів використання, буде розглянута нижче в даній главі.
