- •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.5. Історичний стан
Як було відзначено вище, формалізм звичайного автомата не дозволяє враховувати передісторію в процесі моделювання поведінки об'єктів. Проте функціонування цілого ряду систем засновано на можливості виходу з окремих станів з подальшим поверненням в цей же стан. При цьому може виявитися необхідним врахувати ту частину діяльності, яка була виконана на момент виходу з цього стані, щоб не починати її виконання спочатку. Для цієї мети в язиці UML існує історичний стан.
Історичний стан (history state) застосовується в контексті складового стану. Воно використовується для запам'ятовування того з послідовних підстанів, яке було поточним у момент виходу з складового стану. При цьому існує два різновиди історичного стану: недавнє і давнє (мал. 6.10).
Мал. 6.10. Графічне зображення недавнього (а) і давнього (б) історичного стану
недавній історичний стан (shallow history state) позначається у формі невеликого кола, в яке поміщена латинська буква «Н» (мал. 6.10, а). Цей стан володіє наступною семантикою. По-перше, воно є першим підстаном в складовому стані, і перехід ззовні в цей складовий стан повинен вести безпосередньо в цей історичний стан. По-друге, при першому попаданні в недавній історичний стан воно не береже ніякої історії (історія порожня). Іншими словами, при першому переході в недавній історичний стан воно замінює собою початковий стан підавтомата.
Далі слідує послідовна зміна вкладених підстанів. Якщо в деякий момент відбувається вихід з вкладеного стану (наприклад, у разі деякої зовнішньої події), то цей історичний стан запам'ятовує той з підстанів, яке було поточним на момент виходу. При наступному вході в цей же складовий стан історичний підстан вже має непорожню історію і відразу відправляє підавтомат в підстан, що запам'ятав, минувши всі попередні йому підстани.
Історичний стан втрачає свою історію в той момент, коли підавтомат доходить до свого кінцевого стану. При цьому недавній історичний стан запам'ятовує історію тільки того підавтомата, до якого він відноситься. Іншими словами, цей тип стану здатний запам'ятати історію тільки одного з ним рівня вкладеності.
З другого боку, стан, що запам'ятав, у свою чергу, також може бути складовим станом. Давній історичний стан (deep history state) позначається у формі невеликого кола, в яке поміщена латинська буква «Н» з символом "*" (мал. 6.10, би) і служить для запам'ятовування всіх підстанів будь-якого рівня вкладеності для поточного підавтомата.
Простим прикладом, ілюструючому вживання недавнього історичного стану, може служити логіка роботи поштової програми‑ клієнта. Припустимо, при запуску цієї програми ми знаходимося в стані написання нового повідомлення, причому набраний вже значний фрагмент тексту. Поштова програма може бути конфігурована таким чином, що у фіксовані моменти часу (наприклад, кожні 30 хвилин) вона перевіряє наявність нових повідомлень на сервері провайдера при видаленому доступі. Очевидно, що черговий дозвон, хоча і перериває роботу редактора, не повинен привести до втрати набраного фрагмента тексту.
В цьому випадку складовий стан «робота редактора» повинен містити вкладений історичний підстан, який запам'ятовує виконану роботу. Після закінчення дозвону і завантаження нової пошти (у разі її наявності) ми повинні повернутися до збереженого фрагмента нашого повідомлення і продовжити роботу редактора програми.
Діаграма станів поштової програми‑ клієнта (див. мал. 6.5) може бути доповнена з урахуванням розглянутого аспекту її поведінки. Читачу пропонується це виконати самостійно як вправа.
