5.2. Стосунки між класами

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

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

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

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

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

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

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

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

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

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

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

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

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

• "access" - служить для позначення доступності відкритих атрибутів і операцій класу-джерела для класів-клієнтів;

• "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). Семантика даної асоціації указує на той факт, що з декількох потенційно можливих варіантів даної асоціації в кожен момент часу може використовуватися тільки один її екземпляр. На діаграмі класів асоціація, що виключає, зображається пунктирною лінією, що сполучає дві і більш за асоціацію, поряд з якою записується рядок-обмеження "{Xor}".

Наприклад, рахунок у банці може бути відкритий для клієнта, як який може виступати фізична особа (індивідуум) або компанія, що зображається за допомогою асоціації, що виключає (мал. 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. Можна припустити, що в недалекому майбутньому довідкове керівництво по відповідних середовищах програмування міститиме саме такі діаграми класів, а можливо, і деякі інші.