Варіант використання

💸 Как сделать бизнес проще, а карман толще?

Тот, кто работает в сфере услуг, знает — без ведения записи клиентов никуда. Мало того, что нужно видеть свое раписание, но и напоминать клиентам о визитах тоже. Проблема в том, что средняя цена по рынку за такой сервис — 800 руб/мес или почти 15 000 руб за год. И это минимальный функционал. Нашли самый бюджетный и оптимальный вариант: сервис VisitTime.
⚡️ Для новых пользователей первый месяц бесплатно. А далее 290 руб/мес, это в 3 раза дешевле аналогов. За эту цену доступен весь функционал: напоминание о визитах, чаевые, предоплаты, общение с клиентами, переносы записей и так далее.
✅ Уйма гибких настроек, которые помогут вам зарабатывать больше и забыть про чувство «что-то мне нужно было сделать».
Сомневаетесь? нажмите на текст, запустите чат-бота и убедитесь во всем сами!

Конструкція або стандартний елемент мови UML варіант використання застосовується для специфікації загальних особливостей поведінки системи або будь-якої іншої сутності предметної області без розгляду внутрішньої структури цієї сутності. Кожен варіант використання визначає послідовність дій, які мають бути виконані проектованою системою при взаємодії її з відповідним актором. Діаграма варіантів може доповнюватися текстом пояснення, який розкриває смисл або семантику її складових елементів. Такий текст пояснення називають приміткою або сценарієм.

Окремий варіант використання позначається на діаграмі еліпсом, усередині якого міститься його коротка назва у формі дієслова із словами пояснень (мал. 4.1).

Мал. 4.1. Графічне позначення варіанту використання

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

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

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

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

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

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

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

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

В деяких випадках актор може позначатися у вигляді прямокутника класу з ключовим словом " актор" і звичайними складовими елементами класу. Імена акторів повинні записуватися заголовними буквами і слідувати рекомендаціям використання імен для типів і класів моделі. При цьому символ окремого актора зв'язує відповідний опис актора з конкретним ім'ям. Імена абстрактних акторів, як і інших абстрактних елементів мови UML, рекомендується позначати курсивом.

Ім'я актора має бути достатнє інформативним з точки зору семантики. Для цього цілком підходять мети назви посад в компанії (наприклад, продавець, касир, менеджер, президент). Не рекомендується давати акторам імена власні (наприклад, " О.Бендер") або моделей конкретних пристроїв (наприклад, " маршрутизатор Cisco 3640"), навіть якщо це очевидо з контексту проекту. Річ у тому, що одна і та ж особа може виступати в декількох ролях і, відповідно, звертатися до різних сервісів системи. Наприклад, відвідувач банку може бути як потенційним клієнтом, і тоді він потребує один з його сервісів, а може бути і податковим інспектором або слідчим прокуратури. Сервіс для останнього може бути цілком винятковим за своїм характером.

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

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

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

Будь-яка сутність, яка узгоджується з подібним неформальним визначенням актора, є екземпляром або прикладом актора. Для модельованої системи акторами можуть бути як суб'єкти-користувачі, так і інші системи. Оскільки користувачі системи завжди є зовнішніми по відношенню до цієї системи, то вони завжди представляються у вигляді акторів.

Оскільки в загальному випадку актор завжди є поза системою, його внутрішня структура ніяк не визначається. Для актора має значення лише його зовнішнє представлення, тобто те, як він сприймається з боку системи. Актори взаємодіють з системою за допомогою передачі і прийому повідомлень від варіантів використання. Повідомленням є запит актором сервісу від системи і отримання цього сервісу. Ця взаємодія може бути виражена за допомогою асоціацій між окремими акторами і варіантами використання або класами. Окрім цього, з акторами можуть бути зв'язані інтерфейси, які визначають, яким чином інші елементи моделі взаємодіють з цими акторами.

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