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

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

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

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

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

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

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

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

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

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

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

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

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

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