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

· 6.1. Автомати

· 6.2. Стан

o Ім'я стану

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

o Початковий стан

o Кінцевий стан

· 6.3. Перехід

o Подія

o Сторожова умова

o Вираження дії

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

o Послідовні підстани

o Паралельні підстани

· 6.5. Історичний стан

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

o Переходи між паралельними станами

o Переходи між складеними станами

o Синхронізуючі стани

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

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

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

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

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

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

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

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

Автомати

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

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

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

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

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

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

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

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

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

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

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

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

4. Кількість станів автомата має бути обов'язкове скінченим і всі вони мають бути специфіковані явним чином. При цьому окремі псевдостани можуть не мати специфікацій (початковий і кінцевий стани).

5. Граф автомата не повинен містити ізольованих станів і переходів. Для кожного з станів, окрім початкового, має бути визначений попередній стан. Кожен перехід повинен обов'язково сполучати два стани автомата. Допускається перехід з стану в себе, який називають "петлею".

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

Стан

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Мал. 6.4. Графічне зображення початкового і кінцевого станів на діаграмі станів

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

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

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

Перехід

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

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

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

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

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

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

Подія

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

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

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

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

Сторожова умова

Сторожова умова (guard condition), завжди записується в прямих дужках після події-тригера і є деяким булівським виразом.

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

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

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

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

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

Мал. 6.5. Діаграма станів для моделювання поштової програми-клієнта

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

Вираз дії

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

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

Як приклад виразу дії (див. мал. 6.5) може бути "розірвати телефонне з'єднання (телефонний номер)", що має бути виконане відразу після встановлення істинності ("істина") сторожової умови "поштова скринька на сервері порожня".

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

"натиснута і відпущена ліва кнопка миші (координати) [координати в області графічного об'єкту] / виділити об'єкт (колір).

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

Примітка Інколи після виразу дії може бути записане повідомлення у форматі: '^'<ім'я об'єкту приймача повідомлення>'.'<ім'я повідомлення>'('<параметр>':'<тип>',)'. При цьому повідомлення має чисто інформаційний характер і не передає керування на об'єкт-приймач повідомлення.

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

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

Мал. 6.6. Графічне представлення складеного стану з вкладеними в нього послідовними підстанами

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

Послідовні підстани

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

Для прикладу розглянемо як модельований об'єкт звичайний телефонний апарат. Він може перебувати в різних станах, одним з яких є стан дозвону до абонента. Для того, щоб подзвонити, необхідно зняти телефонну трубку, почути тоновий сигнал, після чого набрати потрібний телефонний номер. Таким чином, стан дозвону до абонента є складеним і складається з двох послідовних підстанів: "підняти телефонну трубку" і "набрати телефонний номер". Фрагмент діаграми станів для цього прикладу містить один складений стан і два послідовних підстани (мал. 6.7).

Мал. 6.7. Приклад складеного стану з двома вкладеними послідовними підстанами

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

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

Це можна пояснити таким чином. Кожна сукупність вкладених послідовних підстанів є підавтоматом того автомата, якому належить даний складений стан. Оскільки кожен автомат може мати за визначенням єдиний початковий і єдиний кінцевий стан, то для підавтомата ця умова також повинна виконуватися (мал. 6.7).

Паралельні підстани

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

Окремі паралельні підстани можуть складатися з декількох послідовних підстанів (підавтомати 1 і 2 на мал. 6.8). В цьому випадку за визначенням об'єкт може перебувати лише в одному з послідовних підстанів підавтомата. Таким чином, для абстрактного прикладу (мал. 6.8) допустиме одночасне перебування об'єкту в підстанах (1, 3, 4) (2, 3, 4) (1, 3, 5) (2, 3, 5). Неприпустимо перебування об'єкту одночасно в підстанах (1, 2,3) або (3, 4, 5).

Мал. 6.8. Графічне зображення складеного стану з вкладеними паралельними підстанами

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

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

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

Мал. 6.9. Складений стан з прихованою внутрішньою структурою і спеціальною піктограмою

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

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

Історичний стан (history state) застосовується в контексті складеного стану. Він використовується для запам'ятовування того з послідовних підстанів, який був поточним у момент виходу із складеного стану. При цьому існує два різновиди історичного стану: недавній і давній (мал. 6.10).

Мал. 6.10. Графічне зображення недавнього (а) і давнього (б) історичного стану

Недавній історичний стан (shallow history state) позначається у формі невеликого кола, всередині з латинською буквою "Н" (мал. 6.10, а). Цей стан володіє наступною семантикою: 1) він є першим підстаном у складеному стані, і перехід ззовні в цей складений стан повинен вести безпосередньо в цей історичний стан; 2) при першому попаданні в недавній історичний стан він не зберігає жодної історії (історія порожня). При першому переході в недавній історичний стан він замінює собою початковий стан підавтомата.

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

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

Запам'ятований стан також може бути складеним станом. Давній історичний стан (deep history state) позначається у формі невеликого кола, з латинською буквою "Н^*" (мал. 6.10, б) і призначений для запам'ятовування всіх підстанів будь-якого рівня вкладеності для поточного підавтомата.

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

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

Діаграма станів поштової програми-клієнта (див. мал. 6.5) може бути доповнена з врахуванням розглянутого аспекту її поведінки. Читачеві пропонується це виконати самостійно як вправу.

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

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

Переходи між паралельними станами

В окремих випадках перехід може мати декілька станів-джерел і декілька цільових станів. Такий перехід називається – паралельний перехід. Розгляд паралельного переходу зумовлений необхідністю синхронізувати і/або розділити окремі підпроцеси на паралельні нитки без специфікації додаткової синхронізації в паралельних підавтоматах.

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

Мал. 6.11. Зображення паралельного переходу з паралельних станів (а) і паралельного переходу в паралельні стани (б)

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

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

Переходи між складеними станами

Перехід, стрілка якого сполучена з межею деякого складеного стану, позначає перехід в складений стан (перехід b на мал. 6.12). Він еквівалентний переходу в початковий стан кожного з підавтоматів (можливо, єдиного), які входять до складу даного суперстану. Перехід, який виходить із складеного стану (переходи f і g на мал. 6.12), відноситься до кожного з вкладених підстанів. Це означає, що об'єкт може покинути складений суперстан, перебуваючи в будь-якому з його підстанів. Для цього цілком досить виконання події і сторожової умови.

Мал. 6.12. Різні варіанти переходів в (з) складений стан

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

Синхронізуючі стани

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

Синхронізуючий стан (synch state) позначається невеликим колом, усередині якого поміщений символ зірочки "*". Він використовується разом з переходом-з'єднанням або переходом-галуженням для того, щоб явно вказати події в інших підавтоматах, які безпосередньо впливають на поведінку даного підавтомата.

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

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

Мал. 6.13. Діаграма станів для прикладу з будівництвом будинку

Розглянемо діаграму станів, яка є прикладом моделювання поведінки конкретного об'єкту, - процесу функціонування телефонного апарату (мал. 6.14).

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

Мал. 6.14. Діаграма станів процесу функціонування телефонного апарату

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

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

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

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

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

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

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

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

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

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

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

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

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

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