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 володіє досить специфічною семантикою, заснованою на теорії автоматів. Вершинами цього графу є стани і деякі інші типи елементів автомата (псевдостани), які зображаються відповідними графічними символами. Дуги графа служать для позначення переходів зі стану в стан. Діаграми станів можуть бути вкладені один в одний, утворюючи вкладені діаграми детальнішого представлення окремих елементів моделі. Для розуміння семантики конкретної діаграми станів необхідно представляти не тільки особливості поведінки модельованої сутності, але й знати загальні відомості з теорії автоматів.