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

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

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

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

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

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

20.3.1. Подія

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

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

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

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

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

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

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

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

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

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

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

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

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

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