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

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

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

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

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

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

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

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

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

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

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

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

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

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

РОЗДІЛ 5

Діаграма класів (class diagram)

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

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

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

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

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

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