Роздрукувати сторінку
Главная \ Методичні вказівки \ Методичні вказівки \ 1643 Лабораторна робота №3 на тему Діаграма станів (Statechart Diagram)

Лабораторна робота №3 на тему Діаграма станів (Statechart Diagram)

« Назад

Лабораторна робота №3

Діаграма станів (Statechart Diagram)

Мета роботи: для заданої предметної області побудувати діаграму станів.

 

Теоретичні відомості

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

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

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

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

1. Автомати

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

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

Рис. 3.1. Простий приклад діаграми станів для технічного пристрою типу “комп'ютер”.

Граф автомата не повинен містити ізольованих станів і переходів. Ця умова означає, що для кожного зі станів, окрім початкового, має бути визначений попередній стан. Кожний перехід має обов'язково сполучати два стани автомата. Допускається перехід зі стану в себе самою, такий перехід ще називають "петлею".

2. Стан

Поняття стану (state) є фундаментальним не тільки в метамоделі мови UML, але й у прикладному системному аналізі. Раніше у розділі 3 коротко були розглянуті особливості відображення динамічних характеристик складних систем, традиційно використовуваних для моделювання поведінки. Вся концепція динамічної системи ґрунтується на понятті стану системи. Проте семантика мови UML має цілий ряд специфічних особливостей.

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

Стани на діаграмі зображаються прямокутником з округленими вершинами (рис. 3.2). 

Рис. 3.2. Графічне зображення станів на діаграмі станів.

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

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

Рис. 3.4. Графічне зображення початкового і кінцевого станів на діаграмі станів.

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

3. Перехід

Простим переходом (simple transition) є відношення між двома послідовними станами, який вказує на факт зміни одного стану іншим.

Перехід здійснюється, коли наступає деяка подія: закінчення виконання діяльності (do activity), отримання об'єктом повідомлення або прийом сигналу. На переході вказується ім'я Події. Крім того, на переході можуть вказуватися дії, що виробляються об'єктом у відповідь на зовнішні події під час переходу з одного стану в інший. Спрацьовування переходу може залежати не тільки від настання деякої події, але й від виконання певної умови, званої сторожовою умовою. Об'єкт перейде з одного стану в інший в тому випадку, якщо відбулася вказана подія і сторожова умова набула значення "істина".

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

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

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

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

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

4. Складений стан і підстан

Складений стан (composite state) – це складний стан, який складається з інших вкладених у нього станів. Останні виступатимуть по відношенню до першого як підстани (substate). Хоча між ними має місце відношення композиції, графічно всі вершини діаграми, які відповідають вкладеним станам, зображаються всередині символа складеного стану (рис. 3.5). У цьому випадку розміри графічного символа складеного стану збільшуються, так щоб вміщувати в себе всі підстани. 

Рис. 3.5. Графічне зображення складеного стану з двома вкладеними в нього послідовними підстанами.

4.1. Послідовні підстани

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

Для прикладу розглянемо звичайний телефонний апарат. Він може перебувати в різних станах, одним з яких є стан телефонування до абонента. Очевидно, щоб зателефонувати, необхідно зняти телефонну трубку, почути тоновий сигнал, після чого набрати потрібний телефонний номер. Отже, стан телефонування до абонента є складеним і передбачає два послідовних підстани: "підняти телефонну трубку" і "набрати телефонний номер". Фраґмент діаграми станів для цього прикладу містить один складений стан і два послідовних підстани (рис. 3.6). 

Рис. 3.6. Приклад складеного стану з двома вкладеними послідовними підстанами.

4.2. Паралельні підстани

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

Проте окремі паралельні підстани можуть, своєю чергою, складатися з декількох послідовних підстанів (підавтомати 1 і 2 на рис. 3.7). У цьому випадку за визначенням об'єкт може перебувати тільки в одному з послідовних підстанів підавтомата. Отже, для абстрактного прикладу (рис. 17.8) допустиме одночасне перебування об'єкту в підстанах (1, 3, 4) (2, 3, 4) (1, 3, 5) (2, 3, 5). Неприпустимо знаходження об'єкту одночасно в підстанах (1, 2, 3) або (3, 4, 5). 

Рис. 3.7. Графічне зображення складеного стану із  вкладеними паралельними підстанами.

5. Історичний стан

Історичний стан (history state) застосовується в контексті складеного стану. Він використовується для запам'ятовування того з послідовних підстанів, який був поточним у момент виходу зі складеного стану. При цьому існує два різновиди історичного стану: недавній і давній (рис. 3.8). 

Рис. 3.8. Графічне зображення недавнього (а) і давнього (б) історичного стану.

Недавній історичний стан (shallow history state) позначається у формі невеликого кола, у яке вміщена латинська літера "Н" (рис. 3.8, а).

Давній історичний стан (deep history state) позначається у формі невеликого кола, в яке вміщена латинська літера "Н" із символом "*" (рис. 3.8, б) і служить для запам'ятовування всіх підстанів будь-якого рівня вкладеності для поточного підавтомата.

Хід роботи

  1. Ознайомитися з теоретичними відомостями.

  2. Побудувати відповідну діаграму за допомогою UML згідно до своєї предметної області.

  3. Оформити звіт за результатами лабораторної роботи.

Зміст звіту

  1. Мета роботи

  2. Короткі теоретичні відомості.

  3. Хід роботи.

  4. Висновки. 

Література

  1. Кальянов  Г.Н. Case -  технологии.  Консалтинг  при  автоматизации бизнес-процессов. - 15.е изд. М.: Горячая линия – Телеком, 2002. - 320 с.

  2. Кирстен В. Объектно-ориентированная разработка приложений в среде постреляционной СКБД CACHE / Кирстен В., Ирингер М., Шульте П  - СП-б: АОЗТ “СП. АРМ”,  2000.

  3. Пасічник В.В. Організація баз даних та знань / В.В.Пасічник, В.А.Резніченко. – Київ: BHV „ПИТЕР”, 2006. – 460с.

  4. Крэг Ларман Применение UML 2.0 и шаблонов проектирования = Applying UML and Patterns : An Introduction to Object-Oriented Analysis and Design and Iterative Development. — 3-е изд. — М.: «Вильямс», 2006. — 736 с. — ISBN 0-13-148906-2

  5. Джозеф Шмуллер Освой самостоятельно UML 2 за 24 часа. Практическое руководство = Sams Teach Yourself UML in 24 Hours, Complete Starter Kit. — М.: «Вильямс», 2005. — 416 с. — ISBN 0-672-32640-X

  6. Грейди Буч. Язык UML. Руководство пользователя = The Unified Modeling Language user guide / Грейди Буч, Джеймс Рамбо, Айвар Джекобсон. — 2. — М., СПб.: «ДМК Пресс», «Питер», 2004. — 432 с. — ISBN 5-94074-260-2

  7. Буч Г. UML. Классика CS. 2-е изд. / Буч Г., Якобсон А., Рамбо Дж. / Пер. с англ.; Под общей редакцией проф. С. Орлова — СПб.: Питер, 2006. — 736 с.

  8. Нікольський Ю.В. Дискретна математика / Ю.В.Нікольський, В.В.Пасічник, Ю.М.Щербина – Львів: Магнолія Плюс, 2007. – 608 с.

  9. Шаховська Н.Б. Сховища даних / Шаховська Н.Б., Пасічник В.В. – Львів: «Магнолія-2006», 2008. – 485 с.

З повагою ІЦ "KURSOVIKS"!