Повідомлення на діаграмі послідовності
Повідомлення як елементи мови UML, вже розглядалися раніше при вивченні діаграми кооперації. Стрілки повідомлень зображуються аналогічно розглянутим раніше, але стосовно до діаграм послідовності повідомлення мають додаткові семантичні особливості. При цьому на діаграмі послідовності всі повідомлення впорядковані за часом своєї передачі в моделюється системі, хоча номери у них можуть не вказуватися.
На діаграмах послідовності можуть бути присутніми три різновиди повідомлень, кожне з яких має своє графічне зображення (рис. 8.4).
Графічне зображення різних видів повідомлень між об'єктами на діаграмі послідовності
Рис. 8.4. Графічне зображення різних видів повідомлень між об'єктами на діаграмі послідовності
Перша різновид повідомлення (рис. 8.4, а) найбільш поширена і використовується для виклику процедур, виконання операцій або позначення окремих вкладених потоків керування. Початок цієї стрілки, як правило, стикається з фокусом управління того об'єкта-клієнта, який ініціює це повідомлення. Кінець стрілки стикається з лінією життя того об'єкту, який приймає це повідомлення і виконує у відповідь певні дії. При цьому приймає об'єкт може отримати фокус управління, стаючи в цьому випадку активним. Передавальний об'єкт може втратити фокус управління або залишитися активним.
Другий різновид повідомлення (рис. 8.4, б) використовується для позначення простого асинхронного повідомлення, яке передається в довільний момент часу. Передача такого повідомлення зазвичай не супроводжується отриманням фокусу керування об'єктом-одержувачем.
Третій різновид повідомлення (рис. 8.4, в) використовується для повернення з виклику процедури. Прикладом може служити просте повідомлення про завершення обчислень без надання результату розрахунків об'єкту-клієнту. У процедурних потоках управління ця стрілка може бути опущена, оскільки її наявність неявно передбачається в кінці активізації об'єкту. У той же час вважається, що кожен виклик процедури має свою пару - повернення виклику. Для непроцедурних потоків управління, включаючи паралельні і асинхронні повідомлення, стрілка повернення повинна указуватися явним чином.
Зазвичай повідомлення зображуються горизонтальними стрілками, що з'єднують лінії життя або фокуси управління двох об'єктів на діаграмі послідовності. При цьому неявно передбачається, що час передачі повідомлення достатньо мало в порівнянні з процесами виконання дій об'єктами. Вважається також, що за час передачі повідомлення з відповідними об'єктами не може статися жодних подій. Іншими словами, стану об'єктів не змінюються. Якщо ж це припущення не може бути визнано справедливим, то стрілка повідомлення зображується під нахилом, так щоб кінець стрілки розташовувався нижче її початку.
Кожне повідомлення на діаграмі послідовності асоціюється з певною операцією, яка має бути виконана прийняв його об'єктом. При цьому операція може мати аргументи або параметри, значення яких впливають на отримання різних результатів. Відповідні параметри операції матиме і зухвала це дія повідомлення. Більш того, значення параметрів окремих повідомлень можуть містити умовні вирази, утворюючи розгалуження або альтернативні шляхи основного потоку управління. Галуження потоку управління
Одна з особливостей діаграми послідовності - можливість візуалізувати просте розгалуження процесу. Для зображення розгалуження використовуються дві або більше стрілки, що виходять з однієї точки фокусу керування об'єкту (об'єкт ob1 на рис. 8.5). При цьому поряд з кожною з них повинно бути явно вказано відповідне умова гілки у формі Булевського вирази.
Кількість гілок може бути довільним, однак наявність розгалужень може істотно ускладнити інтерпретацію діаграми послідовності. Пропозиція-умова має бути явно вказано для кожної гілки і записується у формі звичайного тексту, псевдокоду або вирази мови програмування. Це вираз завжди має повертати деяке Булевського вираз. Запис цих умов повинна виключати одночасну передачу альтернативних повідомлень по двох і більш гілкам. В іншому випадку на діаграмі послідовності може виникнути конфлікт розгалуження.
Рис. 8.5. Графічне зображення бінарного розгалуження потоку управління на діаграмі послідовності
За допомогою розгалуження можна зобразити і більш складну логіку взаємодії об'єктів між собою (об'єкт ob1 на рис. 8.6). Якщо умов більш двох, то для кожного з них необхідно передбачити ситуацію єдиного виконання. Описаний нижче приклад відноситься до моделювання взаємодії програмної системи обслуговування клієнтів у банку. У цьому прикладі діаграми послідовності об'єкт ob1 викликає виконання дій у одного з трьох інших об'єктів.
Умовою розгалуження може бути сума знімаються клієнтом коштів зі свого поточного рахунку. Якщо ця сума перевищує 1500 $, то можуть знадобитися додаткові дії, пов'язані зі створенням і подальшим руйнуванням об'єкту Класу 1. Якщо ж сума перевищує 100 $, але не перевищує 1500 $, то викликається операція або процедура об'єкта ob3. І, нарешті, якщо сума не перевищує 100 $, то викликається операція або процедура об'єкта ob2. При цьому об'єкти ob1, ob2 і ob3 постійно існують в системі. Останній об'єкт створюється від Класу 1 тільки в тому випадку, якщо справедливо перше з альтернативних умов. В іншому випадку він може бути ніколи не створений.
Рис. 8.6. Графічне зображення тернарного розгалуження потоку управління на діаграмі послідовності
Об'єкт ob1 має постійний фокус управління, а всі інші об'єкти - отримують фокус управління тільки для виконання ними відповідних операцій.
На діаграмах послідовності при записі повідомлень також можуть використовуватися стереотипи, розглянуті раніше при побудові діаграми кооперації (лекція 7). Їх семантика і синтаксис залишаються без зміни, як вони визначені в нотації мови UML. Нижче подано діаграму послідовності для описаного вище випадку розгалуження, доповнена стереотипними значеннями окремих повідомлень (рис. 8.7). Очевидно, ця діаграма послідовності є більш виразною і простий для своєї змістовної інтерпретації.
Рис. 8.7. Діаграма послідовності зі стереотипними значеннями повідомлень
Як вже зазначалося раніше, повідомлення можуть мати власне ім'я, в якості якого виступає ім'я операції, виклик якої ініціюють ці повідомлення у приймаючого об'єкту. У цьому випадку поряд із стрілкою записується ім'я операції з круглими дужками, в яких можуть зазначатися параметри або аргументи відповідної операції. Якщо параметри відсутні, то дужки після імені операції все одно повинні бути зображені.