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