Головне призначення діаграми варіантів використання полягає у формалізації функціональних вимог до системи за допомогою понять відповідного пакета й можливості узгодження отриманої моделі із замовником на ранній стадії проектування. Кожної з варіантів використання може бути піддадуть подальшої декомпозиції на безліч подваріантів використання окремих елементів, які утворять вихідну сутність. Загальна кількість акторів, що рекомендується, у моделі - не більше 20, а варіантів використання - не більше 50. У противному випадку модель втрачає свою наочність і, можливо, заміняє собою одну з деяких інших діаграм.
Семантика побудови діаграми варіантів використання повинна визначатися наступними особливостями розглянутих вище елементів моделі. Окремий екземпляр варіанта використання по своєму змісті є виконанням послідовності дій, що ініціалізується за допомогою екземпляра повідомлення від екземпляра актора. Як відгук або відповідної реакції на повідомлення актора екземпляр варіанта використання виконує послідовність дій, установлену для даного варіанта використання. Екземпляри акторів можуть генерувати нові екземпляри повідомлень для екземплярів варіантів використання.
Подібна взаємодія буде тривати доти, поки не закінчиться виконання необхідної послідовності дій екземпляром варіанта використання, і відповідний екземпляр актора (і ніякий іншої) не одержить необхідний екземпляр сервісу. Закінчення взаємодії означає відсутність ініціалізації екземплярів повідомлень від екземплярів акторів для відповідних екземплярів варіантів використання.
Варіанти використання можуть бути специфіковані у вигляді тексту, а надалі - за допомогою операцій і методів разом з атрибутами, у вигляді графа діяльності, за допомогою автомата або будь-якого іншого механізму опису поводження, що включає передумову й післяумову. Взаємодія між варіантами використання й акторами може уточнюватися на діаграмі кооперації, коли описуються взаємозв'язки між сутністю, що містить ці варіанти використання, і оточенням або зовнішнім середовищем цієї сутності.
У випадку, коли для подання ієрархічної структури проектованої системи використовуються підсистеми, система може бути визначена у вигляді варіантів використання на всіх рівнях. Окремі підсистеми або класи можуть виступати в ролі таких варіантів використання. При цьому варіант, що відповідає якомусь із цих елементів, надалі може уточнюватися безліччю більше дрібних варіантів використання, кожний з яких буде визначати сервіс елемента моделі, що втримується в сервісі вихідної системи. Варіант використання в цілому може розглядатися як суперсервіс для уточнюючих його підваріантів, які, у свою чергу, можуть розглядатися як підсервіси вихідного варіанта використання.
Функціональність, певна для більше загального варіанта використання, повністю успадковується всіма варіантами нижніх рівнів. Однак варто помітити, що структура елемента-контейнера не може бути представлена варіантами використання, оскільки вони можуть представляти тільки функціональність окремих елементів моделі. Підлеглі варіанти використання кооперуються для спільного виконання суперсервісу варіанта використання верхнього рівня. Ця кооперація також може бути представлена на діаграмі кооперації у вигляді спільних дій окремих елементів моделі.
Окремі варіанти використання нижнього рівня можуть брати участь у декількох коопераціях, тобто відігравати певну роль при виконанні сервісів декількох варіантів верхнього рівня. Для окремих таких кооперацій можуть бути визначені відповідні ролі акторів, взаємодіючих з конкретними варіантами використання нижнього рівня. Ці ролі будуть грати актори нижнього рівня моделі системи. Хоча деякі з таких акторів можуть бути акторами верхнього рівня, це не суперечить прийнятим у мові UML семантичним правилам побудови діаграм варіантів використання. Більше того, інтерфейси варіантів використання верхнього рівня можуть повністю збігатися по своїй структурі з відповідними інтерфейсами варіантів нижнього рівня.
Оточення варіантів використання нижнього рівня є самостійним елементом моделі, що у свою чергу містить інші елементи моделі, певні для цих варіантів використання. Таким чином, з погляду загального подання верхнього рівня взаємодія між варіантами використання нижнього рівня визначає результат виконання сервісу варіанта верхнього рівня. Звідси треба, що в мові UML варіант використання є елементом-контейнером.
Варіанти використання класів відповідають операціям цього класу, оскільки сервіс класу є по суті виконанням операцій даного класу. Деякі варіанти використання можуть відповідати застосуванню тільки однієї операції, у той час як інші - кінцевої безлічі операцій, певних у вигляді послідовності операцій. У той же час одна операція може бути необхідна для виконання декількох сервісів класу й тому буде з'являтися в декількох варіантах використання цього класу.
Реалізація варіанта використання залежить від типу елемента моделі, у якому він визначений. Наприклад, оскільки варіанти використання класу визначаються за допомогою операцій цього класу, вони реалізуються відповідними методами. З іншого боку, варіанти використання підсистеми реалізуються елементами, з яких складається дана підсистема. Оскільки підсистема не має свого власного поводження, всі пропоновані підсистемою сервіси повинні являти собою композицію сервісів, пропонованих окремими елементами цієї підсистеми, тобто, в остаточному підсумку, класами. Ці елементи можуть взаємодіяти один з одним для спільного забезпечення необхідного поводження окремого варіанта використання. Таке спільне забезпечення необхідного поводження описується спеціальним елементом мови UML - кооперація або співробітництво, що буде розглянутий далі, присвяченої побудові діаграм кооперації. Тут лише відзначимо, що кооперації використовуються як для уточнення специфікацій у вигляді варіантів використання нижніх рівнів діаграми, так і для опису особливостей їхньої наступної реалізації.
Якщо в якості моделюємої сутності виступає система або підсистема самого верхнього рівня, то окремі користувачі варіантів використання цієї системи моделюються акторами. Такі актори, будучи внутрішніми стосовно моделюємих підсистем нижніх рівнів, часто в явному виді не вказуються, хоча й присутні неявно в моделі підсистеми. Замість цього варіанти використання безпосередньо звертаються до тих модельним елементам, які містять у собі подібні неявні актори, тобто екземпляри яких грають ролі таких акторів при взаємодії з варіантами використання. Ці модельні елементи можуть утримуватися в інших пакетах або підсистемах. В останньому випадку ролі визначаються в тім пакеті, до якого ставиться відповідна підсистема.
Із системно-аналітичної точки зору побудова діаграми варіантів використання специфікує не тільки функціональні вимоги до проектованої системи, але й виконує вихідну структуризацію предметної області. Останнє завдання сполучити у собі не тільки проходження технічним рекомендаціям, але і є до певної міри мистецтвом, умінням виділяти головне в моделі системи. Хоча раціональний уніфікований процес не виключає ітеративне повернення надалі до діаграми варіантів використання для її модифікації, не викликає сумнівів той факт, що будь-яка подібна модифікація зажадає, як по ланцюжку, змін у всіх інших поданнях системи. Тому завжди необхідно прагнути до можливо більше точного подання моделі саме у формі діаграми варіантів використання.
Якщо ж варіанти використання застосовуються для специфікації частини системи, то вони будуть еквівалентні відповідним варіантам використання в моделі підсистеми для частини відповідного пакета. Важливо розуміти, що всі сервіси системи повинні бути явно визначені на діаграмі варіантів використання, і ніяких інших сервісів, які відсутні на даній діаграмі, проектована система не може виконувати по визначенню. Більше того, якщо для моделювання реалізації системи використовуються відразу кілька моделей (наприклад, модель аналізу й модель проектування), та безліч варіантів використання всіх пакетів системи повинне бути еквівалентно безлічі варіантів використання моделі в цілому.
Лекція №7
Тема: Статичні діаграми. Об’єктно – орієнтовне конструювання програмного забезпечення, діаграми класів та об’єктів.
Мета: Навчитися створювати діаграми класів, виконувати об’єктно-орієнтовне проектування програмних продуктів.
Перелік питань, що розглядаються на лекції:
1. Призначення діаграми класів
2. Структурна сутність клас
3. Семантика сутності
4. Атрибути та синтаксис їх запису
5. Методи та синтаксис їх запису
