Типи зв’язків UML: асоціація, залежність, узагальнення

Давайте вивчимо їх детально

Типи зв'язків діаграми класів UML

Асоціація

Це набір посилань, що з’єднує елементи моделі UML. Він також визначає, скільки об'єктів бере участь у цьому відношенні.

Залежність

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

Узагальнення

Це також називають стосунками батьків і дітей. При генералізації один елемент є спеціалізацією іншого загального компонента. Його можна замінити. Здебільшого використовується для представлення спадщини.

Реалізація

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

Асоціація

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

• {імпліцитний} – Неявні обмеження вказують на те, що зв’язок не є явним; воно базується на концепції.
• {замовлено} – Упорядковані обмеження визначають, що набір об’єктів на одному кінці асоціації є певним чином.
• {змінний} – Змінне обмеження визначає, що зв’язок між різними об’єктами в системі можна додавати, видаляти та змінювати відповідно до вимог.
• {addOnly} – Це вказує, що нові з’єднання можуть бути додані з об’єкта, який розташований на іншому кінці асоціації.
• {заморожений} – Це вказує, що коли зв’язок додається між двома об’єктами, його не можна змінити, доки заморожене обмеження активне для даного посилання чи з’єднання.

Ми також можемо створити клас, який має властивості асоціації; це називається асоціативним класом.

Рефлексивна асоціація

Рефлексивна асоціація є підтипом зв’язку асоціації в UML. У рефлексивній асоціації екземпляри одного класу можуть бути пов’язані один з одним. Екземпляр класу також називають об’єктом.

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

Розглянемо приклад фрукта класу. Клас фруктів має два екземпляри, наприклад манго та яблуко. Рефлексивна асоціація стверджує, що зв’язок між манго та яблуком може бути присутнім, оскільки вони належать до одного класу, наприклад фрукти.

Спрямована асоціація

Як випливає з назви, спрямована асоціація пов’язана з напрямком потоку в класах асоціацій.

У спрямованій асоціації потік спрямований. Асоціація від одного класу до іншого протікає тільки в одному напрямку.

Позначається суцільною лінією зі стрілкою.

приклад:

Можна сказати, що між сервером і клієнтом існує зв’язок спрямованої асоціації. Сервер може обробляти запити клієнта. Цей потік є односпрямованим і протікає лише від сервера до клієнта. Таким чином, зв’язок спрямованої асоціації може бути присутнім у серверах і клієнтах системи.

Залежність

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

Стереотипи

• «зв'язати» – Прив’язка – це обмеження, яке визначає, що джерело може ініціалізувати шаблон у цільовому місці, використовуючи надані параметри або значення.
• «отримувати» – Це означає, що розташування вихідного об’єкта можна обчислити за цільовим об’єктом.
• «друг» – Це вказує, що джерело має унікальну видимість у цільовому об’єкті.
• «примірник» – Він визначає, що екземпляр цільового класифікатора є вихідним об’єктом.
• «примірник» – Це вказує, що вихідний об’єкт здатний створювати екземпляри цільового об’єкта.
• «досконалити» – Це вказує на те, що вихідний об'єкт має виняткову абсорбціюtracніж у цільового об'єкта.
• «використовувати» – Використовується, коли пакети створюються в UML. Стереотип використання описує, що елементи вихідного пакета також можуть бути присутніми в цільовому пакеті. Він описує, що вихідний пакет використовує деякі елементи цільового пакета.
• «заміна» – вказує, що клієнт може бути замінений постачальником під час виконання.
• «доступ» – Це вказує, що вихідний пакет має доступ до елементів цільового пакета що також називається приватним злиттям.
• "Імпорт" – Це вказує, що мета може імпортувати елемент вихідного пакета, як вони визначені всередині target, який також називається публічним злиттям.
• «дозвіл» – вказує, що вихідний елемент має доступ до елемента постачальника незалежно від оголошеної видимості постачальника.
• «продовжити» – Допомагає вам визначити, що мета може розширити поведінку вихідного елемента.
• "включати" – Дозволяє вказати вихідний елемент, до якого можна включити поведінку іншого елемента у вказаному місці. (те саме, що виклик функції в c/c++)
• «стати» – Це вказує, що ціль подібний до джерела з різними значеннями та ролями.
• «дзвінок» – Це вказує, що джерело може викликати метод цільового об’єкта.
• «копія» – Це вказує, що цільовий об’єкт є незалежною копією вихідного об’єкта.
• «параметр» – постачальник є параметром операцій клієнта.
• «відправити» – клієнт – це операція, яка надсилає постачальнику певну невизначену ціль.

Стереотипи серед державної машини

• «відправити» – Вказує, що операція джерела надсилає цільову подію.

Узагальнення

Це зв’язок між загальною сутністю та унікальною сутністю, яка присутня всередині системи.

У зв'язку узагальнення об'єктно-орієнтована концепція називається спадкування можна реалізувати. Між двома об’єктами, які також називаються сутностями або речами, існує зв’язок узагальнення. У зв’язку узагальнення одна сутність є батьківською, а інша – дочірньою. Ці сутності можна представити за допомогою успадкування.

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

Цей тип зв’язку спільно відомий як зв’язок узагальнення.

Стереотипи та їх обмеження

• «реалізація» – Цей стереотип використовується для представлення того, що дочірня сутність реалізується батьківською сутністю шляхом успадкування структури та поведінки батьківського об’єкта без порушення правил. Примітка: Цей стереотип широко використовується в одному спадкування.

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

Реалізація

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

Реалізацію можна представити двома способами:

• Використання канонічна форма
• Використання видалена форма

На наведеній вище схемі бізнес-правила облікового запису реалізують інтерфейс IRuleAgent.

Види реалізації

1. Канонічна форма: У відношенні реалізації UML канонічна форма використовується для реалізації інтерфейсів у системі. Вона використовує стереотип інтерфейсу для створення інтерфейсу, а відношення реалізації використовується для реалізації конкретного інтерфейсу. У канонічній формі відношення реалізації позначається пунктирною спрямованою лінією з великою незамкненою стрілкою. На наведеній вище діаграмі інтерфейс Iruleagent реалізується за допомогою об'єкта під назвою Account Business Rules.
2. Опущена форма: Реалізація в Діаграма класів UML також можна показати за допомогою форми з пропущеними фрагментами. У формі з пропущеними фрагментами інтерфейс позначається колом, що також називається нотацією льодяника. Цей інтерфейс, реалізований за допомогою будь-чого, присутнього всередині системи, створює структуру з пропущеними фрагментами. На наведеній вище діаграмі інтерфейс Iruleagent позначено за допомогою форми з пропущеними фрагментами, яка реалізується за допомогою acctrule.dll.

Склад:

Це не стандартне відношення UML, але все ще використовується в різних програмах.

Композитне агрегування – це підтип зв’язку агрегування з такими характеристиками:

• це двостороння асоціація між об’єктами.
• Це відношення ціле/частина.
• Якщо композит видаляється, усі інші частини, пов’язані з ним, видаляються.

Композитна агрегація описується як бінарна асоціація, прикрашена заповненим чорним ромбом на кінці агрегату (цілого).

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

Цей тип зв’язку в UML відомий як зв’язок складеного агрегування.

агрегування

An агрегація є підтипом асоціативного відношення в UML. Агрегація та композиція є обома типами асоціативних відношень в UML. Агрегаційне відношення можна описати простими словами як «об'єкт одного класу може володіти або отримувати доступ до об'єктів іншого класу».

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

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

Поширені запитання