- •1.1. Методологія процедурно‑ орієнтованого програмування
- •1.2. Методологія об'єктно-орієнтованого програмування
- •1.3. Методологія об'єктно-орієнтованого аналізу і проектування
- •1.4. Методологія системного аналізу і системного моделювання
- •Розділ 2
- •2.1. Передісторія. Математичні основи
- •Мал. 2.4. Приклади неорієнтованого (а) і орієнтованого (б) графів
- •Мал. 2.5. Приклади неорієнтованого (а) і орієнтованого (б) дерев
- •Мал. 2.6. Ієрархічні схеми неорієнтованого дерева (а) і орієнтованого дерева (б)
- •2.2. Діаграми структурного системного аналізу
- •I (Input) – вхід, т. Е. Все, що поступає в процес або споживається процесом.
- •2.3. Основні етапи розвитку uml
- •2. Забезпечити початкові поняття язика uml можливістю розширення і спеціалізації для більш точного представлення моделей систем в конкретній наочній області.
- •3. Опис язика uml повинен підтримувати таку специфікацію моделей, яка не залежить від конкретних язиків програмування і інструментальних засобів проектування програмних систем.
- •4. Опис язика uml повинен включати семантичний базис для розуміння загальних особливостей ооап.
- •7. Інтегрувати в себе новітні і якнайкращі досягнення практики ооап.
- •3.2. Загальна структура язика uml
- •3.3. Пакети в язиці uml
- •3.4. Основні пакети метамоделі язика uml
- •3.5. Специфіка опису метамоделі язика uml
- •3.6. Особливості зображення діаграм язика uml
- •4.1. Варіант використовування
- •4.2. Актори
- •4.3. Інтерфейси
- •4.4. Примітки
- •4.5. Відносини на діаграмі варіантів використовування
- •4.6. Приклад побудови діаграми варіантів використовування
- •4.7. Рекомендації по розробці діаграм варіантів використовування
- •5.1. Клас
- •5.2. Відносини між класами
- •5.5. Шаблони або класи, що параметризуються
- •5.6. Рекомендації по побудові діаграм класів
- •6.1. Автомати
- •Include – ця мітка використовується для звернення до підавтомата, при цьому наступний за нею вираз дії містить ім'я цього підавтомата.
- •6.3. Перехід
- •6.4. Складовий стан і підстан
- •6.5. Історичний стан
- •Мал. 6.10. Графічне зображення недавнього (а) і давнього (б) історичного стану
- •6.6. Складні переходи
- •Мал. 6.11. Графічне зображення паралельного переходу з паралельних станів (а) і паралельного переходу в паралельні стани (б)
- •6.7. Заключні рекомендації по побудові діаграм станів
- •7.1. Стан дії
- •7.2. Переходи
- •7.5. Рекомендації по побудові діаграм діяльності
- •8.2. Повідомлення
- •Мал. 8.7. Діаграма послідовності із стереотипними значеннями повідомлень
- •8.3. Приклад побудови діаграми послідовності
- •8.4. Заключні рекомендації по побудові діаграм послідовності
- •9.1. Кооперація
- •9.3. Зв'язки
- •9.4. Повідомлення
- •9.6. Заключні рекомендації по побудові діаграм кооперації
- •10.1. Компоненти
- •10.2. Інтерфейси
- •10.3. Залежність
- •10.4. Рекомендації по побудові діаграми компонентів
- •11.1. Вузол
- •11.2. З'єднання
- •Мал. 11.4. Фрагмент діаграми розгортання із з'єднаннями меходу вузлами
- •11.3. Рекомендації по побудові діаграми розгортання
- •12.1. Загальна характеристика case‑ засобу Rational Rose 98/2000
- •12.2. Особливості робочого інтерфейсу Rational Rose
- •12.3. Початок роботи над проектом в середовищі Rational Rose
- •12.4. Розробка діаграми варіантів використовування в середовищі Rational Rose
- •12.5. Розробка діаграми класів в середовищі Rational Rose
- •12.6. Розробка діаграми станів в середовищі Rational Rose
- •12.7. Розробка діаграми послідовності в середовищі Rational Rose
- •12.8. Розробка діаграми кооперації в середовищі Rational Rose
- •12.9. Розробка діаграми компонентів в середовищі Rational Rose
- •12.10. Розробка діаграми розгортання в середовищі Rational Rose
6.1. Автомати
Автомат (state machine) в язиці UML є деяким формалізмом для моделювання поведінки елементів моделі і системи в цілому. В метамоделі UML автомат є пакетом, в якому визначена безліч понять, необхідних для представлення поведінки модельованого єства у вигляді дискретного простору з кінцевим числом станів і переходів. З другого боку, автомат описує поведінку окремого об'єкту у формі послідовності станів, які охоплюють всі етапи його життєвого циклу, починаючи від створення об'єкту і закінчуючи його знищенням. Кожна діаграма станів представляє деякий автомат.
Найпростішим прикладом візуального представлення станів і переходів на основі формалізму автоматів може служити розглянута вище ситуація із справністю технічного пристрою, такого як комп'ютер. В цьому випадку вводяться в розгляд два найзагальніші стани: «справний» і «несправний» і два переходи: «вихід з ладу» і «ремонт». Графічно ця інформація може бути представлена у вигляді зображеної нижче діаграми станів комп'ютера (мал. 6.1).
Мал. 6.1. Найпростіший приклад діаграми станів для технічного пристрою типу комп'ютер
Основними поняттями, що входять у формалізм автомата, є стан і перехід. Головна відмінність між ними полягає в тому, що тривалість знаходження системи в окремому стані істотно перевищує час, який затрачується на перехід з одного стану в інше. Передбачається, що в межі час переходу з одного стану в інше рівний нулю (якщо додатково нічого не сказано). Іншими словами, перехід об'єкту із стану в стан відбувається миттєво.
В загальному випадку автомат представляє динамічні аспекти модельованої системи у вигляді орієнтованого графа, вершини якого відповідають станам, а дуги – переходам. При цьому поведінка моделюється як послідовне переміщення по графу станів від вершини до вершини по зв'язуючих їх дугах з урахуванням їх орієнтації. Для графа станів системи можна ввести в розгляд спеціальні властивості.
Однією з таких властивостей є виділення зі всієї сукупності станів двох спеціальних: початкового і кінцевого. Хоча ні в графі станів, ні на діаграмі станів час знаходження системи в тому або іншому стані явно не враховується, передбачається, що послідовність зміни станів впорядкована в часі. Іншими словами, кожний подальший стан завжди наступає пізніше попереднього йому стану.
Ще однією властивістю графа станів може служити досяжність станів. Йдеться про те, що навігація або орієнтований шлях в графі станів визначає спеціальне бінарне відношення на безлічі всіх станів системи. Це відношення характеризує потенційну можливість переходу системи з даного стану в деякий інший стан. Очевидно, для досяжності станів необхідна наявність зв'язуючого їх орієнтованого шляху в графі станів.
Формалізм автоматів допускає вкладення одних автоматів в інші для уточнення внутрішньої структури окремих більш загальних станів (макростанів). В цьому випадку вкладені автомати одержали назву підавтоматів. підавтомати можуть використовуватися для внутрішньої специфікації процедур і функцій, створюючих поведінку початкового об'єкту. Наприклад, стан несправності технічного пристрою (мал. 6.1) може деталізуватися на окремі підстани, кожне з яких може характеризувати несправність окремих підсистем, що входять до складу даного пристрою.
В язиці UML поняття автомата доповнено спеціальною семантикою вхідних у відповідний пакет елементів. Далі в цьому розділі будуть розглянуті основні елементи поведінки, які утворюють концептуальний базис, необхідний для правильної побудови діаграм станів.
Формалізм звичайного автомата заснований на виконанні наступних обов'язкових умов:
1. Автомат не запам'ятовує історію переміщення із стану в стан. З погляду модельованої поведінки визначаючим є сам факт знаходження об'єкту в тому або іншому стані, але ніяк не послідовність станів, в результаті якої об'єкт перейшов в поточний стан. Іншими словами, автомат «забуває» всі стани, які передували поточному в даний момент часу. Образно кажучи, існує непрозора стіна, що відділяє поточний стан від минулої поведінки об'єкту.
Примітка
Дана умова може бути змінене явним чином для збереження деяких аспектів передісторії поведінки об'єкту на основі введення в розгляд так званих історичних станів, які будуть описані нижче в цьому розділі.
2. В кожний момент часу автомат може знаходитися в одному і лише в одному з своїх станів. Це означає, що формалізм автомата призначений для моделювання послідовної поведінки, коли об'єкт протягом свого життєвого циклу послідовно проходить через все свої стани. При цьому автомат може знаходитися в окремому стані як завгодно довго, якщо не відбувається ніяких подій.
Примітка
Ця умова обмежує вживання автоматів для моделювання послідовних процесів. Необхідність моделювання паралельних процесів приводить до розгляду в контексті однієї моделі декількох автоматів, кожний з яких специфікує окремий процес поведінки.
3. Хоча процес зміни станів автомата відбувається в часі, явно концепція часу не входить у формалізм автомата. Це означає, що тривалість знаходження автомата в тому або іншому стані, а також час досягнення того або іншого стану ніяк не специфікуються. Іншими словами, час на діаграмі станів присутній в неявному вигляді, хоча для окремих подій може бути вказаний інтервал часу і в явному вигляді.
Примітка
Концепція часу в явній формі враховується при побудові діаграми діяльності, коли вимагається синхронізувати в часі процеси взаємодії декількох об'єктів моделі. Оскільки діаграма станів призначена для моделювання поведінки об'єкту, яка визначається асинхронними подіями, ці події можуть відбуватися в наперед невідомі моменти часу.
4. Кількість станів автомата повинна бути обов'язково кінцевою (в язиці UML розглядаються тільки кінцеві автомати), і всі вони повинні бути специфіковані явним чином. При цьому окремі псевдостани можуть не мати специфікацій (початкове і кінцеве стани). В цьому випадку їх призначення і семантика повністю визначаються з контексту моделі і даної діаграми станів.
5. Граф автомата не повинен містити ізольованих станів і переходів. Ця умова означає, що для кожного із станів, окрім початкового, повинно бути визначено попередній стан. Кожний перехід повинен обов'язково сполучати два стани автомата. Допускається перехід із стану в себе, такий перехід ще називають «петлею».
6. Автомат не повинен містити конфліктуючих переходів, т. е. таких переходів з одного і того ж стану, коли об'єкт одночасно може перейти в два і більш подальших стани (окрім випадку паралельних підавтоматів). В язиці UML виключення конфліктів можливе на основі введення так званих сторожових умов, які будуть розглянуті нижче.
Таким чином, правила поведінки об'єкту, модельованого деяким автоматом, визначаються, з одного боку, загальним формалізмом автомата, а з іншою – його графічним зображенням в язиці UML у формі конкретної діаграми станів.
6.2. Стан
Поняття стану (state) є фундаментальним не тільки в метамоде‑ ли язика UML, але і в прикладному системному аналізі. Раніше на чолі 1 стисло були розглянуті особливості представлення динамічних характеристик складних систем, традиційно що використовуються для моделювання поведінки. Вся концепція динамічної системи грунтується на понятті стану системи. Проте семантика стану в язиці UML має цілий ряд специфічних особливостей.
В язиці UML під станом розуміється абстрактний метакласс, що використовується для моделювання окремої ситуації, протягом якої має місце виконання деякої умови. Стан може бути задане у вигляді набору конкретних значень атрибутів класу або об'єкту, при цьому зміна їх окремих значень відбиватиме зміну стану модельованого класу або об'єкту.
Слід помітити, що не кожний атрибут класу може характеризувати його стан. Як правило, мають значення тільки такі властивості елементів системи, які відображають динамічний або функціональний аспект її поведінки. В цьому випадку стан характеризуватиметься деякою інваріантною умовою, що включає тільки значущі для поведінки класу атрибути і їх значення.
Наприклад, інваріант може представляти статичну ситуацію, коли об'єкт знаходиться в стані очікування виникнення деякої зовнішньої події. З другого боку, інваріант використовується для моделювання динамічних аспектів, коли в ході процесу виконуються деякі дії. В цьому випадку модельований елемент переходить в даний стан у момент початку відповідної діяльності і покидає даний стан у момент її завершення.
Мал. 6.2. Графічне зображення станів на діаграмі станів
Стан на діаграмі зображається прямокутником з округляючими вершинами (мал. 6.2). Цей прямокутник, у свою чергу, може бути роздільний на дві секції горизонтальною лінією. Якщо вказана лише одна секція, то в ній записується тільки ім'я стану (мал. 6.2, а). Інакше в першій з них записується ім'я стану, а в другій – список деяких внутрішніх дій або переходів в даному стані (мал. 6.2, би). При цьому під дією в язиці UML розуміють деяку атомарну операцію, виконання якої приводить до зміни стану або повернення деякого значення (наприклад, «істина» або «брехня»).
Ім'я стану
Ім'я стану є рядком тексту, який розкриває змістовне значення даного стану. Ім'я завжди записується із заголовної букви. Оскільки стан системи є складовою частиною процесу її функціонування, рекомендується як ім'я використовувати дієслова в теперішньому часі (дзвенить, друкує, чекає) або відповідні дієприкметника (зайнятий, вільний, передано, одержано). Ім'я у стану може бути відсутній, т. е. воно є необов'язковим для деяких станів. В цьому випадку стан є анонімним, і якщо на діаграмі станів їх дещо, то всі вони повинні розрізнятися між собою.
Список внутрішніх дій
Ця секція містить перелік внутрішніх дій або деятельностей, які виконуються в процесі знаходження модельованого елемента в даному стані. Кожна з дій записується у вигляді окремого рядка і має наступний формат:
‹мітка‑ дії /' выражение‑ действия‑
Мітка дії указує на обставини або умови, при яких виконуватиметься діяльність, визначена виразом дії. При цьому вираз дії може використовувати будь-які атрибути і зв'язки, які належать області імен або контексту модельованого об'єкту. Якщо список виразів дії порожній, то роздільник у вигляді похилої межі /' може не указуватися.
Перелік міток дії має фіксовані значення в язиці UML, які не можуть бути використані як імена подій. Ці значення наступні:
entry – ця мітка указує на дію, специфіковану наступним за нею виразом дії, яка виконується у момент входу в даний стан (вхідна дія);
exit – ця мітка указує на дію, специфіковану наступним за нею виразом дії, яка виконується у момент виходу з даного стану (вихідна дія);
do – ця мітка специфікує діяльність («do асtivity»), яка виконується протягом всього часу, що виконується, поки об'єкт знаходиться в даному стані, або до тих пір, поки не закінчиться обчислення, специфіковане наступним за нею виразом дії.
В останньому випадку при завершенні події генерується відповідний результат;
