Тема 7. Діаграми класів і об'єктів
Центральне місце в ООАП займає розробка логічної моделі системи в виді діаграми класів. Нотація класів в мові UML проста і інтуїтивно зрозуміла всім, хто коли-не-будь мав досвід роботи з CASE-інструментаріями. Подібна нотація застосовується і для об'єктів - екземплярів класу, з тією різницею, що до імені класу додається ім'я об'єкту і весь напис підкреслюється.
Діаграма класів служить для представлення статичної структури моделі системи в термінології класів об'єктно-орієнтованого програмування. Діаграма класів може зображати, зокрема, різні взаємозв'язки між окремими сутностями предметної області, такими як об'єкти і підсистеми, а також описує їх внутрішню структуру і типи відношень. На даній діаграмі не вказується інформація про часові аспекти функціонування системи. З цієї точки зору діаграма класів є подальшим розвитком концептуальної моделі проектованої системи.
Діаграма класів представляє собою деякий граф, вершинами якого є елементи типу «класифікатор», які зв'язані різними типами структурних відношень. Варто зауважити, що діаграма класів може також містити інтерфейси, пакети, відношення і навіть окремі екземпляри, такі як об'єкти і зв'язки. Коли говорять про дану діаграму, мають на увазі статичну структурну модель проектованої системи. Тому діаграму класів прийнято вважати графічним представленням таких структурних взаємозв'язків логічної моделі системи, які не залежать від часу.
Діаграма класів складається з множини елементів, які в сукупності зображають декларативні знання про предметну область. Ці знання інтерпретуються в базових поняттях мови UML, таких як класи, інтерфейси і відношення між ними і їх складовими компонентами. При цьому окремі компоненти цієї діаграми можуть утворювати пакети для представлення більш загальної моделі системи. Якщо діаграма класів є частиною деякого пакету, то її компоненти повинні відповідати елементам цього пакету.
У загальному випадку пакет статичної структурної моделі може бути представлено у виді однієї або декількох діаграм класів. Декомпозиція деякого представлення на окремі діаграми виконується для зручності і графічної візуалізації структурних взаємозв'язків предметної області. При цьому компоненти діаграми відповідають елементам статичної семантичної моделі. Модель системи, у свою чергу, повинна бути узгоджена з внутрішньою структурою класів, яка описується мовою UML.
Клас у мові UML використовується для позначення множини об'єктів, які мають однакову структуру, поведінку і відносини з об'єктами з інших класів. Графічно клас зображається у виді прямокутника, який додатково може бути поділений горизонтальними лініями на секції. У цих секціях можуть вказуватися ім'я класу, атрибути (змінні) і операції (методи).
Обов'язковим елементом позначення класу є його ім'я. На початкових етапах розробки діаграми окремі класи можуть позначатися простим прямокутником з зазначенням тільки імені відповідного класу. У процесі розробки окремих компонентів діаграми описи класів доповнюються атрибутами і операціями. Передбачається, що кінцевий варіант діаграми містить найбільш повний опис класів, який складається з трьох секцій. Іноді в позначеннях класів використовується додаткова четверта секція, в якій приводиться семантична інформація довідкового характеру або явно вказуються виняткові ситуації. Навіть якщо секція атрибутів і операцій пусті, в позначенні класу вони виділяються горизонтальною лінією, щоб відразу відрізнити клас від інших елементів мови UML.
Ім'я класу повинне бути унікальним в межах пакету, який описується деякою сукупністю діаграм класів. Воно вказується в першій верхній секції прямокутника. Ім'я класу записується по центру секції імені жирним шрифтом і повинно починатися з великої букви. Рекомендується як імена класів використовувати іменники, які записуються без прогалин. Саме імена класів утворюють словник предметної області при ООАП. Крім імені при позначенні класу, можуть бути посилання на стандартні шаблони або абстрактні класи, від яких утворений даний клас і, відповідно, від яких він успадковує властивості і методи. Клас може не мати екземплярів або об'єктів. У цьому випадку він називається абстрактним класом, а для позначення його імені використовується курсив.
У другій зверху секції прямокутника класу записуються його атрибути або властивості. Кожному атрибуту класу відповідає окрема стрічка тексту, яка складається з квантора видимості атрибуту, імені атрибуту, його кратності, типу значень атрибуту і, можливо, його початкового значення.
Квантор видимості може приймати одне з трьох можливих значень і, відповідно, зображається за допомогою спеціальних символів:
- Символ "+" позначає атрибут з областю видимості типу загальнодоступний (public). Такий атрибут доступний або видний із будь- якого іншого класу пакету, в якому визначена діаграма.
- Символ "#" позначає атрибут з областю видимості типу захищений (protected). Такий атрибут недоступний або невидимий для всіх класів, за винятком підкласів даного класу.
- Символ "-" позначає атрибут з областю видимості типу закритий (private). Такий атрибут недоступний або невидимий для всіх класів без винятку.
Квантор видимості може бути пропущений, що просто означає, що видимість атрибуту не вказується.
Ім'я атрибуту представляє собою стрічку тексту, яка використовується як ідентифікатор відповідного атрибуту і тому повинна бути унікальною в межах даного класу. Ім'я атрибуту є єдиним обов'язковим елементом синтаксичного позначення атрибуту.
Кратність атрибуту характеризує загальну кількість конкретних атрибутів даного типу, які входять до складу окремого класу. В загальному випадку кратність записується в формі стрічки тексту в квадратних дужках після імені відповідного атрибуту.
Тип атрибуту представляє собою вираз. В нотації UML він іноді визначається в залежності від мови програмування, яку передбачається використовувати для реалізації даної моделі. У найпростішому випадку тип атрибуту вказується стрічкою тексту, яка має змістовне значення в межах пакету або моделі.
Початкове значення використовується для завдання деякого початкового значення для відповідного атрибуту в момент створення окремого екземпляру класу.
При завданні атрибутів можуть використовуватися дві додаткові синтаксичні конструкції - це підкреслення стрічки атрибуту і пояснювальний текст в фігурних дужках. Підкреслення стрічки атрибуту означає, що відповідний атрибут може приймати підмножину значень з деякої області значень атрибуту, яка визначена його типом. Ці значення можна розглядати як набір однотипних записів або масив, які в сукупності характеризують кожен об'єкт класу. Стрічка-властивість використовується для вказівки значень атрибуту, які не можуть бути змінені в програмі при роботі з даним типом об'єктів. Фігурні дужки позначають фіксоване значення відповідного атрибуту для класу в цілому, яке повинні приймати всі знову створювані екземпляри класу без винятків. Це значення приймається за початкове значення атрибуту, яке не може бути перевизначене в майбутньому.
У третій зверху секції прямокутника записуються операції або методи класу. Операція (operation) представляє собою деякий сервіс, який надає кожен екземпляр класу на певну вимогу. Сукупність операцій характеризує функціональний аспект поведінки класу. Кожній операції класу відповідає окрема стрічка, яка складається з квантора видимості операції, імені операції, виразу типу поверненого операцією значення і, можливо, стрічка-властивість даної операції.
Квантор видимості, як і у випадку атрибутів класу, може приймати одне з трьох можливих значень і, відповідно, зображається за допомогою спеціального символу.
Ім'я операції представляє собою стрічку тексту, яка використовується як ідентифікатор відповідної операції і тому повинна бути унікальною в межах даного класу. Ім'я атрибуту є єдиним обов'язковим елементом синтаксичного позначення операції.
Список параметрів є переліком розділених комами формальних параметрів.
Вираз типу поверненого значення також є залежною від мови реалізації специфікації типу або типів значень параметрів, які повертаються об'єктом після виконання відповідної операції. Вираз типу може бути пропущений, якщо операція не повертає жодного значення.
Стрічка-властивість використовується для вказівки значень властивостей, які можуть бути застосовані до даного елемента.
Операція з областю дії на весь клас показується підкресленням імені і стрічки виразу типу. За замовчуванням під областю операції розуміють об'єкт класу. У цьому випадку ім'я і стрічка виразу типу операції не підкреслюються.
Операція, яка не може змінити стан системи і, відповідно, не має жодного побічного ефекту, позначається стрічкою-властивістю «{запит}» («{query}»). В осоружному випадку операція може змінювати стан системи, хоча немає жодних гарантій, що вона буде це робити.
Для підвищення продуктивності системи одні операції можуть виконуватися паралельно або одночасно, а інші - тільки послідовно. У цьому випадку для вказівки паралельності виконання операції використовується стрічка-властивість виду «{concurrency = ім'я}», де ім'я може приймати одне з наступних значень: послідовна (sequential), паралельна (concurrent), збережена (guarded).
Список формальних параметрів і тип значення можуть не вказуватися. Квантор видимості атрибутів і операцій може бути вказаний у виді спеціального символу. Імена операцій, так як і атрибутів, записуються з малої букви, а їх типи - з великої букви. При цьому обов'язковою частиною стрічки запису операції є наявність імені операції і круглих дужок.
Крім внутрішньої будови або структури класів на відповідній діаграмі вказуються різні відношення між класами. При цьому сукупність типів таких відношень фіксована в мові UML. Базовими відношеннями або зв'язками є:
- Відношення залежності;
- Відношення асоціації;
- Відношення узагальнення;
- Відношення реалізації.
Кожне з цих відношень має власне графічне представлення на діаграмі, яке відображає взаємозв'язки між об'єктами відповідних класів.
Відношення залежності в загальному випадку вказує деяке семантичне відношення між двома елементами моделі або двома множинами таких елементів, яке не є відношенням асоціації, узагальнення або реалізації. Воно стосується тільки самих елементів моделі і не потребує множини окремих прикладів для пояснення свого змісту. Відношення залежності використовується в такій ситуації, коли деяка зміна одного елемента моделі може потребувати зміну іншого залежного від неї елемента моделі.
Відношення залежності графічно зображається пунктирною лінією між відповідними елементами зі стрілкою на одному з її кінців. На діаграмі класів дане відношення зв'язує окремі класи між собою, при цьому стрілка направлена від класу-клієнта залежності до незалежного класу або класу-джерелу.
В якості класу-клієнта і класу-джерела залежності можуть виступати цілі множини елементів моделі. У цьому випадку одна лінія зі стрілкою, що виходить від джерела залежності, розщеплюється в деякій точці на декілька окремих ліній, кожна з яких має окрему стрілку для класу-клієнта.
Стрілка може помічатися необов'язковим, але стандартним ключовим словом в лапках і необов'язковим індивідуальним іменем. Для відношення залежності визначені ключові слова, які позначають деякі спеціальні види залежностей. Ці ключові слова (стереотипи) записуються в лапках поруч зі стрілкою, яка відповідає даній залежності. Прикладами стереотипів для відношення залежності можуть бути:
- «access» - служить для позначення доступності відкритих атрибутів і операцій класу-джерела для класів-клієнтів;
- «bind» - клас-клієнт може використовувати деякий шаблон для своєї наступної параметризації;
- «derive» - атрибути класу-клієнта можуть бути обчислені за атрибутам класу-джерела;
- «import» - відкриті атрибути і операції класу-джерела стають частиною класу-клієнта, так як би вони були оголошені безпосередньо в ньому;
- «refine» - вказує, що клас-клієнт служить уточненням класу-джерела з історичних причин, коли з'являється додаткова інформація в ході роботи над проектом.
Відношення асоціації відповідає наявності деякого відношення між класами. Дане відношення позначається суцільною лінією з додатковими спеціальними символами, які характеризують окремі властивості конкретної асоціації. Як додаткові спеціальні символи можуть використовуватися ім'я асоціації, а також імена і кратність класів-ролей асоціації. Ім'я асоціації є необов'язковим елементом її позначення. Якщо воно задане, то записується з великої букви поруч з лінією відповідної асоціації.
Найбільш простий випадок даного відношення - бінарна асоціація. Вона зв'язує точно два класи і, як виняток, може зв'язувати клас з самим собою. Для бінарною асоціації на діаграмі може бути вказано порядок слідування класів з використанням трикутника в формі стрілки поруч імені даної асоціації. Напрямок цієї стрілки вказує на порядок класів, один із яких є першим (зі сторони трикутника), а інший - другим (зі сторони вершини трикутника). Відсутність даної стрілки поруч з іменем асоціації означає, що порядок слідування класів у цьому відношенні не визначений.
Тернарна асоціація і асоціації більш високої арності в загальному випадку називаються N-арною асоціацією. Така асоціація зв'язує деяким відношенням 3 і більше класів, при цьому один клас може брати участь в асоціації більше ніж один раз. Клас асоціації має певну роль у відповідному відношенні, що може бути явно вказано на діаграмі. Кожен екземпляр N-арної асоціації представляє собою N-арний кортеж значень об'єктів із відповідних класів. Бінарна асоціація є частковим випадком N-арної асоціації, коли N=2, і має своє власне позначення.
N-арна асоціація графічно позначається ромбом, від якого ведуть лінії до символів класів даної асоціації. У цьому випадку ромб з'єднується з символами відповідних класів суцільними лініями.
Порядок класів в N-арній асоціації, на відміну від порядку множин у відношенні, на діаграмі не фіксується. Деякий клас може бути приєднаний до ромба пунктирною лінією. Це означає, що даний клас забезпечує підтримку властивостей відповідної N-арної асоціації, а сама N-арна асоціація має атрибути, операції і/або асоціації. Іншими словами, така асоціація, у свою чергу, є класом з відповідним позначенням у виді прямокутника і є самостійним елементом мови UML - асоціацією-класом (Association Class).
Окремий клас асоціації має власну роль у відношенні. Ця роль може бути зображена графічно на діаграмі класів. Для цієї мети у мові UML вводиться спеціальний елемент - кінець асоціації (Association End), який графічно відповідає точці з'єднання лінії асоціації з окремим класом. Кінець асоціації є частиною асоціації, але не класу. Кожна асоціація має два або більше кінців асоціації. Найбільш важливі властивості асоціації вказуються на діаграмі поруч з цими елементами асоціації.
Одним із таких додаткових позначень є ім'я ролі окремого класу, який входить в асоціацію. Ім'я ролі представляє собою стрічку тексту поруч з кінцем асоціації для відповідного класу. Вона вказує специфічну роль, яку відіграє клас, який є кінцем асоціації. Ім'я ролі не є обов'язковим елементом позначень.
Наступний елемент позначень - кратність окремих класів, які є кінцями асоціації. Кратність окремого класу позначається у виді інтервалу цілих чисел, аналогічно кратності атрибутів і операцій класів. Інтервал записується поруч з кінцем асоціації і для N-арної асоціації означає потенційне число окремих екземплярів або значень кортежів цієї асоціації, які можуть мати місце, коли інші N-1 екземплярів або значень класів фіксовані.
Частковим випадком відношення асоціації є так звана виключна асоціація (Xor-association). Семантика даної асоціації вказує на той факт, що із декількох потенційно можливих варіантів даної асоціації в кожен момент часу може використовуватися тільки один її екземпляр. На діаграмі класів виключна асоціація зображається пунктирною лінією, яка з'єднує дві і більше асоціації, поруч з якою записується стрічка-обмеження «{хог}».
Спеціальною формою або частковим випадком відношення асоціації є відношення агрегації, яке, в свою чергу, також має спеціальну форму - відношення композиції.
Відношення агрегації може бути між декількома класами у тому випадку, якщо один із класів представляє собою деяку сутність, що включає в себе як складові частини інші сутності.
Дане відношення має фундаментальне значення для опису структури складних систем, оскільки застосовується для представлення системних взаємозв'язків типу «частина-ціле». Розкриваючи внутрішню структуру системи, відношення агрегації показує, з яких компонентів складається система і як вони зв'язані між собою. З точки зору моделі окремі частини системи можуть виступати як в виді елементів, так і в виді підсистем, які, в свою чергу, також можуть утворювати складові компоненти або підсистеми. Це відношення за своєю суттю описує декомпозицію або поділ складної системи на більш прості складові частини, які також можуть бути поділені, якщо у цьому виникне необхідність.
Розглянутий поділ системи на складові частини представляє собою деяку ієрархію її компонентів, проте дана ієрархія принципово відрізняється від ієрархії, яка породжується відношенням узагальнення. Відмінність полягає у тому, що частини системи ніяк не зобов'язані успадковувати її властивості і поведінку, оскільки є самостійними сутностями. Більше того, частини цілого мають свої власні атрибути і операції, які суттєво відрізняються від атрибутів і операцій цілого.
Графічно відношення агрегації зображається суцільною лінією, один із кінців якої представляє собою не замальований ромб. Цей ромб вказує на той з класів, який представляє собою «ціле». Інші класи є його «частинами».
Відношення композиції є частковим випадком відношення агрегації. Це відношення використовується для виділення спеціальної форми відношення «частина-ціле», при якому складові частини в деякому змісті знаходяться в середині цілого. Специфіка взаємозв'язків між ними полягає у тому, що частини не можуть виступати у відриві від цілого, тобто зі знищенням цілого знищуються і всі його складові частини.
Графічно відношення композиції зображається суцільною лінією, один із кінців якої представляє собою закрашений ромб. Цей ромб вказує на той з класів, який представляє собою клас-композицію або «ціле». Інші класи є його «частинами».
Як додаткові позначення для відношення композиції і агрегації можуть використовуватися додаткові позначення, які застосовуються для відношення асоціації. А саме, вказівка кратності класу асоціації і імені даної асоціації, які не є обов'язковими.
Відношення узагальнення є звичайним таксономічним відношенням між більш загальним елементом (батьком або предком) і більш частковим або спеціальним елементом (дочірнім або нащадком). Дане відношення може використовуватися для представлення взаємозв'язків між пакетами, класами, варіантами використання і іншими елементами мови имь.
Стосовно до діаграм класів дане відношення описує ієрархічну будову класів і успадкування їх властивостей і поведінки. При цьому передбачається, що клас-нащадок має всі властивості і поведінку класу-предка, а також має свої власні властивості і поведінку, які відсутні в класу-предка. На діаграмах відношення узагальнення позначається суцільною лінією з трикутною стрілкою на одному з кінців. Стрілка вказує на більш загальний клас (клас-предок або суперклас), а її відсутність - на більш спеціальний клас (клас-нащадок або підклас).
Як правило, на діаграмі може вказуватися декілька ліній для одного відношення узагальнення, що зображає його таксономічний характер. У цьому випадку більш загальний клас поділяється на підкласи одним відношенням узагальнення.
З метою спрощення позначень на діаграмі класів сукупність ліній, які позначають одне й те ж відношення узагальнення, може об'єднуватися в одну лінію. У цьому випадку дані окремі лінії зображаються такими, що сходяться до єдиної стрілки.
Поруч з стрілкою узагальнення може розміщуватися стрічка тексту, яка вказує на деяку додаткову властивість цього відношення. Даний текст буде відноситися до всіх ліній узагальнення, які йдуть до класів-нащадків. Іншими словами, відмічена властивість стосується всіх підкласів даного відношення. При цьому текст потрібно розглядати як обмеження, і тоді він записується в фігурних дужках.
Інтерфейси є елементами діаграми варіантів використання. Проте при побудові діаграми класів окремі інтерфейси можуть уточнюватися і у цьому випадку для їх зображення використовується спеціальний графічний символ - прямокутник класу з ключовим словом або стереотипом «interface». При цьому секція атрибутів у прямокутника відсутня, а вказується тільки секція операцій.
Об'єкт (object) є окремим екземпляром класу, який створюється на етапі виконання програми. Він має своє власне ім'я і конкретні значення атрибутів. Через різні причини може виникнути необхідність показати взаємозв'язок не тільки між класами моделі, але й між окремими об'єктами, які реалізують ці класи. У даному випадку може бути розроблена діаграма об'єктів, яка, хоча й не є канонічною, але має самостійне призначення.
Для графічного зображення об'єктів використовується такий же символ прямокутника, що й для класів. Відмінності проявляються при вказівці імені об'єктів, які у випадку об'єктів обов'язково підкреслюються. При цьому запис імені об'єкту представляє собою стрічку тексту «ім'я об'єкту:ім'я класу», розділену двокрапкою. Ім'я об'єкту може бути відсутнє, у цьому випадку передбачається, що об'єкт є анонімним, і двокрапка вказує на дану обставину. Може бути відсутнє й ім'я класу. Тоді вказується просто ім'я об'єкту.
При зображенні діаграми об'єктів потрібно пам'ятати, що кожен об'єкт представляє собою екземпляр відповідного класу, а відношення між об'єктами описуються за допомогою зв'язків, які є екземплярами відповідних відношень. При цьому всі зв'язки зображаються суцільними лініями.
Шаблони або параметризовані класи
Шаблон (template) або параметризований клас (parametrized class) призначений для позначення такого класу, який має один (або більше) не фіксованих формальних параметрів. Він визначає цілу сім'ю або множину класів, кожен із яких може бути отриманий зв'язуванням цих параметрів з дійсними значеннями. Часто параметрами шаблонів виступають типи атрибутів класів.
Графічно шаблон зображається прямокутником, до верхнього правого кута якого приєднаний маленький прямокутник із пунктирних ліній, більшого прямокутника.
Шаблон не може бути безпосередньо використаний як клас, оскільки містить невизначені параметри. Часто як шаблон виступає деякий суперклас, параметри якого уточнюються в його класах-нащадках. Очевидно, в цьому випадку між ними існує відношення залежності, коли клас-клієнт може використовувати деякий шаблон для своєї наступної параметризації. У більш частковому випадку між шаблоном і формованим від нього класом має місце відношення узагальнення з успадкуванням властивостей шаблону.
Рекомендації до побудові діаграм класів
Процес розробки діаграми класів займає центральне місце в ООАП складних систем. Від уміння правильно вибрати класи і встановити між ними зв'язки часто залежить не тільки успіх процесу проектування, але й продуктивність виконання програми. Як показує практика ООП, кожен програміст в своїй роботі старається в тій чи іншій мірі використати вже накопичений особистий досвід при розробці нових проектів. Це обумовлено бажанням звести нову задачу до вже вирішених, щоб мати можливість використовувати не тільки перевірені фрагменти програмного коду, але й окремі компоненти в цілому (бібліотеки компонентів).
Такий стереотипний підхід дозволяє суттєво скоротити терміни реалізації проекту, проте допустимий лише у тому випадку, тоді новий проект концептуально і технологічно не дуже відрізняється від попередніх. В осоружному випадку платою за скорочення термінів проекту може стати його реалізація на застарілій технологічній базі. Що стосується власне об'єктної структуризації предметної області, то тут доцільно дотримуватися тих рекомендацій, які накопичені в ООП.
При визначенні класів, атрибутів і операцій і завданні їх імен і типів перед вітчизняними розробниками завжди постає питання: яку з мов використовувати як природну, українську чи англійську? З одного боку, використання рідної мови для опису моделі є найбільш природнім способом її представлення і в найбільшій мірі зображає комунікативну функцію моделі системи. З іншої сторони, розробка моделі є лише одним із етапів розробки відповідної системи, а застосування інструментальних засобів для її реалізації в абсолютній більшості випадків потребує використання англомовних термінів.
При побудові діаграми варіантів використання, яка є найбільш загальною концептуальною моделлю проектованої системи, застосування україномовних термінів є не тільки виправданим з точки зору опису структури предметної області, але й ефективним з точки зору комунікативної взаємодії з замовником і користувачами. При побудові інших типів діаграм потрібно дотримуватися розумного компромісу.
Зокрема, на початкових етапах розробки діаграм доцільність використання україномовних термінів очевидна і виправдана. Проте, в міру готовності графічної моделі для реалізації в виді програмної системи і передачі її для подальшої роботи програмістам, акцент може зміщуватися в сторону використання англомовних термінів, які в тій чи іншій мірі зображають особливості мови програмування, на якій передбачається реалізація моделі.
Більше того, використання САБЕ-інструментів для автоматизації ООАП, часто накладають свої власні вимоги на мову специфікації моделей. Саме через цю причину більшість прикладів в літературі даються в англомовному представленні, а при їх перекладі на українську може бути втрачена не тільки точність формулювань, але й семантика відповідних понять.
Після розробки діаграми класів процес ООАП може бути продовжений в двох напрямках. З одного боку, якщо поведінка системи тривіальна, то можна приступити до розробки діаграм кооперації і компонентів. Проте для складних динамічних систем поведінка представляє важливий аспект їх функціонування. Деталізація поведінки здійснюється послідовно при розробці діаграм станів, послідовності і діяльності.