Особливості зображення діаграм мови 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 немає суворої нотації для графічного представлення приміток.

Інший спосіб специфікації різних видів компонентів - явна вказівка \u200b\u200bстереотипу компонента перед його ім'ям. У мові 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

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