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. Графічне зображення компоненту рівня екземпляра, що реалізовує окремі об'єкти

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

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