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

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

Рекомендації по розробці діаграм варіантів використання

Головне призначення діаграми варіантів використання полягає у формалізації функціональних вимог до системи і можливості узгодження отриманої моделі із замовником на ранній стадії проектування. Будь-який з варіантів використання може бути підданий подальшій декомпозиції на множину підваріантів використання окремих елементів, які утворюють вихідну сутність. Рекомендована кількість акторів у моделі – не більше 20, а варіантів використання – не більше 50. Інакше модель втрачає свою наочність і, можливо, замінює собою одну з деяких інших діаграм.

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

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

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

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

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

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

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

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

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

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

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