Діаграма станів (діаграма автомата) UML
- Діаграма станів (діаграма автомата) UML Для чого використовується техніка креативності
- План дій
- Зауваження (опис)
- Як застосовувати техніку креативності
- як навчитися
- приклад використання
- Внутрішні активності в діаграмі станів
- Стану активності в діаграмі станів
- Суперсостоянія
- паралельні стану
- Реалізація діаграм станів
Діаграма станів (діаграма автомата) UML Для чого використовується техніка креативності
Показати поведінку одного об'єкта протягом його життя, починаючи від створення об'єкта і закінчуючи його знищенням. Кожна діаграма станів представляє певний автомат.
План дій
У розділі «Опис» вивчіть основний набір символів діаграми станів, необхідний для того, щоб вміти читати діаграми.
Після ознайомлення з іншими розділами ( «Приклад», «Застосування») ви можете спробувати свої сили в самостійному складанні діаграм станів.
Зауваження (опис)
Тут представлений основний набір символів діаграми станів, необхідний для того, щоб зуміти прочитати діаграму. Після ознайомлення з іншими розділами ( «Приклад», «Застосування») ви зможете складати діаграми станів самостійно!
Як застосовувати техніку креативності
Діаграми станів UML гарні для опису поведінки одного об'єкта в декількох прецедентах. Але вони не дуже підходять для опису поведінки, що характеризується взаємодією безлічі об'єктів. Тому має сенс спільно з діаграмами станів застосовувати інші технології. Наприклад, діаграми взаємодії (глава 4) прекрасно описують поведінку декількох об'єктів в одному прецедент, а діаграми діяльності UML гарні для показу основної послідовності дій декількох об'єктів в декількох прецедентах.
Не всі вважають діаграми станів природними. Поспостерігайте, як фахівці працюють з ними. Цілком можливо, що члени вашої команди не думають, що діаграми станів підходять для їх стилю роботи. Це не найбільша трудність; ви повинні не забувати спільно використовувати різні прийоми роботи.
Якщо ви застосовуєте діаграми станів, щось не намагайтеся намалювати їх для кожного класу системи. Такий підхід часто застосовується з метою формально суворої повноти, але майже завжди це марна трата сил. Застосовуйте діаграми станів тільки для тих класів, які виявляють цікаве поведінку, коли побудова діаграми станів допомагає зрозуміти, як все відбувається.
Багато фахівців вважають, що редактор UI і керуючі об'єкти мають функціональні засоби, корисні при відображенні за допомогою діаграми станів.
як навчитися
Тут ми спробували надати якомога простіший спосіб вивчення діаграми станів мови UML.
Як і багато інших мов він використовує для опису набір знаків. Сенс цих знаків ви знайдете в таблиці в розділі «Зауваження (опис)». Кожен знак має своє найменування (термін) і написання. Також кожен термін забезпечений коротким поясненням, щоб швидко усвідомити його основну суть.
Далі ми б рекомендували перейти в розділ «Приклади» діаграм станів, щоб спробувати свої сили в читанні різних діаграм. Потім варто вивчити розділ «Застосування», так як, хоча і кількість типів діаграм в UML невелика, максимум переваг від їх використання ви зможете отримати тільки якщо будете застосовувати відповідні діаграми за призначенням.
приклад використання
Діаграма станів UML
Діаграма станів (state machine diagrams) - це відома технологія опису поведінки системи. У тому чи іншому вигляді діаграма станів існує з 1960 року, і на зорі об'єктно-орієнтованого програмування вони застосовувалися для подання поведінки системи. В об'єктно-орієнтованих підходах ви малюєте діаграму станів єдиного класу, щоб показати поведінку одного об'єкта протягом його життя.
Всякий раз, коли пишуть про кінцевих автоматах, в якості прикладів неминуче призводять системи круїз-контролю або торгові автомати.
Ми вирішили використовувати контролер секретної панелі управління в готичному замку. У цьому замку ми хочемо так заховати свої скарби, щоб їх було важко знайти. Для того щоб отримати доступ до замку сейфа, ми повинні витягти з канделябра стратегічну свічку, але замок з'явиться, тільки якщо двері закриті. Після появи замку ми можемо вставити в нього ключ і відкрити сейф. Для додаткової безпеки ми зробили так, щоб сейф можна було відкрити тільки після вилучення свічки. Якщо злодій не зверне уваги на цю обережність, то ми спустимо з ланцюга огидного монстра, який проковтне злодія.
На рис. 10.1 показана діаграма станів класу контролера, який керує моєї незвичайної системою безпеки. Діаграма стану починається з стану створюваного об'єкта контролера: стану Wait (Очікування). На діаграмі це позначено за допомогою початкового псевдосостоянія (initial pseudostate), яке не є станом, але має стрілку, що вказує на початковий стан.
На діаграмі показано, що контролер може перебувати в одному з трьох станів: Wait (Очікування), Lock (Замок) і Open (Відкритий). На діаграмі також представлені правила, згідно з якими контролер переходить з одного стану в інший. Ці правила представлені у вигляді переходів - ліній, що пов'язують стану.
Перехід (transition) означає переміщення з одного стану в інший. Кожен перехід має свою мітку, яка складається з трьох частин:
тригер-ідентифікатор [захист] / активність (trigger-signature [guard] / activity). Всі вони не обов'язкові. Як правило, тригер-ідентифікатор - це єдина подія, яка може викликати зміну стану.
Захист, якщо вона вказана, являє собою логічне умова, яка має бути виконана, щоб перехід мав місце. Активність - це деякий поведінку системи під час переходу. Це може бути будь-який поведінковий вираз. Повна форма тригера-ідентифікатора може включати кілька подій і параметрів. Перехід зі стану Wait (рис. 10.1) в інший стан можна прочитати як «В стані Wait, якщо свічка видалена, ви бачите замок і переходите в стан Lock».
Всі три частини опису переходу не обов'язкові. Пропуск активності означає, що в процесі переходу нічого не відбувається. Пропуск за щити означає, що перехід завжди здійснюється, якщо відбувається ініціює подія. Тригер-ідентифікатор відсутній рідко, але і так буває. Це означає, що перехід відбувається негайно, що можна спостерігати головним чином в станах активності.
Коли в певному стані відбувається подія, то з цього стану можна зробити тільки один перехід, наприклад в стані Lock (рис. 10.1) захисту повинні бути взаємно виключають. Якщо подія відбувається, а дозволених переходів немає - наприклад закриття сейфа в стані Wait або видалення свічки при відкритих дверях, - подія ігнорується.
Кінцевий стан (final state) означає, що кінцевий автомат закінчив роботу, що викликає видалення об'єкта контролера. Так що для тих, хто мав необережність потрапити в пастку, повідомляємо, що оскільки об'єкт контролера припиняє своє існування, ми змушені посадити кролика назад в клітку, вимити підлогу і перевантажити систему.
Пам'ятайте, що кінцеві автомати можуть показувати тільки ті об'єкти, які безпосередньо спостерігаються або діють. Тому, хоча ви могли очікувати, що ми покладемо що-небудь в сейф або що-небудь візьмемо звідти, коли двері відкриті, ми не відзначили це на діаграмі, оскільки контролер про це нічого повідомити не може.
Коли розробники кажуть про об'єкти, вони часто посилаються на стан об'єктів, маючи на увазі комбінацію всіх даних, що містяться в полях об'єктів. Однак стан на діаграмі кінцевого автомата є більш абстрактним поняттям стану; суть в тому, що різні стани припускають різні способи реакції на події.
Внутрішні активності в діаграмі станів
Стану можуть реагувати на події без здійснення переходу, використовуючи внутрішні активності (internal activities), і в цьому випадку подія, захист і активність розміщуються всередині прямокутника стану.
На рис. 10.2 представлено стан з внутрішніми активностями символів і подіями системи допомоги, які ви можете спостерігати в текстових полях редактора UI. Внутрішня активність подібна самопереходу (self-transition) - переходу, який повертає в той же самий стан. Синтаксис внутрішніх активностей побудований по тій же логічній схемі події, захисту та процедури.
На рис. 10.2 показані також спеціальні активності: вхідний і вихідний активності. Вхідна активність виконується всякий раз, коли ви входите в стан; вихідна активність - щоразу, коли ви залишаєте стан. Однак внутрішні активності не ініціюють вхідну і вихідну активності; в цьому полягає відмінність між внутрішніми активностями та самопереходамі.
Стану активності в діаграмі станів
У станах, які ми описували досі, об'єкт мовчить і чекає наступного події, перш ніж що-небудь зробити. Однак можливі стану, в яких об'єкт проявляє деяку активність.
Стан Searching (Пошук) на рис. 10.3 є таким станом активності (activity state): ведеться активність позначається символом do /; звідси термін do-activity (проявляти активність). Після того як пошук завершено, виконуються переходи без активності, наприклад показ нового обладнання (Display New Hardware). Якщо в процесі активності відбувається подія скасування (cancel), то do-активність просто переривається і ми повертаємося в стан Update Hardware Window (Оновлення вікна обладнання). 
І do-активності, і звичайні активності представляють прояв деякого поведінки. Вирішальне відмінність між ними полягає в тому, що звичайні активності відбуваються «миттєво» і не можуть бути перервані звичайними подіями, тоді як do-активності можуть виконуватися протягом деякого обмеженого часу і можуть перериватися, як показано на рис. 10.3. Миттєвість для різних систем трактується по-різному; для систем реального часу це може займати кілька машинних інструкцій, а для настільного програмного забезпечення може скласти кілька секунд.
В UML 1 звичайні активності позначалися терміном action (дія), а термін activity (активність) застосовувався тільки для do-активностей.
Суперсостоянія
Часто буває, що кілька станів мають загальні переходи і внутрішні активності. У таких випадках можна їх перетворити в підстану (substates), а загальна поведінка перенести в суперсостояніе (superstate), як показано на рис. 10.4. Без суперсостоянія довелося б малювати перехід cancel (скасування) для всіх трьох станів всередині стану Enter Connection Details (Введення подробиць з'єднання).
паралельні стану
Стану можуть бути розбиті на декілька паралельних станів, що запускаються одночасно. На рис. 10.5 показаний простий будильник, який може включати або CD, або радіо і показувати або поточний час, або час сигналу.
Опції CD / радіо і поточний час / час сигналу є паралельними. Якби ви захотіли уявити це за допомогою діаграми непаралельних станів, то вийшла б безладна діаграма при необхідності додати стану. Поділ двох областей поведінки на дві діаграми станів робить її значно ясніше.
Мал. 10.5 включає також стан передісторії (history pseudostate). Це означає, що коли включені годинник, опція радіо / CD переходить в стан, в якому знаходилися годинник, коли вони були вимкнені. Стрілка, що виходить з передісторії, показує, який стан існувало спочатку, коли була відсутня передісторія.
Реалізація діаграм станів
Діаграму станів можна реалізувати трьома основними способами: за допомогою вкладеного оператора switch, паттерна State і таблиці станів. Самий прямий підхід в роботі з діаграмами станів - це вкладений оператор switch, такий як на рис. 10.6.
Хоча цей спосіб і прямий, але дуже довгий навіть для цього простого випадку. Крім того, при даному підході дуже легко втратити контроль, тому не рекомендуємо застосовувати його навіть в елементарних ситуаціях.
Патерн «Стан» (State pattern) представляє ієрархію класів станів для обробки поведінки станів. Кожне стан на діаграмі станів має свій підклас стану. Контролер має методи для кожної події, які просто перенаправляють до класу стану. Діаграма станів, показана на рис. 10.1, могла б бути реалізована за допомогою класів, представлених на рис. 10.7.
Вершиною ієрархії є абстрактний клас, який містить опис всіх методів, що обробляють події, але без реалізації.
Для кожного конкретного стану досить переписати метод-обробник певної події, що ініціює перехід зі стану.
Таблиця станів представляє діаграму станів у вигляді даних.
Так, діаграма на рис. 10.1 може бути представлена у вигляді табл. 10.1.
Потім ми будуємо інтерпретатор, який використовує таблицю станів під час виконання програми, або генератор коду, який породжує класи на основі цієї таблиці.
Очевидно, велика частина роботи над таблицею станів проводиться один раз, але потім її можна використовувати всякий раз, коли треба вирішити проблему, пов'язану з станами. Таблиця станів часу виконання може бути модифікована без перекомпіляції, що в деякому сенсі зручно. Шаблон станів зібрати легше, і хоча для кожного стану потрібен окремий клас, але розмір коду, який при цьому треба написати, зовсім невеликий.
Наведені реалізації практично мінімальні, але вони дають уявлення про те, як застосовувати діаграми станів. У кожному разі реалізація моделей станів призводить до досить стереотипної програмою, тому зазвичай для цього краще вдатися до того чи іншого способу генерації коду.
Підписуйтесь на новини сайту, форму підписки ви можете знайти в правій колонці сайту.
Якщо ви хочете навчитися працювати на фрілансі професійно, запрошуємо на курс « Як заробляти на фрілансі ».
Перейти на сторінку курсу
Якщо вам сподобалася стаття - поділіться посиланням з друзями!