ення ієрархічної структури проектованої системи використовуються підсистеми, система може бути визначена у вигляді варіантів використання на всіх рівнях. Окремі підсистеми або класи можуть виступати в ролі таких варіантів використання. При цьому варіант, відповідний деякого з цих елементів, в подальшому може уточнюватися безліччю дрібніших варіантів використання, кожен з яких буде визначати сервіс елемента моделі, що міститься в сервісі вихідної системи. Варіант використання в цілому може розглядатися як суперсервіс для уточнюючих його подвариантов, які, у свою чергу, можуть розглядатися як подсервіси початкового варіанту використання.
Функціональність, певна для більш загального варіанта використання, повністю успадковується усіма варіантами нижніх рівнів. Однак слід зауважити, що структура елемента-контейнера не може бути представлена ??варіантами використання, оскільки вони можуть представляти тільки функціональність окремих елементів моделі. Підлеглі варіанти використання кооперуються для спільного виконання суперсервіс варіанта використання верхнього рівня. Ця кооперація також може бути представлена ??на діаграмі кооперації у вигляді спільних дій окремих елементів моделі.
Окремі варіанти використання нижнього рівня можуть брати участь у кількох коопераціях, т. е. відігравати певну роль при виконанні сервісів декількох варіантів верхнього рівня. Для окремих таких кооперацій можуть бути визначені відповідні ролі акторів, що взаємодіють з конкретними варіантами використання нижнього рівня. Ці ролі гратимуть актори нижнього рівня моделі системи. Хоча деякі з таких акторів можуть бути акторами верхнього рівня, це не суперечить прийнятим в мові UML семантичним правилам побудови діаграм варіантів використання. Більше того, інтерфейси варіантів використання верхнього рівня можуть повністю збігатися за своєю структурою з відповідними інтерфейсами варіантів нижнього рівня.
Оточення варіантів використання нижнього рівня є самостійним елементом моделі, який у свою чергу містить інші елементи моделі, визначені для цих варіантів використання. Таким чином, з точки зору загального уявлення верхнього рівня взаємодія між варіантами використання нижнього рівня визначає результат виконання сервісу варіанту верхнього рівня. Звідси випливає, що в мові UML варіант використання є елементом-контейнером. візуальний моделювання замовник користувач
Варіанти використання класів відповідають операціям цього класу, оскільки сервіс класу є по суті виконанням операцій даного класу. Деякі варіанти використання можуть відповідати застосуванню тільки однієї операції, в той час як інші - кінцевого безлічі операцій, визначених у вигляді послідовності операцій. У той же час одна операція може бути необхідна для виконання декількох сервісів класу і тому буде з'являтися в декількох варіантах використання цього класу.
Реалізація варіанта використання залежить від типу елемента моделі, в якому він визначений. Наприклад, оскільки варіанти використання класу визначаються за допомогою операцій цього класу, вони реалізуються відповідними методами. З іншого боку, варіанти використання підсистеми реалізуються елементами, з яких складається дана підсистема. Оскільки підсистема не має своєї власної поведінки, всі пропоновані підсистемою сервіси повинні представляти собою композицію сервісів, пропонованих окремими елементами цієї підсистеми, т. Е., Зрештою, класами. Ці елементи можуть взаємодіяти один з одним для спільного забезпечення необхідного поводження окремого варіанта використання. Таке спільне забезпечення необхідного поводження описується спеціальним елементом мови UML - кооперація або співробітництво, який буде розглянуто в розділі 9, присвяченій побудові діаграм кооперації. Тут лише зазначимо, що кооперації використовуються як для уточнення специфікацій у вигляді варіантів використання нижніх рівнів діаграми, так і для опису особливостей їх подальшої реалізації.
Якщо в якості модельованої сутності виступає система чи підсистема самого верхнього рівня, то окремі користувачі варіантів використання цієї системи моделюються акторами. Такі актори, будучи внутрішніми по відношенню до модельованим подсистемам нижніх рівнів, часто в явному вигляді не вказуються, хоча і присутні неявно в моделі підсистеми. Замість цього варіанти використання безпосередньо звертаються до тих модельним елементам, які містять в собі подібні неявні актори, т. Е. Екземпляри яких грають ролі таких акторів при взаємодії з варіантами використання. Ці модельні елементи можуть міститися в інших пакетах або підсистемах. В останньому випадку ролі визначаються в тому пакеті, до якого відноситься відповідна підсистема З системно-аналітичної точки зору побудова діаграми варіантів використання специфікує не тільки функціональні в...
