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

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

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

Побудова діаграми варіантів використання є найпершим етапом процесу об'єктно-орієнтованого аналізу і проектування, мета якого – представити сукупність вимог до поведінки проектованої системи. Специфікація вимог до проектованої системи у формі діаграми варіантів використання є самостійною моделлю, яка в мові UML отримала назву моделі варіантів використання і має своє спеціальне стандартне ім'я або стереотип "useCaseModel".

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

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.

19.1. Клас

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

Рис. 19.1. Графічне зображення класу на діаграмі класів

Обов'язковим елементом позначення класу є його ім'я. На початкових етапах розроблення діаграми окремі класи можуть позначатися простим прямокутником з вказівкою тільки імені відповідного класу (рис. 19.1, а). У міру опрацьовування окремих компонентів, діаграми опису класів доповнюються атрибутами (рис. 19.1, б) і операціями (рис. 19.1, в).

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

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

Рис.19.2. Приклади графічного зображення класів на діаграмі

19.1.1. Ім'я класу

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

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

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

Клас може не мати екземплярів або об'єктів. У цьому випадку він називається абстрактним класом, а для позначення його імені використовується похилий шрифт (курсив). У мові UML прийнята загальна згода про те, що будь-який текст, що відноситься до абстрактного елементу, записується курсивом. Дана обставина є семантичним аспектом опису відповідних елементів мови UML.

Поиск по сайту: