PrIS

411

Рис. 19.9. Діаграма класів для ілюстрації відношення аґреґації на прикладі ПК.

19.2.4. Відношення композиції

Відношення композиції, як уже згадувалося раніше, є окремим випадком відношення аґреґації. Це відношення служить для виділення спеціальної форми відношення «частина-ціле», при якій складники в деякому розумінні мчстяться всередині цілого. Специфіка взаємозв'язку між ними полягає в тому, що частини не можуть виступати у відриві від цілого, тобто зі знищенням цілого знищуються і всі його складові частини.

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

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

Рис. 19.10. Графічне зображення відношення композиції в мові UML.

Як додаткові позначення для відношень композиції і аґреґації можуть використовуватися додаткові позначення, які використовуються для відношення асоціації, а саме: вказання кратності класу асоціації й імені цієї асоціації, які не є обов'язковими. Стосовно описаного вище

412

прикладу класу "Вікно_програми" його діаграма класів може мати вигляд як на рис. 19.11.

Рис. 19.11. Діаграма класів для ілюстрації відношення композиції на прикладі класу вікна програми.

Цей приклад може ілюструвати й інші особливості комп'ютерної програми, що розробляється, які не вказувалися в явному вигляді під час описування цього прикладу Так, зокрема, вказання кратності 1 поряд із класом "Робоча_область" характерне для однодокументного застосування.

19.2.5. Відношення узагальнення

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

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

Рис. 19.12. Графічне зображення відношення узагальнення в мові UML.

Як правило, на діаграмі може вказуватися декілька ліній для одного відношення узагальнення, що відображає його таксономічний характер. У

413

цьому випадку загальніший клас розбивається на підкласи одним відношенням узагальнення. Наприклад, клас Геометрична_фіґура_на_площині (курсив позначає абстрактний клас) може виступати як суперклас для підкласів, що відповідають конкретним геометричним фіґурам, таким як Прямокутник, Коло, Еліпс і ін. Цей факт може зображатися графічно у формі діаграми класів такого вигляду як на рис. 19.13.

Рис. 19.13. Приклад графічного зображення відношення узагальнення класів.

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

Рис. 19.14. Варіант графічного зображення відношення узагальнення класів для випадку об'єднання окремих ліній.

Це позначення відповідає графові спеціального вигляду, який розглядався в розділі 4, а саме – ієрархічному дереву. У цьому випадку клас-предок є коренем цього дерева, а класи-нащадки – його листям. Відмінність полягає в можливості вказання на діаграмі класів потенційної можливості наявності інших класів-нащадків, які не включені в

415

Рис. 19.15. Варіант графічного зображення відношення узагальнення класів з використанням рядка-обмеження.

Щоб проілюструвати особливості використання відношення узагальнення, перетворимо один з розглянутих раніше прикладів зображення класів у графічну нотацію мови UML. В якості такого прикладу розглянемо ієрархію вкладеності класів для абстрактного класу "Автомобіль" (див. рис. 3.2, 4.7). Відношення між окремими класами на цих рисунках є саме відношенням узагальнення, яке в мові UML має спеціальне графічне позначення. Із врахуванням цієї графічної нотації, фрагмент семантичної мережі для зображення ієрархії класу "Автомобіль" (див. рис. 4.7) може подаватися у вигляді діаграми класів, наведеної на рис. 19.16.

Рис. 19.16. Фраґмент діаграми класів з відношенням узагальнення для подання ієрархії класів "Автомобіль" з розглянутого раніше прикладу

(див. рис. 4.7).

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

416

виступають виготовлені автомобілі відповідної моделі з унікальним заводським номером.

Примітка

Як вправу для закріплення розглянутого матеріалу можна спробувати побудувати діаграму класів для бібліотек стандартних класів MFC (Microsoft) і VCL (Borland/Inprise) з використанням графічної нотації мови UML.

19.3. Інтерфейси

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

Рис. 19.17. Приклад графічного зображення інтерфейсу на діаграмі класів.

19.4. Об'єкти

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

Для графічного зображення об'єктів використовується такий самий символ прямокутника, як і для класів. Відмінності виявляються під час вказання імен об'єктів, які для об'єктів обов'язково підкреслюють (рис. 19.18). При цьому запис імені об'єкту є рядком тексту "ім'я об’єкту: ім’я класу", розділений двокрапкою (рис. 19.18 а, б). Ім'я об'єкту може бути відсутнім, у цьому випадку передбачається, що об'єкт є анонімним, і

417

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

Рис. 19.18. Приклад графічного зображення об'єктів на діаграмах мови

UML.

Під час реалізації діаграми об'єктів треба пам'ятати, що кожним об'єктом є екземпляр відповідного класу, а відношення між об'єктами описуються за допомогою зв'язків (links), які є екземплярами відповідних відношень. При цьому всі зв'язки зображаються суцільними лініями. Детальніше особливості зображення об'єктів будуть розглянуті в розділі 23 під час вивчення діаграм кооперації.

19.5. Шаблони або параметризовані класи

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

Графічно шаблон зображається прямокутником, до верхнього правого кута якого приєднаний маленький прямокутник з пунктирних

418

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

Рис. 19.19. Графічне зображення шаблону на діаграмі класів.

Шаблон не може бути безпосередньо використаний як клас, оскільки містить невизначені параметри. Найчастіше як шаблон виступає деякий суперклас, параметри якого уточнюються в його класах-нащадках. Очевидно, у цьому випадку між ними існує відношення залежності з ключовим словом "bind", коли клас-клієнт може використовувати деякий шаблон для своєї подальшої параметризації. У частковому випадку між шаблоном і формованим від нього класом має місце відношення узагальнення з успадкуванням властивостей шаблону (рис. 19.20). У цьому прикладі відзначений той факт, що клас "Адреса" може бути отриманий із шаблону Зв’язний_список на основі актуалізації формальних параметрів "S, до, l" фактичними атрибутами "вулиця, будинок, квартира".

S:String

k,l:integer

Зв’язковий список

“bind”<вулиця, будинок, квартира>

Адреса

Попередній елемент Наступний елемент

Рис. 19.20. Приклад використання шаблону на діаграмі класів.

Цей самий шаблон може використовуватися для задання іншого класу, наприклад, для класу "Точка_на_площині". У цьому випадку клас "Точка_на_площині" актуалізує ті самі формальні параметри, але з іншими значеннями, наприклад, <координати_точки, х, у>. Концепція

419

шаблонів є достатньо потужнім засобом в ООП, і тому її використання в мові UML дозволяє не тільки скоротити розміри діаграм, але й найкоректніше керувати успадкуванням властивостей і поведінкою окремих елементів моделі.

19.6. Рекомендації з побудови діаграми класів

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

Такий стереотипний підхід дозволяє істотно скоротити терміни реалізації проекту, проте він прийнятний лише у тому випадку, коли новий проект концептуально і технологічно не дуже відрізняється від попередніх. Інакше розплатою за скорочення термінів проекту може стати його реалізація на застарілій технологічній базі. Що стосується власної об'єктної структуризації предметної області, то тут доречно дотримуватися тих рекомендацій, які накопичені в ООП.

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

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

420

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

І що більше, використання CASE-інструментів для автоматизації ООАП найчастіше накладає свої власні вимоги на мову специфікації моделей. Саме з цієї причини більшість прикладів в літературі даються в англомовному варіанті, а при їх перекладі на українську мову може бути втрачена не тільки точність формулювань, але й семантика відповідних понять.

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

Контрольні запитання

1.Призначення діаграми класів.

2.Позначення класу.

3.Атрибути класу.

4.Операція класу.

5.Відношення між класами.

6.Відношення залежності.

7.Відношення асоціації.

8.Відношення аґреґації.

9.Відношення композиції.

10.Відношення узагальнення.

11.Інтерфейси.

12.Об'єкти.

13.Шаблони або параметризовані класи.