5.2. Відносини між класами

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

Відношення залежності (dependency relationship)

Відношення асоціації (association relationship)

Відношення узагальнення (generalization relationship)

Відношення реалізації (realization relationship)

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

Відношення залежності

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

Відношення залежності графічно зображається пунктирною лінією між відповідними елементами із стрілкою на одному з її кінців («‑ ‑ » або «‹‑ »). На діаграмі класів дане відношення зв'язує окремі класи між собою, при цьому стрілка направлена від класу‑ клієнта залежності до незалежного класу або класу‑ джерела (мал. 5.3). На даному малюнку зображено два класи: Класс_А і Кяасс_Б, при цьому Класс_Б є джерелом деякої залежності, а Класс_А – клієнтом цієї залежності.

Мал. 5.3. Графічне зображення відношення залежності на діаграмі класів

Як клас‑ клієнт і клас‑ джерело залежності може виступати ціла безліч елементів моделі. В цьому випадку одна лінія із стрілкою, що виходить від джерела залежності, розщеплюється в деякій крапці на декілька окремих ліній, кожна з яких має окрему стрілку для класу‑ клієнта. Наприклад, якщо функціонування Класса_С залежить від особливостей реалізації Класса_А і Класса_/‑ , то дана залежність може бути зображена таким чином (мал. 5.4).

Мал. 5.4. Графічне представлення залежності між класом‑ клієнтом (Класс_С) і класами‑ джерелами (Класс_Л і Класс_Б)

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

«асcess»  – служить для позначення доступності відкритих атрибутів і операцій класу‑ джерела для класів‑ клієнтів;

«bind»  – клас‑ клієнт може використовувати деякий шаблон для своєї подальшої параметризації;

«derive»  – атрибути класу‑ клієнта можуть бути обчислені по атрибутах класу‑ джерела;

«import»  – відкриті атрибути і операції класу‑ джерела стають частиною класу‑ клієнта, неначебто вони були оголошені безпосередньо в ньому;

«refine»  – указує, що клас‑ клієнт служить уточненням класу‑ джерела через причини історичного характеру, коли з'являється додаткова інформація в ході роботи над проектом.

Примітка

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

Відношення асоціації

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

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

Як простий приклад відношення бінарної асоціації розглянемо відношення між двома класами – класом «Компанія» і класом «Співробітник» (мал. 5.5). Вони зв'язані між собою бінарною асоціацією Робота, ім'я якої вказано на малюнку поряд з лінією асоціації. Для даного відношення визначений порядок проходження класів, першим з яких є клас «Співробітник», а другим – клас «Компанія». Окремим прикладом або екземпляром даного відношення може бути пара значень (Петров І. І., «Роги Копита»). Це означає, що співробітник Петров І. І. працює в компанії «Рогу Копита».

Мал. 5.5. Графічне зображення відношення бінарної асоціації між класами

Тернарная асоціація і асоціації більш високої арности в загальному випадку називаються N‑ арной асоціацією (читається – «эн арная асоціація»). Така асоціація зв'язує деяким відношенням 3 і більш класів, при цьому один клас може брати участь в асоціації більш ніж один раз. Клас асоціації має певну роль у відповідному відношенні, що може бути явно вказане на діаграмі. Кожний екземпляр N‑ арной асоціації є N‑ арный кортежем значень об'єктів з відповідних класів. Бінарна асоціація є окремим випадком N‑ арной асоціації, коли значення N=2, і має своє власне позначення.

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

Порядок класів в N‑ арной асоціації, на відміну від порядку множин у відношенні, на діаграмі не фіксується. Деякий клас може бути приєднаний до ромба пунктирною лінією. Це означає, що даний клас забезпечує підтримку властивостей відповідної N‑ арной асоціації, а сама N‑ арная асоціація має атрибути, операції и/или асоціації. Іншими словами, така асоціація, у свою чергу, є класом з відповідним позначенням у вигляді прямокутника і є самостійним елементом язика UML – асоціацією‑ класом (Association Class). N‑ арная асоціація не може містити символ агрегації ні для якої з своїх ролей.

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

Як вже згадувалося, окремий клас асоціації має власну роль у відношенні. Ця роль може бути зображена графічно на діаграмі класів. З цією метою в язиці UML вводиться в розгляд спеціальний елемент – кінець асоціації (Association End), який графічно відповідає точці з'єднання лінії асоціації з окремим класом. Кінець асоціації є частиною асоціації, але не класу. Кожна асоціація має два або більше кінців асоціації. Найважливіші властивості асоціації указуються на діаграмі поряд з цими елементами асоціації і повинні перемішатися разом з ними.

Мал. 5.6. Графічне зображення тернарной асоціації між трьома класами

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

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

Так, для розглянутого раніше прикладу (див. мал. 5.5) кратність «1» для класу «Компанія» означає, що кожний співробітник може працювати тільки в одній компанії. Кратність «1.*» для класу «Співробітник» означає, що в кожній компанії можуть працювати декілька співробітників, загальне число яких наперед невідоме і нічим не обмежено. Помітимо, що замість кратності «1.*» записати тільки символ "*" не можна, оскільки останній означає кратність «0.*». Для даного прикладу це означало б, що окремі компанії можуть зовсім не мати співробітників в своєму штаті. Але така кратність цілком прийнятна в інших ситуаціях, як це видно з розглянутого вище прикладу (мал. 5.6).

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

Окремим випадком відношення асоціації є так звана асоціація, що виключає (Xor‑ association). Семантика даної асоціації указує на той факт, що з декількох потенційно можливих варіантів даної асоціації в кожний момент часу може використовуватися тільки один її екземпляр. На діаграмі класів асоціація, що виключає, зображається пунктирною лінією, що сполучає дві і більш асоціації, поряд з якою записується рядок‑ обмеження «{хог}».

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

Мал. 5.7. Графічне зображення асоціації, що виключає, між трьома класами

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

Відношення агрегації

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

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

Примітка

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

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

Як приклад відношення агрегації розглянемо взаємозв'язок типу «часть‑ целое», який має місце між єством «Вантажний автомобіль» і такими компонентами, як «Двигун», «Шасі», «Кабіна», «Кузов». Не претендуючи на точну відповідність термінології даної наочної області, неважко уявити собі, що вантажний автомобіль складається з двигуна, шасі, кабіни і кузова. Саме це відношення між класом «Грузової_автомобіль» і класами «Двигун», «Шасі», «Кабіна», «Кузов» описує відношення агрегації.

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

Мал. 5.8. Графічне зображення відношення агрегації в язиці UML

Ще одним прикладом відношення агрегації може служити відомий кожному з читачів розподіл персонального комп'ютера на складові частини: системний блок, монітор, клавіатуру і мишу. Використовуючи позначення язика UML, компонентний склад ПК можна представити у вигляді відповідної діаграми класів (мал. 5.9), яка в даному випадку ілюструє відношення агрегації.

Мал. 5.9. Діаграма класів для ілюстрації відношення агрегації на прикладі ПК

Відношення композиції

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

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

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

Мал. 5.10. Графічне зображення відношення композиції в язиці UML

Як додаткові позначення для відносин композиції і агрегації можуть використовуватися додаткові позначення, вживані для відношення асоціації. А саме, вказівка кратності класу асоціації і імені даної асоціації, які не є обов'язковими. Стосовно описаного вище прикладу класу «Окно_программи» його діаграма класів може мати наступний вигляд (мал. 5.11).

Мал. 5.11. Діаграма класів для ілюстрації відношення композиції на прикладі класу вікна програми

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

Відношення узагальнення

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

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

Мал. 5.12. Графічне зображення відношення узагальнення в язиці UML

Як правило, на діаграмі може указуватися декілька ліній для одного відношення узагальнення, що відображає його таксономический характер. В цьому випадку більш загальний клас розбивається на підкласи одним відношенням Узагальнення. Наприклад, клас Геометрічеськая_фігура_на_плоськості (курсив позначає абстрактний клас) може виступати як суперклас для підкласів, відповідних конкретним геометричним фігурам, таким як, Прямокутник, Коло, Еліпс і ін. Даний факт може бути представлений графічно у формі діаграми класів наступного вигляду (мал. 5.13).

Мал. 5.13. Приклад графічного зображення відношення узагальнення класів

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

Мал. 5.14. Варіант графічного зображення відношення узагальнення класів для випадку об'єднання окремих ліній

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

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

Як обмеження можуть бути використані наступні ключові слова язика UML:

{complete} – означає, що в даному відношенні узагальнення специфіковані всі класи‑ нащадки, і інших класів‑ нащадків у даного класу‑ предка бути не може. Приклад – клас Клієнт_банка є предком для двох класів: Фізічеськоє_ліцо і Компанія, і інших класів‑ нащадків він не має. На відповідній діаграмі класів це можна вказати явно, записавши поряд з лінією узагальнення даний рядок‑ обмеження;

{disjoint} – означає, що класи‑ нащадки не можуть містити об'єктів, одночасно є екземплярами двох або більш класів. В приведеному вище прикладі ця умова також виконується, оскільки передбачається, що ніяка конкретна фізична особа не може бути одночасно і конкретною компанією. В цьому випадку поряд з лінією узагальнення можна записати даний рядок‑ обмеження;

{incomplete} – означає випадок, протилежний першому. А саме, передбачається, що на діаграмі вказані не всі класи‑ нащадки. В подальшому можливо заповнити їх перелік не змінюючи вже побудовану діаграму. Приклад – діаграма класу «Автомобіль», для якої вказівка всіх без виключення моделей автомобілів сумірно із створенням відповідного каталога. З другого боку, для окремої задачі, такий як розробка системи продажу автомобілів конкретних моделей, в цьому немає необхідності. Але вказати неповноту структури класів‑ нащадків все ж таки слід;

{overlapping} – означає, що окремі екземпляри класів‑ нащадків можуть належати одночасно декільком класам. Приклад – клас «Багатокутник» є класом‑ предком для класу «Прямокутник» і класу «Ромб». Проте існує окремий клас «Квадрат», екземпляри якого одночасно є об'єктами перших двох класів. Цілком природно таку ситуацію вказати явно за допомогою даного рядка‑ обмеження.

З урахуванням можливості використовування рядків‑ обмежень діаграма класів (мал. 5.14) може бути зображена без многоточий і без втрати інформації (мал. 5.15).

Мал. 5.15. Варіант графічного зображення відношення узагальнення класів з використанням рядка‑ обмеження

Щоб проілюструвати особливості використовування відношення узагальнення, перетворюваний один з розглянутих раніше прикладів зображення класів в графічну нотацію язика UML. Як такий приклад розглянемо ієрархію вкладеності класів для абстрактного класу «Автомобіль» (див. мал.  1, 2, 2.7). Як неважко помітити, відношення між окремими класами на цих малюнках є саме відношення узагальнення, яке в язиці UML має спеціальне графічне позначення. З урахуванням цієї графічної нотації, фрагмент семантичної мережі для представлення ієрархії класу «Автомобіль» (див. мал. 2.7) може бути представлений у вигляді наступної діаграми класів (мал. 5.16).

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

Мал. 5.16. Фрагмент діаграми класів з відношенням узагальнення для представлення ієрархії класів «Автомобіль» з розглянутого раніше прикладу (див. мал. 2.7)

Примітка

Як вправа для закріплення розглянутого матеріалу можна спробувати побудувати діаграми класів або хоча б їх фрагменти для бібліотек стандартних класів MFC (Microsoft) і VCL (Borland/Inprise) з використанням графічної нотації язика UML. Можна припустити, що в недалекому майбутньому довідкове керівництво по відповідних середовищах програмування міститиме саме такі діаграми класів, а можливо, і деякі інші.

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

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

Мал. 5.17. Приклад графічного зображення інтерфейсу на діаграмі класів

5.4. Об'єкти

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

Для графічного зображення об'єктів використовується такий же символ прямокутника, що і для класів. Відмінності виявляються при вказівці імен об'єктів, які у разі об'єктів обов'язково підкреслюються (мал. 5.18). При цьому запис імені об'єкту є рядком тексту «ім'я об'єкту: ім'я класу», розділену двокрапкою (мал. 5.18 а, би). Ім'я об'єкту може бути відсутній, в цьому випадку передбачається, що об'єкт є анонімним, і двокрапка указує на дану обставину (мал. 5.18, г). Бути відсутній може і ім'я класу. Тоді указується просто ім'я об'єкту (мал. 5.18, в). Атрибути об'єктів приймають конкретні значення.

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

Мал. 5.18. Приклад графічного зображення об'єктів на діаграмах язика UML