Приклад побудови діаграми кооперації
Приклад. Розглянемо побудову діаграми кооперації для моделювання процесу телефонної розмови з використанням звичайної телефонної мережі (див. главу 8). Об'єктами в даному прикладі є два абоненти а і b, два телефонні апарати c і d, комутатор і сама розмова як об'єкт моделювання. При цьому комутатор і розмова є анонімними об'єктами.
На початковому етапі зобразимо всі об'єкти і зв'язки між ними на діаграмі кооперації (мал. 9.11). Перший телефонний апарат зображений активним об'єктом, а другий - пасивним.
Мал. 9.11. Початковий фрагмент діаграми кооперації для прикладу моделювання звичайної телефонної розмови.
Далі необхідно специфікувати всі зв'язки на цій діаграмі, вказавши на їх кінцях необхідну інформацію у формі ролей зв'язків. Доповнений варіант діаграми кооперації зображений на (мал. 9.12). Відмітимо, що для об'єкту "Розмова" вказано помічене значення {transient}, яке означає, що цей об'єкт створюється в процесі виконання охоплюючого процесу і знищується до його завершення. Нагадаємо, що помічені значення (tagged values) є стандартними елементами мови UML.
Мал. 9.12. фрагмент діаграми кооперації, доповнений стереотипами ролей зв'язків, іменами асоціацій і поміченим значенням об'єкту
Мал. 9.13. Остаточний варіант діаграми кооперації для моделювання телефонної розмови
Нарешті, на діаграму кооперації необхідно нанести всі повідомлення, вказавши їх порядок і семантичні особливості. Остаточний фрагмент діаграми кооперації зображений на мал. 9.13 і містить, строго кажучи, модель кооперації лише для початку розмови. Ця діаграма може бути доповнена повідомленнями, необхідними для закінчення розмови{, що читачам пропонується виконати самостійно як вправу}.
Діаграма кооперації для прикладу з телефонною розмовою не містить ні часових особливостей передачі повідомлень, ні особливостей життєвого циклу об'єктів, що беруть участь в даній кооперації. Тому може бути прийняте рішення про те, що вона є надлишковій за наявності побудованої діаграми послідовності. Цей факт не викликає сумнівів в тих випадках, коли структура взаємодіючих об'єктів є досить тривіальною.
Якщо ж взаємодіючі об'єкти утворюють між собою різні типи відношень-асоціацій (композиція, агрегація), то діаграма кооперації є необхідним представленням моделі на всіх її рівнях.
Завершальні рекомендації по побудові діаграм кооперації
Побудову діаграми кооперації можна починати відразу після побудови діаграми варіантів використання. В цьому випадку кожен з варіантів використання може бути специфікований у вигляді окремої діаграми кооперації рівня специфікації. Ця діаграма сприяє більш повному розумінню особливостей реалізації функцій системою, хоча і не може містити всю інформацію, необхідну для їх реалізації.
Після побудови діаграми класів, кожна з діаграм кооперації може уточнюватися у вигляді відповідної діаграми рівня прикладів. Діаграма кооперації цього рівня може містити ті і лише ті об'єкти і зв'язки, які вже визначені на побудованій раніше діаграмі класів. Інакше, якщо виникає необхідність включення в діаграму кооперації об'єктів, які створюються на основі відсутніх класів, відповідні діаграми класів мають бути модифіковані явним описом цих класів.
На діаграмі кооперації зображаються лише ті об'єкти, які безпосередньо в ній беруть участь. При цьому об'єкти можуть виступати в різних ролях, які мають бути явно вказані на відповідних кінцях зв'язків діаграми. Вживання стереотипів уніфікує кооперацію, забезпечуючи її адекватну інтерпретацію з боку замовників і з боку розробників. Доцільно розрізняти термінологію, яка використовується на діаграмах кооперації рівня специфікації і рівня прикладів.
При побудові діаграм кооперації рівня специфікації бажано застосовувати найбільш зрозумілу замовникові термінологію, уникаючи технічних фраз. Наприклад, "оформити замовлення", "відвантажити товар", "представити звіт", "розробити план" і т. д. Такі відомі розробникам слова як "сервер", "захищений протокол", "закрита операція класу", а також стереотипи і помічені значення на цьому рівні застосовувати не рекомендується. На рівні специфікації потрібно прагнути досягти по можливості повного взаєморозуміння між замовником і командою розробників всіх варіантів використання проектованої системи в контексті їх кооперації.
При побудові діаграм кооперації рівня прикладів термінологія повинна найточніше відображати всі аспекти реалізації відповідних об'єктів і зв'язків. Оскільки діаграма цього рівня є документацією для розробників системи, тут допустимо використовувати весь арсенал стереотипів, обмежень і помічених значень, який є в мові UML. Якщо типових позначень недостатньо, розробники можуть доповнити діаграму власними елементами, використовуючи механізм розширень мови UML.
Процес побудови діаграми кооперації рівня прикладів має бути погоджений з процесами побудови діаграми класів і діаграми послідовності. У першому випадку, як вже наголошувалося, необхідно стежити за використанням лише тих об'єктів, для яких визначені класи, що породжують їх. У другому випадку потрібно погоджувати послідовності передаваних повідомлень. Не допускається різний порядок отримання повідомлень для моделювання однієї і тієї ж взаємодії на діаграмі кооперації і діаграмі послідовності. Таким чином, діаграма кооперації, з одного боку, забезпечує концептуально погоджений перехід від статичної моделі діаграми класів до динамічних моделей поведінки, що представляються діаграмами послідовності, станів і діяльності.