UML Prezentation class diagram

1. ' “ ”Комп ютерна академія ШАГ
- 200Рівне 9
' -Об єктно орієнтоване проектування
з використанням
UML 2.0
Лекція 3:
Діаграми класів в UML 2.0
1

2. Призначення діаграми класівПризначення діаграми класів
 Діаграма класів (Class diagram) - це статична структурна діаграма, що описує структуру
системи, демонструє класи системи, їх атрибути і залежності між класами.
 Діаграма класів дозволяє відображати деталізовану інформацію про необхідний клас:
абстрактні класи та методи, стереотипи, загальні й часткові методи, деталізовані інтерфейси,
параметризовані, тобто шаблонні класи тощо.
 При цьому можна використовувати графічні зображення для асоціацій та їхніх специфічних
властивостей, таких як відношення агрегації, коли складовими частинами класу можуть
виступати інші класи. А також існують широкі можливості для відображення взаємозв’язків
між різними класами, інтерфейсами тощо.
 Діаграма класів показує будівельні блоки довільної об’єктно-орієнтованої
системи, незалежно від мови реалізації проекту. Вона в першу чергу служить для
представлення статичної структури моделі системи в термінології класів об’єктно-
орієнтованого програмування або окремої її частини, описує які атрибути та поведінка їй
притаманні, але не деталізує окремі методи.
 Діаграма класів найбільш корисна при необхідності відображення відношень між класами та
інтерфейсами.
2

3. Приклад діаграми класівПриклад діаграми класів
3

4. Клас та його описКлас та його опис
 Клас (class) у мові UML служить для позначення конкретної сутності, яка має однакову
структуру та поведінку. Як видно з прикладу, графічно клас зображується у вигляді
прямокутника, що додатково може бути розділений горизонтальними лініями на 3 розділи
або секції: ім'я класу, атрибути (змінні-члени класу) та операції (методи класу)
 Як видно з графічного представлененя, перша частина, тобто вказання імені класу, являється
обов’язковою умовою, на відміну від другої та третьої частини, які, як правило, дописуються в
ході деталізації та розширення загальної схеми. Та навіть за відсутності останніх двох розділів,
місце для них на практиці відводиться, тобто вказуються пусті секції. Це робиться для того,
щоб на діаграмі легко було відрізнити клас від інших елементів.
 Дуже рідко, але буває, що при описі класу використається додатковий четвертий розділ, в
якому наводиться семантична інформація довідкового характеру або явно вказуються
виняткові ситуації.
4

5. Правила побудови розділу опису іменіПравила побудови розділу опису імені
класукласу
 Правила іменування класу аналогічні правилам будь-якої об’єктно-орієнтованої мови
програмування, але варто відмітити, що ім.’я класу здебільшого записується по центру секції
напівжирним шрифтом і повинне починатися із загловної літери.
 В даному розділі також дозволяється вказувати посилання на стандартні шаблони або абстрактні
класи, від яких походить даний клас та, відповідно, від яких він успадковує свої властивості й методи.
 Тут також дозволяється приводити інформацію про розробника класу, статус стану розробки та інші
загальні властивості цього класу, що мають відношення до інших класів діаграми або стандартних
елементів мови UML.
 Імена абстрактних класів і абстрактних методів в UML пишуться курсивом.
 Крім назви класу, в першій секції може також бути присутній стереотип (stereotype), який розширює
словник мови (дозволяє створювати із існуючих блоків нові, специфічні для конкретної розв’язуваної
задачі). Стереотип вказується над іменем і заключений в кутові дужки - <<стереотип>>. Крім
використання існуючих, користувач може створювати свої власні стереотипи, наприклад: <<layer>>,
<<interface>> тощо.
5

6. Атрибути (властивості, змінні-члени)Атрибути (властивості, змінні-члени)
класукласу
 Кожному атрибуту класу відповідає окремий рядок тексту, що складається із типу доступу
або, як кажуть, видимості (visibility) атрибута, його імені та інших додаткових характеристик.
Причому варто не забувати, що обов’язковим є лише вказання імені атрибуту. Повна нотація
запису атрибута наступна:
 Статичні змінні, тобто атрибути виділяються курсивом.
 Перед іменем атрибута може вказуватись символ ( / ), який вказує на те, що даний атрибут є
похідним від іншого атрибута цього ж класу. Це означає, що значення цього атрибута може
бути обчислено за рахунок значення інших атрибутів цього класу.
6

7. Позначення атрибутів класуПозначення атрибутів класу
 При показі синтаксису вжиті наступні позначення:
1. visibility – тип доступу до атрибуту, який може позначатись одним з наступних знаків:
Однак замість умовних графічних позначень можна записувати і відповідне ключове слово:
public, protected, private, package. Крім того, якщо тип доступу не вказується, то це означає, що
атрибут немає жодного типу доступу, оскільки типу доступу по замовчуванню в мові UML
невизначено.
7

8. 2. multiplicity – різноманіття значень, які може набувати атрибут. Воно може бути рівним значенню
* або іншому довільному додатньому числу, що вказує на кількість появи даного атрибуту.
Символ ( * ) вказує на необмежену кількість, а число 0 – на його імовірну відсутність. По
замовчуванню кратність атрибута приймається рівним 1..1, тобто 1. Наприклад:
 [0..1] - кратність атрибута може приймати значення 0 або 1. Тобто атрибут може бути
відсутнім або існувати лише в одному екземплярі
 [0..*] - кратність атрибута може приймати будь-яке додатнє ціле значення більше або рівне
0. Ця кратність може бути записана скорочено, - [*].
 [1..*] - кратність може приймати будь-яке додатнє ціле значення більше або рівне 1.
 [1..5] - кратність атрибута може приймати будь-яке значення із чисел: 1, 2, 3, 4, 5.
 [1..3,5,7] - кратність атрибута може приймати будь-яке значення із чисел: 1, 2, 3, 5, 7.
 [1..3,7.. 10] - кратність може приймати будь-яке значення із чисел: 1, 2, 3, 7, 8, 9, 10.
 [1..3,7..*] - кратність атрибута може приймати будь-яке значення із чисел: 1, 2, 3, а також
будь-яке додатне ціле значення більше або рівне 7.
 middleName [0..1] : String - атрибут може бути відсутнім або існувати лише в одному
екземплярі. При цьому, якщо ім‘я відсутнє, то використовується значення null.
 color [3]: Saturation - масив із 3-х кольорів.
 points [2..*]: Points - масив із 2-х або більше точок.
 phoneNumber [1..*] – массив телефонів від 1 значення до безлічі.
8

9. 3. type - тип атрибута (integer, String, Person, Contact). Тип атрибута може вказуватись у
вигляді ідентифікатора, який слідує після імені атрибуту і відділений від нього
двокрапкою. Тип також може залежати від кінцевої мови реалізації класу. Для
порівняння:
4. initial value – початкове значення, тобто значення по замовчуванню. При його вказанні
необхідно дотримуватися правила приналежності значення типу до конкретного атрибуту.
По замовчуванню, якщо initial value не вказаний, значення відповідного атрибута
вважається не визначеним. З іншого боку, конструктор відповідного об’єкта може
перевизначати початкове значення в процесі виконання програми, якщо в цьому виникає
необхідність.
5. property – значення, тобто властивості атрибута, які не можуть бути змінені в ході
виконання програми для цього типу атрибута. Наприклад, Changeable, readOnly, addOnly,
frozen (C++: const, Java: final). Фігурні дужки служать якраз для вказання фіксованого
значення відповідного атрибута для класу вцілому. Це значення приймається за початкове
значення атрибута, що не може бути перевизначене надалі. Відсутність рядка-властивості
по замовчуванню вказує на те, що значення відповідного атрибута може бути змінене в
ході виконання програми.
9

10. Приклади написання атрибутівПриклади написання атрибутів
 + isLightOn : boolean = false
 - numOfPeople : int
 mySport
 + passengers : Customer[0..10]
 - id : long {readOnly}
10

11. Операції (методи) класуОперації (методи) класу
 У третьому розділі опису класу визначається перелік операцій або методів класу. Запис операцій
класу в мові UML також стандар­тизований і має певний набір синтаксичних правил. Повна натація
запису операції класу виглядає так:
 Назва операції, як і при вказанні атрибутів, являється обов’язковою, а також обов’язковими
являються круглі дужки.
 Імена операцій, так само як й атрибутів, записуються з маленької літери, а їхні типи – з заглавної.
 Імена статичних методів пушуться курсивом.
 При показі синтаксису вжиті наступні позначення:
1. parameter list – список параметрів операції, причому він може бути рівний нулю, тобто
невказаний. Синтаксис вказання параметрів має наступний вигляд:
Щодо напрямку, то він може приймати значення:
 in (input paremeter) – вхідний параметер;
 out (output parameter) – вихідний параметер;
 inout (input output paremeter) – вхідний або вихідний.
11

12. 2. return type – тип повертаємого значення, якщо він існує. Він також визначається кінцевою
мовою реалізації методу.
3. property – вираз, що вказує на значення властивості, яке може повертатись:
 {leaf} – конкретна операція;
 {query} – виконання операції не змінює стан системи;
 {abstract} – абстрактна операція;
 {concurrency = ім’я} – операція виконується паралельно, що підвищить продуктивність системи.
Ім’я може приймати одне з наступних значень:
 послідовна (sequential) – для даної операції необхідно забезпечити її єдине виконання в
системі, одночасне виконання інших операцій може привести до помилок або порушень
цілісності об'єктів класу;
 паралельна (concurrent) – дана операція може виконуватися паралельно з іншими
операціями в системі, при цьому паралель­ність повинна підтримуватися на рівні реалізації
моделі;
 захищена (guarded) – всі звернення до даної операції повинні бути строго впорядковані в часі
з метою збереження цілісності об'єктів даного класу, при цьому можуть бути вжиті додаткові
заходи щодо контролю виняткових ситуацій на етапі її виконання.
12

13. Приклади написання операційПриклади написання операцій
 + create()
 + isLightOn() : boolean
 + addColor(newColor : Color)
 + addColor(newColor : Color) : void
 # convertToPoint(x : int, y : int) : Point
 - changeItem([in] key : string, [out] newItem : Item) : int
 + draw(shape: type = Rectangle, fill: Color = (200, 150, 255))
 showMessage() : {"Error! Devide by zero"}
13

14. ІнтерфейсиІнтерфейси
 Інтерфейс в контексті мови UML являється спеціальним випадком класу, в якого присутні назви
операції, але відсутні атрибути. Тому для відображення інтерфейсів використається круг (в
основному використовується в діаграмах компонентів і розгортки (deployment)) або прямокутник
класу, який поділений тепер на два розділи:
 розділ, в якому вказується назва інтерфейсу з стереотипом <<interface>>.
 поле для методів інтерфейсу, які потребують подальшої реалізації в дочірних класах.
 Наприклад, відобразимо стандартний інтерфейс фігури:
 Другий спосіб може бути більш уточнений за допомогою деяких програм розробки. При такому
уточненні третій метод буде описаний наступним чином:
+ TestMethod(b: double, a: int) : void
15

15. Шаблони класівШаблони класів
 Шаблон (template) класу або параметризований клас (parametrized class) служать для створення
каркасів класів та набувають конкретного типу під час виконання програми.
 Параметрами шаблонів класів якраз і є типи, які будуть використані в якості атрибутів та операцій
класу.
 Графічно шаблон зображується аналогічно класу, тобто прямокутником з трьох розділів. Різницею
між ними є те, що шаблон класу містить в верхньому правому кутку маленький прямокутник з
пунктирних ліній.
 У цьому прямокутнику вказується список формальних параметрів для шаблонного класу.
16
class Class Model
Class:T1
Class:T2
TemplateClass
+ Print() : void

16. Перелічувані константиПерелічувані константи
 В мові UML на діаграмах класів також можна показувати перелічувані константи. Відображаються
вони за допомогою прямокутника класу з стереотипом <<enumeration>> та без вказання розділу
операцій.
 Для прикладу спробуємо створити перелічувальну константу з позначеннями кольорів:
17

17. Відношення між класамиВідношення між класами
 Відношення узагальнення (generalization relationship) – зв’язують дочірні
класи з батьківськими;
 Відношення асоціації (association relationship) – представляють структурні
відношення між класами;
 Відношення агрегації (aggregation relationship) – відображає
взаємовідносини типу «частина­ціле» між класом та його складовими
частинами;
 Відношення композиції (composition relationship) – підвид попереднього.
18

18. Відношення узагальненняВідношення узагальнення (generalization(generalization
relationship)relationship)
 Відношення узагальнення є, по суті, відображенням звичайних відносин успадкування. Даний тип
відношення може використовуватись для вказання взаємозв’язків між класами, пакетами,
варіантами використання та іншими елементами мови UML.
 На діаграмах відношення узагальнення позначається суцільною лінією із трикутною стрілкою на
одному з кінців. Причому, стрілка направлена від дочірного класу (підклас) до загального
(батьківський клас, суперклас).
19
class Class Model
ChildClass BaseClass

19.  Як правило, від одного батьківського класу походить
ряд дочірних. Для відображення таких відносини на
діаграмі UML вказується кілька стрілок до
батьківського класу. Наприклад:
20
class Class Model
Animal
Dog Cat Mouse
 З метою спрощення позначень на діаграмі класів цю
сукупність ліній можна замінити однією. В такому
випадку окремі лінії зображуються направленими до
єдиної стрілки, що має з ними загальну точку перетину.

20. Додаткові позначення на відношенніДодаткові позначення на відношенні
узагальненняузагальнення
 Поруч із стрілкою узагальнення може розміщатися рядок тексту, що вказує на деякі додаткові
властивості цього зв’язку. Цей текст розглядається як обмеження та вказується в фігурних дужках.
Існують таступні типи обмежень, кожне з яких позначається ключовим словом:
 {complete} – означає, що в даному відношенні відображені всі дочірні класи і інших дочірних класів в
базового класу бути не може. Наприклад, клас ClientBank є базовим лише для двох класів -
SoleProprietor (фізична особа) та Company;
 {incomplete} - випадок, протилежний першому. Тобто на діаграмі відображаються не всі батьківські
класи. Передбачається, що при їх появі вони будуть добавлені на діаграму;
 {disjoint} - означає, що батьківські класи не можуть мати дочірних класів, які одночасно являються
похідними і від інших класів (тобто мають більше одного батька);
 {overlapping} – випадок, протилежний попередньому. Тобто один дочірний клас обов’язково має
більше одного батька.
21

21. ПрикладПриклад
 Щоб проілюструвати особливості використання відносини узагальнення, побудуємо діаграму класів,
яка відображає ієрархічну модель графічних об’єктів:
22
class Class Model
Rectangle
- height: int
- width: int
+ Area() : int
+ Draw() : void
+ GetHeight() : int
+ GetWidth() : int
+ SetHeight(i nt) : void
+ SetWidth(i nt) : voidSquare
+ Draw() : void
RoundRect
- x: int
- y: int
+ Draw() : void
+ GetX() : int
+ GetY() : int
+ SetRound(int, int) : void
{disjoint}
{disjoint}

22. Відношення реалізаціїВідношення реалізації
 В відношення узагальнення є ще один підвид – відношення реалізації, які вказують на
взаємовідносини між інтерфейсом або абстрактним класом і дочірним класом. В такому випадку
дочірний клас повністю реалізує перший і тому кажуть про реалізацію, а не успадкування.
23
class Class Model
«interface»
IShape
+ Area() : int
+ Draw() : void
+ TestMethod(double, int) : void
Rectangle
- height: int
- width: int
+ Area() : int
+ Draw() : void
+ GetHeight() : int
+ GetWidth() : int
+ SetHeight(i nt) : void
+ SetWidth(i nt) : void
Ellipse
- radius: int
+ Area() : int
+ Draw() : void
+ GetRadius() : int
+ SetRadius(i nt) : void
Square
+ Draw() : void
RoundRect
- x: int
- y: int
+ Draw() : void
+ GetX() : int
+ GetY() : int
+ SetRound(int, int) : void
{disjoint}
{disjoint}
 Для відображення
відношень
реалізації
використовується
пунктирна лінія з
трикутною
стрілкою, яка
направлена від
дочірного класу до
батьківського.

23. Відношення асоціації (Відношення асоціації (associationassociation
relationshiprelationship))
 Відношення асоціації (association) вказують на деякі відносини між двома або більше класами або
їх екземплярами. Відношення асоціації позначається суцільною лінією з додатковими
необов’язковими спеціальними символами, які характеризують окремі властивості конкретної
асоціації. В ролі додаткових позначень можуть виступати:
 Ім’я асоціації. Якщо воно задане, то записується із великої літери поруч із лінією відповідної
асоціації. Асоціації, які мають імена називають іменованими.
 Роль – це клас, який приймає участь в асоціації та відіграє в ній певну роль. По суті, роль вказує
на вказує специфічне відношення одного класу до іншого. Наприклад, клас Людина, який грає
роль Працівника, асоційований з класом Компанія, яка грає роль Роботодавця.
 Кратність ролей позначається у вигляді інтервалу цілих чисел, аналогічно кратності атрибутів й
операцій класів. Інтервал записується поруч із кінцем асоціації і для N-арной асоціації означає
потенційне число окремих екземплярів або значень упорядкованих наборів (кортежів) цієї
асоціації, які можуть мати місце, коли інші N-1 екземпляри або значення класів фіксовані.
24
class Class Model
Людина Компанія
+Працівник +Роботодавець

24. Бінарна асоціаціяБінарна асоціація
 Існують різні типи асоціації. Найбільш поширеними є двонаправлена (бінарна) і однонаправлена
(рефлексивна) асоціації.
 Бінарна або двонаправлена асоціація (binary association) використовується тоді, коли обидва
класи знають один одного, тобто вказує на відношення лише двох класів між собою. Позначається
дана асоціація звичайною суцільною лінією. Наприклад, спробуємо відобразити на діаграмі класів
відношення асоціації між працівником компанії та самою компанією. Ці класи будуть зв’язані між
собою бінарною асоціацією Робота:
25
class Class Model
Компанія Працівник
*
Робота
1..*

25.  Для бінарної асоціації на діаграмі може бути зазначений порядок проходження класів:
направлений та ненаправлений, тобто симетричний.
 Направлена асоціація позначається лінією із стрілкою, а ненаправлена трикутником у формі
стрілки поруч із ім'ям даної асоціації. Напрямок стрілки вказує на порядок класів, один із яких є
першим (з боку трикутника). Відсутність даної стрілки поруч із ім'ям асоціації означає, що порядок
проходження класів у розглянутому відношенні невизначений.
 Для нашого прикладу, діаграма класів з використанням направленого асоціативного зв’язку набуде
вигляду:
26
class Class Model
Компанія Працівник
*
Робота
1..*

26. Інші типи асоціаційІнші типи асоціацій
 Рефлексивна або однонаправлена асоціація являється частковим випадком бінарної, коли клас
зв’язаний сам з собою.
 Крім бінарної та рефлексивної асоціації існують N-арні асоціації, які вказують на взаємозв’язок між
трьома та більше класами. При цьому один клас може приймати участь в асоціації більше одного
разу. Графічно N-арна асоціація позначається ромбом, від якого йдуть суцільні лінії, направлені до
класів даної асоціації. Зазвичай ці лінії направлені від вершин ромба або від середин його сторін.
 В якості прикладу тернарної асоціації можна розглянути відношення між трьома класами:
Працівник, Компанія і Проект. Цей зв’язок відображає інформацію про проекти компанії та про
працівників, які прцюють над цими проктами:
27
class Class Model
Працівник
Компанія
Проект
1
* 1..*
 Клас може бути приєднаний до ліній
асоціації пунктирною лінією. Це
означає, що даний клас забезпечує
підтримку властивостей відповідної
n-арної асоціації, а сама n-арна
асоціація має атрибути, операції і/або
асоціації. Іншими словами, така
асоціація є автономним класом
(класом асоціацією - Association Class)
і позначається в вигляді
прямокутника.

27. Відношення агрегації (Відношення агрегації (aggregationaggregation
relationshiprelationship))
 Агрегація – це спеціальна форма асоціації, яка відображає взаємовідносини типу «частина-ціле»
між агрегатом (ціле, тобто цілісний клас) та його складовою частиною, тобто коли один клас
являється колекцією або контейнером інших класів.
 Відношення агрегації фактично показує з яких компонентів складається система і як її складові
частини взаємопов’язані між собою. Причому час життя складових частин не залежить від часу
життя класу, що їх містить. Якщо контейнер буде знищено, то його вміст – ні, тобто класи, що
описують складові частини являються повністю самостійними.
 Графічно відношення агрегації зображується суцільною лінією, один з кінців якої являє собою
незафарбований всередині ромб. Цей ромб вказує на той із класів, що являє собою «ціле». Інші
класи є його «частинами».
28
class Class Model
Ціле Частина

28. Приклад 1Приклад 1
 Для прикладу відобразимо відносини агрегації, які виникають між Персональним комп’ютером та
його складовими частинами: системний блок, монітор, клавіатура та миша. Використовуючи
позначення мови UML, компонентний склад ПК можна представити у вигляді відповідної діаграми
класів, що в даному випадку ілюструє відношення агрегації.
29
class Class Model
PersonalComputer
MouseMonitorKeyboardSysBlock

29. Приклад 2Приклад 2
 Приклад, в якому ілюструється взаємозв’язок текстового документа та зображень, які він може
містити:
30
class Class Model
WordDocument Picture
*

30. Відношення композиції (Відношення композиції (compositioncomposition
relationshiprelationship))
 Відношення композиції є частковим випадком відношення агрегації. Різниця між ними полягає в
тому, що час життя складової частини залежить від часу життя класу, в якому вона міститься. (Хоча
багато програмістів при проектуванні не дуже звертають на це увагу. Здебільшого це уточнюється
пізніше при потребі). Тобто при знищенні контейнера, знищуються і його складові.
 Графічно відношення композиції зображується суцільною лінією, один з кінців якої являє собою
зафарбований всередині ромб. Цей ромб вказує на клас-контейнер.
31
class Class Model
Ціле Частина

31. ПрикладПриклад
 Наприклад, вікно прикладної програми, що складається з рядка заголовка, кнопок
керування розміром, головного меню, робочої області, рядка стану тощо. Вікно являється
класом-контейнером, а все інше – його складовими частинами, які при закритті вікна також
знищуються.
32
class Class Model
Window
+ Close() : void
+ Create() : void
+ Move() : void
Slider Menu Header
OperationSystem
0..2

32. Різниця між композицією та агрегацієюРізниця між композицією та агрегацією
 Композиція також відома як композитна агрегація (composite aggregation), що вказує на чітко
визначений тип зв'язку «ціле-частина», - більш жорсткий за агрегацію. Різниця між ними
відображена в таблиці.
33
Агрегація Композиція
Частина може належати одночасно декільком «цілим» Екземпляр частини в кожний момент часу належить тільки одному
цілому. Наприклад, клас Slider не може існувати окремо від Window.
Частини можуть жити незалежно (відношення цілого
до частини може бути 0..*)
Частина живе і вмирає разом з цілим
Ціле не відповідає цілком за об’єкт Ціле повністю відповідальне за частину: створює та знищує свої частини