Стан та його графічне зображення
Моделювання поведінки об'єктів і системи в цілому ґрунтується на понятті стану.
Стан (state) - умова чи ситуація в ході життєвого циклу об'єкта, протягом якого він задовольняє логічному умові, виконує певну діяльність або очікує події.
Стан може бути задано у вигляді набору конкретних значень атрибутів об'єкта деякого класу, при цьому зміна окремих значень цих атрибутів буде відображати зміну стану модельованого об'єкта або системи в цілому. Однак не кожен атрибут класу може характеризувати стан його об'єктів. Як правило, мають значення тільки ті властивості елементів системи, які відображають динамічний або функціональний аспект її поведінки. У цьому випадку стан буде характеризуватися деяким інваріантним умовою, що включає в себе лише принципові для поводження об'єкта або системи атрибути класів та їх значення.
Така умова може відповідати ситуації, коли модельований об'єкт знаходиться в стані очікування виникнення зовнішнього події. У той же час знаходження об'єкта в деякому стані може бути пов'язане з виконанням певних дій. В останньому випадку відповідна діяльність починається в момент переходу модельованого елемента в розглядається стан, а після і елемент може покинути даний стан у момент завершення цієї діяльності.
Стан на діаграмі зображується прямокутником із закругленими вершинами (рис. 9.1). Цей прямокутник, у свою чергу, може бути розділений на дві секції горизонтальною лінією. Якщо вказана лише одна секція, то в ній записується тільки ім'я стану (рис. 9.1, а). В іншому випадку в першій з них записується ім'я стану, а в другій - список деяких внутрішніх дій або переходів в даному стані (рис. 9.1, б). При цьому під дією в мові UML розуміють деяку атомарну операцію, виконання якої призводить до зміни стану або поверненню деякого значення (наприклад, "істина" або "брехня").
Графічне зображення станів на діаграмі станів
Рис. 9.1. Графічне зображення станів на діаграмі станів
Ім'я стану представляє собою рядок тексту, яка розкриває змістовний сенс або семантику даного стану. Ім'я повинно являти собою закінчену пропозицію і завжди записуватися з великої літери. Оскільки стан системи є частиною процесу її функціонування, рекомендується в якості імені використовувати дієслова в теперішньому часі або відповідні причастя. Як виняток, ім'я у стану може бути відсутнім, тобто воно необов'язково для деяких станів. У цьому випадку стан є анонімним. Якщо на одній діаграмі станів кілька анонімних станів, то всі вони повинні розрізнятися між собою.
Дія (action) - специфікація здійсненного твердження, яка утворює абстракцію обчислювальної процедури.
Дія зазвичай призводить до зміни стану системи, і може бути реалізовано за допомогою передачі повідомлення об'єкту, модифікацією зв'язку або значення атрибуту. Для ряду станів може знадобитися додатково вказати дії, які повинні бути виконані модельований елементом. Для цієї мети служить додаткова секція в позначенні стану, що містить перелік внутрішніх дій чи діяльність, які виробляються в процесі знаходження модельованого елемента в даному стані. Кожна дія записується у вигляді окремого рядка і має наступний формат:
<Мітка дії '/' вираз дії>
Мітка дії вказує на обставини або умови, за яких буде виконуватися діяльність, визначена виразом дії. При цьому вираз дії може використовувати будь-які атрибути та зв'язки, що належать області імен або контексту модельованого об'єкта. Якщо список виразів дії порожній, то мітка дії з роздільником у вигляді похилої риси '/' не вказується. Перелік міток дій в мові UML фіксований, причому ці мітки не можуть бути використані в якості імен подій:
Вхідна дія (entry action) - дія, яка виконується в момент переходу в даний стан.
Позначається за допомогою ключового слова - мітки дії entry, яке вказує на те, що наступне за нею вираз дії повинно бути виконано в момент входу в даний стан.
Дія виходу (exit action) - дія, вироблене при виході з цього стану.
Позначається за допомогою ключового слова - мітки дії exit, яке вказує на те, що наступне за нею вираз дії повинно бути виконано в момент виходу з цього стану.
Внутрішня діяльність (do activity) - виконання об'єктом операцій або процедур, які вимагають певного часу.
Позначається за допомогою ключового слова - мітки діяльності do, яке специфікує так звану "ду-діяльність", виконувану протягом усього часу, поки об'єкт знаходиться в даному стані, або до тих пір, поки не буде перервано зовнішнім подією. При нормальному завершенні внутрішньої діяльності генерується відповідна подія.
У всіх інших випадках мітка дії ідентифікує подію, яка запускає відповідний вираз дії. Ці події називаються внутрішніми переходами. Семантично вони еквівалентні переходам в саме цей стан, за винятком тієї особливості, що вихід з цього стану або повторний вхід в нього не відбувається. Це означає, що дії входу і виходу не виробляються. При цьому виконання внутрішніх дій в стані не може бути перервано ніякими зовнішніми подіями, на відміну від внутрішньої діяльності, виконання якої вимагає певного часу.
Як приклад стану можна розглянути аутентифікацію клієнта для доступу до ресурсів моделюється інформаційної системи (рис. 9.2). Список внутрішніх дій в даному стані може включати наступні дії. Перша дія - вхідна, яке виконується при вході в цей стан і пов'язане з отриманням рядки символів, відповідних паролю клієнта. Далі виконується діяльність з перевірки введеного клієнтом пароля. При успішному завершенні цієї перевірки виконується дія на виході, яке відображає меню доступних для клієнта опцій.
Рис. 9.2. Приклад стану з непорожній секцією внутрішніх дій
Крім звичайних станів на діаграмі станів можуть розміщуватися псевдосостоянія.
Псевдосостояніе (pseudo-state) - вершина в кінцевому автоматі, яка має форму стану, але не володіє поведінкою.
Прикладами псевдосостояній, які визначені в мові UML, є початкове і кінцеве стану.
Початковий стан (start state) - різновид псевдостану що позначає початок виконання процесу зміни станів кінцевого автомата або знаходження модельованого об'єкта в складеному стані.
У цьому стані знаходиться об'єкт за умовчанням в початковий момент часу. Воно служить для вказівки на діаграмі станів графічній області, від якої починається процес зміни станів. Графічно початковий стан в мові UML позначається у вигляді зафарбованого кружка (рис. 9.3, а), з якого може тільки виходити стрілка-перехід.
Графічне зображення початкового і кінцевого станів на діаграмі станів
Рис. 9.3. Графічне зображення початкового і кінцевого станів на діаграмі станів
На самому верхньому рівні представлення об'єкту перехід з початкового стану може бути позначений подією створення (ініціалізації) даного об'єкта. В іншому випадку цей перехід ніяк не позначається. Якщо цей перехід не позначений, то він є першим переходом на діаграмі станів в наступне за ним стан. Кожна діаграма або під-діаграма станів повинна мати єдине початковий стан.
Кінцевий стан (final state) - різновид псевдостану, що позначає припинення процесу зміни станів кінцевого автомата або знаходження модельованого об'єкта в складеному стані.
У цьому стані повинен перебувати модельований об'єкт або система за замовчуванням після завершення роботи кінцевого автомата. Воно служить для вказівки на діаграмі станів графічній області, в якій завершується процес зміни станів або життєвий цикл даного об'єкта. Графічно кінцевий стан в мові UML позначається у вигляді зафарбованого кружка, поміщеного в коло (рис. 9.3, б), в яку може тільки входити стрілка-перехід. Кожна діаграма станів або підстану може мати кілька кінцевих станів, при цьому всі вони вважаються еквівалентними на одному рівні вкладеності станів.
Перехід та подія
Перебування модельованого об'єкта або системи в першому стані може супроводжуватися виконанням деяких внутрішніх дій або діяльності. При цьому зміна поточного стану об'єкта буде можливо або після завершення цих дій (діяльності), або при виникненні деяких зовнішніх подій. В обох випадках говорять, що відбувається перехід об'єкта з одного стану в інший.
Перехід (transition) - відношення між двома станами, яке вказує на те, що об'єкт в першому стані повинен виконати певні дії та перейти в друге стан.
Перехід здійснюється при настанні деякої події: закінчення виконання діяльності (do activity), отриманні об'єктом повідомлення або прийомом сигналу. На переході вказується ім'я події, а також дії, вироблені об'єктом у відповідь на зовнішні події при переході з одного стану в інший.
Перехід може бути спрямований в той же стан, з якого він виходить. У цьому випадку його називають переходом в себе. Початкове і цільове стану переходу в себе співпадають. Цей перехід зображується петлею із стрілкою і відрізняється від внутрішнього переходу. При переході в себе об'єкт покидає початковий стан, а потім знову входить в нього. При цьому всякий раз виконуються внутрішні дії, специфіковані мітками entry і exit.
Спрацьовування <переходу> (fire) - виконання переходу з одного стану в інший.
Спрацьовування переходу може залежати не тільки від настання події, але і від виконання певної умови, званої охоронною. Об'єкт перейде з одного стану в інший в тому випадку, якщо відбулося зазначене подія і охоронна умова прийняло значення "істина". До спрацьовування переходу об'єкт знаходиться в попередньому від нього стані, званим вихідним, або в джерелі (не плутати з початковим станом - це різні поняття), а після його спрацьовування об'єкт знаходиться в подальшому від нього стані (цільовому стані).
На діаграмі станів перехід зображується суцільною лінією зі стрілкою, яка виходить з вихідного стану і спрямована в цільовий стан (наприклад, вихід з ладу на рис. 9.1). Кожен перехід може бути позначений рядком тексту, яка має наступний загальний формат:
<Ім'я події> '(' <список параметрів, розділених комами> ')''[' <Охоронна умова> ']'<Вираз дії>.
Подія (event) - специфікація істотних явищ у поведінці системи, які мають місце розташування у часі і просторі.
Формально, подія являє собою специфікацію факту, що має місце в просторі і в часі. Про події говорять, що вони "відбуваються", при цьому окремі події повинні бути впорядковані в часі. Після настання події не можна вже повернутися до попередніх, якщо така можливість явно не передбачена в моделі.
Семантика поняття події фіксує увагу на зовнішніх проявах якісних змін, що відбуваються при переході модельованого об'єкта зі стану в стан. Наприклад, при включенні електричного перемикача відбувається подія, в результаті якого кімната висвітлюється. Після успішного ремонту комп'ютера також відбувається важлива подія - відновлення його працездатності. Якщо підняти трубку звичайного телефону, то, у разі його справності, ми очікуємо почути тоновий сигнал. Це теж є подією.
В UML події грають роль стимулів, які ініціюють переходи з одних станів в інші. В якості подій можна розглядати сигнали, виклики, закінчення фіксованих проміжків часу або моменти закінчення виконання певних дій. В залежності від виду подій, що відбуваються - стимулів у мові UML розрізняють два типи переходів: тригерні і нетригерні.
Перехід називається тригерним, якщо його специфікує подія-тригер, пов'язане із зовнішніми умовами по відношенню до розглянудуваного станом.
У цьому випадку поряд із стрілкою тригерній переходу обов'язково вказується ім'я події в формі рядки тексту, що починається з малої літери. Найбільш часто в якості імен тригерних переходів задають імена операцій, що викликаються у тих чи інших об'єктів системи. Після імені такої події слідують круглі дужки для явного завдання параметрів відповідної операції. Якщо таких параметрів немає, то список параметрів з дужками може бути відсутнім. Наприклад, перехід на рис. 9.4, а, є тригерним, оскільки з ним пов'язано конкретну подію-тригер, що відбувається асинхронно при спрацьовуванні деякого датчика.
Перехід називається нетригерним, якщо він відбувається по завершенні виконання ду-діяльності в даному стані.
Нетригерні переходи часто називають переходами по завершенні ду-діяльності. Для них поруч зі стрілкою переходу не вказується ніякого імені події, а в початковому стані повинна бути описана внутрішня ду-діяльність, по закінченні якої відбудеться той чи інший нетригерний перехід.
Рис. 9.4. Графічне зображення тригерного (а) і нетригерного (б) переходів на діаграмі станів
Охоронна умова (guard condition) - логічне умова, записана в прямих дужках і представляє собою Булевського вираз.
При цьому Булевський вираз має приймати одне з двох взаємно виключають значень: "істина" або "брехня". З контексту діаграми станів повинна явно слідувати семантика цього виразу, а для запису виразу може використовуватися звичайний мову, псевдокод або мова програмування.
Доповнення тригерних і нетригерних переходів сторожовими умовами дозволяє явно специфікувати семантику їх спрацювання. Якщо сторожове умова приймає значення "істина", то відповідний перехід при настанні події-тригера або завершенні діяльності може спрацювати, в результаті чого об'єкт перейде в цільовий стан. Якщо ж сторожове умова приймає значення "брехня", то перехід не може спрацювати, навіть якщо відбулася подія-тригер або завершилася діяльність у вихідному стані. Очевидно, в разі невиконання сторожового умови модельований об'єкт або система залишиться в початковому стані. Однак обчислення істинності сторожового умови в моделі відбувається тільки після виникнення асоційованого з ним події-тригера або завершення діяльності, які ініціюють відповідний перехід.
Оскільки загальна кількість виходять переходів з будь-якого стану в мові UML не обмежена, хоча і є кінцевим, не виключена ситуація, коли з одного стану можуть виходити кілька переходів з ідентичним подією-тригером. Кожен такий перехід повинен містити власне сторожове умова, при цьому жодні два або більше сторожових умов не повинні одночасно приймати значення "істина". В іншому випадку на діаграмі станів виникне конфлікт тригерних переходів, що робить неспроможною (ill formed) модель системи в цілому.
Аналогічне зауваження справедливо і для нетригерних переходів, коли з одного стану виходять кілька переходів по завершенні діяльності. Кожен з таких переходів також повинен утримувати власне сторожове умова, при цьому жодні два або більше сторожових умов не повинні одночасно приймати значення "істина". В іншому випадку на діаграмі станів матиме місце конфлікт нетригерних переходів, що також робить неспроможною (ill formed) модель системи в цілому.
Тригерні і нетригерні переходи на діаграмі станів
Рис. 9.5. Тригерні і нетригерні переходи на діаграмі станів
Зображений фрагмент діаграми станів (рис. 9.5) моделює зміна станів банкомату при перевірці ПІН-коду. Нетригерні переходи на даній діаграмі позначені охоронними умовами, які виключають конфлікт між ними. Що стосується тригерній переходу, поміченого подією скасування транзакції, то він відбувається незалежно від перевірки ПІН-коду в тому випадку, коли клієнт вирішив відмовитися від введення ПІН-коду.
Вираз дії (action expression) являє собою виклик операції або надсилання повідомлення, має атомарний характер і виконується відразу після спрацьовування відповідного переходу до початку дій в цільовому стані.
Вираз дії виконується в тому і тільки в тому випадку, коли перехід спрацьовує. Атомарність дії означає, що воно не може бути перервано ніяким іншим дією до тих пір, поки не закінчиться його виконання. Дана дія може впливати як на сам об'єкт, так і на його оточення, якщо це з очевидністю випливає з контексту моделі. Даний вираз записується після знака "/" в рядку тексту, приєднаної до відповідного переходу.
У загальному випадку, вираз дії може містити цілий список окремих дій, розділених символом ";". Обов'язкова вимога - всі дії зі списку повинні чітко розрізнятися між собою і слідувати в порядку їх запису. На синтаксис запису виразів дії не накладається ніяких обмежень. Головне - їх запис повиний бути зрозумілий розробникам моделі і програмістам. Тому найчастіше вираз записують на одній з мов програмування, який передбачається використовувати для реалізації моделі.
Як приклад виразу дії переходу (рис. 9.6) може служити відображення повідомлення на екрані банкомату в тому випадку, коли запитувана клієнтом сума перевищує залишок на його рахунку. У випадку якщо кредит не перевищений, то відбувається перехід в стан одержання готівки.
Вираз дії переходу на діаграмі станів
Рис. 9.6. Вираз дії переходу на діаграмі станів
Формалізм кінцевих автоматів допускає вкладення одних кінцевих автоматів в інші для уточнення внутрішньої структури окремих більш загальних станів. У цьому випадку вкладені кінцеві автомати отримали назву кінцевих підавтоматов. Підавтомати можуть використовуватися для внутрішньої специфікації процедур і функцій, реалізація яких обумовлює поведінку модельованої системи або об'єкта.