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

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

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

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

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

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

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

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

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

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

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

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

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

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

Висновки

Контрольні питання

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

2. Актори.

3. Інтерфейси.

4. Примітки в мові UML

5. Відношення на діаграмі варіантів використання.

6. Відношення асоціації.

7. Відношення розширення.

8. Відношення узагальнення.

9. Відношення включення.

10. Наведіть приклад побудови діаграми варіантів використання.

РОЗДІЛ 19. Діаграма класів (class diagram)

• Клас

• Відношення між класами

• Інтерфейси

• Об'єкти

• Шаблони або параметризовані класи

• Рекомендації з побудови діаграм класів

Центральне місце в ООАП займає розроблення логічної моделі системи у вигляді діаграми класів. Нотація класів в мові UML проста і інтуїтивно зрозуміла всім, хто коли-небудь мав досвід роботи з CASE-інструментами. Схожа нотація застосовується й для об'єктів – екземплярів класу, з тією відмінністю, що до імені класу додається ім'я об'єкту й весь напис підкреслюється.

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

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

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

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

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