PrIS

461

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

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

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

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

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

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

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

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

462

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

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

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

Контрольні запитання

1.Призначення діаграми діяльності.

2.Стан дії.

3.Переходи на діаграмі діяльності.

4.Доріжки на діаграмі діяльності.

5.Об'єкти на діаграмі діяльності.

463

Розділ 22. Діаграма послідовності (sequence diagram)

Лінія життя об'єкту

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

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

Тимчасові обмеження на діаграмах послідовності

Рекомендації з побудови діаграм послідовності

Як було відзначено вище, однією з характерних рис систем різної природи і призначення є взаємодія окремих елементів, з яких утворені ці системи. Мова йде про те, що різні складені елементи систем не існують ізольовано, а певним чином впливають один на одного, що й відрізняє систему як цілісне утворення від простої сукупності елементів.

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

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

Раніше, при вивченні діаграм стану і діяльності, була відзначена одна важлива обставина. Хоча розглянуті діаграми й використовуються для специфікації динаміки поведінки систем, час в явному вигляді на них не є присутнім. Однак часовий аспект поведінки може мати істотне значення під час моделювання синхронних процесів, що описують взаємодію об'єктів. Саме для цієї мети в мові UML використовуються діаграми послідовності.

По-друге, можна розглядати структурні особливості взаємодії об'єктів. Для подання структурних особливостей передавання і приймання повідомлень між об'єктами використовується діаграма кооперації. Цей вид канонічних діаграм є предметом вивчення розділу 23.

464

22.1. Об'єкти на діаграмі послідовностей

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

Примітка

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

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

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

Другий вимір діаграми послідовності – вертикальна тимчасова вісь, спрямована зверху вниз. Початковому моменту часу відповідає найвища

466

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

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

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

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

467

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

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

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

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

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

468

повідомленням. На діаграмі послідовності всі повідомлення впорядковані за часом свого виникнення в модельованій системі.

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

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

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

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

469

натискань на клавіші клавіатури під час введення тексту в документ, при наборі цифр номера телефону абонента.

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

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

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

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

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

470

банку. На цьому прикладі діаграми послідовності об'єкт 1 передає керування одному із трьох інших об'єктів.

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

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

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

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