Лекція № 6

Тема: UML-діаграми класів

План

1. Принципи побудови UML-діаграм класів

Ключові поняття: Клас, екземпляр класу, атрибут, відношення

Короткий виклад теоретичного матеріалу

1. Принципи побудови UML-діаграм класів

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

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

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

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

У зображенні класу виокремлюють три секції, в яких послі­довно записують назву, атрибути та операції. Кожну секцію, крім першої, можна опустити. Назва класу має бути унікальною в межах пакета, в якому розташовано клас. Назви абстрактних класів в UML позначають курсивом.

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

- немає жодного екземпляра - службовий клас (Utility);

- рівно один екземпляр - синглетний клас (Singleton);

- строго визначена кількість екземплярів;

- довільна кількість екземплярів - варіант за домовленістю.

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

Атрибут - це позначене місце (слот), в якому може/можуть зберігатися значення. Загальний формат атрибутів такий:

[<видимість>] <назва> [<кратність>] [:<тип>] [=<початкове значення>][<властивості>]

Видимість атрибута визначає рівень доступу до атрибута і найчастіше набуває таких значень1:

- відкритий (public) - передбачає необмежений доступ до атрибута з боку інших класів і позначається символом "+";

- захищений (protected) - передбачає доступ до атрибута лише класам, які його наслідують, і позначається символом "#";

- закритий (private) - забороняє доступ до атрибута всім іншим класам і позначається символом "-".

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

Можна задавати такі властивості атрибута:

- changeable (змінюваний) - за домовленістю;

- addOnly (тільки долучення) - можна долучати нові значення для атрибута-масиву, без можливості наступних змін;

- frozen (заморожений) - після ініціалізації значення атрибута не змінюється (відповідає слову const у С++).

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

На рис. 1.1 зображено клас Customer, який має чотири атрибути: два загальні атрибути name і birthDate, закритий атрибут password і статичний захищений атрибут count з початковим значенням 1.

Рис. 1.1 – Приклад класу Customer

Операції дають змогу закласти в клас та його об'єкти деяку поведінку. Загальний формат запису операцій наступний:

[<видимість>]<назва>([список параметрів])[:<тип результату>]

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

Список параметрів дає змогу специфікувати інтерфейс опе­рації. Кількість параметрів у списку може бути довільною.

Кожен параметр у загальному випадку записують так:

[<напрям>] <назва> [:<тип>][= <значення за домовленістю>]

Напрям визначає характер використання параметра в опе­рації і найчастіше набуває таких значень:

- in - параметр використовується як вхідний;

- out - параметр використовується як вихідний;

- inout - параметр використовується як вхідний і вихідний од­ночасно.

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

Приклади різних форм запису операцій наведено на рис. 1.2.

Рис. 1.2 – Операції класу CreditCard

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

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

Статичні операції (або операції класу) належать цілому кла­су, працюють зі статичними атрибутами класу і позначаються на діаграмах підкресленням.

На рис. 1.3 зображено клас Document, який налічує чо­тири секції: назви, атрибу­ти, операції та відповідаль­ності класу.

Рис. 1.3 – Приклад класу Document

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

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

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

Базова нотація асоціації (суцільна лінія) засвідчує, що об'єк­ти асоційованих класів (полюси асоціації) взаємодіють між собою під час виконання програми. Для асоціацій в UML передбачено чи­мало доповнень. Доповнення не є обов'язковими: їх використову­ють за необхідності, у різних ситуаціях по-різному. Якщо використовувати усі доповнення одразу, то діаграма класів стає переванта­женою настільки, що її важко читати і розуміти. Розглянемо най­важливіші доповнення:

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

- Роль полюса асоціації (або специфікатор інтерфейсу) - кон­кретизує асоціацію щодо певного класу. Роль зазначається поблизу лінії неподалік класу, набуває вигляду:

[<видимість>] <назва ролі> [: <тип>]

Використовується для ідентифікації полюсів у випадку самоасоціації (клас зв'язується сам з собою) або у випадку, коли два класи зв'язані декількома різними асоціаціями.

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

<нижня межа>.. <верхня межа>

Кратність полюса або верхню межу може зображати символ "*", який позначає довільну кількість екземплярів класу. При­клади допустимих діапазонів: 1..5, 1..*, *, 0..4.

- Сортування на полюсі асоціації - визначає тип упорядкування об'єктів на полюсі з кратністю понад 1. Можливі значення: упорядковано (ordered або sorted), неупорядковано (un­ordered або unsorted). За домовленістю - неупорядковано.

- Змінюваність на полюсі асоціації (Is changeable) - визначає можливість/неможливість зміни кількості екземплярів класу з боку полюса під час роботи програми (у межах специ­фікованої кратності).

- Напрям навігації на полюсі асоціації (Is navigable) - визна­чає можливість/неможливість доступу до екземплярів класу з боку полюса за допомогою певної асоціації. Ті полюси, через які навігація можлива, на діаграмах позначають стрілками.

У деяких CASE-засобах відсутність стрілок означає можли­вість навігації у будь-якому напрямку.

Найчастіше використовують бінарні асоціації (Binary Asso­ciation) - відношення між двома класами або рефлексивне відно­шення класу із самим собою. На рис. 1.4 зображено бінарну асо­ціацію з назвою Містить типу "один до багатьох" між класами Авіарейс і Місце (у літаку).

Рис. 1.4 – Приклад бінарної асоціації між класами

Можлива ситуація, коли один екземпляр класу асоціюється з декількома екземплярами того ж самого класу. Нехай один екзем­пляр класу ЧлениКафедри представ­ляє завідувача кафедри, а інші ек­земпляри цього класу - викладачів. Завідувач кафедри керує викладача­ми. Зв'язок, який виникає між екземплярами одного і того ж класу, називають самоасоціацією (рис. 1.5).

Рис. 1.5 – Приклад самоасоціації

Здебільшого асоціація між класами А і В - це множина пар (а; b), де а - об'єкт класу А, а b - об'єкт класу В. Ці пари є екземп­лярами асоціації (зв'язками). Отже, асоціація є класом, який ще може володіти іншими додатковими властивостями, які залежать від асоціації.

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

Рис. 1.6 – Приклад асоційованого класу

Одну деталь можуть постачати різні постачальники, а один постачальник може постачати різні деталі. Вартість деталі зале­жить від асоціації (від конкретної деталі та конкретного постачаль­ника) і може бути тільки атрибутом асоційованого класу.

Багатополюсна асоціація (N-ary Association) - це зв'язок між трьома та більше класами. Такий зв'язок графічно зображають ром­бом, до якого підходять лінії, що з' єднують ромб із класами. Клас, що описує зв'язок, приєднується до ромба за допомогою штрихової лінії. Приклад такої асоціації зображено на рис. 1.7.

Рис. 1.7 – Приклад багатополюсної асоціації

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

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

При агрегації жодних додаткових обмежень не накладають: об'єкт класу А ("частина") може бути зв'язаний відношеннями аг­регації з іншими об'єктами (тобто брати участь у декількох агрега­ціях), може створюватися і знищуватися незалежно від об'єкта класу В ("цілого"). На рис. 1.8 зображено агрегацію між класом Рисунок ("ціле") і класом Фігури ("частина").

Рис. 1.8 – Приклад агрегації Композиція (Composition) є посиленою формою агрегації і створюється на основі бінарної асоціації. Композиція накладає де­що сильніші обмеження: композиційно "частина" може входити тільки в одне "ціле", "частина" існує доти, доки існує "ціле", і при­пиняє своє існування разом з "цілим". Графічно відношення компо­зиції зображають зафарбованим ромбиком.

"Ціле" у композиції слугує класом-власником, а "частина" - підпорядкованим класом. Підпорядковані класи, що належать до композиції, не можуть водночас налічувати декілька класів-власників. Об'єкт-власник і його складові частини (підпорядковані об'єк­ти) не можуть існувати окремо. Усі підпорядковані об'єкти зміню­ються разом із об'єктом-власником.

Графічно, композицію зображають як "дерево", коренем яко­го є клас-власник, а листками - підпорядковані класи. На рис. 1.9 зображено частину композиції класу Автомобіль.

Рис. 1.9 – Приклад композиції

Узагальнення (generahzation) - це відношення між двома сутностями, одна з яких є частковим (або спеціалізованим) випад­ком іншої. Відношення узагальнення передбачає виконання прин­ципу підстановки: якщо сутність А - загальне (або батько - parent, предок) є узагальненням сутності В - часткове (або дитина - child, на­щадок), то В може бути підставлене замість А.

Графічно відношення узагальнення зображають лінією з незафарбованою стрілкою, яка вказує на предка (рис. 1.10).

Відношення успадкування між класами в об'єктно-орієнтова­ному програмуванні є типовим прикладом узагальнення, за якого об'єкт спеціалізованого класу (нащадок) може бути підставлений замість об'єкта узагальненого класу (батька, предка).

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

Суперклас може бути конкретним (тобто мати власні екземп­ляри), або абстрактним, введеним саме для побудови відношення узагальнення. Узагальнення в моделі класів вводять довільно (за винятком вимоги відсутності циклів у ланцюжках узагальнень), зо­крема, клас може бути підкласом декількох суперкласів (множинне успадкування); не потрібно, щоб у базових класів був загальний су­перклас. На рис. 1.10 зображено узагальнення геометричної фігури.

Рис. 1.10 – Приклад узагальнення між класами Залежність (dependency) - це найузагальненіше відношення між двома сутностями, яке вказує на те, що зміна незалежної сут­ності якось впливає на залежну сутність. Графічно відношення залежності зображають пунктирною стрілкою, спрямованою від залежної сутності до незалежної (рис. 1.11). Зазвичай, семантика конкретної залежності уточнюється в моделі за допомогою додат­кової інформації.

На рис. 1.11 зображено залежність Області малювання від Геометричної фігури. Подібний зв'язок ніяк не регламентує тип відношення між об'єктами, а вказує лише на те, що залежний клас Геометрична фігура використовує якісь особливості реалізації ін­шого класу Область малювання.

Рис. 1.11 – Приклад залежності між класами

Під час моделювання класів залежності найчастіше викорис­товують, щоб відобразити у сигнатурі операції той факт, що один клас використовує інший клас (незалежну сутність) як аргумент (рис. 1.12). У цьому випадку зміна одного класу знайде своє відо­браження при роботі іншого, оскільки незалежний клас може пред­ставити новий інтерфейс і/або поведінку.

Рис. 1.12 – Виклик класу залежним класом

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

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

До стереотипного підходу можна зачислити і механізми роз­ширення UML, які дають змогу вводити додаткові графічні позна­чення, орієнтовані на розв'язування задач з певної предметної об­ласті. Важливе значення мають два спеціальні розширення: профіль розробки програмного забезпечення (The UML Profile for Soft­ware Development Processes) і профіль бізнес-моделювання (The UML Profile for Busіness ModeUng).

У рамках профілю розробки програмного забезпечення за­пропоновано три спеціальні графічні позначення: для класу керу­вання, класу-сутності та межового класу. Ці позначення викорис­товують з метою уточнення семантики класів під час побудови різ­них діаграм. На рис. 1.13 наведені відповідні позначення: у формі піктограми (верхній рядок) і у формі класу зі стереотипом (нижній рядок).

Рис. 1.13 – Позначення профілю розробки програмного забезпечення

Клас керування (control class) відповідає за координацію по­ведінки об'єктів системи. У кожного прецеденту, зазвичай, є хоча б один клас керування, який контролює послідовність виконання дій цього прецеденту. Зазвичай, цей клас є активним та ініціює розси­лання множини повідомлень іншим класам моделі. Клас керування може бути відсутнім у прецедентах, які здійснюють прості маніпу­ляції зі збереженими даними.

Клас-сутність (entity) містить інформацію, яка повинна збе­рігатися постійно і не знищуватися зі знищенням об'єктів певного класу чи припиненням роботи системи (вимиканням системи чи за­вершенням програми). Цей клас може відповідати окремій таблиці бази даних; у цьому випадку його атрибути є полями таблиці, а операції - збереженими процедурами. Зазвичай, цей клас є пасив­ним і лише приймає повідомлення від інших класів моделі. Класи-сутності є ключовими абстракціями (поняттями) ПО системи.

Межовий клас (boundary) розташовується на межі системи з зовнішнім середовищем, однак є складовою частиною системи.

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

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

Використання профілю розробки програмного забезпечення та інтерфейсу наведено на рис. 1.14 на прикладі побудови діаграми класів системи керування банкоматом.

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

У рамках профілю бізнес-моделювання також запропоновано три спеціальні графічні позначення:

- співробітник (worker) - клас опису співробітника, який є еле­ментом бізнес-системи і взаємодіє з іншими співробітниками під час реалізації бізнес-процесу;

- співробітник для зв'язків з оточенням (caseworker) - клас опи­су співробітника, який є елементом бізнес-системи і взаємодіє з акторами під час реалізації бізнесу-процесу;

- бізнес-сутність (business entity) - спеціальний випадок класу-сутності, що також не ініціює жодних повідомлень.

Рис. 1.14 – Діаграма класів системи керування банкоматом

Питання для самоконтролю:

1. Дайте визначення класу?

2. Як зображується клас на діаграмі класів?

3. Опишіть формат запису атрибутів?

4. Опишіть формат запису операцій?

5. Опишіть формат запису параметрів?

6. Як записується відношення асоціації на діаграмі класів?

7. Як записується відношення узагальнення на діаграмі класів?

8. Як записується відношення агрегації на діаграмі класів?

9. Як записується відношення композиції на діаграмі класів?

Література:

1. Дудзяний І.М. Об’єктно-орієнтоване моделювання програмних систем: Навчальний посібник. – Львів: Видавничий центр ЛНУ імені Івана Франка, 2007. – 108 с.

2. Киммел Пол. UML. Универсальный язык программирования. НТ Пресс - 2008

3. Рамбо Д., Буч Г., Якобсон А. Язык UML изд.2. Пер. с англ. ДМК - 2007

Дата добавления: 2014-01-04