Діагра́ма кла́сів (англ. Class diagram) — статичне представлення структури моделі в UML. Відображає статичні (декларативні) елементи, такі як: класи, типи даних, їх зміст та відношення. Діаграма класів може містити позначення для пакетів та може містити позначення для вкладених пакетів. Також, діаграма класів може містити позначення деяких елементів поведінки, однак їх динаміка розкривається в інших типах діаграм.^[1]

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

На діаграмі класи представлені у вигляді прямокутників, які містять три відділення:

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

Можливо додання четветого відділення, яке містить коментарі.

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

Для подальшого опису поведінки систем діаграми класів можуть бути доповнені діаграмою станів автомата або машиною станів UML.

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

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

Асоціація (англ. association) показує, що об'єкти однієї сутності (класу) пов'язані з об'єктами іншої сутності.

Якщо між двома класами визначена асоціація, то можна переміщатися від об'єктів одного класу до об'єктів іншого. Цілком припустимі випадки, коли обидва кінці асоціації відносяться до одного і того ж класу. Це означає, що з об'єктом деякого класу дозволено зв'язати інші об'єкти з того ж класу. Асоціація, що зв'язує два класи, називається бінарною. Можна, хоча це рідко буває необхідним, створювати асоціації, що зв'язують відразу кілька класів; вони називаються n-арними. Графічно асоціація зображується у вигляді лінії, що з'єднує клас сам з собою або з іншими класами.

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

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

Часто при моделюванні буває важливо вказати, скільки об'єктів може бути пов'язано допомогою одного примірника асоціації. Це число називається кратністю (Multiplicity) ролі асоціації та записується або як вираз, значенням якого є діапазон значень, або в явному вигляді. Вказуючи кратність на одному кінці асоціації, ви тим самим говорите, що на цьому кінці саме стільки об'єктів повинно відповідати кожному об'єкту на протилежному кінці. Кратність можна задати рівною одиниці (1), можна вказати діапазон: «нуль або одиниця» (0..1), «багато» (0 .. *), «одиниця або більше» (1 .. *). Дозволяється також вказувати певне число (наприклад, 3). За допомогою списку можна задати і більш складні кратності, наприклад 0. . 1, 3..4, 6 .. *, що означає «будь-яке число об'єктів, крім 2 і 5».

Спрямована асоціація (англ. Navigable Association) - відносини направлені тільки в одному напрямку.

Агрегація (англ. aggregation)— проста асоціація між двома класами, де один з класів має вищий ранг (ціле) і складається з декількох менших за рангом (частин).

Ставлення такого типу також називають слабкою агрегацією (англ. weak aggregation); воно зараховане до відносин типу «має» (з урахуванням того, що об'єкт-ціле має кілька об'єктів-частин). Агрегація є окремим випадком асоціації і її зображують як просту асоціацію з незафарбованим ромбом з боку «цілого».

За потреби можна вказувати кратність агрегації.

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

Графічно агрегація представлена порожнім ромбом на блоці «цілого», і лінією, яка проведена від цього ромба до класу, що міститься в ньому («частин»).

Композиція (англ. composition) — більш строгий варіант агрегації (англ. strong aggregation). Відома також як агрегація за значенням.

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

Графічно представляється як і агрегація, але з зафарбованим ромбиком.

Відносини між класом Виш і класами Студент і Факультет злегка відрізняються один від одного, хоча обидва є відносинами агрегування. У виші може бути будь-яка кількість студентів (включаючи нуль), і кожен студент може навчатися в одному або декількох вишах; виш може складатися з одного або декількох факультетів, але кожен факультет належить одному і лише одному вишу. Відношення між класами Виш і Факультет називають композицією, оскільки при знищенні моделі Виш моделі факультетів, що належать цьому ВНЗ, також будуть знищені. Студент і Виш пов'язані агрегацією тому, що Студента не можна видалити при знищенні Вишу.

1. При спробі представити реальні відношення «ціле-частина», наприклад, двигун є частиною автомобіля.

2. Коли руйнується контейнер, руйнується і його вміст, наприклад, університет та його факультети.

1. При представленні відношення програмного забезпечення або бази даних, наприклад, двигун моделі автомобіля ENG01 є частиною моделі автомобіля CM01, оскільки двигун, ENG01, може також бути частиною іншої моделі автомобіля[9].

2. Коли контейнер знищується, його вміст зазвичай не знищується, наприклад, у професора є студенти; коли професор залишає університет, студенти не йдуть разом з ним.

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

Це означає, що один з двох споріднених класів (підклас, підтип, нащадок) вважається спеціалізованою формою іншого (суперклас, супертип, батько), а суперклас вважається узагальненням підкласу. На практиці це означає, що будь-який екземпляр підкласу є також екземпляром суперкласу. Зразкове дерево узагальнень такої форми можна знайти в біологічній класифікації: людина є підкласом приматів, який є підкласом ссавців, і так далі. Відношення найлегше зрозуміти за допомогою фрази «А є В» (людина є ссавцем, ссавець є твариною).

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

Відношення узагальнення також відоме як успадкування (наслідування) або відношення «є».

Суперклас (базовий клас) у відношенні узагальнення також відомий як «батько», суперклас, базовий клас або базовий тип.

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

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

А є різновидом Б

Наприклад, «дуб — це вид дерева», «автомобіль — це вид транспортного засобу».

Узагальнення можна показати лише на діаграмах класів і на діаграмах варіантів використання (англ. use case diagrams).

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

Графічне представлення Реалізації в UML — це порожнистий трикутник на інтерфейсному кінці пунктирної лінії (або дерева ліній), яка з'єднує її з одним або декількома реалізаторами. На інтерфейсному кінці пунктирної лінії, що з'єднує її з користувачами, використовується звичайна стрілка. На діаграмах компонентів використовується графічна конвенція «куля-розетка» (реалізатори показують кулю або льодяник, тоді як користувачі показують розетку). Реалізації можуть бути показані тільки на діаграмах класів або компонентів. Реалізація — це зв'язок між класами, інтерфейсами, компонентами та пакетами, який з'єднує елемент-клієнт з елементом-постачальником. Зв'язок реалізації між класами/компонентами та інтерфейсами показує, що клас/компонент реалізує операції.

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

Цей асоціативний зв'язок вказує на те, що (принаймні) один з двох пов'язаних класів посилається на інший. Цей зв'язок зазвичай описується як «A має B» (мати-кішка має кошенят, кошенята мають матір-кішку).

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

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

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

Залежно від цілей використання діаграма класів може бути використана для побудови таких моделей:

• концептуальна модель, модель аналізу (англ. conceptual model) — діаграма класів описує модель предметної області, у ній присутні тільки класи прикладних об'єктів, використовується для управління процесом мислення, розуміння; потребує концептуальної цілісності (англ. consistency);
• модель проектування (англ. design model) — діаграма класів застосовується при проектуванні інформаційних систем, призначена для подальшої розробки моделей реалізації; головна вимога — зрозумілість (англ. usability).
• модель реалізації (англ. implementation model) — діаграма класів містить класи, які використовуються безпосередньо у програмному коді (при використанні об'єктно-орієнтованих мов програмування); головна вимога — повнота (англ. completeness).

Вікісховище має мультимедійні дані за темою: Class diagram

• UML
• Об'єктно-орієнтоване моделювання
• Діаграма об'єктів
• Модель «сутність — зв'язок»
• Модель предметної області

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