6.7. Заключні рекомендації по побудові діаграм станів

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

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

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

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

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

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

І, нарешті, слід зазначити, що деякі додаткові конструкції автоматів, такі як точки динамічного вибору (dynamic choice points) або крапки з'єднання (junction points), в книзі не знайшли віддзеркалення. Це зроблено з тієї причини, що дані модельні елементи хоча і дозволяють моделювати складніші аспекти динамічного управління поведінкою об'єкту, не є базовими. Відповідна інформація міститься в оригінальній документації по язику UML.

РОЗДІЛ 7

Діаграма діяльності (асtivity diagram)

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

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

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

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

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

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

Примітка

Хоча діаграма діяльності призначена для моделювання поведінки систем, час в явному вигляді відсутній на цій діаграмі. Ситуація тут багато в чому аналогічна діаграмі станів.