5.5. Шаблони або класи, що параметризуються

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

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

Мал. 5.19. Графічне зображення шаблона на діаграмі класів

Шаблон не може бути безпосередньо використаний як клас, оскільки містить невизначені параметри. Частіше за все як шаблон виступає деякий суперклас, параметри якого уточнюються в його класах‑ нащадках. Очевидно, в цьому випадку між ними існує відношення залежності з ключовим словом «bind», коли клас‑ клієнт може використовувати деякий шаблон для своєї подальшої параметризації. В більш окремому випадку між шаблоном і формованим від нього класом має місце відношення узагальнення із спадкоємством властивостей шаблона (мал. 5.20). В даному прикладі відзначений той факт, що клас «Адреса» може бути одержаний з шаблона Связний_спісок на основі актуалізації формальних параметрів «S, до, l» фактичними атрибутами «вулиця, будинок, квартира».

Цей же шаблон може використовуватися для завдання (инстанцирования) іншого класу, скажімо, класу «Точки_на_плоськості». В цьому випадку клас «Точки_на_плоськості» актуалізує ті ж формальні параметри, але з іншими значеннями, наприклад, "ЬтсГ‹координаты_точки, х, у‑ . Концепція шаблонів є достатньо могутнім засобом в ООП, і тому її використовування в язиці UML дозволяє не тільки скоротити розміри діаграм, але і найбільш коректно управляти спадкоємством властивостей і поведінки окремих елементів моделі.

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

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

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

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

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

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

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

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

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

РОЗДІЛ 6

Діаграма станів (statechart diagram)

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

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

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

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

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

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

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

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