Подякувати Студентському архіву довільною сумою
Admin
26.02.2023 12:38
Дякуємо, що користуєтесь нашим архівом!
Діаграми станів
Інформація про навчальний заклад
ВУЗ:
Інші
Інститут:
Не вказано
Факультет:
Комп’ютерні науки
Кафедра:
Не вказано
Інформація про роботу
Рік:
2009
Тип роботи:
Методичні вказівки до лабораторної роботи
Предмет:
Основи автоматизованого проектування складних об’єктів і систем
Частина тексту файла (без зображень, графіків і формул):
Методичні вказівки
до лабораторної роботи № 6
«Діаграми станів»
з дисципліни
«Основи автоматизованого проектування складних об’єктів та систем»
для студентів базового напрямку підготовки по спеціальності
“Комп’ютерні науки” (шифр 0804)
Львів-2009
Методичні вказівки до лабораторної роботи № 6 “Моделювання станів” з дисципліни “Основи автоматизованого проектування складних об’єктів та систем ” для студентів спеціальності - шифр 0804 “Комп’ютерні науки” Укл. Скрибайло-Леськів Д.Ю.,
Львів: Національний університет “Львівська політехніка”, 2012.
Методичні вказівки обговорено та схвалено на засіданні кафедри АСУ Протокол № ___________ від «___»___________2012 р.
Завідувач кафедрою АСУ ______________ Рашкевич Ю. М.
Методичні вказівки обговорено та схвалено на засіданні методичної комісії базового напрямку підготовки
Протокол № ___________ від «___»___________2012 р.
Мета: Оволодіти навичками моделювання діаграм станів та навчитися реалізовувати їх.
Завдання: Здійснити моделювання діаграм станів за допомогою середовища розробки діаграм Enterprise Architect або в Borland Together.
Теоретичні відомості
Поняття стану (state) є фундаментальним не тільки в метамоделі мови UML, але і в прикладному системному аналізі. Вся концепція динамічної системи грунтується на понятті стану системи. Проте семантика полягання в мові UML має цілий ряд специфічних особливостей.
У мові UML під станом розуміється абстрактний метаклас, використовуваний для моделювання окремої ситуації, протягом якої має місце виконання деякої умови. Стан може бути задане у вигляді набору конкретних значень атрибутів класу або об'єкту, при цьому зміна їх окремих значень відбиватиме зміну стану модельованого класу або об'єкту.
Слід відмітити, що не кожен атрибут класу може характеризувати його стан. Як правило, мають значення тільки такі властивості елементів системи, які відображають динамічний або функціональний аспект її поведінки. В цьому випадку стан характеризуватиметься деякою інваріантною умовою, що включає тільки значущі для поведінки класу атрибути і їх значення.
Наприклад, інваріант може представляти статичну ситуацію, коли об'єкт знаходиться в стані очікування виникнення деякої зовнішньої події. З іншого боку, інваріант використовується для моделювання динамічних аспектів, коли в ході процесу виконуються деякі дії. В цьому випадку модельований елемент переходить в даний стан у момент початку відповідної діяльності і покидає даний стан у момент її завершення.
Рис. 1 Графічне зображення перебувань на діаграмі станів
Перебування на діаграмі зображається прямокутником з вершинами, що округляють (Рис. 1). Цей прямокутник, у свою чергу, може бути роздільний на дві секції горизонтальною лінією. Якщо вказана лише одна секція, то в ній записується тільки ім'я стану (Рис. 1 а). Інакше в першій з них записується ім'я стану, а в другій — список деяких внутрішніх дій або переходів в даному стані (Рис. 1 би). При цьому під дією в мові UML розуміють деяку атомарну операцію, виконання якої приводить до зміни стану або повернення деякого значення (наприклад, "істина" або "брехня").
Ім'я стану
Ім'я стану є рядком тексту, який розкриває змістовний сенс даного стану. Ім'я завжди записується із заголовної букви. Оскільки стан системи є складовою частиною процесу її функціонування, рекомендується як ім'я використовувати дієслова в теперішньому часі (дзвенить, друкує, чекає) або відповідні дієприкметники (зайнятий, вільний, передано, отримано). Ім'я у стану може бути відсутнім, тобто воно є необов'язковим для деяких станів. В цьому випадку стан є анонімним, і якщо на діаграмі станів їх декілька, то всі вони повинні розрізнятися між собою.
Список внутрішніх дій
Ця секція містить перелік внутрішніх дій або деятельностей, які виконуються в процесі знаходження модельованого елементу в даному стані. Кожна з дій записується у вигляді окремого рядка і має наступний формат:
<мітка – дія '/' вираз – дія >
Мітка дії указує на обставини або умови, при яких виконуватиметься діяльність, визначена виразом дії. При цьому вираз дії може використовувати будь-які атрибути і зв'язки, які належать області імен або контексту модельованого об'єкту. Якщо список виразів дії порожній, то роздільник у вигляді похилої межі '/' може не указуватися.
Перелік міток дії має фіксовані значення в мові UML, які не можуть бути використані як імена подій. Ці значення наступні:
entry — ця мітка указує на дію, специфіковану наступним за нею виразом дії, яка виконується у момент входу в даний стан (вхідна дія);
exit — ця мітка указує на дію, специфіковану наступним за нею виразом дії, яка виконується у момент виходу з даного стану (вихідна дія);
do — ця мітка специфікує діяльність ("do activity"), що виконується, яка виконується протягом всього часу, поки об'єкт знаходиться в даному стані, або до тих пір, поки не закінчиться обчислення, специфіковане наступним за нею виразом дії.
У останньому випадку при завершенні події генерується відповідний результат;
include — ця мітка використовується для звернення до підавтомата, при цьому наступний за нею вираз дії містить ім'я цього підавтомата.
У решті всіх випадків мітка дії ідентифікує подію, яка запускає відповідний вираз дії. Ці події називаються внутрішніми переходами і семантично еквівалентні переходам в само це стан, за винятком тієї особливості, що вихід з цього стану або повторний вхід в нього не відбувається. Це означає, що дії входу і виходу не виконуються.
Як приклад стани розглянемо ситуацію введення пароля користувача при аутентифікації входу в деяку програмну систему (Рис. 2). В цьому випадку список внутрішніх дій в даному стані не порожній і включає 4 окремих дії, перші два з яких стандартні і описані вищим, а два останніх визначаються своєю специфікацією.
Рис. 2 Приклад стану з непорожньою секцією внутрішніх дій
Початковий стан
Початковим станом є окремий випадок стану, який не містить ніяких внутрішніх дій (псевдостани). У цьому стані знаходиться об'єкт за умовчанням в початковий момент часу. Воно служить для вказівки на діаграмі станів графічної області, від якої починається процес зміни станів. Графічно початкове полягання в мові UML позначається у вигляді закрашеного кружка (Рис. 3, а), з якого може тільки виходити стрілка, відповідна переходу.
Рис. 3 Графічне зображення початкового і кінцевого перебування на діаграмі станів
На самому верхньому рівні представлення об'єкту перехід з початкового стану може бути помічений подією створення (ініціалізації) даного об'єкту. Інакше перехід ніяк не позначається. Якщо цей перехід не помічений, то він є першим переходом в наступний за ним стан.
Кінцевий стан
Кінцевим (фінальне) станом є окремий випадок стану, який також не містить ніяких внутрішніх дій (псевдостани). У цьому стані знаходитиметься об'єкт за умовчанням після завершення роботи автомата в кінцевий момент часу. Воно служить для вказівки на діаграмі станів графічної області, в якій завершується процес зміни станів або життєвий цикл даного об'єкту. Графічно кінцеве полягання в мові UML позначається у вигляді закрашеного кружка, поміщеного в коло (Рис. 3, би), в яке може тільки входити стрілка, відповідна переходу.
Перехід
Простій переходом (simple transition) є відношення між двома послідовними станами, яке указує на факт зміни одного стану іншим. Перебування модельованого об'єкту в першому стані може супроводжуватися виконанням деяких дій, а перехід в другий стан буде можливий після завершення цих дій, а також після задоволення деяких додаткових умов. В цьому випадку говорять, що перехід спрацьовує, Або відбувається спрацьовування переходу. До спрацьовування переходу об'єкт знаходиться в попередньому від нього стані, званим початковим станом, або в джерелі (не плутати з початковим станом — це різні поняття), а після його спрацьовування об'єкт знаходиться в подальшому від нього стані (цільовому стані).
Перехід здійснюється при настанні деякої події: закінчення виконання діяльності (do activity), отриманні об'єктом повідомлення або прийомом сигналу. На переході указується ім'я події Крім того, на переході можуть указуватися дії, вироблювані об'єктом у відповідь на зовнішні події при переході з одного стану в інше. Спрацьовування переходу може залежати не тільки від настання деякої події, але і від виконання певної умови, званої сторожовою умовою. Об'єкт перейде з одного стану в інше в тому випадку, якщо відбулася вказана подія і сторожова умова прийняло значення "істина".
Примітка. Перехід може бути направлений в той же стан, з якого він виходить. В цьому випадку його називають переходом в себе. Початковий і цільовий стани переходу в себе співпадають. Цей перехід зображається петлею із стрілкою і відрізняється від внутрішнього переходу. При переході в себе об'єкт покидає початковий стан, а потім знову входить в нього. При цьому всякий раз виконуються внутрішні дії, специфіковані мітками entry і exit.
На діаграмі станів перехід зображається суцільною лінією із стрілкою, яка направлена в цільовий стан (наприклад, "вихід з ладу" на Рис. 6.1). Кожен перехід може помічений рядком тексту, який має наступний загальний формат:
<сигнал події>'['<умова>']' <вираз дії>.
При цьому сигнатура події описує деяку подію з необхідними аргументами:
<ім'я події>'('<список параметрів, розділених комами>')'.
Подія
Термін подія (event) вимагає окремого пояснення, оскільки є самостійним елементом мови UML. Формально, подія є специфікацією деякого факту, що має місце в просторі і в часі. Про події говорять, що вони "відбуваються", при цьому окремі події повинні бути впорядковані в часі. Після настання деякої події не можна вже повернутися до попередніх подій, якщо така можливість не передбачена явно в моделі.
Семантика поняття події фіксує увага на зовнішніх проявах якісних змін, що відбуваються під час переходу модельованого об'єкту із стану в стан. Наприклад, при включенні електричного перемикача відбувається деяка подія, в результаті якої кімната стає освітленою. Після успішного ремонту комп'ютера також відбувається важлива подія — відновлення його працездатності. Якщо підняти трубку звичайного телефону, то, у разі його справності, ми чекаємо почути тоновий сигнал. І цей факт теж є подією.
У мові UML події грають роль стимулів, які ініціюють переходи з одних станів в інших. Як події можна розглядати сигнали, виклики, закінчення фіксованих проміжків часу або моменти закінчення виконання певних дій. Ім'я події ідентифікує кожен окремий перехід на діаграмі станів і може містити рядок тексту, що починається з рядкової букви. В цьому випадку прийнято вважати перехід тригерним, тобто таким, який специфікує подію-трігер. Наприклад, переходи на Рис. 1 є тригерними, оскільки з кожним з них пов'язана деяка подія-трігер, що відбувається асихронно у момент виходу з ладу технічного пристрою або у момент закінчення його ремонту.
Якщо поряд із стрілкою переходу не вказаний ніякий рядок тексту, то відповідний перехід є нетригерним, і в цьому випадку з контексту діаграми станів повинно бути ясно, після закінчення якої діяльності він спрацьовує. Після імені події можуть слідувати круглі дужки для явного завдання параметрів відповідної події-трігера. Якщо таких параметрів немає, то список параметрів з дужками може бути відсутнім.
Сторожова умова
Сторожова умова (guard condition), якщо воно є, завжди записується в прямих дужках після події-трігера і є деяким булевим виразом. Нагадаємо, що булевий вираз повинен приймати одне їх двох значень, що взаємно виключають: "істина" або "брехня". З контексту діаграми станів повинна явно виходити семантика цього виразу, а для запису виразу може використовуватися синтаксис мови об'єктних обмежень, основи якої викладені в додатку.
Введення для переходу сторожової умови дозволяє явно специфікувати семантику його спрацьовування. Якщо сторожову умову приймає значення "істина", то відповідний перехід може спрацювати, внаслідок чого об'єкт перейде в цільовий стан. Якщо ж сторожову умову приймає значення "брехня", то перехід не може спрацювати, і за відсутності інших переходів об'єкт не може перейти в цільовий стан по цьому переходу. Проте обчислення істинності сторожової умови відбувається тільки після виникнення асоційованої з ним події-трігера, що ініціює відповідний перехід.
У загальному випадку з одного стану може бути декілька переходів з однією і тією ж подією-трігером. При цьому ніякі дві сторожові умови не повинні одночасно приймати значення "істина". Кожна із сторожових умов необхідно обчислювати всякий раз при настанні відповідної події-трігера.
Прикладом події-трігера може служити розрив телефонного з'єднання з провайдером Інтернет-послуг після закінчення завантаження електронної пошти клієнтською поштовою програмою (при видаленому доступі до Інтернету). В цьому випадку сторожова умова є не що інше, як відповідь на питання: "Чи порожня поштова скринька клієнта на сервері провайдера?". У разі позитивної відповіді "істина", слід відключити з'єднання з провайдером, що і робить автоматично поштова програма-клієнт. У разі негативної відповіді "брехня", слід залишатися в стані завантаження пошти і не розривати телефонне з'єднання.
Графічно фрагмент логіки моделювання поштової програми може бути представлений у вигляді наступної діаграми станів (Рис. 4). Як можна укласти з контексту, в початковому стані програма не виконується, хоча і є на комп'ютері користувача. У момент її включення відбувається її активізація. У цьому стані програма може знаходитися невизначено довго, поки користувач її не закриє, тобто не вивантажить з оперативної пам'яті комп'ютера. Після закінчення активізації програма переходить в кінцевий стан. У активному стані програми користувач може читати повідомлення електронної пошти, створювати власні послання і виконувати інші дії, не вказані явно на діаграмі.
Проте при необхідності отримати нову пошту, користувач повинен встановити телефонне з'єднання з провайдером, що і показане явно на діаграмі верхнім переходом. Іншими словами, користувач ініціює подію-трігер "встановити телефонне з'єднання". Як параметр цієї події виступає конкретний телефонний номер модемного пулу провайдера. Далі слідує перевірка сторожової умови "телефонне з'єднання встановлене", яке слід розуміти як питання. Тільки у разі позитивної відповіді "так", тобто "істина", відбувається перехід поштової програми-клієнта із стану "активізація поштової програми" в стан "завантаження пошти з сервера провайдера". Інакше (лінія зайнята, невірне введення пароля, відключений логін) ніякого завантаження пошти не відбудеться, і програма залишиться в колишньому своєму стані.
Рис. 4 Діаграма станів для моделювання поштової програми-клієнта
Другий тригерний перехід на діаграмі ініціює автоматичний розрив телефонного з'єднання з провайдером після закінчення завантаження пошти на комп'ютер користувача. В цьому випадку подія-трігер "закінчити завантаження пошти" відбувається після перевірки сторожової умови "поштова скринька на сервері порожній", яке також слід розуміти у формі питання. При позитивній відповіді на це питання (вся пошта завантажена або її просто немає в ящику) поштова програма припиняє завантаження пошти і переходить в стан активізації. У разі ж негативної відповіді завантаження пошти буде продовжено.
Примітка. Звичайно, розглянутий приклад має методичний характер і ілюструє лише основні особливості поведінки поштової програми-клієнта в одному з її аспектів. І навіть цей аспект завантаження пошти багато в чому умовний, оскільки не враховує реакцію програми на такі повідомлення, як "лінія зайнята" або мимовільний розрив з'єднання.
Мова йде про тому, що в окремих випадках може відбутися рідкісна, але вельми неприємна подія, що отримала назву "Залипання модему". Це характерно для ситуації, коли вся пошта завантажена, а автоматичний розрив з'єднання не відбувається. Проте і цей випадок можна передбачити в наший моделі, доповнивши діаграму ще одним переходом з аналогічною подією-трігером "закінчити завантаження пошти" і з новою сторожовою умовою. Це сторожова умова повинна перевіряти максимально
допустимий час з'єднання для завантаження пошти (наприклад, 600 секунд) і може бути сформульовано у вигляді "час завантаження пошти перевищує 600 секунд". Модифікувати діаграму станів для цього випадку пропонується самостійно як вправа.
Вираз дії
Вираз дії (action expression) виконується в тому і лише у тому випадку, коли перехід спрацьовує. Є атомарною операцією (достатньо просте обчислення), що виконується відразу після спрацьовування відповідного переходу до початку яких би то не було дій в цільовому стані. Атомарність дії означає, що воно не може бути перерване ніяким іншою дією до тих пір, поки не закінчиться його виконання. Дана дія може робити вплив як на сам об'єкт, так і на його оточення, якщо це з очевидністю виходить з контексту моделі. Вираз записується після знаку "/" в рядку тексту, приєднаному до відповідного переходу.
У загальному випадку, вираз дії може містити цілий список окремих дій, розділених символом ";". Обов'язкова вимога — всі дії із списку повинні чітко розрізнятися між собою і слідувати в порядку їх запису. На синтаксис запису виразів дії не накладаються ніяких обмежень. Головне — їх запис повинен бути зрозуміла розробникам моделі і програмістам. Тому частіше за весь вираз записують на одній з мов програмування, яку передбачається використовувати для реалізації моделі.
Як приклад вирази дії (див. Рис. 4) може служити "розірвати телефонне з'єднання (телефонний номер), яке повинне бути виконане відразу після встановлення істинності ("істина") сторожової умови "поштова скринька на сервері порожня".
Іншим прикладом може служити очевидна ситуація з виділенням графічних об'єктів на екрані монітора при одноразовому натисненні лівої кнопки миші. Мається на увазі обробка сигналів від користувача при виділенні тих або інших графічних примітивів (піктограм). В цьому випадку відповідний перехід може мати наступний рядок тексту: "натиснута і відпущена ліва кнопка миші (координати) [координати в області графічного об'єкту] / виділити об'єкт (колір). Результатом цього тригерного переходу може бути, наприклад, активізація деяких властивостей об'єкту (розмір файлу в рядку стану) або подальше його видалення в корзину.
Примітка. Іноді після виразу дії може бути записане повідомлення у форматі: 'Л' <ім'я об'єкту приймача повідомлення> '.' <ім'я посиланого повідомлення> '('<параметр>':'<тип>',)'. При цьому повідомлення має чисто інформаційний характер і не передає управління на об'єкт-приймач повідомлення.
Складений стан і підстан
Складений стан (composite state) — такий складний стан, який складається з інших вкладених в нього станів. Останні виступатимуть по відношенню до першого як підстани (substate). Хоча між ними має місце відношення композиції, графічно всі вершини діаграми, які відповідають вкладеним станам, зображаються усередині символу складеного стану (Рис. 5). В цьому випадку розміри графічного символу складеного стану збільшуються, так щоб вміщати в себе всі підстани.
Рис. 5 Графічне представлення складеного стану з двома вкладеними в нього послідовними підстанами
Складений стан може містити два або більш паралельних підавтомата або декілька послідовних підстанів. Кожен складний стан може уточнюватися тільки одним з вказаних способів. При цьому будь-який з підстанів, у свою чергу, може бути складеним станом і містити усередині себе інші вкладені підстани. Кількість рівнів вкладеності складених станів не фіксована в мові UML.
Послідовні підстани
Послідовні підстани (sequential substates) використовуються для моделювання такої поведінки об'єкту, під час якого в кожен момент часу об'єкт може знаходитися в одному і лише одному підстанів. Поведінка об'єкту в цьому випадку є послідовною зміною підстанів, починаючи від початкового і закінчуючи кінцевим підстанами. Хоча об'єкт продовжує знаходитися в складеному стані, введення в розгляд послідовних підстанів дозволяє врахувати тонші логічні аспекти його внутрішньої поведінки.
Для прикладу розглянемо як модельований об'єкт звичайний телефонний апарат. Він може знаходитися в різних станах, одним з яких є стан дозвону до абонента. Очевидно, для того, щоб подзвонити, необхідно зняти телефонну трубку, почути тоновий сигнал, після чого набрати потрібний телефонний номер. Таким чином, стан дозвону до абонента є складеним і складається з двох послідовних підстанів: "підняти телефонну трубку" і "набрати телефонний номер". Фрагмент діаграми станів для цього прикладу містить один складений стан і два послідовних підстанів (Рис. 6).
Рис. 6 Приклад складеного стану з двома вкладеними послідовними підстанами
Деяких пояснень можуть зажадати переходи. Два з них специфікують подію-трігер набір цифри, яке має ім'я "цифра" з параметром "п". Як параметр, як неважко припустити, виступає окрема цифра на диску телефонного апарату. Перехід з початкового под-состояния нетригерний, оскільки він не містить ніякого рядка тексту. Останній перехід в кінцевий підстан не має події-трігера, але має сторожову умову, перевіряючу правильність набраного номера абонента. Тільки у разі істинності цієї умови телефонний апарат може перейти в кінцевий підстан, який характеризує суперстан "дозвон до абонента" в цілому.
Складений стан
Складений стан може містити як вкладені підстани початковий і кінцевий стани. При цьому початковий підстан є початковим, коли відбувається перехід об'єкту в даний складений стан. Якщо складений стан містить усередині себе кінцевий підстан, то перехід в цей вкладений кінцевий стан означає завершення знаходження об'єкту в даному вкладеному стані. Важливо пам'ятати, що для послідовних підстанів початковий і кінцевий стани повинні бути єдиними в кожному складеному стані.
Це можна пояснити таким чином. Кожна сукупність вкладених послідовних підстанів є підавтоматом того автомата, якому належить даний складений стан. Оскільки кожен автомат може мати за визначенням єдине початкове і єдине кінцеве стани, то для підавтомата ця умова також повинна виконуватися (Рис. 6).
Паралельні підстани
Паралельні підстани (concurrent substates) дозволяють специфікувати два і більш за підавтомат, які можуть виконуватися паралельно усередині складеної події. Кожен з підавтоматів займає деяку область (регіон) усередині складеного стану, яка відділяється від останніх горизонтальною пунктирною лінією. Якщо на діаграмі станів є складений стан з вкладеними паралельними підстанами, то об'єкт може одночасно знаходитися в кожному з цих підстанів.
Проте окремі паралельні підстани можуть, у свою чергу, складатися з декількох послідовних підстанів (підавтомати 1 і 2 на Рис. 7). В цьому випадку за визначенням об'єкт може знаходитися тільки в одному з послідовних підстанів підавтомата. Таким чином, для абстрактного прикладу (Рис. 7) допустиме одночасне знаходження об'єкту в підстанах (1, 3, 4) (2, 3, 4) (1, 3, 5) (2, 3, 5). Неприпустимо знаходження об'єкту одночасне в підстанах (1, 2,3) або (3, 4, 5).
Рис. 7 Графічне зображення складеного стану з вкладеними паралельними підстанами
Оскільки кожен регіон вкладеного стану специфікує деякий підавтомат, то для кожного з вкладених підавтоматів можуть бути визначені власні початкове і кінцеві підстани (Рис. 8). При переході в даний складений стан кожен з підавтоматів опиняється в своєму початковому підстанів. Далі відбувається паралельне виконання кожного з цих підавтоматів, причому вихід з складеного стану буде можливий лише у тому випадку, коли всі підавтомати знаходитимуться в своїх кінцевих підстанах.
Якщо який-небудь з підавтоматів прийшов в свій кінцевий стан раніше інших, то він повинен чекати, поки і інші підавтомати не прийдуть в свої кінцеві стани.
В деяких випадках буває бажано приховати внутрішню структуру складеного стану. Наприклад, окремий підавтомат, що специфікує складений стан, може бути настільки великим по масштабу, що його візуалізація утруднить загальне представлення діаграми станів. У подібній ситуації допускається не розкривати на початковій діаграмі станів даний складений стан, а вказати в правому нижньому кутку спеціальний символ-піктограму (Рис. 8). У подальшому діаграма станів для відповідного підавтомата може бути зображена окремо від основної з необхідними коментарями.
Рис. 8 Складений стан з прихованою внутрішньою структурою і спеціальною піктограмою
Складні переходи
Розглянуте вище поняття переходу є цілком достатнім для більшості типових розрахунково-обчислювальних завдань. Проте сучасні програмні системи можуть реалізовувати дуже складну логіку поведінки окремих своїх компонентів. Може опинитися, що для адекватного представлення процесу зміни станів семантика звичайного переходу для них недостатня. З цією метою в мові UML специфіковані додаткові позначення і властивості, якими можуть володіти окремі переходи на діаграмі станів.
Переходи між паралельними станами
В окремих випадках перехід може мати декілька станів-джерел і декілька цільових станів. Такий перехід отримав спеціальну назву — паралельний перехід. Введення в розгляд паралельного переходу обумовлене необхідністю синхронізувати і/або розділити окремі підпроцеси на паралельні нитки без специфікації додаткової синхронізації в паралельних підавтоматах. Графічно такий перехід зображається вертикальною рискою, аналогічно позначенню переходу у відомому формалізмі мереж Петрі. Якщо паралельний перехід має дві або більш вхідних дуг (Рис. 9, а), то його називають з'єднанням (join). Якщо ж він має дві або більш витікаючих з нього дуг (Рис. 9, би), то його називають галуженням (fork). Текстовий рядок специфікації паралельного переходу записується поряд з рискою і відноситься до всіх вхідних (витікаючим) дуг.
Рис. 9 Графічне зображення паралельного переходу з паралельних станів (а) і паралельного переходу в паралельні стани (б)
Спрацьовування паралельного переходу відбувається таким чином. У першому випадку (перехід-з'єднання) перехід спрацьовує, якщо має місце подія-трігер для всіх початкових станів цього переходу, і виконана (при його наявності) сторожова умова. При спрацьовуванні переходу-з'єднання одночасно покидаются всі початкові стани переходу (стани 1 і 2) і відбувається перехід в цільовий стан. При цьому кожен з початкових станів переходу повинен належати окремому підавтомату, що входить до складу автомата (процесу 1).
У другому випадку (галуження) відбувається розщеплювання автомата на два підавтомати, створюючих паралельні гілки вкладених підстанів. При цьому після спрацьовування переходу модельований об'єкт одночасно знаходитиметься у всіх цільових станах цього переходу (стани 3 і 4). Далі процес зміни станів протікатиме згідно раніше розглянутим правилам для складених станів.
Переходи між складеними станами
Перехід, стрілка якого сполучена з межею деякого складеного стану, позначає перехід в складений стан (перехід b на Рис. 10). Він еквівалентний переходу в початковий стан кожного з підавтоматів (можливо, єдиному), що входять до складу даного суперстану. Перехід, що виходить з складеного стану (переходи f і g на Рис. 6.12), відноситься до кожного з вкладених підстанів. Це означає, що об'єкт може покинути складений суперстан, знаходячись в будь-якому з його підстанів. Для цього цілком достатньо виконання події і сторожової умови.
Рис. 10. Різні варіанти переходів в (з) складений стан
Іноді бажано реалізувати ситуацію, коли вихід з окремого вкладеного стану відповідав би виходу і з складеного стану теж. В цьому випадку зображають перехід, який безпосередньо виходить з вкладеного підстану за межу суперстану (перехід з на Рис. 6.12). Аналогічно, допускається зображення переходів, що входять ззовні складеного стану в окремий вкладений стан (перехід а на Рис. 10).
Синхронізуючі стани
Як вже було відмічено, поведінка паралельних підавтоматів незалежно один від одного, що дозволяє реалізувати багатозадачність в програмних системах. Проте в окремих випадках може виникнути необхідність врахувати в моделі синхронізацію настання окремих подій. Для цієї мети в мові UML є спеціальний псевдостан, який називається синхронізуючим станом.
Синхронізуючий стан (synch state) позначається невеликим колом, усередині якого поміщений символ зірочки "*". Воно використовується спільно з переходом-з'єднанням або переходом-галуженням для того, щоб явно вказати події в інших підавтоматах, що роблять безпосередній вплив на поведінку даного підавтомата.
Для ілюстрації використання синхронізуючих станів розглянемо спрощену ситуацію з моделюванням процесу споруди будинку. Припустимо, що споруда будинку включає будівельні роботи (зведення фундаменту і стенів, зведення даху і обробні роботи) і роботи по електрифікації будинку (підведення електричної лінії, прокладка прихованої електропроводки і установка освітлювальних ламп). Очевидно, два цих комплексу робіт можуть виконуватися паралельно, проте між ними є деякий взаємозв'язок.
Зокрема, прокладка прихованої електропроводки може початися лише після того, як буде завершено зведення фундаменту і стенів. А обробні роботи слід почати лише після того, як буде закінчена прокладка прихованої електропроводки. Інакше обробні роботи доведеться проводити повторно. Розглянуті особливості синхронізації цих паралельних процесів враховані на відповідній діаграмі станів за допомогою двох синхронізуючих станів (Рис. 11).
Рис. 11. Діаграма станів для прикладу з будівництвом будинку
На завершення цього розділу розглянемо діаграму станів, яка є прикладом моделювання поведінки конкретного об'єкту, — процесу функціонування телефонного апарату (Рис. 6.12). Цей приклад ілюструє всі основні особливості графічної нотації, використовуваної при побудові діаграми станів.
Стисло прокоментуємо основні особливості цього прикладу. Дана діаграма станів представляє єдиний автомат з одним складеним станом. Поза цим складеним станом є тільки одне стан "очікування", яке характеризує справний і підключений до телефонної мережі телефонний апарат. Перехід в наступний стан відбувається при піднятті телефонної трубки. Перехід з атомарною дією "подати тоновий сигнал" переводить апарат в складений стан, а точніше — в початковий його підстан.
Рис. 12. Діаграма станів процесу функціонування телефонного апарату
Далі телефонний апарат знаходитиметься в змозі "тоновий сигнал". При цьому безперервно видаватиме цей сигнал до тих пір, поки не відбудеться подія-трігер "набір цифри (п)", або не закінчиться 15 секунд з моменту підняття трубки. У першому випадку апарат перейде в стан "набір номера", а в другому — в стан "закінчення часу очікування". Остання ситуація може бути результатом сумнівів по приводу "дзвонити — не дзвонити?", слідством чого можуть стати гудки в трубці. При цьому нам нічого не залишається робити, як опустити її на важіль.
При наборі номера виконується подія-трігер "набір цифри (п) із сторожовою умовою "номер неповний". Це означає, що якщо набраний телефонний номер не містить необхідної кількості цифр, то нам слід продовжувати набір чергової цифри, залишаючись в змозі "набір номера".
Якщо ж набраний номер повний, то можна перейти в стан "невірний номер" або "з'єднання". У разі невірного номера (сторожова умова "невірний" істинно) нічого не залишається, як покинути складений стан, опустивши трубку на важіль. Якщо ж номер вірний, то відбувається з'єднання по цьому номеру.
Проте в результаті з'єднання може опинитися, що апарат абонента зайнятий (перехід в стан "зайнято") або вільний (перехід в стан "дзвінок у абонента"). У першому випадку можна повторити дозвон, заздалегідь опустивши трубку на важіль (вихід з складеного стану). У другому випадку відбувається перевірка сторожової умови "розмова доступна". Якщо воно істинне, що відповідає зняттю трубки абонентом, починається телефонна розмова. Інакше (ця умова не виконується, тобто воно помилкове) телефон абонента продовжуватиме дзвонити, сповіщаючи нас про відсутність останнього або про неможливість з якої-небудь причини вести розмову по телефону. При цьому нам нічого не залишається, як опустити трубку на важіль.
Якщо ж розмова відбулася, то після слів прощання і виконання сторожової умови "підтвердження" на закінчення розмови ми знову опускаємо трубку. При цьому телефонний апарат переходить в стан "очікування", в якому може знаходитися невизначено довго.
Примітка. Строго кажучи, розглянутий приклад відображає не всі аспекти поведінки навіть такого нескладного на перший погляд пристрою, яким є звичайний телефонний апарат. Зокрема, дана діаграма станів може бути доповнена переходом із стану "очікування" по події-трігеру "телефонний дзвінок", який може відразу перевести нас у внутрішній підстан "розмова", якщо ми вирішили зняти телефонну трубку (перехід типу а на Рис. 6.10).
Інша модифікація може бути пов'язана з бажанням повторно використовувати набраний номер у разі коротких гудків "зайнято" у абонента. Рішення цієї задачі може бути реалізоване на основі використання історичного стану замість початкового підстану, який запам'ятовуватиме в пам'яті апарату одного разу набраний номер. Доповнити діаграму станів читачеві пропонується самостійно як вправа.
Завершальні рекомендації по побудові діаграм станів
Основні особливості побудови діаграм станів були розглянуті при описі відповідних модельних елементів, що входять в пакет Автомати. Проте деякі моменти не знайшли віддзеркалення, про що необхідно сказати на закінчення цього розділу.
По своєму призначенню діаграма станів не є обов'язковим уявленням в моделі і як би "приєднується" до того елементу, який, за задумом розробників, має нетривіальну поведінку протягом свого життєвого циклу. Наявність у системи декількох станів, що відрізняються від простій дихотомії "справний, — несправний", "активний — неактивний", "очікування — реакція на зовнішні дії", вже служить ознакою необхідності побудови діаграми станів. Як початковий варіант діаграми станів, якщо немає очевидних міркувань з приводу станів об'єкту, можна скористатися цими суперстанами, розглядаючи їх як складені і уточнюючи їх (деталізуючи їх внутрішню структуру) у міру розгляду логіки поведінки об'єкту.
При виділенні станів і переходів слід пам'ятати, що тривалість спрацьовування окремих переходів повинна бути істотно меншою, ніж знаходження модельованого об'єкту у відповідних станах. Кожен із станів повинен характеризуватися певною стійкістю в часі. Іншими словами, з кожного перебування на діаграмі не може бути мимовільного переходу в яке б то не було інший стан. Всі переходи повинні бути явно специфіковані, інакше побудована діаграма станів є або неповною, або помилковою.
При розробці діаграми станів потрібно постійно стежити, щоб об'єкт в кожен момент міг знаходитися тільки в єдиному стані. Якщо це не так, то дана обставина може бути як наслідком помилки, так і неявною ознакою наявності паралельності у поведінки модельованого об'єкту. У останньому випадку слід явно специфікувати необхідне число підавтоматів, вклавши їх в той складений стан, який характеризується порушенням умови одночасності.
Слід обов'язково перевіряти, що ніякі два переходи з одного стану не можуть спрацювати одночасно (вимога відсутності конфліктів у переходів). Наявність такого конфлікту може служити ознакою помилки або неявної паралельності типу галуження даного процесу на два і більш за підавтомат. Якщо паралельність за задумом розробника відсутня, то необхідно ввести додаткові сторожові умови або змінити що існують, щоб виключити конфлікт переходів. За наявності паралельності слід замінити конфліктуючі переходи одним паралельним переходом типу галуження.
Використання історичних станів виправдане у тому випадку, коли необхідно організувати обробку виняткових ситуацій (переривань) без втрати даних або виконаної роботи. При цьому застосовувати історичні стани, особливо глибокі, треба з відомою часткою обережності. Потрібно пам'ятати, що кожен з підавтоматів може мати тільки одне історичний стан. Інакше можливі помилки, особливо коли підавтомати зображаються на окремих діаграмах станів.
І, нарешті, слід зазначити, що деякі додаткові конструкції автоматів, такі як точки динамічного вибору (dynamic choice points) або точки з'єднання (junction points), в книзі не знайшли віддзеркалення. Це
07.04.2013 21:04-
Ділись своїми роботами та отримуй миттєві бонуси!
0%
Оголошення від адміністратора