Новини освіти і науки:

G+

Тлумачний словник
Авто
Автоматизація
Архітектура
Астрономія
Аудит
Біологія
Будівництво
Бухгалтерія
Винахідництво
Виробництво
Військова справа
Генетика
Географія
Геологія
Господарство
Держава
Дім
Екологія
Економетрика
Економіка
Електроніка
Журналістика та ЗМІ
Зв'язок
Іноземні мови
Інформатика
Історія
Комп'ютери
Креслення
Кулінарія
Культура
Лексикологія
Література
Логіка
Маркетинг
Математика
Машинобудування
Медицина
Менеджмент
Метали і Зварювання
Механіка
Мистецтво
Музика
Населення
Освіта
Охорона безпеки життя
Охорона Праці
Педагогіка
Політика
Право
Програмування
Промисловість
Психологія
Радіо
Регилия
Соціологія
Спорт
Стандартизація
Технології
Торгівля
Туризм
Фізика
Фізіологія
Філософія
Фінанси
Хімія
Юриспунденкция

Діаграми станів

Діаграма станів взаємно пов’язує події та стани. У разі приймання події наступний стан системи залежить як від поточного стану, так і від події. Зміна стану називається переходом.

Рис. 47 . Діаграма станів телефонної лінії

Діаграма станів — це граф, вузли якого подають стан, а напрямлені дуги, позначені іменами відповідних подій, — переходи. Діаграма станів, наприклад телефонної мережі, дозволяє одержати послідовність станів за заданою послідовністю подій.

5.2. Умови

Умова — це логічна (бульова) функція значень об’єктів, таких як «картку пощастило прочитати», «температура нижча від нуля» і т. ін. Умова може бути виконана протягом деякого проміжку часу. Подія, на відміну від умови, відбувається, як уже зазначалося, миттєво і не має тривалості в часі.

Умови можуть використовуватися як обмеження на переходи: умовний перехід виконується лише тоді, коли відбулася відповідна подія, тобто виконано умову такого переходу. Діаграма станів, подана на рис. 48, унаочнює це на прикладі автомобільного руху по магістралях «Північ—Південь» та «Захід—Схід»). На діаграмах станів умови записуються слідом за подіями у квадратних дужках.

Рис. 48. Діаграма станів, на якій зазначено умови

5.3. Активності та дії

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

Активністю називається операція, пов’язана з деяким станом об’єкта (вона здійснюється, коли об’єкт набуває зазначеного стану). Виконання активності потребує певного часу.

Приклади активностей: видача картинки на екран телевізора, телефонний дзвінок; зчитування порції файла в буфер і т. ін. Іноді активністю буває просто зупинка виконання програми (пауза), яка має забезпечити необхідний час перебування у відповідному стані (це особливо важливо в разі паралельної асинхронної програми). Активність пов’язана зі станом, тому на діаграмі станів вона позначається «do: ім’я активності» у вузлі, який описує відповідний стан (рис. 49).

Рис. 49. Позначення активностей
і дій на діаграмі станів

Дією називається миттєва операція, пов’язана з подією: при настанні події відбувається не лише перехід об’єкта до нового стану, а й виконується дія, пов’язана із цією подією. Наприклад,
у телефонній мережі подія «повісив трубку» супроводжується дією «роз’єднати зв’язок» (рис. 50). Дія, яка вказує на діаграмі стан, що настає услід за подією, якій дія відповідає, та ім’я (чи опис) стану відокремлюються від імені події скісною рискою («/») (рис. 49).

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

Рис. 50. Діаграма станів телефонної лінії, на якій вказані активності та дії

5.4. Одночасні події. Синхронізація

Діаграма стану складового об’єкта: він складається з чотирьох паралельно і незалежно працюючих компонентів (стан кожного компонента не залежить від станів інших компонентів). Стан такого об’єкта визначається як кортеж, членами якого є стани кожного зі складових об’єктів. Діаграма станів при цьому розпадається на чотири незалежні діаграми станів кожного з компонентів (див. також п. 5).

Рис. 51. Діаграма станів складового об’єкта (підсистеми)

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

Рис. 52. Передача подій від одного об’єкта до іншого

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

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

Синхронізація використовується і в разі, коли в деякому стані потрібно паралельно виконати кілька активностей. Розглянемо, наприклад, пристрій виводу АТМ (рис. 53). Він одночасно (паралельно) видає готівку та картку. Обидві ці операції можна розглядати як складену активність, утворену з двох активностей, що працюють паралельно (пунктирна лінія на діагоналі станів поділяє стан на дві області, в кожній з яких виконується одна із зазначених активностей). Поділ управління на два паралельних потоки схематично зображається у вигляді стрілки, яка розгалужується на дві: подія «Готовий» спричинює перехід зі стану «Установлення» відразу до двох паралельних підстанів стану «Видача». Перехід до наступного стану відбувається за двома станами «Гроші взяті» та «Картка взята». Якщо якийсь із цих станів здійсниться раніше від іншого, переходу все одно не буде, доки не досягнеться й інший стан (саме в цьому й полягає синхронізація).

Рис. 53. Синхронізація в підсистемі

Із розглянутого прикладу бачимо, що в різних станах може паралельно працювати різне число процесів (активностей).

5.5. Вкладені діаграми станів

Діаграма станів компонента «трансмісія» (див. рис. 51) має вузол (стан) «вперед», який сам є діаграмою станів (вкладена діаграма станів). Інтерпретація цієї діаграми така: «трансмісія» має три стани: «нейтральний», «назад», «уперед»; стан «вперед» має три підстани (вони уточнюють стан «уперед»): «перший», «другий», «третій». На діаграмах станів суперстан зображується як прямокутник із заокругленими кутами, усередину якого вміщуються всі його підстани.

5.6. Динамічна модель
банківської мережі

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

АТМ просить клієнта вставити картку Клієнт вставляє картку АТМ приймає картку та читає її номер АТМ просить ввести пароль Клієнт вводить «1234.» АТМ передає номер та пароль у консорціум Консорціум перевіряє номер та пароль Визначає код банку — «39» та повідомляє АТМ, що запит прийнято АТМ просить клієнта (за допомогою меню на екрані) вибрати вид проведення (зняття, вклад, переказ, запит) Клієнт вибирає зняття АТМ запитує клієнта, яка сума вимагається Клієнт вводить $ 100 АТМ переконується, що введена сума в межах ліміту та просить консорціум здійснити проведення Консорціум передає запит до банку Банк виконує проведення та повертає нове значення балансу рахунку АТМ видає суму та просить клієнта взяти її Клієнт бере гроші АТМ запитує, чи не потрібно клієнтові ще чого Клієнт вводить ні АТМ друкує рахунок, видає картку та просить клієнта взяти її Клієнт бере рахунок та картку АТМ просить (іншого) клієнта ввести картку

Рис 54. Нормальний сценарій для банківської мережі

АТМ просить клієнта вставити картку Клієнт вставляє картку АТМ приймає картку і читає її номер АТМ просить ввести пароль Клієнт вводить «9999.» АТМ передає номер та пароль у консорціум; консорціум, проконсультувавшись із відповідним банком, відмовляє в запиті АТМ повідомляє, що пароль введено неправильно Клієнт вводить «1234.» АТМ передає номер та пароль у консорціум Консорціум перевіряє номер та пароль, визначає код банку — «39» та повідомляє АТМ, що запит прийнято АТМ просить вибрати вид проведення Клієнт вибирає зняття АТМ запитує, яка сума вимагається Клієнт (передумав брати гроші) набирає відміну АТМ видає картку та просить клієнта взяти її Клієнт бере картку АТМ просить (іншого) клієнта вставити картку

Рис. 55. Сценарій для банківської мережі, яка містить
в собі виняткові ситуації

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

Рис. 56. Траса подій у банківській мережі

Маючи траси подій, можна побудувати діаграми станів об’єктів проектованої системи. Банківська система є агрегацією певного числа паралельно та незалежно працюючих об’єктів чотирьох класів: «консорціум», «банк», «АТМ (банкомат)» та «клієнт». Тому стан банківської мережі визначається як кортеж станів об’єктів, з яких вона складається: один об’єкт класу «консорціум», b об’єктів класу «банк», a об’єктів класу «АТМ (банкомат)» та c об’єктів класу «клієнт» (a, b, c — кількість відповідно АТМ, банків та клієнтів мережі). Класифікація об’єктів, застосовувана в разі об’єктно-орієнтованого підходу, дозволяє замість a + b + 1 діаграм станів побудувати лише три (діаграми станів клієнтів будувати не потрібно, оскільки їх теперішній стан зрозумілий і без того).

Рис. 57. Прив’язування подій до об’єктів
банківської мережі

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

Діаграми станів об’єктів класів «АТМ (банкомат)», «консорціум» і «банк» наведено на рис. 58—60 відповідно.

Рис. 58. Діаграма станів об’єктів класу «АТМ (банкомат)»

Рис. 59. Діаграма станів об’єктів класу «консорціум»

Рис. 60. Діаграма станів об’єктів класу «банк»

<== попередня сторінка	\|	наступна сторінка ==>
Сценарії та траси подій	\|

Не знайшли потрібну інформацію? Скористайтесь пошуком google:

Генерація сторінки за: 0.006 сек.