Тема
Розробка об’єктно-орієнтованої моделі системи у вигляді діаграми класів (Class Diagram)
Мета
Ознайомлення з об’єктно-орієнтованим методологією при проетуванні комп’ютерних систем. Побудова діаграми класів.
Теоретичні відомості
Одне з основних місць в Об’єктно Орієнтованому Аналізі(Проектуванні)-ООА(П) займає розробка логічної моделі системи у вигляді діаграми класів. Діаграма Класів (class diagram) служить для представлення статичної структури моделі системи в термінології класів об'єктно-орієнтованого програмування. Діаграма класів може відображати, різні взаємозв'язки між окремими сутностями в заданій предметній області, а також описує їх внутрішню структуру і типи відношень. На даній діаграмі не вказується інформація про тимчасові аспекти функціонування системи. З цієї точки зору діаграма класів є подальшим розвитком концептуальної моделі проектованої системи.
Діаграму класів можна прирівняти до графа, вершинами якого є елементи типу "класифікатор", які зв'язані різними типами структурних відношень. Слід відмітити, що діаграма класів може також містити інтерфейси, пакети, відношення і навіть окремі екземпляри, такі як об'єкти і зв'язки. Коли говорять про дану діаграму, мають на увазі статичну структурну модель проектованої системи. Тому діаграму класів прийнято вважати графічним представленому таких структурних взаємозв'язків логічної моделі системи, які не залежать від часу.
Діаграма класів складається з безлічі елементів, які в сукупності відображають декларативні знання про предметну область. Ці знання інтерпретуються в базових поняттях мови UML, таких як класи, інтерфейси і відношення між ними і їх компонентами, що становлять.
Клас
Клас (class) в мові UML служить для позначення безлічі об'єктів, які володіють однаковою структурою, поведінкою і відношеннями з об'єктами інших класів. Графічно клас зображається у вигляді прямокутника, який додатково може бути роздільний горизонтальними лініями на розділи або секції (рис 1). У цих розділах можуть вказуватися ім'я класу, атрибути (змінні) і операції (методи).
EMBED Visio.Drawing.6
Рис. 1. Графічне представлення класів на діаграмі класів
Ім'я класу
Ім'я класу повинне бути унікальним в межах діаграми класів. Воно вказується в першій верхній секції прямокутника. На додаток до загального правила найменування елементів мови UML, ім'я класу записується по центру секції імені напівжирним шрифтом і повинно починатися із великої букви. Рекомендується як імена класів використовувати іменники, записані по практичних міркуваннях без пропусків. Необхідно пам'ятати, що саме імена класів утворюють словник предметної області при ООА(П).
Прикладами імен класів можуть бути такі іменники, як "Співробітник", "Компанія", "Керівник", "Клієнт", "Продавець", "Менеджер", "Офіс" і багато інших, що мають безпосереднє відношення до модельованої предметної області і функціонального призначення проектованої системи.
Атрибути класу
У другій зверху секції прямокутника класу записуються його атрибути (attributes) або властивості. У мові UML прийнята певна стандартизація запису атрибутів класу, який підкоряється деяким синтаксичним правилам. Кожному атрибуту класу відповідає окремий рядок тексту, який складається з квантора видимості атрибуту, імені атрибуту, його кратності, типу значень атрибуту і, можливо, його початкового значення:
<квантор видимости><имя атрибута>[кратність]:
<тип атрибута> = <вихідне значення>{рядок-властивість}
Квантор видимості може приймати одне з трьох можливих значень і відображається за допомогою спеціальних символів:
Символ "+" позначає атрибут з областю видимості типу загальнодоступний (public). Атрибут з цією областю видимості доступний з будь-якого іншого класу пакету, в якому визначена діаграма.
Символ "#" позначає атрибут з областю видимості типу захищений (protected). Атрибут з цією областю видимості недоступний або невидний для всіх класів, за винятком підкласів даного класу.
Символ "-" позначає атрибут з областю видимості типу закритий (private). Атрибут з цією областю видимості недоступний або невидний для всіх класів без виключення.
Квантор видимості може бути опущений. В цьому випадку його відсутність просто означає, що видимість атрибуту не вказується. Проте замість умовних графічних позначень можна записувати відповідне ключове слово: public, protected, private.
Ім'я атрибуту є рядком тексту, який використовується як ідентифікатор відповідного атрибуту і тому повинна бути унікальною в межах даного класу. Ім'я атрибуту є єдиним обов'язковим елементом синтаксичного позначення атрибуту.
Кратність атрибуту характеризує загальну кількість конкретних атрибутів даного типу, що входять до складу окремого класу. У загальному випадку кратність записується у формі рядка тексту в квадратних дужках після імені відповідного атрибуту.
Як приклад розглянемо наступні варіанти кратності атрибутів.
[0..1] означає, що кратність атрибуту може приймати значення або 1. При цьому 0 означає відсутність значення для даного атрибуту.
[0..*] означає, що кратність атрибуту може приймати будь-яке позитивне ціле значення більше або рівніше 0. Ця кратність може бути записана коротше у вигляді простого символу - [*].
[1.:*] означає, що кратність атрибуту може приймати будь-яке позитивне ціле значення більше або рівніше 1.
Якщо ж кратність атрибуту не вказана, то позамовчуванню приймається її значення рівне 1..1, тобто в точності 1.
Операція
У третій зверху секції прямокутника записуються операції або методи класу. Операція (operation) це сервіс, що надає кожен екземпляр класу на певну вимогу. Сукупність операцій характеризує функціональний аспект поведінки класу. Кожній операції класу відповідає окремий рядок, який складається з квантора видимості операції, імені операції, виразу типу значення, що повертається операцією, і, можливо, рядок-властивість даної операції:
<квантор видимості><Ім’я операції>(список параметрів):
Квантор видимості, визначається за такими самими правилами як і в атрибутів класу, тобто, може приймати одне з трьох можливих значень.
Ім'я операції є рядком тексту, який використовується як ідентифікатор відповідної операції і тому повинна бути унікальною в межах даного класу. Ім'я операції є єдиним обов'язковим елементом синтаксичного позначення операції.
Поведінка операції може бути вказана додатково у формі приєднаної до операції примітки.
Відношення між класами
Окрім внутрішньої структури класів на діаграмі класів вказуються ще й різні відношення між класами. При цьому сукупність типів таких відношень фіксована в мові UML і зумовлена семантикою цих типів відношень. Базовими відношеннями або зв'язками в мові UML є:
Відношення залежності (dependency relationship)
Відношення асоціації (association relationship)
Відношення узагальнення (generalization relationship)
Кожне з цих відношень має власне графічне уявлення на діаграмі, яке відображає взаємозв'язки між об'єктами відповідних класів.
Відношення залежності
Відношення залежності в загальному випадку вказує деяке семантичне відношення між двома елементами моделі або безліччю таких елементів, яке не є відношенням асоціації, узагальнення або реалізації. Воно торкається тільки самих елементів моделі і не вимагає безлічі окремих прикладів для пояснення свого сенсу. Відношення залежності використовується в такій ситуації, коли зміна одного елементу моделі може зажадати зміни іншого залежного від нього елементу моделі.
Відношення залежності графічно зображається пунктирною лінією між відповідними елементами із стрілкою на одному з її кінців ("->" або "<-"). На діаграмі класів дане відношення зв'язує окремі класи між собою, при цьому стрілка направлена від класу-клієнта залежності до незалежного класу або класу-джерела (рис. 2.). На даному малюнку зображені два класи: Класс_А і Кяасс_Б, при цьому Клас_Б є джерелом деякої залежності, а Клас_А - клієнтом цієї залежності.
INCLUDEPICTURE "../Docy/Леоненков_%20Самоучитель%20UML%20Диаграмма%20классов%20(class%20diagram)_files/gl5-3.jpg" \* MERGEFORMAT
Рис.2. Графічне зображення відношення залежності на діаграмі класів
Як клас-клієнт і клас-джерело залежності може виступати ціла безліч елементів моделі. В цьому випадку одна лінія із стрілкою, що виходить від джерела залежності, розгалужується на декілька окремих ліній, кожна з яких має окрему стрілку для класу-клієнта. Наприклад, якщо функціонування Класа_С залежить від особливостей реалізації Класа_А і Клас_Б, то дана залежність може бути зображена так:
INCLUDEPICTURE "../Docy/Леоненков_%20Самоучитель%20UML%20Диаграмма%20классов%20(class%20diagram)_files/gl5-4.jpg" \* MERGEFORMAT
Рис.3. Графічне представлення залежності між класом-клієнтом (Клас_С) і класами-джерелами (Клас_А і Клас_Б)
Стрілка може позначатися необов'язковим, але стандартним ключовим словом в лапках і необов'язковим індивідуальним ім'ям.
Відношення залежності є найбільш загальною формою відношення в мові UML. Всі інші типи даних відношень можна вважати окремим випадком даного відношення. Проте важливість виділення специфічних семантичних властивостей і додаткових характеристик для інших типів відношень обумовлюють їх самостійний розгляд при побудові діаграм.
Відношення асоціації
Відношення асоціації відповідає наявності деякого відношення між класами. Дане відношення позначається суцільною лінією з додатковими спеціальними символами, які характеризують окремі властивості конкретної асоціації. Як додаткові спеціальні символи можуть використовуватися ім'я асоціації, а також імена і кратність класів-ролей асоціації. Ім'я асоціації є необов'язковим елементом її позначення. Якщо воно задане, то записується поряд з лінією відповідної асоціації.
Найбільш простий випадок даного відношення - бінарна асоціація. Вона зв'язує в точності два класи і, як виняток, може пов'язувати клас з самим собою. Для бінарної асоціації на діаграмі може бути вказаний порядок проходження класів з використанням трикутника у формі стрілки поряд з ім'ям даної асоціації. Напрям цієї стрілки вказує на порядок класів, один з яких є першим (з боку трикутника), а інший - другим (з боку вершини трикутника). Відсутність даної стрілки поряд з ім'ям асоціації означає, що порядок проходження класів в даному відношенні не визначений.
Як простий приклад відношення бінарної асоціації розглянемо відношення між двома класами - класом "Компанія" і класом "Співробітник" (рис.4.). Вони зв'язані між собою бінарною асоціацією. Робота, ім'я якої вказане на малюнку поряд з лінією асоціації. Для даного відношення визначений порядок проходження класів, першим з яких є клас "Співробітник", а другим - клас "Компанія".
EMBED Visio.Drawing.6
Рис.4. Графічне зображення відношення бінарної асоціації між класами
Кратність "1" для класу "Компанія" означає, що кожен співробітник може працювати тільки в одній компанії. Кратність "1..*" для класу "Співробітник" означає, що в кожній компанії можуть працювати декілька співробітників, загальне число яких наперед невідомо і нічим не обмежено.
Що стосується інших властивостей відношення, асоціації, то у разі їх наявності, вони можуть розглядатися як атрибути класу асоціації і можуть бути вказані на діаграмі звичайним для класу способом у відповідній секції прямокутника класу.
Спеціальною формою або окремим випадком відношення асоціації є відношення агрегації, яке, у свою чергу, теж має спеціальну форму - відношення композиції. Оскільки ці відношення мають свої спеціальні позначення і відносяться до базових понять мови UML, розглянемо їх окремо.
Відношення агрегації
Відношення агрегації має місце між декількома класами в тому випадку, якщо один з класів є деякою сутністю, що включає як складові частини іншу сутність.
Дане відношення має фундаментальне значення для опису структури складних систем, оскільки застосовується для представлення системних взаємозв'язків типу "частинка-ціле". Розкриваючи внутрішню структуру системи, відношення агрегації показує, з яких компонентів складається система і як вони зв'язані між собою. З погляду моделі окремі частини системи можуть виступати як у вигляді елементів, так і у вигляді підсистем, які, у свою чергу, теж можуть утворювати складені компоненти або підсистеми. Це відношення за своєю суттю описує декомпозицію або розбиття складної системи на простіші складові частини, які також можуть бути піддані декомпозиції, якщо в цьому виникне необхідність в подальшому.
Очевидно, що ділення системи, що розглядається в такому аспекті, на складові частини є деякою ієрархією її компонентів, проте дана ієрархія принципово відрізняється від ієрархії, що породжується відношенням узагальнення. Відмінність полягає в тому, що частини системи ніяк не зобов'язані успадковувати її властивості і поведінку, оскільки є цілком самостійною суттю. Більше того, частини цілого володіють своїми власними атрибутами і операціями, які істотно відрізняються від атрибутів і операцій цілого.
Як приклад відношення агрегації розглянемо взаємозв'язок типу "частина-цілого", між сутностями "Вантажний автомобіль" і такими компонентами, як "Двигун", "Шасі", "Кабіна", "Кузов". Неважко уявити собі, що вантажний автомобіль складається з двигуна, шасі, кабіни і кузова. Саме це відношення між класом "Грузовой_автомобиль" і класами "Двигун", "Шасі", "Кабіна", "Кузов" описує відношення агрегації.
Графічно відношення агрегації зображається суцільною лінією, один з кінців якої є незакрашеним всередині ромбом. Цей ромб указує на той з класів, який є "цілим". Решта класів є його "частинами" (Рис.6.).
EMBED Visio.Drawing.6
Рис.5. Графічне зображення відношення агрегації у мові UML
Ще одним прикладом відношення агрегації може служити відоме кожному з читачів розділення персонального комп'ютера на складові частини: системний блок, монітор, клавіатуру і мишу. Використовуючи позначення мови UML, компонентний склад ПК можна представити у вигляді відповідної діаграми класів (рис.6.), яка в даному випадку ілюструє відношення агрегації.
EMBED Visio.Drawing.6
Мал.6. Діаграма класів для ілюстрації відношення агрегації на прикладі ПК
Відношення композиції
Відношення композиції, як вже згадувалося раніше, є окремим випадком відношення агрегації. Це відношення служить для виділення спеціальної форми відношення "частина-цілого", при якому складники знаходяться всередині цілого. Специфіка взаємозв'язку між ними полягає в тому, що частини не можуть виступати окремо від цілого, тобто із знищенням цілого знищуються і всі його складові частини.
Приклад - вікно графічного інтерфейсу програми, яке складається з рядка заголовка, кнопок управління розміром, смуг прокрутки, головного меню, робочої області і рядка стану. В даному випадку вікно є класом, а його компоненти є як класами, так і атрибутами або властивостями вікна. Остання обставина вельми характерна для відношення композиції, оскільки відображає різні способи представлення даного відношення.
Графічно відношення композиції зображається суцільною лінією, один з кінців якої є закрашеним всередині ромбом. Цей ромб вказує на той з класів, який є класом-композицією або "ціле". Решта класів є його "частинами" (рис.7.).
EMBED Visio.Drawing.6
Рис.7. Графічне зображення відношення композиції в мові UML
Як додаткові позначення для відношень композиції і агрегації можуть використовуватися додаткові позначення, вживані для відношення асоціації. А саме, вказівка кратності класу асоціації і імені даної асоціації, які не є обов'язковими. Стосовно описаного вище прикладу класу "Вікно програми" його діаграма класів може мати наступний вигляд (рис.8.).
EMBED Visio.Drawing.6
Рис.8. Діаграма класів для ілюстрації відношення композиції на прикладі класу вікна програми
Даний приклад може ілюструвати і інші особливості комп'ютерної програми, що розробляється, які не вказувалися в явному вигляді при описі цього прикладу Так, зокрема, вказівка кратності 1 поряд з класом "Робоча Область" характерний для однодокументних застосувань.
Відношення узагальнення
Відношення узагальнення є звичайним відношенням між більш загальним елементом (батьком або предком) і більш приватним або спеціальним елементом (дочірним або нащадком). Дане відношення може використовуватися для представлення взаємозв'язків між пакетами, класами, варіантами використання і іншими елементами мови UML.
На діаграмі класів дане відношення описує ієрархічну будову класів і спадкоємство їх властивостей і поведінки. При цьому передбачається, що клас-нащадок володіє всіма властивостями і поведінкою класу-предка, а також має свої власні властивості і поведінку, які відсутні у класу-предка. На діаграмах відношення узагальнення позначається суцільною лінією з трикутною стрілкою на одному з кінців (рис.9.). Стрілка указує на більш загальний клас (клас-предок або суперклас), а її відсутність - на більш спеціальний клас (клас-нащадок або підклас).
EMBED Visio.Drawing.6 INCLUDEPICTURE "../Docy/Леоненков_%20Самоучитель%20UML%20Диаграмма%20классов%20(class%20diagram)_files/gl5-12.jpg" \* MERGEFORMAT
Рис.9. Графічне зображення відношення узагальнення в мові UML
Наприклад, клас Геометрична_фігура виступає як суперклас для підкласів, відповідних конкретних геометричних фігур, таких як, Прямокутник, Коло, Еліпс і ін. Даний факт може бути представлений графічно у формі діаграми класів наступного вигляду (рис.10.)
EMBED Visio.Drawing.6
Рис.10. Приклад графічного зображення відношення узагальнення класів
Поряд із стрілкою узагальнення може розміщуватися рядок тексту, вказуючий на деякі додаткові властивості цього відношення. Даний текст відноситиметься до всіх ліній узагальнення, які йдуть до класів-нащадків. Іншими словами, відмічена властивість торкається всіх підкласів даного відношення. При цьому текст слід розглядати як обмеження, і тоді він записується у фігурних дужках.
Приклад діаграми класів
EMBED Visio.Drawing.6
Рис.11 Приклад діаграми класів
Завдання для індивідуального виконання
Розробити діаграму класів, для своєї індивідуальної системи.