9.3. Зв'язки

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

Зв'язки не мають власних імен, оскільки повністю ідентичні як екземпляри асоціації. Іншими словами, всі зв'язки на діаграмі кооперації можуть бути тільки анонімними і записуються без двокрапки перед‑ ім'ям асоціації. Для зв'язків не указується також і кратність. Проте інші позначення спеціальних випадків асоціації (агрегація, композиція) можуть бути присутні на окремих кінцях зв'язків. Наприклад, символ зв'язку типу «композиція» між мультиобъектом «Принтер» і окремим об'єктом «Принтер» (див. мал. 9.7).

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

Зв'язок може мати деякі стереотипи, які записуються поряд з одним з її кінців і указують на особливість реалізації даного зв'язку. В язиці UML для цієї мети можуть використовуватися наступні стереотипи:

«association»  – асоціація (передбачається за умовчанням, тому цей стереотип можна не указувати).

«parameter»  – параметр методу. Відповідний об'єкт може бытьчтолько параметром деякого методу.

«local»  – локальна змінна методу. Її область видимості обмежена тільки сусіднім об'єктом.

«global»  – глобальна змінна. Її область видимості розповсюджується на всю діаграму кооперації.

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

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

Мал. 9.9. Графічне зображення зв'язків з різними стереотипами

Примітка

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

9.4. Повідомлення

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

Мал. 9.10. Графічне зображення різних типів повідомлень на діаграмі кооперації

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

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

2.  Суцільна лінія з V‑ образной стрілкою (мал. 9.10, би) позначає простий потік управління. Кожна така стрілка зображає один етап в послідовності потоку управління. Звичайно всі такі повідомлення є асинхронними.

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

4.  Пунктирна лінія з V‑ образной стрілкою (мал. 9.10, г) позначає повернення з виклику процедури. Стрілки цього типу часто відсутні на діаграмах кооперації, оскільки неявно передбачається їх існування після закінчення процесу активізації деякої діяльності.

Формат запису повідомлень

Кожне повідомлення може бути помічено рядком тексту, який має наступний формат:

‹Попередні сообщения‑ ‹[Сторожова умова]‑

‹Вираз последовательности‑

‹Значение– ім'я сообщения‑ , що повертається ‹Список аргументов‑

Розглянемо кожний з цих елементів більш детально.

Попередні повідомлення – є розділені комами номери повідомлень, записані перед похилою рискою:

‹Номер повідомлення,'‑ ‹Номер повідомлення, ‑ /

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

Примітка

Помітимо, що самі номери послідовності повідомлень з однаковим префіксом утворюють відношення впорядкованості і, відповідно, неявно указують на попередні повідомлення. Таким попереднім повідомленням буде повідомлення з номером, найправіша цифра якого на одиницю менше ніж у даного повідомлення. Наприклад, повідомлення з номером «3.1.4.6» має як передування повідомлення з номером «3.1.4.5».

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

Приклад запису попередніх повідомлень:

A3, В4/ С5: помилка запису (сектор).

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

Приклад запису сторожових умов без номерів попередніх повідомлень:

[(х‑ =0) (х‹=255)] 1.2: отобразить_на_экране_цвет(х)

[кількість цифр номера = 7] 3.1: набрать_телефонный_номер()

Вираз послідовності – є розділений крапками список окремих термів послідовностей, після якого записується двокрапка:

‹Терм последовательности'. ‑ ‹Терм последовательности'. ‑ ':

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

[Ціле число| Ім'я] [Символ рекуррентности].

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

Наприклад, повідомлення з номером «3.1.4» слідує за повідомленням з номером «3.1.3» в процедурній послідовності «3.1».

Ім'я використовується для специфікації паралельних ниток управління. Повідомлення, які відрізняються тільки ім'ям, є паралельними на цьому рівні вкладеності. На одному рівні вкладеності всі нитки управління еквівалентні в значенні пріоритету передачі повідомлень. З

Наприклад, повідомлення з виразами «Зла» і «3.16» є паралельними в процедурній послідовності «3.1».

Символ рекуррентности використовується для вказівки умовного або ітеративного виконання. Семантика рекуррентности представляє нуль або більше повідомлень, які повинні бути виконані залежно від записаної умови. Можливі два випадки запису рекуррентности:

1. *' [' Пропозиція‑ ітерація ]' для запису ітеративного виконання відповідного виразу.

Ітерація представляє послідовність повідомлень одного рівня вкладеності. Пропозиція‑ ітерація може бути опущене, якщо умови ітерації ніяк не специфікуються. Найбільш часто пропозиція‑ ітерація записується на деякому псевдокоді або язиці програмування. В язиці UML формат запису цієї пропозиції не визначений. Наприклад, «*[/:=/.л]», що означає послідовну передачу повідомлення з параметром /, який змінюється від 1 до деякого цілого числа п з кроком 1.

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

Примітка

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

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

Наприклад, повідомлення

1.2.3: р:= найти_документ (спецификация_документа)

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

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

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

Так, в приведеному вище прикладі повідомлення

1.2.3: р:= найти_документ (спецификация_документа)

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

Примітка

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

9.5. Приклад побудови діаграми кооперації

Як приклад розглянемо побудову діаграми кооперації для моделювання процесу телефонної розмови з використанням звичайної телефонної мережі (див. главу ф. Нагадаємо, що об'єктами в даному прикладі є два абоненти а і Ь, два телефонні апарати з і ‹/, комутатор і сама розмова як об'єкт моделювання. При цьому як комутатор, так і розмова є анонімними об'єктами.

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

Мал. 9.11. Початковий фрагмент діаграми кооперації для прикладу моделювання звичайної телефонної розмови

В подальшому необхідно специфікувати всі зв'язки на цій діаграмі, вказавши на їх кінцях необхідну інформацію у формі ролей зв'язків. Доповнений таким чином варіант діаграми кооперації зображений нижче (мал. 9.12). Помітимо, що для об'єкту «Розмову» вказано помічене значення {transient}, яке означає, що цей об'єкт створюється в процесі виконання охоплюючого процесу і знищується до його завершення. Нагадаємо, що помічені значення (tagged values) є стандартними елементами язика UML.

Мал. 9.12. фрагмент діаграми кооперації, доповнений стереотипами ролей зв'язків, іменами асоціацій і поміченим значенням об'єкту

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

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

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

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