Примітка. Як вправа для закріплення розглянутого матеріалу можна спробувати побудувати діаграму класів для бібліотек стандартних класів MFC (Microsoft) і VCL

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

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

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

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

19.4. Об'єкти

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

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

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

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

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

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

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

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

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

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

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

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

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

Такий стереотипний підхід дозволяє істотно скоротити терміни реалізації проекту, проте він прийнятний лише у тому випадку, коли новий проект концептуально і технологічно не дуже відрізняється від попередніх. Інакше розплатою за скорочення термінів проекту може стати його реалізація на застарілій технологічній базі. Що стосується власної об'єктної структуризації предметної області, то тут доречно дотримуватися тих рекомендацій, які накопичені в ООП. Вони широко висвітлені в літературі [1, 2, 4, 10, 13, 18, 20] і тому тут не розглядаються.

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

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

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

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

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

Висновки

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

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

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

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

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

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

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

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

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

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

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

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

12. Об'єкти.

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

РОЗДІЛ 20. Діаграма станів (statechart diagram)

à Автомати

à Стан

à Перехід

à Складений стан і підстан

à Історичний стан

à Складні переходи

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

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

Розглянемо простий приклад. Будь-який технічний пристрій, такий як телевізор, комп'ютер, автомобіль, телефонний апарат у найзагальнішому випадку може характеризуватися такими своїми станами, як "справний" і "несправний". Інтуїтивно ясно, який сенс вкладається в кожне із цих понять. Більше того, використання за призначенням такого пристрою можливе тільки тоді, коли він знаходиться у справному стані. Інакше необхідно зробити абсолютно конкретні дії з його ремонту і відновлення працездатності.

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

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

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

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

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

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

20.1. Автомати

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

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

Рис. 20.1. Простий приклад діаграми станів для технічного пристрою типу комп'ютер

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

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

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

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

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

У мові UML поняття автомату доповнене спеціальною семантикою вхідних у відповідний пакет елементів. Далі в цьому розділі будуть розглянуті основні елементи поведінки, які утворюють концептуальний базис, необхідний для правильної побудови діаграм станів.

Формалізм звичайного автомата заснований на виконанні наступних обов'язкових умов:

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

Поиск по сайту: