3. Діаграма класів
При проектуванні сисетми інформаційна складова предметної області
виконується у вигляді логічної моделі рівня відносин (логічна модель)
Логічна модель описує відносини (об’єкти даних) автомтаизованої предметної
області і зв ’ язку між ними
В уніфікованій мові моделювання(UML) для представлення логічної моделі
можно використовувати діаграму класів
Діаграма класів (class diagram) – це діаграма, на якій показана множина класів,
інтерфейсів, кооперацій і відношень між ними. ЇЇ виконують у вигляді множини
вершин і дуг
3
4. Діаграма класів
Призначення діаграми класів
• Діаграма класів необхідна для представлення статичної структури моделі
системи
• Діаграма класі може відображати різноманітні взаємозв’язки між окремими
сутностями предметної області, такими як об’єкти і підсистеми, а також описує
їхню внутрішню структуру і тип відносин
Особливості діаграми класів
• На діаграмі класів не вказується інформація про тимчасові аспекти
функціонування системи
4
6. КласиКлас (class) призначений для позначення множини об’єктів, які мають одинакову структуру, поведінку і
відношення з об’єктами із інших класів. Графічно клас зображується у вигляді прямокутника, який
додатково може бути розділений горизонтальними лініями на розділи або секції. У цих розділах можуть
вказуватися ім’я класу, атрибути (змінні) і операції (методи).
6
class cls 01
Круг Круг
- центр
- радиус
- заливка
Круг
- центр
- радиус
- заливка
+ переместить()
+ увеличить()
+ скрыть()
+ показать()
Имя класса
Атрибуты класса
Операции класса
7. Класи
Ім’я класу
•Ім’я класу повинно бути унікальним у рамках пакету, чкий описується деякою
сукупністю діаграм класів (можливо, одною діаграмою). Ім’я класу вказується у
верхній секції прямокутника напівжирним шрифтом і повинен починатися з
великої букви.
•Абстрактний клас – це клас, який не може мати екземплярів(об’єктів). Для
позначення його ім’я викоритовується курсив.
7
8. Класи
Атрибути класу
Атрибут - це іменоване властивість класу, загальна для всіх його об'єктів, що
включає опис безлічі значень, які можуть приймати екземпляри цієї властивості
8
• Клас мати будь-яке число атрибутів або
не може мати їх зовсім
• Атрибут є абстракцією даних об'єкта або
його стану
• У кожен момент часу будь-який атрибут об'єкта, що належить даному класу, має
цілком певним значенням
• Атрибути представлені в розділі, який розташований під ім'ям класу
• При описі атрибута можна явно вказувати його тип і значення, яке приймається за
замовчуванням
class cls 02
Custome r
- name
- address
- phone
Wall
- height: double
- width: double
- thickness: double
- isLoadBearing: boolean = true
9. Класи
Операції класу
Операція - це реалізація послуги, яку можна запросити у будь-якого об'єкта класу
для впливу на поведінку. Операція - це абстракція того, що може робити об'єкт.
9
• Як правило (хоча не завжди) звернення до операції об'єкта змінює його стан або
його дані
• Операції класу зображуються в розділі, розташованому нижче розділу з
атрибутами. При цьому можна обмежитися тільки іменами.
• У всіх об'єктів класу є загальний набір
операцій
• Клас може містити будь-яке число операцій
або не містити їх зовсім
class cls 03
Rectangle
+ move()
+ expand()
+ isEmpty()
Sensor
+ reset() : void
+ setAlarm(double) : void
+ getValue() : double
10. Класи
Поради
Зображуючи клас в UML, дотримуйтеся наступних правил:
показуйте тільки ті властивості класу, які важливі для
розуміння абстракції в даному контексті
розділяйте довгі списки атрибутів і операцій на групи
відповідно до них
категоріями показуйте взаємопов'язані класи на одній і тій
же діаграмі
10
11. Відношення
Відносини між класами
Крім внутрішнього устрою класів на діаграмі класів
вказуються різні відносини (зв'язку) між ними. Сукупність
типів відносин фіксована.
Базові відносинами в мові UML:
Ставлення залежності (dependency relationship)
Ставлення асоціації (association relationship)
Ставлення узагальнення (generalization relationship)
11
12. Відношення
Відношення залежності
Залежність (dependency) - відношення використання, згідно з
яким зміна в специфікації одного елемента може вплинути
на інший елемент, його використовує, причому зворотне не
обов'язково.
Графічно залежність зображується пунктирною лінією зі
стрілкою, спрямованої від залежного елемента на той, від
якого він залежить.
12
class cls 04
Client Order
13. Відношення
Відношення асоціації
Асоціація (association) - структурний ставлення, що показує,
що об'єкти одного типу якимось чином пов'язані з об'єктами
іншого типу. Асоціація, що зв'язує два класи, називається
бінарною. Можна створювати асоціації, що зв'язують відразу
кілька класів; вони називаються n-арнимі. У асоціацій можуть
бути: ім'я, роль, кратність і агрегування.
13
class cls 05
Person
Company
Person
Company
+Employee 1..*
work on
+Employer *
14. Відношення
Відношення асоціації
14
Ім'я описує природу відносини. Щоб уникнути можливих
направленіедвусмисленностей в розумінні імені,
вказується, в якому воно повинно читатися.
Роль - це «обличчя», яким клас, що знаходиться на
одній стороні асоціації, звернений до класу з іншого
її боку. Один клас може грати в різних асоціаціях як
одну і ту ж роль, так і різні.
Кратність - кількість об'єктів, яке може бути пов'язане
допомогою одного примірника асоціації. Кратність
записується або як вираз, значенням якого є діапазон
значень, або в явному вигляді. Кратність можна задати
дорівнює одиниці (1), можна вказати діапазон: «нуль або
одиниця» (0..1), «багато» (0 .. *), «одиниця або більше»
(1 .. *), «будь-яке число об'єктів, крім 2 і 5 »(0.. 1, 3..4, 6 ..
*).
class cls 06
Person Company
work on
class cls 07
Person Company
+Employee +Employer
class cls 08
Person Company
1..* *
15. Відношення
Відношення асоціації
15
Агрегування (aggregation) показує відношення типу «частина / ціле», в якому один клас
складається з кількох менших класів
Композиція (composition) служить для виділення спеціальної форми відносини «частина /
ціле». Специфіка зв'язку полягає в тому, що частини не можуть виступати у відриві від цілого,
тобто зі знищенням цілого знищуються і всі його складові частини.
class cls 09
Team Person
*1
class cls 10
Building Room
*1
16. Відношення
Відношення узагальнення
16
Узагальнення (generalization) - це відношення між загальною сутністю (суперкласом, або
батьком) і її конкретним втіленням (подклассом, або нащадком). Дане відношення описує
ієрархію класів і спадкування їх властивостей і поведінки. Передбачається, що клас-нащадок
має всі властивості і поведінкою класу-предка, а також має свої власні властивості і поведінку,
які відсутні у класу-предка.
class cls 11
Актив
Банковский счет Недвижимость Ценная бумага
Чековый счет Сберегательный
счет
Акция Облигация
17. Відношення
Поради
При моделюванні відносин в UML дотримуйтесь наступних
правил:
•використовуйте залежність, тільки якщо відношення, яке
моделюється не є структурним
•використовуйте узагальнення, тільки якщо має місце
відношення типу «є» уникайте множинного спадкоємства
ієрархія успадкування не повинна бути ні занадто глибокою
(бажано не більше п'яти рівнів), ні занадто широкою
•застосовуйте асоціації перш за все там, де між об'єктами
існують структурні відносини
17
18. ІнтерфейсиІнтерфейс (interface) - набір операцій, який використовується для специфицирования послуг, що
надаються класом або компонентом.
18
Інтерфейс повинен мати унікальне ім'я. І
нтерфейс може включати будь-яке число операцій.
Особливості
Інтерфейси не містять атрибутів
Інтерфейси не містять реалізують операції методів
Інтерфейс специфікує контракт класу, але не
накладає ніяких обмежень на свою реалізацію.
Зв'язок інтерфейсу з реалізують його елементом
можна графічно представити двома способами:
інтерфейс представляють у вигляді стереотипного
класу і пов'язують його з класом ставленням
реалізації. Ставлення реалізації об'єднує відносини
узагальнення і залежності відношення між
інтерфейсом і його реалізацією зображується
кружечком з одного боку класу.
class cls 12
«interface»
IEmployee
+ getHistory()
+ getCompensation() IEmployee
class cls 13
Employee
+ getHistory()
+ getCompensation()
«interface»
IEmployee
+ getHistory()
+ getCompensation()
Employee
+ getHisory()
+ getCompensation()
IEmployee
19. Інтерфейси
19
Інтерфейси можуть брати участь у відносинах узагальнення, асоціації та залежності. Інтерфейс
являє собою стикувальний вузол в системі. Він визначає умови контракту, після чого обидві
сторони - клієнт і постачальник - можуть діяти незалежно один від одного, повністю
покладаючись на взаємні зобов'язання.
class cls 14
TemperatureSensor
+ getValue()
ISensor
Dev ice Observ er
+ scan()
10
1
20. Інтерфейси
Поради
Зображуючи інтерфейс на мові UML, керуйтеся наведеними
нижче правилами:
•використовуйте скорочену нотацію, якщо треба просто
показати наявність стикувального вузла в системі
•використовуйте форму, якщо треба візуалізувати деталі
самого сервісу
20
21. КоопераціїКооперація (collaboration) - це спільнота класів, інтерфейсів і інших елементів, які працюють спільно для
забезпечення кооперативного поведінки, більш значущого, ніж сума його складових.
21
class System
А гент траектории Датчик
столкновений
Мотор
Мотор
поворотного
мех анизма
Главный мотор
Привод
1 *
1 1
1 1
22. Приклади
22
class cls 15
Colledge
- name
- address
- phone
+ attestInstructors()
+ attestStudents() : void
Faculty
- name
+ addInstructor()
+ removeInstructor()
+ getInstructor()
+ getAllInstructor()
Student
- id
- name
Course
- id
- name
Instructor
1..*
include
1
*
studied at
1..*
*
visit
*
1..*
1..*
1..*
work on
1..*
+dean 1
rule
0..1
23. Приклади
23
class cls 16
Позиция заказа
- количество: int
Товар
- название: String
- цена: double
Заказ
- номер: ID
- дата заказа: Date
- дата оплаты: Date
+ сумма() : double
Сотрудник
- имя: String
+ принять заказ()
+ проверить оплату()
+ выполнить()
Клиент
- имя: String
- адрес: Адрес
+ оплатить()
Физическое лицо
+ оплатить()
Юридическое
лицо
+ оплатить()
1
входит в
*
1..*
включает
1
0..1
работает с
*
1
делает
*
0..1
формирует отчет
*
