Методичні вказівки
до лабораторної роботи № 3
«Моделювання видів діяльності»
з дисципліни
«Основи автоматизованого проектування складних об’єктів та систем»
для студентів базового напрямку підготовки по спеціальності
“Комп’ютерні науки” (шифр 0804)
Львів-2009
Методичні вказівки до лабораторної роботи № 3 “ Моделювання видів діяльності ” з дисципліни “Основи автоматизованого проектування складних об’єктів та систем ” для студентів спеціальності - шифр 0804 “Комп’ютерні науки” Укл. Дорошенко А.В.,
Львів: Національний університет “Львівська політехніка”, 2009.
Методичні вказівки обговорено та схвалено на засіданні кафедри АСУ Протокол № ___________ від «___»___________2009 р.
Завідувач кафедрою АСУ ______________ Рашкевич Ю. М.
Методичні вказівки обговорено та схвалено на засіданні методичної комісії базового напрямку підготовки
Протокол № ___________ від «___»___________2009 р.
Лабораторна робота № 3
Моделювання видів діяльності
Мета: Оволодіти навичками моделювання діаграм видів діяльності для індивідуального завдання та навчитися реалізовувати їх.
Завдання: Здійснити моделювання діаграм видів діяльності за допомогою середовища розробки діаграм EA або в Borland Together.
1. Теоретична частина
Діаграми діяльності - це один з п'яти видів діаграм, вживаних в UML для моделювання динамічних аспектів поведінки. Це, по суті, блок-схема, яка показує, як потік управління переходить від однієї діяльності до іншої.
Як правило, діаграми діяльності застосовуються, щоб змоделювати послідовні (а іноді і паралельні) кроки обчислювального процесу. За допомогою діаграм діяльності можна також моделювати життя об'єкту, коли він переходить з одного стану в інший в різних точках потоку управління. Діаграми діяльності можуть використовуватися самостійно для візуалізації, специфікації, конструювання і документування динаміки сукупності об'єктів, але вони придатні також і для моделювання потоку управління при виконанні деякої операції. Якщо в діаграмах взаємодій акцент робиться на переходах потоку управління від об'єкту до об'єкту, то діаграми діяльності описують переходи від однієї діяльності до іншої. Діяльність (Activity) - це деякий відносно тривалий етап виконання в автоматі. Зрештою діяльність зводиться до деякої дії (Action), яка складена з атомарних обчислень, що приводять до зміни стану системи або повернення значення.
У UML є декілька елементів, які не мають реального семантичного змісту для моделі, але допомагають прояснити частини діаграми. Цими елементами є
Рядки тексту
Текстові нотатки і якорі
Блоки
Рядки тексту можуть знадобитися, якщо до діаграми слід додати коротку текстову інформацію. Вони є довільно розташованим тестом і не мають значення для самої моделі.
Нотатками можна скористатися для додавання докладніших відомостей щодо об’єкта або певної ситуації. У них є велика перевага у тому, що нотатки можна пов’язати з елементами UML, щоб було видно, що нотатка“стосується” певного об’єкта або ситуації.
Блоки є довільно розташованими прямокутниками, які можна використовувати для групування об’єктів діаграми, яке зробить діаграму зрозумілішою. Вони не мають логічного навантаження у межах моделі.
/
Мал.1. Діаграма діяльності
На цьому малюнку після прийому замовлення є розділення. Розділення має єдиний вхідний перехід і декілька переходів, що виходять. Коли спрацьовує вхідний перехід, всі переходи, що виходять, виконуються паралельно. Таким чином, після надходження замовлення заповнення бланка замовлення і виставляння рахунку виконуються паралельно. Можна спочатку заповнити бланк замовлення, виставити рахунок і відправити товар, після чого отримати оплату. Або можна спочатку виставити рахунок, отримати оплату, після чого заповнити бланк замовлення і відправити товар. Всі ці варіанти допускаються даною діаграмою.
Також ці діяльності можна зробити такими, що чергуються. Наприклад, узяти першу позицію замовлення з складу, надрукувати рахунок, потім другу позицію замовлення, помістити рахунок в конверт і так далі. Або виконувати деякі з цих діяльностей одночасно: друкувати рахунок і перевіряти наявність товарів на складі. Згідно наший діаграмі, будь-який з цих варіантів є коректним.
Дана діаграма діяльності дозволяє вибрати окреме замовлення, з яким необхідне що-небудь зробити. Іншими словами, дана діаграма просто встановлює основні правила послідовності дій, які необхідно дотримувати.
Далі на діаграмі після заповнення бланку замовлення іде розгалуження. Розгалуження має єдиний вхід і декілька вихідних переходів зі сторожовими умовами. Оскільки може виконуватися тільки один з переходів, що виходять, сторожові умови повинні взаємно виключати один одного. Якщо як сторожова умова використовується [інакше], то це означає, що перехід з міткою «інакше» повинен відбутися у тому випадку, коли всі інші сторожові умови для даного галуження є помилковими. Наприклад, якщо замовлення виявляється терміновим, виконується його термінова доставка, інакше - звичайна доставка. Далі йде з’єднання. З'єднання має декілька вхідних переходів і єдиний перехід, що виходить. Воно означає закінчення умовної поведінки, яка була почата відповідним галуженням. Щоб зробити розгалуження і з'єднання зрозумілішими на діаграмі, слід використовувати ромби.
Далі на діаграмі після з’єднання слідує злиття. Злиття вказує на необхідність синхронізації: ми не можемо закрити замовлення до тих пір, поки воно не буде оплачене і відправлене клієнтові. Злиття на діаграмі діяльності означає, що вихідні переходи можуть відбутися тільки у тому випадку, коли стани у всіх вхідних переходах завершать свої діяльності.
Розділення і злиття повинні відповідати один одному. У простому випадку це означає, що для будь-якого розділення на діаграмі повинне бути відповідне злиття, яке об'єднує всі гілки, що мають початок в цьому розділенні.
Проте це правило має декілька виключень:
Гілка, що виходить з деякого розділення, сама може бути розділенням з новими гілками, які об’єднуються ще до того, як буде досягнуто злиття всіх початкових гілок;
Якщо гілка, яка виходить з одного розділення, одразу потрапляє в інше розділення, то це друге розділення можна видалити. Гілки, що виходять з цього другого розділення можна зобразити такими, що виходять з першого розділення.
Якщо деяке злиття переходить в інше злиття, то перше злиття можна видалити, а всі вхідні в нього гілки зобразити такими, що входять в друге злиття. Це спрощення нотації дозволяє подолати непотрібне ускладнення діаграм, і така сама семантика дозволяє зображати на діаграмі додаткові розділення і злиття.
В загальному випадку, діаграма взаємодій повинна складатися з вершин наступних п’яти видів:
Стан. В такій вершині виконується деяка дія. Вона має не більше однієї гілки, що входить у неї, і не більше однієї, що виходить.
Розгалуження. Ця вершина має одну гілку, що входить, і дві або більше, що виходять. Кожній гілці, що виходить, відповідає деяка умова, причому з усіх умов тільки одна повинна бути істинною. По гілці, якій відповідає істинна умова, передається керування.
З’єднання. Вершина цього виду має дві або більше гілок, що входять, і одну, що виходить. З’єднання означає закінчення декількох варіантів умовної поведінки, які були розпочаті відповідним розгалуженням.
Розділення. Така вершина має одну гілку, що входить, і не менше двох, що виходять. Вона призначена для опису паралельної поведінки системи. При виконанні розділення керування передається по всім дугам, що виходять.
Злиття. Ця вершина має дві або більше гілок, що входять, і одну, що виходить. Злиття виконується, якщо воно отримує керування по всіх гілках, що входять.
Діаграма діяльності, як і будь-яка інша діаграма, може містити примітки і обмеження.
2. Приклад моделювання діаграми взаємодій на тему: «Інформаційно-аналітична система «Реєстратура готелю»»
Діаграма видів діяльності
Рис.2.1.1 Види діяльності для прецеденту «Пошук»
Рис. 2.1.2. Діаграма видів діяльності для прецеденту «Пошук»
Таблиця 2.1.1 Установка дії в основних та альтернативних потоках для прецеденту «Пошук»
№
Формулювання прецеденту
Стан видів діяльності
1.
2.
3.
4.
5.
Після того як клієнт натисне кнопку «Пошук»,
система відображає на екрані форму пошуку і просить ввести необхідні дані для пошуку
Клієнт повинен ввести дані в поля пошуку
Система безпосередньо проводить пошук по базі даних
Система виводить результат пошуку на екран
Система пропонує клієнту повторити процедуру пошуку.
Відобразити форму пошуку
Ввести дані
Здійснити пошук
Вивести результат пошуку
Повторити
/
Рис.2.2.1 Види діяльності для прецеденту «Реєстрація»
Таблиця 2.2.1 Установка дії в основних та альтернативних потоках для прецеденту «Реєстрація»
№
Формулювання прецеденту
Стан видів діяльності
1.
2.
3.
Після того, як клієнт натисне кнопку «Зареєструватись», система відображає на екрані форму реєстрації і просить ввести необхідні дані
Система перевіряє введені дані на коректність
Система переходить до прецеденту «Повідомлення клієнту»
Показати реєстраційну форму
Перевірити введені дані на коректність
Перехід до прецеденту «Повідомлення клієнту»
Рис. 2.2.2. Діаграма видів діяльності для прецеденту «Реєстрація»
Рис.2.3.1 Види діяльності для прецеденту «Оплата»
Таблиця 2.3.1 Установка дії в основних та альтернативних потоках для прецеденту «Оплата»
№
Формулювання прецеденту
Стан видів діяльності
1.
2.
3.
4.
Початок прецеденту співпадає з рішенням клієнта розпочати оплату. Після того як клієнт натисне клавішу «оплатити», він обирає зручну для нього форму оплати.
Клієнт безпосередньо оплачує вартість проживання і/або додаткових послуг
Система перевіряє чи оплата пройшла успішно
Система видає клієнту закодовану ключ-картку «VingCard»
Клієнт обирає зручну для нього форму оплати
Клієнт безпосередньо оплачує вартість проживання і/або додаткових послуг
Оплата пройшла успішно
Видання клієнту закодованої ключ-картки «VingCard»
Рис. 2.3.2. Діаграма видів діяльності для прецеденту «Оплата»
Рис.2.4.1 Види діяльності для прецеденту «Обслуговування»
Таблиця 2.4.1 Установка дії в основних та альтернативних потоках для прецеденту «Обслуговування»
№
Формулювання прецеденту
Стан видів діяльності
1.
2.
Система перевіряє чи прийшов час для певної послуги(наприклад, зміна рушників в номері)
Система проводить безпосереднє виконання послуги
Чи прийшов час для певної послуги
Безпосереднє виконання послуги
Рис. 2.4.2. Діаграма видів діяльності для прецеденту «Обслуговування»
Рис.2.5.1 Види діяльності для прецеденту «Обновлення бази даних»
Таблиця 2.5.1 Установка дії в основних та альтернативних потоках для прецеденту «Обновлення бази даних»
№
Формулювання прецеденту
Стан видів діяльності
1.
Система постійно обновлює в базі даних статус номерів
Обновлення в базі даних статусу номера(вільний, зайнятий чи заброньований)
Рис. 2.5.2. Діаграма видів діяльності для прецеденту «Обновлення бази даних»
Рис.2.6.1 Види діяльності для прецеденту «Повідомлення клієнту»
Таблиця 2.6.1 Установка дії в основних та альтернативних потоках для прецеденту «Повідомлення клієнту»
№
Формулювання прецеденту
Стан видів діяльності
1.
2.
Система постійно получає різного роду запити, які одразу опрацьовує
Виведення на екран відповідного повідомлення
Опрацювання запиту
Відправлення відповідного повідомлення
Рис. 2.6.2. Діаграма видів діяльності для прецеденту «Повідомлення клієнту»
/
Рис.2.7.1 Види діяльності для прецеденту «Бронювання»
Таблиця 2.7.1 Установка дії в основних та альтернативних потоках для прецеденту «Бронювання»
№
Формулювання прецеденту
Стан видів діяльності
1.
2.
3.
Після того, як клієнт натисне кнопку «Забронюватись», система відображає на екрані форму бронювання і просить ввести необхідні дані
Система перевіряє правильність заповнення полів.
Система переходить до прецеденту «Повідомлення клієнту»
Показати форму бронювання
Перевірити введені дані на коректність
Перехід до прецеденту «Повідомлення клієнту»
Рис. 2.7.2. Діаграма видів діяльності для прецеденту «Бронювання»
Рис.2.8.1 Види діяльності для прецеденту «Виїзд з готелю»
Таблиця 2.8.1 Установка дії в основних та альтернативних потоках для прецеденту «Виїзд з готелю»
№
Формулювання прецеденту
Стан видів діяльності
1.
2.
3.
4.
Система перевіряє чи вийшов термін проживання клієнта в готелі
Система повідомляє клієнта про закінчення терміну проживання
Клієнт повинен повернути ключ від номера
Система переходить до прецеденту «Обновлення бази даних»
Чи вийшов термін проживання в готелі
Повідомити клієнта про закінчення терміну проживання
Повернення клієнтом ключа від номера
Перехід до прецеденту «Обновлення бази даних»
Рис. 2.8.2. Діаграма видів діяльності для прецеденту «Виїзд з готелю»
Рис.2.9.1 Види діяльності для прецеденту «Замовлення додаткових послуг»
Таблиця 2.9.1 Установка дії в основних та альтернативних потоках для прецеденту «Замовлення додаткових послуг»
№
Формулювання прецеденту
Стан видів діяльності
1.
2.
3.
4.
Початок прецеденту співпадає з рішенням клієнта замовити додаткові послуги. Далі клієнт вибирає зі списку ті послуги, які його зацікавили.
Система просить клієнта підтвердити здійснення замовлення.
Система пропонує повторити спробу.
Система переходить до прецеденту «Повідомлення клієнту»
Клієнт вибирає зі списку ті послуги, які його зацікавили
Клієнт підтвердив здійснення замовлення
Повторити спробу
Перехід до прецеденту «Повідомлення клієнту»
Рис. 2.9.2. Діаграма видів діяльності для прецеденту «Замовлення додаткових послуг»
Порядок виконання роботи
Ознайомитися з теоретичною частиною.
Ознайомитися із середовищем розробки діаграм.
Розробити діаграму прецедентів для свого індивідуального завдання.
Здійснити документацію для кожного прецеденту діаграми.
Оформити звіт по результатах виконаної роботи.
Вимоги до звіту
Оформити звіт для захисту лабораторної роботи за зразком:
назва роботи
мета роботи
порядок роботи
короткі теоретичні відомості
аналіз отриманих результатів та висновок.
Рекомендована література
Язык UML. Руководство пользователю / Грейди Буч, Джеймс Рамбо, Айвар Джекобсон. 2-е изд., Питер 2004.
Головатий О.О. Методичні вказівки до оформлення пояснювальних записок із дипломних робіт, літньої практики, курсових робіт та рефератів для студентів спеціальностей “Програмне забезпечення автоматизованих систем” та “Економічна кібернетика”. Жовті Води, ІП “Стратегія”, 2005.
Хабуш А., Ткачук Н.В., Исмаилов Р. Применение Web–технологии в информационно-управляющей системе газокомпрессорной станции магистрального газопровода. // Вісник ХДПУ. Харків, ХДПУ, вип. 102, 2000- С.113-117.
4. Кватрани Т. Rational Rose 2000 и UML Визуальное моделирование: Пер. с а ДМК Пресс, 2001. - 176 с: ил. (Серия «Объектно-ориентированные технологии в программировании»).
5. Ларман, Крэг.Л25 Применение UML и шаблонов проектирования. 2-е издание. : Пер. с англ. —М. : Издательский дом "Вильяме", 2004. — 624 с. : ил. —Па-рал, тит. англ.http://www.omg.org.
http://www.asp.net.
http://www.rational.com.
http://www.omg.org.
Методичні вказівки до лабораторної роботи № 3 “ Моделювання видів діяльності ” з дисципліни “ Основи автоматизованого проектування складних об’єктів та систем ” для студентів спеціальності 0804 “Комп’ютерні науки”
Укладач:
Дорошенко А.В.
Комп’ютерний набір, верстку та редагування
здійснили ст. гр. КН-410, каф. АСУ, Мастикаш О.В. , Тринкін М.