PrIS

421

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

Автомати

Стан

Перехід

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

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

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

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

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

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

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

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

423

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

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

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

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

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

424

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

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

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

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

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

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

Примітка

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

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

426

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

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

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

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

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

427

Рис. 20.2. Графічне зображення станів на діаграмі станів.

20.2.1. Ім'я стану

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

20.2.2. Список внутрішніх дій

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

<мітка-дії '/' вираз-дії>

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

Перелік міток дії має фіксовані значення в мові UML, які не можуть бути використані як імена подій. Це такі значення:

entry – ця мітка вказує на дію, специфіковану наступним за нею виразом дії, яка виконується в момент входження у цей стан (вхідна дія);

exit – ця мітка вказує на дію, специфіковану наступним за нею виразом дії, яка виконується в момент виходу з цього стану (вихідна дія);

do – ця мітка специфікує виконавчу діяльність ("do activity"), яка відбивається протягом всього часу, поки об'єкт перебуває в цьому стані, або доти, поки не закінчиться обчислення, специфіковане наступним за нею виразом дії; в останньому випадку під час завершення події ґенерується відповідний результат;

include – ця мітка використовується для звернення до підавтомата, при цьому наступний за нею вираз дії містить ім'я цього підавтомата.

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

428

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

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

Введення пароля

entry / встановити символи невидимими exit / встановити символи видимими символ / отримати символ допомога / показати допомогу

Рис. 20.3. Приклад стану з непорожньою секцією внутрішніх дій.

20.2.3. Початковий стан

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

Рис. 20.4. Графічне зображення початкового і кінцевого станів на діаграмі станів.

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

429

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

20.2.4. Кінцевий стан

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

20.3. Перехід

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

Перехід здійснюється, коли наступає деяка подія: закінчення виконання діяльності (do activity), отримання об'єктом повідомлення або прийом сигналу. На переході вказується ім'я Події. Крім того, на переході можуть вказуватися дії, що виробляються об'єктом у відповідь на зовнішні події під час переходу з одного стану в інший. Спрацьовування переходу може залежати не тільки від настання деякої події, але й від виконання певної умови, званої сторожовою умовою. Об'єкт перейде з одного стану в інший в тому випадку, якщо відбулася вказана подія і сторожова умова набула значення "істина".

Примітка

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

430

На діаграмі станів перехід зображається суцільною лінією зі стрілкою, яка напрямлена в цільовий стан (наприклад, "вихід з ладу" на рис. 20.1). Кожний перехід може бути позначений рядком тексту, який має наступний такий формат:

<сигнатура події>'['<сторожова умова>']' <вираз дії>.

При цьому сигнатура події описує деяку подію з необхідними арґументами:

<ім'я події>'('<список параметрів, розділених комами>')'.

20.3.1. Подія

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

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

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

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

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