Подякувати Студентському архіву довільною сумою
Admin
26.02.2023 12:38
Дякуємо, що користуєтесь нашим архівом!
Моделювання послідовностей
Інформація про навчальний заклад
ВУЗ:
Інші
Інститут:
Не вказано
Факультет:
Комп’ютерні науки
Кафедра:
Не вказано
Інформація про роботу
Рік:
2009
Тип роботи:
Методичні вказівки до лабораторної роботи
Предмет:
Основи автоматизованого проектування складних об’єктів і систем
Частина тексту файла (без зображень, графіків і формул):
Методичні вказівки
до лабораторної роботи № 5
«Моделювання послідовностей»
з дисципліни
«Основи автоматизованого проектування складних об’єктів та систем»
для студентів базового напрямку підготовки за спеціальністю
“Комп’ютерні науки” (шифр 0804)
Львів-2009
Методичні вказівки до лабораторної роботи № 5 «Моделювання послідовностей»
з дисципліни “Основи автоматизованого проектування складних об’єктів та систем” для студентів спеціальності - шифр 0804 “Комп’ютерні науки” Укл. Скрибайло-Леськів Д.Ю., Львів: Національний університет “Львівська політехніка”, 2012.
Методичні вказівки обговорено та схвалено на засіданні кафедри АСУ Протокол № ___________ від «___»___________2009 р.
Завідувач кафедрою АСУ ______________ Рашкевич Ю. М.
Методичні вказівки обговорено та схвалено на засіданні методичної комісії базового напрямку підготовки
Протокол № ___________ від «___»___________2012 р.
Мета роботи: Освоїти моделювання послідовностей в UML—діаграмах та їх побудову у конкретному середовищі.
Завдання:
Оволодіти навиками моделювання послідовностей для UML—діаграм
Розробити діаграми класів для індивідуального завдання.
Теоретичні відомості
Діаграма послідовності (sequence diagram) - діаграма, на якій показані взаємодії об'єктів, впорядковані за часом їх прояву.
На діаграмі послідовності неявно присутня вісь часу, що дозволяє візуалізувати тимчасові відносини між переданими повідомленнями. За допомогою діаграми послідовності можна представити взаємодію елементів моделі як своєрідний часовий графік "життя" всієї сукупності об'єктів, пов'язаних між собою для реалізації варіанту використання програмної системи, досягнення бізнес-мети або виконання якої-небудь задачі. На рис. 1 показано, що для створення такої діаграми треба перш за все розташувати об'єкти, що беруть участь у взаємодії, у верхній її частині уздовж осі X. Об'єкт, що зазвичай ініціює взаємодію, розміщують зліва, а останні - правіше (тим далі, чим більш підлеглим є об'єкт). Потім уздовж осі Y розміщуються повідомлення, що посилаються та приймаються об’єктами, причому пізніші виявляються нижчими. Це дає читачеві наочну картину, що дозволяє зрозуміти розвиток потоку управління в часі.
Розглянемо детальніше побудову діаграми послідовності. На цій діаграмі зображуються виключно ті об'єкти, які безпосередньо беруть участь у взаємодії, і не показуються можливі статичні асоціації з іншими об'єктами. При цьому діаграма послідовності має умовно два вимірювання. Перше — зліва направо, у вигляді вертикальних ліній, кожна з яких зображає лінію життя окремого об'єкту, що бере участь у взаємодії. Графічно кожен об'єкт зображується прямокутником і розташовується у верхній частині своєї лінії життя (рис. 1). Усередині прямокутника записуються ім'я об'єкту і ім'я класу, розділені двокрапкою. При цьому весь запис підкреслюється, що є ознакою об'єкту, який, як відомо, є екземпляром класу.
Примітка. Не виключається ситуація, коли ім'я об'єкту може бути відсутнім на діаграмі послідовності. В цьому випадку указується тільки ім'я класу, а сам об'єкт вважається анонімним.
Друге вимірювання діаграми послідовності — вертикальна тимчасова вісь, направлена зверху вниз. Початковому моменту часу відповідає сама верхня частина діаграми. При цьому взаємодії об'єктів реалізуються за допомогою повідомлень, які посилаються одними об'єктами іншим. Повідомлення зображуються у вигляді горизонтальних стрілок з ім'ям повідомлення і також утворюють порядок за часом свого виникнення. Іншими словами, повідомлення, розташовані на діаграмі послідовності вище, ініціюються раніше тих, які розташовані нижче. При цьому масштаб на осі часу не указується, оскільки діаграма послідовності моделює лише тимчасову впорядкованість взаємодій типу "раніше-пізніше".
Рис. 1 Різні графічні примітиви діаграми послідовності
Отже, діаграми послідовностей характеризуються двома особливостями, що відрізняють їх від діаграм кооперації. По-перше, на них показана лінія життя об'єкту — це вертикальна пунктирна лінія, що відображає існування об'єкту в часі. Велика частина об'єктів, представлених на діаграмі взаємодій, існує впродовж всієї взаємодії, тому їх зображують у верхній частині діаграми, а їх лінії життя промальовують від верху до низу. Об'єкти можуть створюватися і під час взаємодій. Лінії життя таких об'єктів починаються з отримання повідомлення із стереотипом create. Об'єкти можуть також знищуватися під час взаємодій; у такому разі їх лінії життя закінчуються отриманням повідомлення із стереотипом destroy, а як візуальний образ використовується велика буква X, що позначає кінець життя об'єкту (Обставини життєвого циклу об'єкту можна указувати за допомогою обмежень new, destroyed і transient).
Примітка: Якщо об'єкт впродовж свого життя змінює значення атрибутів, стан або роль, це можна показати, помістивши копію його піктограми на лінії життя в точці зміни.
Друга особливість цих діаграм - фокус управління. Він зображується у вигляді витягнутого прямокутника, що показує проміжок часу, протягом якого об'єкт виконує яка-небудь дія, безпосередньо або за допомогою підлеглої процедури. Верхня грань прямокутника вирівнюється по тимчасовій осі з моментом початку дії, нижня - з моментом його завершення (і може бути помічена повідомленням про повернення). Вкладеність фокусу управління, викликана рекурсією (тобто зверненням до власної операції) або зворотним викликом з боку іншого об'єкту, можна показати, розташувавши інший фокус управління трохи правіше свого батька (допускається вкладеність довільної глибини). Якщо місце розташування фокусу управління потрібно вказати з максимальною точністю, можна заштрихувати область прямокутника, відповідну до часу, протягом якого метод дійсно працює і не передає управління іншому об'єкту.
Типові приклади застосування
Діаграми взаємодій використовуються для моделювання динамічних аспектів системи. Мова йде про взаємодії екземпляра будь-якого різновиду в будь-якому представленні системної архітектури, включаючи екземпляри класів, зокрема активних, інтерфейсів, компонентів і вузлів.
Моделювання динамічних аспектів системи за допомогою діаграми взаємодій можливо в контексті системи в цілому, підсистеми, операції або класу. Діаграми взаємодій можна приєднувати також до прецедентів (для моделювання сценарію) і до кооперацій (для моделювання динамічних аспектів співтовариства об'єктів)
Анатомія діаграм послідовності
Об'єкти зображуються у вигляді прямокутників і розміщуються над лініями життя (lifeline).
Лінії життя зображуються вертикальними лініями.
Напрям часу – згори вниз.
Повідомлення – це горизонтальні стрілки з назвою повідомлення.
За напрямом стрілки визначають відправника та отримувача.
Активізація об'єктів (focus of control).
Діаграми послідовностей (sequence diagrams).
Тепер звернемося до тимчасових властивостей алгоритмів роботи системи прийому телефонних заявок. Для цього в UML є діаграми послідовностей (і ще тимчасові діаграми, що розглядаються нижче). Приклад такої діаграми представлений на рис. 2.
Рис. 2 Приклад діаграми послідовностей
Дана діаграма сфокусована на діях оператора клієнтського ПО. По-перше, на ній явно зображено, що дві події - дзвінок операторові по телефону і поява діалогу для внесення інформації про дзвінок на дисплеї оператора - повинні відбуватися одночасно. Це "одночасно" може згодом доставити багато клопоту, оскільки необхідно буде тестувати цю вимогу в умовах, ідентичних умовам замовника, - в його локальній мережі, з тією швидкодією, яку вона може забезпечувати, з певною кількістю операторів, що одночасно працюють в мережі, і так далі, і зрозуміло, що в цій ситуації ПО повинно змагатися за швидкістю з процесом комутації в PBX. Цілком можливо, що телефонний апарат дзвонитиме значно раніше, ніж відповідна екранна форма з'явиться на екрані оператора, і це може виявитися вельми незручним. Значить, потрібно "прискорювати" обробку дзвінка сервером ПО. При цьому та або інша швидкодія може зажадати істотно різної реалізації серверних компонентів, тому потрібно турбуватися цією проблемою заздалегідь. Створення діаграм послідовностей допомагає на етапі проектування відмітити і не забути про подібні місця в алгоритмах. Програмістам бажано подолати нетерплячість і згаяти час на промальовування різних деталей архітектури перед початком та під час програмування, приступаючи до нового етапу роботи. Начебто і так все зрозуміло, але попереднє обдумування з фіксацією рішень за допомогою діаграм, обговорення цих діаграм з колегами може запобігти помилкам, які, будучи допущеними, зажадають для виправлення зусиль, які значно перевищують ті, що були витрачені на проектування.
Фокус управління
В процесі функціонування об'єктно-орієнтованих систем одні об'єкти можуть знаходитися в активному стані, безпосередньо виконуючи певні дії, або в стані пасивного очікування повідомлень від інших об'єктів. Щоб явно виділити подібну активність об'єктів, в мові UML застосовується спеціальне поняття, що отримало назву фокусу управління (focus of control). Фокус управління зображується у формі витягнутого вузького прямокутника (див. об'єкт1), верхня сторона якого позначає початок отримання фокусу управління об'єкту (початок активності), а її нижня сторона — закінчення фокусу управління (закінчення активності). Цей прямокутник розташовується нижче за позначення відповідного об'єкту і може замінювати його лінію життя, якщо протягом неї він є активним.
З іншого боку, періоди активності об'єкту можуть чергуватися з періодами його пасивності або очікування. В цьому випадку у такого об'єкту є декілька фокусів управління. Важливо розуміти, що отримати фокус управління може тільки існуючий об'єкт, у якого у цей момент є лінія життя. Якщо ж деякий об'єкт був знищений, то знов виникнути в системі він вже не може. Замість нього лише може бути створений інший екземпляр цього ж класу, який, строго кажучи, буде іншим об'єктом.
В окремих випадках ініціатором взаємодії в системі може бути актор або зовнішній користувач. В цьому випадку актор зображується на діаграмі послідовності найпершим об'єктом зліва зі своїм фокусом управління. Найчастіше актор і його фокус управління існуватимуть в системі постійно, відзначаючи характерну для користувача активність в ініціації взаємодій з системою. При цьому сам актор може мати власне ім'я або залишатися анонімним.
Іноді деякий об'єкт може ініціювати рекурсивну взаємодію з самим собою. Мова йде про те, що наявність в багатьох мовах програмування спеціальних засобів побудови рекурсивних процедур вимагає візуалізації відповідних понять у формі графічних примітивів. На діаграмі послідовності рекурсія позначається невеликим прямокутником, приєднаним до правої сторони фокусу управління того об'єкту, для якого зображується ця рекурсивна взаємодія (рис. 3).
Рис. 3 Графічне зображення актора, рекурсії і повідомлення рефлексії на діаграмі послідовності
Повідомлення
Як було відмічено вищим, мета взаємодії в контексті мови UML полягає в тому, щоб специфікувати комунікацію безліччю взаємодіючих об'єктів. Кожна взаємодія описується сукупністю повідомлень, якими об'єкти, що беруть участь в нім, обмінюються між собою. У цьому сенсі повідомленням (message) є закінчений фрагмент інформації, який відправляється одним об'єктом іншому. При цьому прийом повідомлення ініціює виконання певних дій, направлених на рішення окремої задачі тим об'єктом, якому це повідомлення відправлене.
Таким чином, повідомлення не тільки передають деяку інформацію, але і вимагають або припускають від приймаючого об'єкту виконання очікуваних дій. Повідомлення можуть ініціювати виконання операцій об'єктом відповідного класу, а параметри цих операцій передаються разом з повідомленням. На діаграмі послідовності всі повідомлення впорядковані за часом свого виникнення в модельованій системі.
У такому контексті кожне повідомлення має напрям від об'єкту, який ініціює і відправляє повідомлення, до об'єкту, який його отримує. Іноді відправника повідомлення називають клієнтом, а одержувача — сервером. При цьому повідомлення від клієнта має форму запиту деякого сервісу, а реакція сервера на запит після отримання повідомлення може бути пов'язана з виконанням певних дій або передачі клієнтові необхідної інформації теж у формі повідомлення.
Рис. 4 Графічне зображення різних видів повідомлень між об'єктами на діаграмі послідовності
У мові UML можуть зустрічатися декілька різновидів повідомлень, кожне з яких має своє графічне зображення.
Перший різновид повідомлення є найбільш поширеним і використовується для виклику процедур, виконання операцій або позначення окремих вкладених потоків управління. Початок цієї стрілки завжди стикається з фокусом управління або лінією життя того об'єкту-клієнта, який ініціює це повідомлення. Кінець стрілки стикається з лінією життя того об'єкту, який приймає це повідомлення і виконує у відповідь певні дії. При цьому приймаючий об'єкт часто отримує і фокус управління, стаючи активним.
Другий різновид повідомлення використовується для позначення простого (не вкладеного) потоку управління. Кожна така стрілка указує на прогрес одного кроку потоку. При цьому відповідні повідомлення зазвичай є асинхронними, тобто можуть виникати в довільні моменти часу. Передача такого повідомлення зазвичай супроводжується отриманням фокусу управління об'єктом, що його прийняв.
Третій різновид явно позначає асинхронне повідомлення між двома об'єктами в деякій процедурній послідовності. Прикладом такого повідомлення може служити переривання операції при виникненні виняткової ситуації. В цьому випадку інформація про таку ситуацію передається зухвалому об'єкту для продовження процесу подальшої взаємодії.
Нарешті, останній різновид повідомлення використовується для повернення з виклику процедури. Прикладом може служити просте повідомлення про завершення деяких обчислень без надання результату розрахунків об'єкту-клієнтові. У процедурних потоках управління ця стрілка може бути опущена, оскільки її наявність неявно передбачається в кінці активізації об'єкту. В той же час вважається, що кожен виклик процедури має свою пару — повернення виклику. Для не процедурних потоків управління, включаючи паралельні і асинхронні повідомлення, стрілка повернення повинна указуватися явним чином.
Зазвичай повідомлення зображуються горизонтальними стрілками, що сполучають лінії життя або фокуси управління двох об'єктів на діаграмі послідовності. При цьому неявно передбачається, що час передачі повідомлення достатній мало в порівнянні з процесами виконання дій об'єктами. Вважається також, що за час передачі повідомлення з відповідними об'єктами не може відбутися ніяких подій. Іншими словами, стани об'єктів залишаються без зміни. Якщо ж це припущення не може бути визнане справедливим, то стрілка повідомлення зображується під деяким нахилом, так щоб кінець стрілки розташовувався нижче за її початок.
В окремих випадках об'єкт може посилати повідомлення самому собі, ініціюючи так звані повідомлення рефлексій. Такі повідомлення зображуються прямокутником із стрілкою, почало і кінець якої співпадають. Подібні ситуації виникають, наприклад, при обробці натиснень на клавіші клавіатури при введенні тексту в редагований документ, при наборі цифр номера телефону абонента.
Таким чином, в мові UML кожне повідомлення асоціюється з деякою дією, яка повинна бути виконане об'єктом, що прийняв його. При цьому дія може мати деякі аргументи або параметри, залежно від конкретних значень яких може бути отриманий різний результат. Відповідні параметри матиме і що викликає це дія повідомлення. Більш того, значення параметрів окремих повідомлень можуть містити умовні вирази, утворюючи галуження або альтернативні шляхи основного потоку управління.
Галуження потоку управління
Для зображення галуження малюються дві або більш стрілки, що виходять з однієї точки фокусу управління об'єкту. При цьому відповідні умови повинні бути явно вказані поряд з кожною із стрілок у формі сторожової умови. Як неважко представити, якщо умова записана у формі булевого виразу, то галуження міститиме тільки дві гілки. У будь-якому випадку умови повинні взаємно виключати одночасну передачу альтернативних повідомлень.
За допомогою галуження можна зобразити і складнішу логіку взаємодії об'єктів між собою. Якщо умов більше двох, то для кожного з них необхідно передбачити ситуацію єдиного виконання. Даний приклад відноситься до моделювання взаємодії програмної системи обслуговування клієнтів в банці. На цьому прикладі діаграми послідовності об'єкт1 передає управління одному з трьох інших об'єктів.
Рис. 5 Графічне зображення бінарного галуження потоку управління на діаграмі послідовності
Рис. 6 Графічне зображення тернарного галуження потоку управління на діаграмі послідовності
Умовою галуження може служити сума коштів, що знімаються клієнтом, зі свого поточного рахунку. Якщо ця сума перевищує $1000, то можуть потрібно додаткові дії, пов'язані із створенням і подальшим руйнуванням об'єкту 4. Якщо ж сума перевищує $50, але не перевищує $1000, то управління передається об'єкту 3. І, нарешті, якщо сума не перевищує $50, то управління отримує об'єкт 2. При цьому об'єкти 1, 2 і 3 постійно існують в системі. Об'єкт 4 створюється, тільки якщо справедливо перше з альтернативних умов. Інакше він може бути ніколи не створений. Після виконання необхідних дій об'єкти 2 і 3 просто інформують об'єкт 1 про завершення відповідних операцій, не вимагаючи від нього ніяких дій (пунктирна стрілка). Об'єкт 4 після завершення своїх дій знищується, передаючи управління об'єкту 3, роблячи його активним (фокус управління).
Стереотипи повідомлень
У мові UML передбачені деякі стандартні дії, що виконуються у відповідь на отримання відповідного повідомлення. Вони можуть бути явно вказані на діаграмі послідовності у формі стереотипу поряд з повідомленням, до якого вони відносяться. В цьому випадку вони записуються в лапках. Використовуються наступні позначення для моделювання дій:
"call" (викликати) — повідомлення, що вимагає виклику операції або процедури приймаючого об'єкту. Якщо повідомлення з цим стереотипом рефлексія, то воно ініціює локальний виклик операції у того, що самого послало це повідомлення об'єкту;
"return" (повернути) — повідомлення, що повертає значення виконаної операції або процедури об'єкту, що викликав її. Значення результату може ініціювати галуження потоку управління;
"create" (створити) — повідомлення, що вимагає створення іншого об'єкту для виконання певних дій. Створений об'єкт може отримати фокус управління, а може і не отримати його;
"destroy" (знищити) — повідомлення з явною вимогою знищити відповідний об'єкт. Посилається у тому випадку, коли необхідно припинити небажані дії з боку об'єкту, що існує в системі, або коли об'єкт більше не потрібний і повинен звільнити задіяні їм системні ресурси;
"send" (послати) — позначає посилку іншому об'єкту деякого сигналу, який асинхронно ініціюється одним об'єктом і приймається (перехоплюється) іншим. Відмінність сигналу від повідомлення полягає в тому, що сигнал повинен бути явно описаний в тому класі, об'єкт якого ініціює його передачу.
Нижче представлена діаграма послідовності для розглянутого вище випадку галуження, доповнена стереотипними значеннями.
Окрім стереотипів, повідомлення можуть мати власне позначення операції, виклик якої вони ініціюють у приймаючого об'єкту. В цьому випадку поряд із стрілкою записується ім'я операції з круглими дужками, в яких можуть указуватися параметри або аргументи відповідної операції. Якщо параметри відсутні, то дужки все одно повинні бути присутніми після імені операції. Прикладами таких операцій можуть служити наступні: "видати клієнтові готівкою суму (п)", "встановити з'єднання між абонентами (а, Ь)", "зробити текст, що вводиться, невидимим ()", "подати звуковий сигнал тривоги ()".
Примітка. Згідно прийнятої в мові UML системі позначень такі імена операцій записуються на англійському з малої букви і одним словом, можливо, що складається з декількох скорочених слів, написаних без пропуску і без лапок. Якщо немає ніяких додаткових обмежень з боку інструментальних засобів візуалізації канонічних діаграм, то справа смаку вітчизняного розробника, які позначення йому використовувати в україномовній транслітерації. Можливо, для цієї мети більше підходить варіант з нижньою рискою, що виключає пропуски в імені операції: "зробити_вводимий_текст_невидимим()", аніж варіант із заголовними буквами всередині імені операції: "зробитиВводимийТекстНевидимим()".
Рис. 7 Діаграма послідовності із стереотипними значеннями повідомлень
Тимчасові обмеження на діаграмах послідовності
В окремих випадках виконання тих або інших дій на діаграмі послідовності може зажадати явної специфікації тимчасових обмежень, що накладаються на сам інтервал виконання операцій або передачу повідомлень. У мові UML для запису тимчасових обмежень використовуються фігурні дужки. Тимчасові обмеження можуть відноситися як до виконання певних дій об'єктами, так і до самих повідомлень, явно специфікуючи умови їх передачі або прийому. Важливо розуміти, що на відміну від умов галуження, які повинні виконуватися альтернативно, тимчасові обмеження мають обов'язковий або директивний характер для асоційованих з ними об'єктів.
Тимчасові обмеження можуть записуватися поряд з початком стрілки відповідного повідомлення. Але найчастіше вони записуються зліва від цієї стрілки на одному рівні з нею. Якщо тимчасова характеристика відноситься до конкретного об'єкту, то ім'я цього об'єкту записується перед ім'ям характеристики і відділяється від неї крапкою.
Прикладами таких обмежень на діаграмі послідовності можуть служити ситуації, коли необхідно явно специфікувати час, протягом якого допускається передача повідомлення від клієнта до сервера або обробка запиту клієнта сервером:
{ час_прийому_повідомлення - час_відправки_повідомлення < 1 сек.}
{ час_очікування_відповіді< 5 сек.}
{ час_передачі_пакета < 10 сек.}
{ об’єкт_1. час_подачі_сигналу_тривоги > 30 сек.}
Примітка. У першому з розглянутих випадків знак "-" в тимчасовому обмеженні позначає арифметичну операцію віднімання (мінус). Інші знаки є звичайними знаками порівняння величин. У останньому випадку перед тимчасовою характеристикою вказано ім'я об'єкту, до якого вона відноситься.
Коментарі або примітки
Коментарі або примітки вже розглядалися раніше при вивченні інших видів діаграм. Вони можуть включатися і в діаграми послідовності, асоціюючись з окремими об'єктами або повідомленнями. При цьому використовується стандартне позначення для коментаря — прямокутник з "заламаним" правим верхнім кутом. Усередині цього прямокутника записується текст коментаря на природній мові.
Приклад побудови діаграми послідовності
Як приклад розглянемо побудову діаграми послідовності для моделювання процесу телефонної розмови з використанням звичайної телефонної мережі. Об'єктами в даному прикладі є: два абоненти а і Ь, два телефонні апарати end, комутатор і сама розмова як об'єкт моделювання. При цьому як комутатор, так і розмова є анонімними об'єктами.
На першому етапі розташовуємо вибрані об'єкти на передбачуваній діаграмі. Відмітимо, що абонентів ми розглядатимемо як акторів, причому перший з них — а — грає активну роль, а другий — b — пасивну роль. Тому перший отримує фокус управління відразу після своєї появи в системі, а другою має тільки лінію життя. Комутатор також має постійну активність, що зображується його фокусом управління. Розмова як об'єкт з'являється тільки після установки з'єднання і знищується з його припиненням. Тому він буде зображений пізніше на цій же діаграмі послідовності.
Рис. 8 Початковий фрагмент діаграми послідовності для моделювання телефонної розмови
Процес взаємодії в цій системі починається з підняття трубки телефонного апарату першим абонентом. Тим самим він посилає повідомлення телефонного апарату з, яке переводить цей апарат в активний стан і викликає дію — подачу тонового сигналу в телефонну трубку для першого абонента. Наступна дія також ініціюється першим абонентом — набір цифр телефонного номера. Це представлено у формі ітеративного повідомлення із знаком "*" зліва від його імені.
Відмітимо, що підняття телефонної трубки і набір цифр номера є фізичними діями і тому зображуються у формі простих асинхронних повідомлень. Після набору цифр’ номера телефону апарат з рекурсивно викликає процедуру посилки комутаційних імпульсів на комутатор. Останній ініціює створення нового об'єкту в модельованій системі — телефонної розмови. Доповнений фрагмент діаграми послідовності зображений на рис. нижче.
Після створення анонімний об'єкт "розмова" відразу отримує фокус активності і посилає повідомлення телефонного апарату d на виконання дії — дзвінка виклику. При цьому другий абонент знімає трубку (асинхронне повідомлення), тим самим встановлюється пряме з'єднання між абонентами а і Ь. Після того, як абоненти опустять трубки, розмова закінчується. Тим самим об'єкт "розмова" знищується. Остаточний варіант діаграми послідовності може містити деякі тимчасові обмеження і коментарі. Призначення окремих повідомлень відповідають розглянутим діям.
Рис. 9 Доповнений фрагмент діаграми послідовності для моделювання телефонної розмови
Рис. 10 Остаточний варіант діаграми послідовності для моделювання телефонної розмови
Примітка. Доповнити діаграму послідовності для цього прикладу тимчасовими обмеженнями пропонується виконати самостійно як вправу.
Завершальні рекомендації по побудові діаграм послідовності
Як вже наголошувалося, побудову діаграми послідовності доцільно починати з виділення зі всієї сукупності тих і лише тих класів, об'єкти яких беруть участь в модельованій взаємодії. Після цього всі об'єкти наносяться на діаграму з дотриманням деякого порядку ініціалізації повідомлень. Тут необхідно встановити, які об'єкти існуватимуть постійно, а які тимчасово — тільки на період виконання ними необхідних дій.
Коли об'єкти візуалізовані, можна приступати до специфікації повідомлень. При цьому слід враховувати ті ролі, які грають повідомлення в системі. При необхідності уточнення цих ролей треба використовувати їх різновиди і стереотипи. Для знищення об'єктів, які створюються на час виконання своїх дій, потрібно передбачити явне повідомлення.
Найбільш прості випадки галуження процесу взаємодії можна зобразити на одній діаграмі з використанням відповідних графічних примітивів. Проте слід пам'ятати, що кожен альтернативний потік управління може істотно утруднити розуміння побудованої моделі. Тому загальним правилом є візуалізація кожного потоку управління на окремій діаграмі послідовності. У цій ситуації такі окремі діаграми повинні розглядатися спільно як одна модель взаємодії.
Подальша деталізація діаграми послідовності пов'язана з введенням тимчасових обмежень на виконання окремих дій в системі. Для простих асинхронних повідомлень тимчасові обмеження можуть бути відсутніми. Проте необхідність синхронізувати складні потоки управління, як правило, вимагають введення в модель таких обмежень. Загальний їх запис повинен слідувати семантиці мови об'єктних обмежень, яка розглянута в додатку.
Приклад моделювання діаграми послідовностей на тему: «Інформаційно-аналітична система «Реєстратура готелю» »
Рис. 11.1 Діаграма послідовностей для виду діяльності «Пошук»
Рис. 11.2. Діаграма послідовностей для виду діяльності «Реєстрація»
Рис. 11.3. Діаграма послідовностей для виду діяльності «Оплата».
Рис. 11.4. Діаграма послідовностей для виду діяльності «Обслуговування»
Рис. 11.5. Діаграма послідовностей для виду діяльності «Повідомлення клієнту» і «Обновлення бази даних»
Рис. 11.6. Діаграма послідовностей для виду діяльності «Бронювання»
Рис. 11.7. Діаграма послідовностей для виду діяльності «Виїзд з готелю»
Рис. 11.8. Діаграма послідовностей для виду діяльності «Замовлення додаткових послуг»
Порядок виконання роботи
Ознайомитися з теоретичною частиною.
Ознайомитися із середовищем розробки діаграм.
Розробити діаграму прецедентів для свого індивідуального завдання.
Здійснити документацію для кожного прецеденту діаграми.
Оформити звіт по результатах виконаної роботи.
Вимоги до звіту
Оформити звіт для захисту лабораторної роботи за зразком:
назва роботи
мета роботи
порядок роботи
короткі теоретичні відомості
аналіз отриманих результатів та висновок.
Рекомендована література
1. Чекурін В., Острей С., Острей О. Модель функціонування інформаційно-аналітичної системи багаторівневого моніторингу якості освіти // Фізико-математичне моделювання та інформаційні технології. – Львів. – 2007. – №6. – С. 66-76. 2. Чекурін В.Ф., Острей С.В., Острей О.Р. Моделювання програмної системи для багаторівневого моніторингу якості освіти // Інформаційні технології та інформаційна безпека в науці, техніці та навчанні “ІНФОТЕХ-2007”. Частина 2: Матеріали між нар. наук.-практ. конф., м. Севастополь, 10-16 вересня 2007р. – Севастополь: Вид-во СевНТУ, 2007. – С.147-148. 3. Якобсон А., Буч Г., Рамбо Дж. Унифицированный процесс разработки программного обеспечения. – СПб.: Питер, 2002. – 498 с.: ил. 4. Гарсиа-Молина Г., Ульман Дж., Уидом Дж. Системы баз данных. Полный курс: Пер. с англ. – М.: Издательский дом “Вильямс”, 2004. – 1088с.: ил. 5. Кузнецов С.Д. Концептуальное проектирование реляционных баз данных с использованием языка UML // Новые публикации, 15.03.2008. – www.CITForum.ru. 6. Буч Г., Рамбо Дж., Якобсон А Язык UML: Руководство пользователя. – М.: ДМК, 2000. – 356 с.: ил. 7. Мюллер Р. Дж. Базы данных и UML. Проектирование / Перевод. С англ. Е. Молодцов. – М.: Издательство “Лори”,2002. – 432с.: ил. 8. Гордеев А.В., Молчанов А.Ю. Системное программное обеспечение. – С.-Пб. Питер, 2001. – 740 с.: ил.
Методичні вказівки до лабораторної роботи № 5 “ Моделювання послідовностей” з дисципліни “ Основи автоматизованого проектування складних об’єктів та систем ” для студентів спеціальності 0804 “Комп’ютерні науки”
Укладач:
Скрибайло-Леськів Д.Ю.
Комп’ютерний набір, верстку та редагування
здійснив ст. гр. КН-42, каф. АСУ, Грицько Тарас.
05.04.2013 09:04-
Ділись своїми роботами та отримуй миттєві бонуси!
0%
Оголошення від адміністратора