Особливості зображення діаграм мови UML

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

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

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

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

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

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

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

Діаграма кооперації

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

· показати набір взаємодіючих об'єктів у реальному оточенні "з висоти пташиного польоту";

· Розподілити функціональність між класами, ґрунтуючись на результатах вивчення динамічних аспектів системи;

· Описати логіку виконання складних операцій, особливо у випадках, коли один об'єкт взаємодіє ще з кількома об'єктами;

· Вивчити ролі, які виконуються об'єктами всередині системи, а також відносини між об'єктами, в які вони залучаються, виконуючи ці ролі.

Говорячи про діаграми кооперації, часто згадують два "рівні" таких діаграм:

· рівень екземплярів(Прикладів, Instance-Level): відображає взаємодії між об'єктами (примірниками класів); така діаграмазазвичай створюється, щоб досліджувати внутрішній пристрійоб'єктно-орієнтованої системи.

· рівень специфікації(Specification-Level): використовується вивчення ролей, виконуваних у системі основними класами.

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

Діаграма компонентів

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

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

Основний тип сутностей на діаграмі компонентів – це компоненти 1, а також інтерфейси 2, за допомогою яких вказується взаємозв'язок між компонентами. На діаграмі компонентів використовуються такі відносини:

· Реалізація між компонентами та інтерфейсами (компонент реалізує інтерфейс);

· залежності між компонентами та інтерфейсами (компонент використовує інтерфейс) 3.

Діаграма розгортання

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

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

При розробці діаграми розгортання переслідують такі цілі:

· Визначити розподіл компонентів системи за її фізичними вузлами;

· показати фізичні зв'язкиміж усіма вузлами реалізації системи на етапі виконання;

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

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

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

При розробці діаграм компонентів переслідуються цілі:

Специфікація загальної структури вихідного кодусистеми;

Специфікація можливого варіанта системи.

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

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

Рис. 15.2. Приклади компонентів

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

Компоненти можуть мати такі стандартні стереотипи:

- "file" - будь-який файл, крім таблиці:

o «executable» - програма (виконуваний файл);

o «library» – статична чи динамічна бібліотека;

o "source" - файл з вихідним текстом програми;

o "document" - інші файли (наприклад, файл довідки);

- "table" - таблиця бази даних.

Всередині компонента, як і класу, може бути виділено додаткові секції, в яких вказуються надані (provided) або необхідні для роботи (required) інтерфейси та класи, методи (operations), найменування файлу-компонента (artifacts) тощо.

Рис. 15.3. Компонент із секціями

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

Рис. 15.4. Способи відображення інтерфейсів

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

У методах класів одного компонента (залежного) здійснюється виклик методів чи звернення до атрибутів класів іншого компонента (незалежного);

Компонент складається з інших компонентів (наприклад, при складанні файлу, що виконується, з файлів з вихідними кодами);

Компонент здійснює читання чи запис даних на інший компонент;

Зв'язок між таблицями БД;

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

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

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

Рис. 15.5. Фрагмент діаграми компонентів, що специфікує структуру вихідного коду

Діаграма на мал. 15.5 показує склад класів (файлів), з яких складається компонент iskraPUT.jar, що виконується, а також залежності між класами.

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

Рис. 15.6. Приклад діаграми компонентів специфікує склад компонентів на робочому місці користувача

4. На діаграмі можуть бути представлені відносини залежності між компонентами та включеними до них класами. Ця інформація має важливе значення для забезпечення узгодженості між логічним та фізичним уявленням системи. І тут залежність можна показати двома способами:

Класи показати окремо від компонента та зв'язати компонент з кожним класом відношенням залежності. Наприклад, на рис. 15.5 замість компонентів з розширенням java показати відповідні їм класи;

Класи відобразити всередині компонент компонент.

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

Показати розбиття програмної системи на структурні компоненти та зв'язки (залежності) між компонентами.

Як фізичні компоненти можуть виступати файли, бібліотеки, модулі, виконувані файли, пакети і т.п.

План дій

Після ознайомлення з розділами («Приклад», «Застосування»), ви можете спробувати свої сили в самостійному складанні діаграм компонентів.

Як застосовувати метод проектування

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

Приклад використання

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

У UML 1 був окремий символ компонента (рис. 14.1). В UML 2цього значка немає, але можна позначити прямокутник класу схожим значком. Або можна скористатися ключовим словом « component» ( компонент).

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

На рис. 14.2 показаний приклад простий діаграми компонентів. У цьому прикладі компонент Till (Каса)може взаємодіяти з компонентом Sales Server (Сервер продажів)за допомогою інтерфейсу sales message (Повідомлення про продаж).Оскільки мережа ненадійна, то компонент Message Queue (Черга повідомлень)встановлений так, щоб каса могла спілкуватися з сервером, коли мережа працює, і розмовляти з чергою повідомлень, коли мережу вимкнено. Тоді черга повідомлень зможе поговорити із сервером, коли мережа знову стане доступною. В результаті черга повідомлень надає інтерфейс для розмови з касою, і вимагає такий самий інтерфейс для розмови з сервером. Сервер розділений на два основні компоненти: Transaction Processor (Процесор транзакцій) реалізує інтерфейс повідомлень, а Accounting Driver (Драйвер рахунків)спілкується з Accounting System (Система ведення рахунків).

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

Компоненти – це технологія. Технічні фахівці вважають їх важкими розуміння. Компоненти – це скоріше стиль ставлення клієнтів до програмного забезпечення. Вони хочуть мати можливість купувати необхідне програмне забезпечення частинами, а також мати можливість оновлювати його, як вони оновлюють свою стереосистему. Вони хочуть, щоб нові компоненти працювали так само, як і колишні, і оновлювати їх згідно своїх планів, а не за вказівкою виробників. Вони хочуть, щоб системи різних виробниківмогли працювати разом і були взаємозамінними. Це дуже розумні вимоги. Одна проблема: їх важко виконати.
Ральф Джонсон (Ralph Johnson), http://www.c2.com/cgi/wiki?DoComponentsExist

Важливо те, що компоненти є елементами, які можна незалежно один від одного купити і оновити. Через війну поділ системи на компоненти є більшою мірою маркетинговим рішенням, ніж технічним. Прекрасний посібник з цього питання представляє книга Хохмана. Вона також нагадує, що слід остерігатися поділу системи на занадто дрібні компоненти, оскільки дуже великою кількістюкомпонентів важко управляти, особливо коли виробництво версій піднімає свою потворну голову; звідси пішов вираз "пекло DLL" або "dll hell". У ранніх версіях мови компоненти UML застосовувалися для представлення фізичних структур, таких як DLL. Тепер це не є актуальним; в даний час це завдання вирішується за допомогою артефактів(artifacts).

Підписуйтесь на новини сайту, форму підписки ви можете знайти у правій колонці сайту.

Якщо ви бажаєте навчитися працювати на фрілансі професійно, запрошуємо на курс «».

Діаграма компонентів, на відміну раніше розглянутих діаграм, визначає особливості фізичного уявлення системи. Діаграма компонентів, Component diagram - статична структурна діаграма, що показує розбиття програмної системи на структурні компоненти та зв'язки (залежності) між компонентами.

Таким чином ілюструються відносини клієнт-джерело між двома компонентами. Після ознайомлення з розділами («Приклад», «Застосування»), ви можете спробувати свої сили в самостійному складанні діаграм компонентів. У объектно-ориентированном співтоваристві точаться дебати у тому, у чому полягає різницю між компонентом і звичайним класом. У UML 1 був окремий символ компонента (рис. 14.1). У UML 2 цієї значки немає, але можна позначити прямокутник класу схожим значком.

У цьому прикладі компонент Till (Каса) може взаємодіяти з компонентом Sales Server (Сервер продаж) за допомогою інтерфейсу sales message (Повідомлення про продаж). Питання сутності компонента є предметом нескінченних суперечок. Компоненти – це технологія. Компоненти – це скоріше стиль ставлення клієнтів до програмного забезпечення. Вони хочуть, щоб нові компоненти працювали так само, як і колишні, і оновлювати їх згідно своїх планів, а не за вказівкою виробників.

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

Діаграма класів служить уявлення статичної структури моделі системи у термінології класів объектно-ориентированного програмування. З цього погляду діаграма класів є подальшим розвитком концептуальної моделі проектованої системи. Для моделювання взаємодії об'єктів у мові UML використовуються відповідні діаграми взаємодії.

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

Ця діаграма, по суті, завершує процес ООП для конкретної програмної системи та її розробка, як правило, є останнім етапом специфікації моделі. І сприяють цьому кілька спеціальних технік (Scrum of scrums, компонентні команди, участь архітектора у ролі Product owner'а). Це і є розвиток реальної системи.

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

3.4.3. Застосування діаграм компонентів та розміщення

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

Діаграма компонентів та особливості її побудови

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

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

У розробці діаграм компонентів беруть участь як системні аналітики та архітектори, і програмісти. UML компоненти та стереотипи. Діаграма розгортання призначена для візуалізації елементів та компонентів програми, що існують лише на етапі її виконання (runtime). Також можна розбивати компоненти на частини за допомогою діаграм складових структур. Цей розділприсвячений відразу двом діаграмам: компонентів та розміщення, для яких можна використовувати узагальнюючу назву – діаграми реалізації.

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

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

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

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

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

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

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

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

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

10.1. Компоненти

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

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

Рис. 10.1.Графічне зображення компонента у мові UML

Так, у першому випадку (рис. 10.1, а) з компонентом рівня екземпляра пов'язується лише його ім'я, а в другому (рис. 10.1, б) – додатково ім'я пакета та позначене значення.

Ім'я компонента

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

Якщо ж компонент представляється на рівні екземпляра, то як його ім'я записується<имя компонента ":" имя типаХ При этом вся строка имени подчеркивается.

В якості простих імен прийнято використовувати імена файлів, що виконуються (із зазначенням розширення ехе після точки-розділювача), імена динамічних бібліотек (розширення dll), імена Web-сторінок (розширення html), імена текстових файлів (розширення txt або doc) або файлів довідки ( hip), імена файлів баз даних (DB) або імена файлів із вихідними текстами програм (розширення h, cpp для мови C++, розширення Java для мови Java), скрипти (pi, asp) та ін.

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

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

Види компонентів

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

У мові UML виділяють три види компонентів.

По-перше, компоненти розгортання, які забезпечують безпосереднє виконання системою своїх функцій. Такими компонентами можуть бути бібліотеки з розширенням dll, що динамічно підключаються (рис. 10.2, а), Web-сторінки на мові розмітки гіпертексту з розширенням html (рис. 10.2, б) і файли довідки з розширенням Ыр (рис. 10.2, в).
По-друге, компоненти – робочі продукти. Зазвичай – це файли з вихідними текстами програм, наприклад, з розширеннями h або срр мови C++ (рис. 10.2, г).
По-третє, компоненти виконання, що представляють модулі - файли з розширенням ехе. Вони позначаються звичайним чином.

Рис. 10.2.Варіанти графічного зображення компонентів на діаграмі компонентів

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

Інший спосіб специфікації різних видів компонентів – очевидна вказівка стереотипу компонента перед його ім'ям. У мові UML для компонентів визначено такі стереотипи:

Бібліотека (library) – визначає перший різновид компонента, який представляється у формі динамічної чи статичної бібліотеки.
Таблиця (table) - також визначає перший різновид компонента, який представляється у формі таблиці бази даних.
Файл (file) – визначає другий різновид компонента, який представляється як файлів з вихідними текстами програм.
Документ (document) – визначає другий різновид компонента, . який представляється у вигляді документа.
Здійсненний (executable) - визначає третій вид компонента, який може виконуватися у вузлі.

10.2. Інтерфейси

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

Рис. 10.3.Графічне зображення інтерфейсів на діаграмі компонентів

Іншим способом представлення інтерфейсу на діаграмі компонентів є його зображення у вигляді прямокутника класу зі стереотипом «інтерфейс» та можливими секціями атрибутів та операцій (рис. 10.3 б). Як правило, цей варіант позначення використовується для представлення внутрішньої структури інтерфейсу, яка може бути важливою для реалізації.

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

10.3. Залежності

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

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

У першому випадку малюють стрілку від компонента-клієнта до інтерфейсу, що імпортується (рис. 10.4). Наявність такої стрілки означає, що компонент не реалізує відповідний інтерфейс, а використовує його у процесі виконання. Причому на цій діаграмі може бути присутнім і інший компонент, який реалізує цей інтерфейс. Так, наприклад, зображений нижче фрагмент діаграми компонентів представляє інформацію про те, що компонент з ім'ям «main.exe» залежить від інтерфейсу I Dialog, що імпортується, який, у свою чергу, реалізується компонентом з ім'ям «image.java». Для другого компонента цей інтерфейс є експортованим.

Рис. 10.4.Фрагмент діаграми компонентів із відношенням залежності

Зауважимо, що зобразити другий компонент з ім'ям «image.java» у формі варіанта примітки не можна саме через той факт, що цей компонент реалізує інтерфейс.

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

Рис. 10.5.Графічне зображення відносини залежності між компонентами

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

Рис. 10.6.Графічне зображення залежності між компонентом та класами

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

Рис. 10.7.Графічне зображення компонента з додатковою інформацією про реалізовані ним класи

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

Рис. 10.8.Графічне зображення компонента рівня екземпляра, що реалізує окремі об'єкти

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

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

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

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

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

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

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

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

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

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

Примітки:

Примітка 7

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

Примітка 72

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

Примітка 73

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

Примітка 74

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

Примітка 75

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