Тема 8. Діаграми станів
Розглянута діаграма класів представляє собою логічну модель статичного представлення модельованої системи. Мова йде про те, що на даній діаграмі зображаються тільки взаємозв'язки структурного характеру, які не залежать від часу або реакції системи на зовнішні події. Проте для більшості фізичних систем, крім самих простих і тривіальних, статичних представлень зовсім недостатньо для моделювання процесів функціонування подібних систем як в цілому, так і їх окремих підсистем і елементів.
Проте розуміння семантики поняття стану представляє певні труднощі. Справа в тому, що характеристика станів системи не залежить (або слабо залежить) від логічної структури, яка зафіксовані на діаграмі класів. Тому при розгляді станів системи доводиться на час відволіктися від особливостей її об'єктної структури і думати зовсім іншими категоріями, які утворюють динамічний контекст поведінку модельованої системи. Тому при побудові діаграм станів необхідно використовувати спеціальні поняття.
Кожна прикладна система характеризується не тільки структурою складових її елементів, але й деякою поведінкою або функціональністю. Для загального представлення функціональності модельованої системи призначені діаграми варіантів використання, які на концептуальному рівні описують поведінку системи в цілому. Зараз задача полягає в тому, щоб представити поведінку більш детально на логічному рівні, тим самим розкрити суть відповіді на питання: «В процесі якої поведінки система забезпечує необхідну функціональність?».
Для моделювання поведінки на логічному рівні у мові UML можуть використовуватися відразу декілька канонічних діаграм: станів, діяльності, послідовності і кооперації, кожна з яких фіксує увагу на окремому аспекті функціонування системи. На відміну від інших діаграм діаграма станів описує процес зміни станів тільки одного класу, а точніше - одного екземпляру певного класу, тобто моделює всі можливі зміни в стані конкретного об'єкта. При цьому зміна станів об'єкту може бути викликане зовнішніми впливами зі сторони інших об'єктів або ззовні. Саме для опису реакції об'єкту на подібні зовнішні впливами і використовуються діаграми станів.
Головне призначення цієї діаграми - описати можливі послідовності станів і переходів, які в сукупності характеризують поведінку елемента моделі на протязі його життєвого циклу. Діаграма станів представляє динамічну поведінку сутностей, на основі специфікації їх реакції на сприйняття деяких конкретних подій. Системи, які реагують на зовнішні дії від інших систем або від користувачів, іноді називають реактивними. Якщо такі дії ініціюються в довільні випадкові моменти часу, то говорять про асинхронну поведінку моделі.
Хоча діаграми станів часто використовуються для опису поведінку окремих екземплярів класів (об'єктів), але вони також можуть бути застосовані для специфікації функціональності інших компонентів моделей, таких як варіанти використання, актори, підсистеми, операції і методи.
Діаграма станів по суті є графом спеціального виду, який представляє деякий автомат. Поняття автомата в контексті UML має доволі специфічну семантику, яка базується на теорії автоматів. Вершинами цього графа є стани і деякі інші типи елементів автомата (псевдостани), які зображаються відповідними графічними символами. Дуги графа служать для позначення переходів із стану в стан. Діаграми станів можуть бути вкладені одна в одну, утворюючи вкладені діаграми більш детального представлення окремих елементів моделі.
Автомат (state machine) в мові UML представляє собою деякий формалізм для моделювання поведінки елементів моделі і системи в цілому. В метамоделі UML автомат є пакетом, в якому визначена множина понять, які необхідні для представлення поведінки модельованої сутності в виді дискретного простору з скінченною кількості станів і переходів. З іншої сторони, автомат описує поведінку окремого об'єкта в формі послідовності станів, яке охоплює всі етапи його життєвого циклу, починаючи від створення об'єкту і закінчуючи його знищенням. Кожна діаграма станів представляє деякий автомат.
Основними поняттями, які входять в формалізм автомату, є стан і перехід. Головна відмінність між ними полягає в тому, що тривалість знаходження системи в окремому стані суттєво перевищує час, який затрачується на перехід із одного стану в інший. Передбачається, що в граничний час переходу з одного стану в інший рівний нулю (якщо додатково нічого не сказано). Іншими словами, перехід об'єкта з стану в стан відбувається миттєво.
У загальному випадку автомат представляє динамічні аспекти модельованої системи в виді орієнтованого графу, вершини якого відповідають станам, а дуги - переходам. При цьому поведінка моделюється як послідовне переміщення графом станів від вершини до вершини через дуги, що їх зв'язують, з врахуванням їх орієнтації. Для графа станів системи можна ввести спеціальні властивості.
Однією з таких властивостей є виділення з всієї сукупності станів двох спеціальних: початкового і кінцевого. Хоча ні в графі станів, ні на діаграмі станів час знаходження системи в том чи іншому стані явно не враховується, передбачається, що послідовність зміни станів впорядкована в часі. Іншими словами, кожен наступний стан завжди наступає пізніше попереднього стану.
Ще однією властивістю графу станів може бути досяжність станів. Мова йде про те, що навігація або орієнтований шлях в графі станів визначає спеціальне бінарне відношення на множині всіх станів системи. Це відношення характеризує потенційну можливість переходу системи з розглядуваного стану в деякий інший стан. Очевидно, для досяжності станів необхідна наявність орієнтованого шляху в графі станів, який їх зв'язує.
Формалізм автоматів допускає вкладеність одних автоматів в інші для уточнення внутрішньої структури окремих більш загальних станів (макро станів). У цьому випадку вкладені автомати отримали назву підавтоматів. Підавтомати можуть використовуватися для внутрішньої специфікації процедур і функцій, які утворюють поведінку вихідного об'єкта.
У мові имь поняття автомата доповнено спеціальною семантикою, яка входить у відповідний пакет елементів.
Формалізм звичайного автомата базується на виконанні наступних обов'язкових умов:
1. Автомат не запам'ятовує історію переміщення з стану в стан. З точки зору модельованої поведінки визначальним є сам факт знаходження об'єкта в тому чи іншому стані, але ніяк не послідовність станів, в результаті якої об'єкт перейшов в поточний стан. Іншими словами, автомат «забуває» всі стани, які передували поточному в даний момент часу.
2. В кожен момент часу автомат може знаходитися в одному і тільки в одному з своїх станів. Це означає, що формалізм автомату призначений для моделювання послідовної поведінки, коли об'єкт на протязі свого життєвого циклу послідовно проходить через всі свої стани. При цьому автомат може знаходитися в окремому стані як завгодно довго, якщо не відбувається жодних подій.
3. Хоча процес зміни станів автомата відбувається в часі, явно концепція часу не входить в формалізм автомату. Це означає, що тривалість знаходження автомата в тому чи іншому стані, а також час досягнення того чи іншого стану ніяк не специфікуються. Іншими словами, час на діаграмі станів присутній в неявному виді, хоча для окремих подій може бути вказано інтервал часу і в явному виді.
4. Кількість станів автомату повинно бути обов'язково скінченним, і всі вони повинні бути специфіковані явним чином. При цьому окремі псевдостани можуть не мати специфікацій (початковий і кінцевий стани). У цьому випадку їх призначення і семантика повністю визначаються із контексту моделі і розглядуваної діаграми станів.
Граф автомату не повинен містити ізольованих станів і переходів. Ця умова означає, що для кожного з станів, крім початкового, повинно бути визначено попередній стан. Кожен перехід повинен обов'язково з'єднувати два стани автомату. Допускається перехід із стану в себе, такий перехід ще називають «петлею».
Автомат не повинен містити конфліктуючих переходів, тобто таких переходів із одного і того ж стану, коли об'єкт одночасно може перейти в два і більше наступних стани (крім випадку паралельних підавтоматів). У мові имь виключення конфліктів можливе на основі введення так званих сторожових умов.
Таким чином, правила поведінки об'єкту, який моделюється деяким автоматом, визначаються, з одного боку, загальним формалізмом автомату, а з іншої - його графічним зображенням мовою имь в формі конкретної діаграми станів.
Поняття стану (state) є фундаментальним не тільки в метамоделі мови UML, але й в прикладному системному аналізі. Вся концепція динамічної системи базується на понятті стану системи. Проте семантика стану в мові UML має цілий ряд специфічних особливостей.
В мові UML під станом розуміють абстрактний метаклас, який використовується для моделювання окремої ситуації, на протязі якої виконується деяка умова. Стан може бути задано в виді набору конкретних значень атрибутів класу або об'єкту, при цьому зміна їх окремих значень буде зображати зміну стану модельованого класу або об'єкту.
Але не кожен атрибут класу може характеризувати його стан. Як правило, мають значення тільки такі властивості елементів системи, які зображають динамічний або функціональний аспект її поведінки. У цьому випадку стан буде характеризуватися деякою інваріантною умовою, яка включає в себе тільки значимі для поведінки класу атрибути і їх значення.
Стан на діаграмі зображається прямокутником з заокругленими вершинами. Цей прямокутник, у свою чергу, може бути розділений на дві секції горизонтальною лінією. Якщо вказана лише одна секція, то в неї записується тільки ім'я стану. В осоружному випадку в першій з них записується ім'я стану, а в другій - список деяких внутрішніх дій або переходів в даному стані. При цьому під дією в мові UML розуміють деяку атомарну операцію, виконання якої приводить до зміни стану або повернення деякого значення.
Ім'я стану представляє собою стрічку тексту, яка розкриває зміст даного стану. Ім'я завжди записується з великої букви. Оскільки стан системи є складовою частиною процесу її функціонування, рекомендується як ім'я використовувати дієслова в теперішньому часі або відповідні дієприкметники. Ім'я в стану може бути відсутнім, тобто воно є необов'язковим для деяких станів. У цьому випадку стан є анонімним, і якщо на діаграмі станів їх декілька, то всі вони повинні відрізнятися між собою.
Секція списку внутрішніх дій містить перелік внутрішніх дій або діяльностей, які виконуються в процесі знаходження модельованого елемента в даному стані. Кожна з дій записується у виді окремої стрічки.
Метка дії вказує на обставини або умови, при яких буде виконуватися діяльність визначена виразом дії. При цьому вираз дії може використовувати будь-які атрибути і зв'язки, які належать області імен або контексту модельованого об'єкту.
Мітки дій мають фіксовані значення в мові UML, які не можуть бути використані як імена подій:
- Entry - це мітка вказує на дію, що специфікована наступним за нею виразом дій, яка виконується в момент входу в даний стан (вхідна дія);
- Exit - ця мітка вказує на дію, що специфікована наступним за нею виразом дій, яка виконується в момент виходу з даного стану (вихідна дія);
- Do - це мітка специфікує виконувану діяльність («do activity»), яка виконується на протязі всього часу, поки об'єкт знаходиться в даному стані, або до тих пір, поки не закінчиться обчислення, специфіковане наступним за нею виразом дій;
- include - ця мітка використовується для звернення до підавтомату, при цьому наступний за нею вираз дії містить ім'я цього підавтомата.
У всіх інших випадках мітка дій ідентифікує подію, яка запускає відповідний вираз дій. Ці події називаються внутрішніми переходами і семантично еквівалентні переходам в саме цей стан, за винятком тієї особливості, що вихід із цього стану або повторний вхід в нього не відбувається. Це означає, що дії входу і виходу не виконуються.
Початковий стан представляє собою частковий випадок стану, який не містить жодних внутрішніх дій. У цьому стані знаходиться об'єкт за замовчуванням в початковий момент часу. Він служить для вказівки на діаграмі стану графічної області, від якої починається процес зміни станів. Графічно початковий стан у мові UML позначається в виді закрашеного круга, з якого може тільки виходити стрілка, що відповідає переходу.
На самому верхньому рівні представлення об'єкту перехід із початкового стану може бути помічений подією створення (ініціалізації) даного об'єкту. В осоружному випадку перехід ніяк не помічається. Якщо цей перехід не помічений, то він є першим переходом в наступний за ним стан.
Кінцевий (фінальний) стан представляє собою частковий випадок стану, який також не містить жодних внутрішніх дій. У цьому стані буде знаходитися об'єкт за замовчуванням після завершення роботи автомата в кінцевий момент часу. Він служить для вказівки на діаграмі станів графічної області, в якій завершується процес зміни станів або життєвий цикл даного об'єкту. Графічно кінцевий стан в мові UML позначається у виді закрашеного круга, поміщеного в коло, в яку може тільки входити стрілка, яка відповідає переходу.
Простий перехід (simple transition) представляє собою відношення між двома послідовними станами, яке вказує на факт зміни одного стану іншим. Перебування модельованого об'єкту в першому стані може супроводжуватися виконанням деяких дій, а перехід у другий стан буде можливий після завершення цих дій, а також після виконання деяких додаткових умов. У цьому випадку говорять, що перехід спрацьовує, Або відбувається спрацювання переходу. До спрацювання переходу об'єкт знаходиться в попередньому від нього стані, який називається вихідним станом, або в джерелі, а після його спрацювання об'єкт знаходиться в наступному від нього стані (цільовому).
Перехід здійснюється при настанні деякої події: закінчення виконання діяльності (do activity), отриманні об'єктом повідомлення або прийом сигналу. На переході вказується ім'я події. Крім того, на переході можуть вказуватися дії, які виконує об'єкт у відповідь на зовнішні події при переході з одного стану в інший. Спрацювання переходу може залежати не тільки від настання деякої події, але й від виконання певної умови, яка називається сторожовою умовою. Об'єкт перейде з одного стану в інший у тому випадку, якщо відбулася вказана подія і сторожова умова прийняла значення «істина».
На діаграмі станів перехід зображається суцільною лінією зі стрілкою, яка направлена в цільовий стан. Кожен перехід може помічатися стрічкою тексту.
Термін подія (event) потребує окремого пояснення, оскільки є самостійним елементом мови UML. Формально, подія представляє собою специфікацію деякого факту, який може бути в просторі і в часі. Про події говорять, що вони «відбувається», при цьому окремі події повинні бути впорядковані в часі. Після настання деякої події не можна вже повернутися до попередніх подій, якщо така можливість не передбачена явно в моделі.
Семантика поняття події фіксує увагу на зовнішніх проявах якісних змін, які відбуваються при переході модельованого об'єкта з стану в стан.
У мові UML події відіграють роль стимулів, які ініціюють переходи з одних станів в інші. Як події можна розглядати сигнали, виклики, закінчення фіксованих проміжків часу або моменти закінчення виконання певних дій. Ім'я події ідентифікує кожен окремий перехід на діаграмі станів і може містити стрічку тексту, яка починається з великої букви. У цьому випадку прийнято вважати перехід тригерним, тобто таким, який специфікує подію-тригер.
Якщо поруч зі стрілкою переходу не вказано жодного тексту, то відповідний перехід є нетригерним, і в цьому випадку з контексту діаграми станів повинно бути ясно, після закінчення якої діяльності він спрацьовує. Після імені події можуть йти круглі дужки для явного завдання параметрів відповідної події-тригера.
Сторожова умова (guard condition), якщо вона є, завжди записується в прямих дужках після події-тригера і представляє собою деякий логічний вираз. Із контексту діаграми станів повинно явно слідувати семантика цього виразу, а для запису виразу може використовуватися синтаксис мови об'єктних обмежень.
Введення для переходу сторожової умови дозволяє явно специфікувати семантику його спрацювання. Якщо сторожова умова приймає значення «істина», то відповідний перехід може спрацювати, в результаті чого об'єкт перейде в цільовий стан. Якщо ж сторожова умова приймає значення «фальш», то перехід не може спрацювати, і при відсутності інших переходів об'єкт не може перейти в цільовий стан через цей перехід. Проте обчислення істинності сторожової умови відбувається тільки після виникнення асоційованого з ним події-тригера, яке ініціює відповідний перехід.
В загальному випадку з одного стану може бути декілька переходів з однією подією-тригером. При цьому жодні дві сторожові умови не повинні одночасно приймати значення «істина». Кожна з сторожових умов необхідно обчислювати кожен раз при настанні відповідної події-тригера.
Вираз дій (action expression) виконується у тому і тільки в тому випадку, коли перехід спрацьовує. Він представляє собою атомарну операцію, яка виконується відразу після спрацьовування відповідного переходу до початку будь-яких дій в цільовому стані. Атомарність дії означає, що вона не може бути перервана жодною іншою дією до тих пір, поки не закінчиться її виконання. Дана дія може впливати як на сам об'єкт, так і на його оточення, якщо це з очевидністю слідує з контексту моделі.
Складний стан (composite state) - такий стан, який складається з інших вкладених в нього станів. Останні будуть виступати по відношенні до першого як підстани (substate). Хоча між ними й існує відношення композиції, графічно всі вершини діаграми, які відповідають вкладеним станам, зображаються в середині символу складного стану.
Складений стан може містити два або більше паралельних підавтомати або декілька послідовних підстани. Кожний складний стан може уточнюватися тільки одним із вказаних способів. При цьому будь-який із підстанів, у свою чергу, може бути складним станом і містити в собі інші вкладені підстани.
Послідовні підстани (sequential substates) використовуються для моделювання такої поведінки об'єкта, під час якого в кожен момент часу об'єкт може знаходитися в одному і тільки одному підстані. Поведінка об'єкта в цьому випадку представляє собою послідовну зміну підстанів, починаючи від початкового і закінчуючи кінцевим підстанами. Хоча об'єкт продовжує знаходитися в складеному стані, введення послідовних підстанів дозволяє врахувати більш тонкі логічні аспекти його внутрішньої поведінки.
Складений стан може містити як вкладені підстани початковий і кінцевий стани. При цьому початковий підстан є вихідним, коли відбувається перехід об'єкта в даний складений стан. Якщо складений стан містить в собі кінцевий підстан, то перехід в цей вкладений кінцевий стан означає завершення знаходження об'єкта в даному вкладеному стані. Важливо пам'ятати, що для послідовних підстанів початковий і кінцевий стани повинні бути єдиними в кожному складеному стані.
Паралельні підстани (concurrent substates) дозволяють специфікувати два і більше підавтоматів, які можут виконуватися паралельно в складеному стані. Кожен із підавтоматів займає деяку область в складеному стані, яка відділяється від інших горизонтальною пунктирною лінією. Якщо на діаграмі станів є складений стан з вкладеними паралельними підстанами, то об'єкт може одночасно знаходитися в кожному з цих підстанів.
Оскільки кожен регіон вкладеного стану специфікує деякий підавтомат, то для кожного з вкладених підавтоматів можуть бути визначені власні початкові і кінцеві підстани. При переході в данний складений стан кожен із підавтоматів виявляється у своєму початковому підстані. Далі відбувається паралельне виконання кожного з цих підавтоматів, причому вихід із складеного стану буде можливий лише у тому випадку, коли всі підавтомати будуть знаходитися в своїх кінцевих підстанах.
Якщо будь-який з підавтоматів прийшов до свого кінцевого стану раніше інших, то він повинен очікувати, поки й інші підавтомати не прийдуть в свої кінцеві стани.
Історичний стан (history state) застосовується в контексті складеного стану. Він використовується для запам'ятовування того з останніх підстанів, який був поточним в момент виходу з складеного стану. При цьому існує дві різновидності історичного стану: недавній і давній.
Недавній історичний стан позначається в формі невеликого кола, в якому поміщена латинська буква "Н". Цей стан має наступну семантику. По-перше, він є першим підстаном в складеному стані, і перехід ззовні в цей стан повинен вести безпосередньо в цей історичний стан. По-друге, при першому попаданні в недавній історичний стан він не зберігає ніякої історії.
Далі слідує послідовна зміна вкладених підстанів. Якщо в деякий момент відбувається вихід із вкладеного стану, то цей історичний стан запам'ятовує той з підстанів, який був поточним на момент виходу. При наступному вході в цей же підстан вже має непусту історію і відразу відправляє підавтомат в збережений підстан, проминувши всі попередні його підстани.
Історичний стан втрачає свою історію в той момент, коли підавтомат доходить до свого кінцевого стану. При цьому недавній історичний стан зберігає історію тільки того підавтомата, до якого він відноситься.
З іншого боку, збережений стан, в свою чергу, також може бути складеним станом. Давній історичний стан позначається в формі невеликого кола, в яке поміщена латинськая буква "Н" з символом "*" і служить для збереження всіх підстанів будь-якого рівня вкладеності для поточного підавтомата.
Розглянуте поняття переходу є достатнім для більшості типових розрахункових задач. Проте сучасні програмні системи можуть реалізовувати дуже складну логіку поведінки окремих своїх компонентів. Може виявитися, що для адекватного представлення процесу зміни станів семантика звичайного переходу для них недостатня. Для цієї мети в UML специфіковані додаткові позначення і властивості, які можуть мати окремі переходи на діаграмі станів.
У окремих випадках перехід може мати декілька станів-джерел і декілька цільових станів. Такий перехід отримав спеціальну назву - паралельний перехід.
Графічно такий перехід зображається вертикальною лінією. Якщо паралельний перехід має дві або більше вхідних дуги, то його називають об'єднанням (join). Якщо ж він має дві або більше вихідних із нього дуг, то його називають розгалуженням (fork). Текстова стрічка специфікації паралельного переходу записується поруч з лінією і відноситься до всіх дуг.
Спрацювання паралельного переходу відбувається наступним чином. У першому випадку (перехід-об'єднання) перехід спрацьовує, якщо є подія-тригер для всіх вихідних станів цього переходу, і виконана (при його наявності) сторожова умова. При спрацюванні переходу-об'єднання одночасно покидаються всі вихідні стани переходу і відбувається перехід до цільового стану. При цьому кожен із вихідних станів переходу повинен належати окремому підавтомату, який входить до складу автомату.
У другому випадку (розгалуження) відбувається розщеплення автомату на два підавтомати, які утворюють паралельні гілки вкладених підстанів. При цьому після спрацювання переходу модельований об'єкт одночасно буде знаходитися у всіх цільових станах цього переходу. Далі процес зміни станів буде протікати згідно правил для складених станів.
Перехід, стрілка якого з'єднана з межею деякого складеного стану, позначає перехід до складеного стану. Він еквівалентний переходу в початковий стан кожного з підавтоматів, які входять до складу даного суперстану. Перехід, який виходить з складеного стану, відноситься до кожного з вкладених підстанів. Це означає, що об'єкт може покинути складений суперстан, знаходячись в будь-якому з його підстанів. Для цього достатньо виконання події і сторожової умови.
Іноді бажано реалізувати ситуацію, коли вихід із окремого вкладеного стану відповідав би виходу і з складеного стану також. У цьому випадку зображають перехід, який безпосередньо виходить з вкладеного підстану за межі суперстану. Аналогічно, допускається зображення переходів, які входять ззовні складеного стану в окремий вкладений стан.
Поведінка паралельних підавтоматів незалежна одна від одної, що дозволяє реалізувати багатозадачність в програмних системах. Проте в окремих випадках може виникнути необхідність врахувати в моделі синхронізацію настання окремих подій. Для цієї мети в UML є спеціальний псевдостан, який називається синхронізуючим станом.
Синхронізуючий стан позначається невеликим кругом, в який поміщено символ "*". Він використовується разом з переходом-об'єднанням або переходом-розгалуженням для того, щоб явно вказати подію в інших підавтоматах, які безпосередньо впливають на поведінку даного підавтомату.
Рекомендації по побудові діаграм станів
За своїм призначенням діаграма станів не є обов'язковим представленням в моделі і мов би «приєднується» до цього елемента, який, за задумом розробників, має нетривіальну поведінку на протязі свого життєвого циклу. Наявність в системи декількох станів, відмінних від простої дихотомії, вже служить ознакою необхідності побудови діаграми станів. Як початковий варіант діаграми станів, якщо немає очевидних думок на рахунок станів об'єкту, можна скористатися цими суперстанами, розглядаючи їх як складені і уточнюючи їх в процесі розгляду логіки поведінки об'єкту.
При виділенні станів і переходів потрібно пам'ятати, що тривалість спрацювання окремих переходів повинна бути суттєво меншою, ніж знаходження модельованого об'єкту у відповідних станах. Кожен із станів повинен характеризуватися певною стійкістю в часі. Іншими словами, з кожного стану на діаграмі не може бути самовільного переходу в будь-який інший стан. Всі переходи повинні бути явно специфіковані, в іншому випадку побудована діаграма станів буде або неповною, або помилковою.
При розробці діаграми станів потрібно постійно слідкувати, щоб об'єкт в кожен момент міг знаходитися тільки в єдиному стані. Якщо це не так, то дана обставина може бути наслідком помилки або неявною ознакою наявності паралельності у поведінці модельованого об'єкту. В останньому випадку потрібно явно специфікувати необхідну кількість підавтоматів, вклавши їх в той складений стан, який характеризується порушенням умови одночасності.
Потрібно обов'язково перевіряти, що жодні два переходи з одного стану не можуть спрацьовувати одночасно. Наявність такого конфлікту може служити ознакою помилки або неявної паралельності типа розгалуження. Якщо паралельність за задумом відсутня, то необхідно ввести додаткові сторожові умови або змінити існуючі, щоб виключити конфлікт переходів. При наявності паралельності потрібно замінити конфліктуючі переходи одним паралельним.
Використання історичних станів виправдане у тому випадку, коли необхідно організувати обробку виняткових ситуацій без втрати даних або виконаної роботи. При цьому застосовувати історичні стани потрібно обережно. Кожен із підавтоматів може мати тільки один історичний стан. В іншому випадку можливі помилки, особливо коли підавтомати зображаються на окремих діаграмах станів.