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

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

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

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

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

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

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

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

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

Примітка

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

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