9.6. Заключні рекомендації по побудові діаграм кооперації

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

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

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

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

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

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

РОЗДІЛ 10

Діаграма компонентів (component diagram)

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

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

Щоб пояснити відмінність логічного і фізичного уявлень, розглянемо у загальних рисах процес розробки деякої програмної системи. Її початковим логічним уявленням можуть служити структурні схеми алгоритмів і процедур, описи інтерфейсів і концептуальні схеми баз даних. Проте для реалізації цієї системи необхідно розробити початковий текст програми на деякому язиці програмування (C++, Pascal, Basic/VBA, Java). При цьому вже в тексті програми передбачається така організація програмного коду, яка припускає його розбиття на окремі модулі.

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

Таким чином, повний проект програмної системи є сукупністю моделей логічного і фізичного уявлень, які повинні бути злагоджені між собою. В язиці UML для фізичного представлення моделей систем використовуються так звані діаграми реалізації (implementation diagrams), які включають дві окремі канонічні діаграми: діаграму компонентів і діаграму розгортання. Особливості побудови першої з них розглядаються в цьому розділі, а другий – в наступній.

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

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

Візуалізація загальної структури початкового коду програмної системи.

Специфікації здійснимого варіанту програмної системи.

Забезпечення багатократного використовування окремих фрагментів програмного коду.

Представлення концептуальної і фізичної схем баз даних.

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

Примітка

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