Примітка. Не виключається ситуація, коли ім'я об'єкта може бути відсутнім на діаграмі послідовності

Не виключається ситуація, коли ім'я об'єкта може бути відсутнім на діаграмі послідовності. У цьому випадку вказується тільки ім'я класу, а сам об'єкт вважається анонімним.

Рис. 22.1. Різні графічні примітиви діаграми послідовності

Крайнім ліворуч на діаграмі зображується об'єкт, що є ініціатором взаємодії (об'єкт 1 на рис. 22.1). Правіше зображується інший об'єкт, що безпосередньо взаємодіє з першим. Таким чином, всі об'єкти на діаграмі послідовності утворять деякий порядок, обумовлений ступенем активності цих об'єктів під час взаємодії один з одним.

Другий вимір діаграми послідовності – вертикальна тимчасова вісь, спрямована зверху вниз. Початковому моменту часу відповідає сама верхня частина діаграми. При цьому взаємодії об'єктів реалізуються за допомогою повідомлень, які посилають одні об'єкти іншим. Повідомлення зображуються у вигляді горизонтальних стрілок з іменем повідомлення й також утворять порядок згідно часу свого виникнення. Інакше кажучи, повідомлення, розташовані на діаграмі послідовності вище, ініціюються раніше тих, які розташовані нижче. При цьому масштаб на осі часу не вказується, оскільки діаграма послідовності моделює лише тимчасову впорядкованість взаємодій типу "пізніше".

22.1.1. Лінія життя об'єкта

Лінія життя об'єкта (object lifeline) зображується пунктирною вертикальною лінією, що асоціюється з єдиним об'єктом на діаграмі послідовності. Лінія життя служить для позначення періоду часу, протягом якого об'єкт існує в системі й, отже, може потенційно брати участь у всіх її взаємодіях. Якщо об'єкт існує в системі постійно, то і його лінії життя повинна тривати на всій площині діаграми послідовності від самої верхньої її частини до самої нижньої (об'єкти 1 і 2 на рис. 22.1).

Окремі об'єкти, виконавши свою роль у системі, можуть бути знищені (зруйновані), щоб звільнити займані ними ресурси. Для таких об'єктів лінія життя обривається в момент його знищення. Для позначення моменту знищення об'єкта в мові UML використається спеціальний символ у формі латинської букви "X" (об'єкт 3 на рис. 22.1). Нижче цього символу пунктирна лінія не зображується, оскільки відповідного об'єкта в системі вже немає, і цей об'єкт повинен бути виключений із всіх наступних взаємодій.

Зовсім не обов'язково створювати всі об'єкти в початковий момент часу. Окремі об'єкти в системі можуть створюватися в міру необхідності, істотно заощаджуючи ресурси системи й підвищуючи її продуктивність. У цьому випадку прямокутник такого об'єкта зображується не у верхній частині діаграми послідовності, а в тій її частині, що відповідає моменту створення об'єкта (об'єкт 6 на рис. 22.2). При цьому прямокутник об'єкта вертикально розташовується в тому місці діаграми, що на осі часу збігається з моментом його виникненням в системі. Об'єкт обов'язково створюється зі своєю лінією життя й, можливо, з фокусом керування.

22.1.2. Фокус керування

У процесі функціонування об'єктно-орієнтованих систем одні об'єкти можуть перебувати в активному стані, безпосередньо виконуючи певні дії або в стані пасивного очікування повідомлень від інших об'єктів. Щоб явно виділити подібну активність об'єктів, у мові UML застосовується спеціальне поняття, що одержало назву фокус керування (focus of control). Фокус керування зображується у формі витягнутого вузького прямокутника (див. об'єкт 1 на рис. 22.1), верхня сторона якого позначає початок отримання фокусу керування об'єкта (початок активності), а її нижня сторона – закінчення фокусу керування (закінчення активності). Цей прямокутник розташовується нижче позначення відповідного об'єкта й може замінювати його лінію життя (об'єкт 4 на рис. 22.2), якщо він є активним на протязі всього свого життя.

Рис. 22.2. Графічне зображення різних варіантів ліній життя й фокусів керування об'єктів

Періоди активності об'єкта можуть чергуватися з періодами його пасивності або очікування. У цьому випадку в такого об'єкта є кілька фокусів керування (об'єкт 5 на рис. 22.2). Важливо розуміти, що одержати фокус керування може тільки існуючий об'єкт, у якого в цей момент є лінія життя. Якщо ж деякий об'єкт був знищений, то знову виникнути в системі він вже не зможе. Замість нього лише може бути створений інший екземпляр цього ж класу, що, строго говорячи, буде іншим об'єктом.

В окремих випадках ініціатором взаємодії в системі може бути актор або зовнішній користувач. У цьому випадку актор зображується на діаграмі послідовності найпершим об'єктом ліворуч зі своїм фокусом керування (рис. 22.3). Найчастіше актор і його фокус керування будуть існувати в системі постійно, відзначаючи характерну для користувача активність в ініціюванні взаємодій із системою. При цьому сам актор може мати власне ім'я або залишатися анонімним.

Іноді деякий об'єкт може ініціювати рекурсивну взаємодію із самим собою. Мова йде про те, що наявність у багатьох мовах програмування спеціальних засобів побудови рекурсивних процедур вимагає візуалізації відповідних понять у формі графічних примітивів. На діаграмі послідовності рекурсія позначається невеликим прямокутником, приєднаним до правої сторони фокуса керування того об'єкта, для якого зображується ця рекурсивна взаємодія (об'єкт 7 на рис. 22.3).

Рис. 22.3. Графічне зображення актора, рекурсії й рефлексивного повідомлення на діаграмі послідовності

22.2. Повідомлення

Як було відзначено вище, ціль взаємодії в контексті мови UML полягає в тому, щоб специфікувати комунікацію між множиною взаємодіючих об'єктів. Кожна взаємодія описується сукупністю повідомлень, якими об'єкти обмінюються між собою. У цьому змісті повідомлення (message) є закінченим фрагментом інформації, що відправляється одним об'єктом іншому. При цьому прийом повідомлення ініціює виконання певних дій, спрямованих на рішення окремого завдання тим об'єктом, якому це повідомлення відправлене.

Таким чином, повідомлення не тільки передає деяку інформацію, але й вимагає від приймаючого об'єкта виконання очікуваних дій. Повідомлення можуть ініціювати виконання операцій об'єктом відповідного класу, а параметри цих операцій передаються разом з повідомленням. На діаграмі послідовності всі повідомлення впорядковані за часом свого виникнення в модельованій системі.

У такому контексті кожне повідомлення має напрямок від об'єкта, що ініціює й відправляє повідомлення, до об'єкта, що його одержує. Іноді відправника повідомлення називають клієнтом, а одержувача – сервером. При цьому повідомлення від клієнта має форму запиту деякого сервісу, а реакція сервера на запит після одержання повідомлення може бути пов'язана з виконанням певних дій або передачі клієнтові необхідної інформації теж у формі повідомлення.

Рис. 22.4. Графічне зображення різних видів повідомлень між об'єктами на діаграмі послідовності

У мові UML можуть зустрічатися кілька різновидів повідомлень, кожне з яких має своє графічне зображення (рис. 22.4).

Перший різновид повідомлення (рис. 22.4, а) є найпоширенішим й використовується для виклику процедур, виконання операцій або позначення окремих вкладених потоків керування. Початок цієї стрілки завжди доторкається до фокуса керування або лінією життя того об'єкта-клієнта, що ініціює це повідомлення. Кінець стрілки доторкається до лінії життя того об'єкта, що приймає це повідомлення й виконує у відповідь певні дії. При цьому приймаючий об'єкт найчастіше одержує й фокус керування, стаючи активним.

Другий різновид повідомлення (рис. 22.4, б) використовується для позначення простого (не вкладеного) потоку керування. Кожна така стрілка вказує на прогрес одного кроку потоку. При цьому відповідні повідомлення звичайно є асинхронними, тобто можуть виникати в довільні моменти часу. Передача такого повідомлення звичайно супроводжується одержанням фокуса керування приймаючим об'єктом.

Третій різновид (рис. 22.4, в) явно позначає асинхронне повідомлення між двома об'єктами в деякій процедурній послідовності. Прикладом такого повідомлення може служити переривання операції при виникненні виняткової ситуації. У цьому випадку інформація про таку ситуацію передається початковому об'єкту для продовження процесу подальшої взаємодії.

Нарешті, останній різновид повідомлення (рис. 22.4, г) використовується для повернення з виклику процедури. Прикладом може служити просте повідомлення про завершення деяких обчислень без надання результату розрахунків об'єкту-клієнтові. У процедурних потоках керування ця стрілка може бути опущена, оскільки її наявність неявно передбачається наприкінці активізації об'єкту. У той же час вважається, що кожний виклик процедури має свою пару – повернення виклику. Для не процедурних потоків керування, включаючи паралельні й асинхронні повідомлення, стрілка повернення повинна вказуватися явно.

Звичайно повідомлення зображуються горизонтальними стрілками, що з'єднують лінії життя або фокуси керування двох об'єктів на діаграмі послідовності. При цьому неявно передбачається, що час передачі повідомлення досить малий в порівнянні із процесами виконання дій об'єктами. Вважається також, що за час передачі повідомлення з відповідними об'єктами не може відбутися ніяких подій. Інакше кажучи, стан об'єктів залишаються без зміни. Якщо ж це припущення не є правильним, то стрілка повідомлення зображується під деяким нахилом, так щоб кінець стрілки розташовувався нижче її початку.

В окремих випадках об'єкт може посилати повідомлення самому собі, ініціюючи рефлексивні повідомлення (об'єкт 8 на рис. 22.3). Такі повідомлення зображуються прямокутником зі стрілкою, початок і кінець якої збігаються. Подібні ситуації виникають, наприклад, при опрацюванні натискань на клавіші клавіатури під час введення тексту в документ, при наборі цифр номера телефону абонента.

Таким чином, у мові UML кожне повідомлення асоціюється з деякою дією, що повинна бути виконана його приймаючим об'єктом. При цьому дія може мати деякі аргументи або параметри, залежно від конкретних значень, в залежності від яких може бути отриманий різний результат. Відповідні параметри буде мати й викликаючі цю дію повідомлення. Більше того, значення параметрів окремих повідомлень можуть містити умовні вирази, утворюючи розгалуження або альтернативні шляхи основного потоку керування.

22.2.1. Розгалуження потоку керування

Для зображення розгалуження рисуються дві або більше стрілок, що виходять із однієї точки фокусу керування об'єкта (фокус керування об'єкта 1 на рис. 22.5). При цьому відповідні умови повинні бути явно зазначені поруч із кожної зі стрілок у формі сторожової умови. Якщо умова записана у формі булевого виразу, то розгалуження буде містити тільки дві вітки. У кожному разі умови повинні взаємно виключати одночасну передачу альтернативних повідомлень.

За допомогою розгалуження можна зобразити й складнішу логіку взаємодії об'єктів між собою (фокус керування об'єкта 1 на рис. 22.6). Якщо умов більше ніж дві, то для кожної необхідно передбачити ситуацію єдиного виконання. Розглянутий приклад може виникнути під час моделювання взаємодії програмної системи обслуговування клієнтів у банку. На цьому прикладі діаграми послідовності об'єкт 1 передає керування одному із трьох інших об'єктів.

Рис. 22.5. Графічне зображення бінарного розгалуження потоку керування на діаграмі послідовності

Рис. 22.6. Графічне зображення тернарного розгалуження потоку керування на діаграмі послідовності

Умовою розгалуження може служити сума, що знімає клієнт зі свого поточного рахунку. Якщо ця сума перевищує $1000, то можуть знадобитися додаткові дії, пов'язані зі створенням і наступним руйнуванням об'єкта 4. Якщо ж сума перевищує $50, але не перевищує $1000, то керування передається об'єкту 3. І, нарешті, якщо сума не перевищує $50, то керування одержує об'єкт 2. При цьому об'єкти 1, 2 і 3 постійно існують у системі. Об'єкт 4 створюється, тільки якщо справедлива перша з альтернативних умов. В іншому випадку він може бути ніколи не створений. Після виконання необхідних дій об'єкти 2 і 3 просто інформують об'єкт 1 про завершення відповідних операцій, не вимагаючи від його ніяких дій (пунктирна стрілка). Об'єкт 4 після завершення своїх дій знищується, передаючи керування об'єкту 3, роблячи його активним (фокус керування).

22.2.2. Стереотипи повідомлень

У мові UML передбачені деякі стандартні дії, що виконуються у відповідь на одержання відповідного повідомлення. Вони можуть бути явно зазначені на діаграмі послідовності у формі стереотипу поруч із повідомленням, до якого вони відносяться. У цьому випадку вони записуються в лапках. Використовуються такі позначення для моделювання дій:

¨ "call" (викликати) – повідомлення, що викликає операції або процедури приймаючого об'єкта. Якщо повідомлення із цим стереотипом рефлексивне, то воно ініціює локальний виклик операції в самого об'єкта, що послав це повідомлення;

¨ "return" (повернути) – повідомлення, що повертає значення виконаної операції або процедури об'єкту, що її викликав. Значення результату може ініціювати розгалуження потоку керування;

¨ "create" (створити) – повідомлення, що вимагає створення іншого об'єкта для виконання певних дій. Створений об'єкт може одержати фокус керування, а може й не одержати його;

¨ "destroy" (знищити) – повідомлення з явною вимогою знищити відповідний об'єкт. Посилається в тому випадку, коли необхідно припинити небажані дії з боку існуючого в системі об'єкта, або коли об'єкт більше не потрібний і повинен звільнити задіяні ним системні ресурси;

¨ "send" (послати) – позначає посилання іншому об'єкту деякого сигналу, що асинхронно ініціюється одним об'єктом і приймається (перехоплюється) іншим. Відмінність сигналу від повідомлення полягає в тому, що сигнал повинен бути явно описаний у тому класі, об'єкт якого ініціює його передачу.

Нижче представлена діаграма послідовності для розглянутого вище випадку розгалуження, доповнена стереотипними значеннями (рис. 22.7).

Крім стереотипів, повідомлення можуть мати власне позначення операції, виклик якої вони ініціюють у приймаючого об'єкта. У цьому випадку поруч зі стрілкою записується ім'я операції із круглими дужками, у яких можуть вказуватися параметри або аргументи відповідної операції. Якщо параметри відсутні, то дужки однаково повинні бути присутніми після імені операції. Прикладами таких операцій можуть служити такі операції: "видати клієнтові суму (n)", "встановити з'єднання між абонентами (а, b)", "зробити введення тексту невидимим ()", "подати звуковий сигнал тривоги ()".

Поиск по сайту: