Подякувати Студентському архіву довільною сумою
Admin
26.02.2023 12:38
Дякуємо, що користуєтесь нашим архівом!
Інформація про навчальний заклад
ВУЗ:
Національний університет Львівська політехніка
Інститут:
Не вказано
Факультет:
КН
Кафедра:
Не вказано
Інформація про роботу
Рік:
2013
Тип роботи:
Звіт до лабораторної роботи
Предмет:
Основи автоматизованого проектування складних об’єктів і систем
Частина тексту файла (без зображень, графіків і формул):
Міністерство освіти і науки України
Національний університет „Львівська політехніка”
Кафедра АСУ
Звіт
до лабораторної роботи №6
з дисципліни
«Основи автоматизованого проектування
складних об’єктів та систем»
Тема роботи: Діаграми станів.
Мета роботи: Оволодіти навичками моделювання діаграм станів та навчитися реалізовувати їх.
Завдання: Здійснити моделювання діаграм станів за допомогою середовища розробки діаграм Enterprise Architect або в Borland Together.
Теоретичні відомості
Поняття стану (state) є фундаментальним не тільки в метамоделі мови UML, але і в прикладному системному аналізі. Вся концепція динамічної системи ґрунтується на понятті стану системи. Проте семантика полягання в мові UML має цілий ряд специфічних особливостей.
У мові UML під станом розуміється абстрактний метаклас, використовуваний для моделювання окремої ситуації, протягом якої має місце виконання деякої умови. Стан може бути задане у вигляді набору конкретних значень атрибутів класу або об'єкту, при цьому зміна їх окремих значень відбиватиме зміну стану модельованого класу або об'єкту.
Слід відмітити, що не кожен атрибут класу може характеризувати його стан. Як правило, мають значення тільки такі властивості елементів системи, які відображають динамічний або функціональний аспект її поведінки. В цьому випадку стан характеризуватиметься деякою інваріантною умовою, що включає тільки значущі для поведінки класу атрибути і їх значення.
Наприклад, інваріант може представляти статичну ситуацію, коли об'єкт знаходиться в стані очікування виникнення деякої зовнішньої події. З іншого боку, інваріант використовується для моделювання динамічних аспектів, коли в ході процесу виконуються деякі дії. В цьому випадку модельований елемент переходить в даний стан у момент початку відповідної діяльності і покидає даний стан у момент її завершення.
Початковим станом є окремий випадок стану, який не містить ніяких внутрішніх дій (псевдо стани). У цьому стані знаходиться об'єкт за умовчанням в початковий момент часу. Воно служить для вказівки на діаграмі станів графічної області, від якої починається процес зміни станів. Графічно початкове полягання в мові UML позначається у вигляді закрашеного кружка (Рис. 1, а), з якого може тільки виходити стрілка, відповідна переходу.
Рис. 1 Графічне зображення початкового і кінцевого перебувань на діаграмі станів
На самому верхньому рівні представлення об'єкту перехід з початкового стану може бути помічений подією створення (ініціалізації) даного об'єкту. Інакше перехід ніяк не позначається. Якщо цей перехід не помічений, то він є першим переходом в наступний за ним стан.
Кінцевим (фінальне) станом є окремий випадок стану, який також не містить ніяких внутрішніх дій (псевдо стани). У цьому стані знаходитиметься об'єкт за умовчанням після завершення роботи автомата в кінцевий момент часу. Воно служить для вказівки на діаграмі станів графічної області, в якій завершується процес зміни станів або життєвий цикл даного об'єкту. Графічно кінцеве полягання в мові UML позначається у вигляді закрашеного кружка, поміщеного в коло (Рис. 1, б), в яке може тільки входити стрілка, відповідна переходу.
Простій переходом (simple transition) є відношення між двома послідовними станами, яке указує на факт зміни одного стану іншим. Перебування модельованого об'єкту в першому стані може супроводжуватися виконанням деяких дій, а перехід в другий стан буде можливий після завершення цих дій, а також після задоволення деяких додаткових умов. В цьому випадку говорять, що перехід спрацьовує, Або відбувається спрацьовування переходу. До спрацьовування переходу об'єкт знаходиться в попередньому від нього стані, званим початковим станом, або в джерелі (не плутати з початковим станом — це різні поняття), а після його спрацьовування об'єкт знаходиться в подальшому від нього стані (цільовому стані).
Перехід здійснюється при настанні деякої події: закінчення виконання діяльності (do activity), отриманні об'єктом повідомлення або прийомом сигналу. На переході указується ім'я події Крім того, на переході можуть указуватися дії, вироблювані об'єктом у відповідь на зовнішні події при переході з одного стану в інше. Спрацьовування переходу може залежати не тільки від настання деякої події, але і від виконання певної умови, званої сторожовою умовою. Об'єкт перейде з одного стану в інше в тому випадку, якщо відбулася вказана подія і сторожова умова прийняло значення "істина".
По своєму призначенню діаграма станів не є обов'язковим уявленням в моделі і як би "приєднується" до того елементу, який, за задумом розробників, має нетривіальну поведінку протягом свого життєвого циклу. Наявність у системи декількох станів, що відрізняються від простій дихотомії "справний, — несправний", "активний — неактивний", "очікування — реакція на зовнішні дії", вже служить ознакою необхідності побудови діаграми станів. Як початковий варіант діаграми станів, якщо немає очевидних міркувань з приводу станів об'єкту, можна скористатися цими суперстанами, розглядаючи їх як складені і уточнюючи їх (деталізуючи їх внутрішню структуру) у міру розгляду логіки поведінки об'єкту.
При виділенні станів і переходів слід пам'ятати, що тривалість спрацьовування окремих переходів повинна бути істотно меншою, ніж знаходження модельованого об'єкту у відповідних станах. Кожен із станів повинен характеризуватися певною стійкістю в часі. Іншими словами, з кожного перебування на діаграмі не може бути мимовільного переходу в яке б то не було інший стан. Всі переходи повинні бути явно специфіковані, інакше побудована діаграма станів є або неповною, або помилковою.
При розробці діаграми станів потрібно постійно стежити, щоб об'єкт в кожен момент міг знаходитися тільки в єдиному стані. Якщо це не так, то дана обставина може бути як наслідком помилки, так і неявною ознакою наявності паралельності у поведінки модельованого об'єкту. У останньому випадку слід явно специфікувати необхідне число підавтоматів, вклавши їх в той складений стан, який характеризується порушенням умови одночасності.
Слід обов'язково перевіряти, що ніякі два переходи з одного стану не можуть спрацювати одночасно (вимога відсутності конфліктів у переходів). Наявність такого конфлікту може служити ознакою помилки або неявної паралельності типу галуження даного процесу на два і більш за підавтомат. Якщо паралельність за задумом розробника відсутня, то необхідно ввести додаткові сторожові умови або змінити що існують, щоб виключити конфлікт переходів. За наявності паралельності слід замінити конфліктуючі переходи одним паралельним переходом типу галуження.
Використання історичних станів виправдане у тому випадку, коли необхідно організувати обробку виняткових ситуацій (переривань) без втрати даних або виконаної роботи. При цьому застосовувати історичні стани, особливо глибокі, треба з відомою часткою обережності. Потрібно пам'ятати, що кожен з під автоматів може мати тільки одне історичний стан. Інакше можливі помилки, особливо коли під автомати зображуються на окремих діаграмах станів.
Діаграма станів
Діаграма станів для класу Повідомлення:
Діаграма станів для класу Зареєстрований клієнт:
Діаграма станів для класу Персональний рахунок:
Діаграма станів для класу Квиток:
Діаграма станів для класу Веб-сторінка:
Діаграма станів для класу Пошук:
Висновок: Будівельними цеглинками діаграм станів є стани. Стан належить лише одному класу і відповідає переліку значень атрибутів, які може приймати клас. У UML стан описує внутрішній стан об’єкта одного з окремих класів
Зауважте, що не кожну зміну одного з атрибутів об’єкта має бути показано станом, станам відповідають лише ті зміни, які значно впливають на виконання об’єктом завдань.
Існує два особливих типи станів: початок і кінець. Їх особливість полягає у тому, що не існує жодної події, яка може спричинити повернення об’єкта до його початкового стану, так само, не існує жодної події, яка б могла повернути об’єкт зі стану кінця, тільки-но він його досягне.
01.02.2013 03:02-
Ділись своїми роботами та отримуй миттєві бонуси!
0%
Оголошення від адміністратора