PrIS

471

"call" (викликати) – повідомлення, що викликає операції або процедури об'єкту, який приймає; якщо повідомлення із цим стереотипом рефлексивне, то воно ініціює локальний виклик операції в самого об'єкту, що послав це повідомлення;

"return" (повернути) – повідомлення, що повертає значення виконаної операції або процедури об'єкту, якщо її викликав; значення результату може ініціювати розгалуження потоку керування;

"create" (створити) – повідомлення, що вимагає створення іншого об'єкту для виконання певних дій; створений об'єкт може одержати фокус керування, а може й не одержати його;

"destroy" (знищити) – повідомлення з явною вимогою знищити відповідний об'єкт; посилається в тому випадку, коли необхідно припинити небажані дії з боку наявного в системі об'єкту, або коли об'єкт більше не потрібний і повинен звільнити задіяні ним системні ресурси;

"send" (послати) – позначає посилання іншому об'єкту деякого сигналу, що асинхронно ініціюється одним об'єктом і приймається (перехоплюється) іншим; відмінність сиґналу від повідомлення полягає в тому, що сиґнал має бути явно описаний у тому класі, об'єкт якого ініціює його передавання.

На рис. 22.7 зображена діаграма послідовності для розглянутого раніше випадку розгалуження, доповнена стереотипними значеннями.

Крім стереотипів, повідомлення можуть мати власне позначення операції, викликання якої вони ініціюють у об'єкту, який приймає. У цьому випадку поруч зі стрілкою записується ім'я операції із круглими дужками, у яких можуть вказуватися параметри або арґументи відповідної операції. Якщо параметри відсутні, то дужки все одно мають бути присутніми після імені операції. Прикладами таких операцій можуть служити такі операції: "видати клієнтові суму (n)", "встановити з'єднання між абонентами (а, b)", "зробити введення тексту невидимим ()", "подати звуковий сигнал тривоги ()".

472

Рис. 22.7. Діаграма послідовності зі стереотипними значеннями повідомлень.

Примітка

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

22.2.3. Тимчасові обмеження на діаграмах послідовності

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

473

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

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

{час_прийомання_повідомлення – час_відсилання_повідомлення < 1 сек.}

{час_очікування_відповіді < 5 сек.}

{час_передавання_пакету < 10 сек.}

{об'єкт_1. час_подання_сигналу_тривоги > 30 сек.}

Примітка

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

22.2.4. Коментарі або примітки

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

22.3. Приклад побудови діаграми послідовності

Як приклад розглянемо побудову діаграми послідовності для моделювання процесу телефонної розмови з використанням звичайної телефонної мережі. Об'єктами в цьому прикладі є: два абоненти a і b, два телефонних апарати end, комутатор і сама розмова як об'єкт моделювання. При цьому як комутатор, так і розмова є анонімними об'єктами.

474

На першому етапі розташовуємо обрані об'єкти на діаграмі (рис. 22.8). Зазначимо, що абонентів ми будемо розглядати як акторів, причому перший з них – a – відіграє активну роль, а другий – b – пасивну роль. Тому перший одержує фокус керування відразу після своєї появи в системі, а другий має тільки лінію життя. Комутатор також має постійну активність, що зображається його фокусом керування. Розмова як об'єкт з'являється тільки після встановлення з'єднання і знищується після її припинення. Тому вона буде зображена пізніше на цій діаграмі послідовності.

Рис. 22.8. Початковий фраґмент діаграми послідовності для моделювання телефонної розмови.

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

– набір цифр телефонного номера.

Зазначимо, що підняття слухавки і набір цифр номера є фізичними діями і тому зображаються у формі простих асинхронних повідомлень. Після набору цифрового номера телефону апарат с рекурсивно викликає процедуру відсилання комутаційних імпульсів на комутатор. Останній ініціює створення нового об'єкту в модельованій системі – телефонної розмови. Доповнений фраґмент діаграми послідовності зображений на рис. 22.9.

475

Рис. 22.9. Доповнений фраґмент діаграми послідовності для моделювання телефонної розмови.

Після створення анонімний об'єкт "розмова" відразу одержує фокус активності й посилає повідомлення телефонному апарату d на виконання дії – дзвінка виклику. При цьому другий абонент знімає трубку (асинхронне повідомлення), тим самим установлюється пряме з'єднання між абонентами а і b. Після того як абоненти покладуть трубки, розмова закінчується. Тим самим об'єкт "розмова" знищується. Остаточний варіант діаграми послідовності може містити деякі тимчасові обмеження і коментарі (рис. 22.10). Призначення окремих повідомлень відповідають розглянутим діям.

Примітка

Доповнення діаграми послідовності для цього прикладу тимчасовими обмеженнями пропонується виконати самостійно.

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

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

476

{Після встановлення з'єднання абоненти a та b можуть розпочати обмін інформацією}

Рис. 22.10. Остаточний варіант діаграми послідовності для моделювання телефонної розмови

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

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

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

477

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

1.Призначення діаграми послідовності.

2.Лінія життя об'єкту.

3.Фокус керування.

4.Повідомлення між об'єктами на діаграмі послідовності.

5.Розгалуження потоку керування.

6.Стереотипи повідомлень.

7.Тимчасові обмеження на діаграмах послідовності.

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

478

РОЗДІЛ 23. Діаграма кооперації (collaboration diagram)

Кооперація

Мультиоб'єкт. Активний об'єкт. Складений об'єкт

Зв'язки. Стереотипи зв'язків

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

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

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

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

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

479

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

23.1. Кооперація

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

Кооперація може бути подана на двох рівнях:

на рівні специфікації – вказує ролі класифікаторів і ролі асоціацій в цій взаємодії;

на рівні прикладів – вказує екземпляри і зв'язки, створюючи окремі ролі в кооперації.

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

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

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

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

480

класів, на якій мають бути вказані всі властивості і асоціації між елементами діаграми.

Діаграма кооперації рівня специфікації

Кооперація на рівні специфікації зображається на діаграмі пунктирним еліпсом, всередині якого записується ім'я цієї кооперації (рис. 23.1). Таке подання кооперації відноситься до окремого варіанту використання і деталізує особливості його подальшої реалізації. Символ еліпса кооперації з'єднується відтинками пунктирної лінії з кожним з учасників цієї кооперації, якими можуть виступати об'єкти або класи. Кожна з цих пунктирних ліній позначається роллю (role) учасника. Ролі відповідають іменам елементів у контексті всієї кооперації. Ці імена трактуються як параметри, які обмежують специфікацію елементів при будь-якій їх появі в окремих поданнях моделі.

Рис. 23.1. Загальне зображення кооперації на діаграмах рівня специфікації .

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

Рядок тексту в прямокутнику повинен мати такий формат:

'/' <Ім'я ролі класифікатора> ':' <Ім'я класифікатора> [':' <Ім'я класифікатора >]*

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

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