7.5. Рекомендації по побудові діаграм діяльності
Діаграми діяльності грають важливу роль в розумінні процесів реалізації алгоритмів виконання операцій класів і потоків управління в модельованій системі. Традиційні блок-схеми алгоритмів, що використовуються для цієї мети, володіють серйозними обмеженнями в представленні паралельних процесів і їх синхронізації. Вживання доріжок і об'єктів відкриває додаткові можливості для наочного представлення бізнес‑ процесів, дозволяючи специфікувати діяльність підрозділів компаній і фірм.
Зміст діаграми діяльності багато в чому нагадує діаграму станів, хоча і не тотожне їй. Тому багато рекомендацій по побудові останньої виявляються справедливими стосовно діаграми діяльності. Зокрема, ця діаграма будується для окремого класу, варіанту використовування, окремої операції класу або цілої підсистеми.
З одного боку, на початкових етапах проектування, коли деталі реалізації деятельностей в проектованій системі невідомі, побудову діаграми діяльності починають з виділення под‑ деятельностей, які в сукупності утворюють діяльність підсистем. В подальшому, у міру розробки діаграм класів і станів, ці черінь‑ діяльності уточнюються у вигляді окремих вкладених діаграм діяльності компонентів підсистем, якими виступають класи і об'єкти.
З другого боку, окремі ділянки робочого процесу в існуючій системі можуть бути добре відладженими, і у розробників може виникнути бажання зберегти цей механізм виконання дій в проектованій системі. Тоді будується діаграма діяльності для цих ділянок, що відображає конкретні особливості виконання дій з використанням доріжок і об'єктів. В подальшому така діаграма вкладається в більш загальні діаграми діяльності для підсистеми і системи в цілому, зберігаючи свій рівень деталізації.
Таким чином, процес об'єктно-орієнтованого аналізу і проектування складних систем представляється як послідовність ітерацій низхідної і висхідної розробки окремих діаграм, включаючи і діаграму діяльності. Домінування того або іншого з напрямів розробки визначається особливостями конкретного проекту і його новизною.
У разі типового проекту більшість деталей реалізації дій може бути відомі наперед на основі аналізу існуючих систем або попереднього досвіду розробки систем‑ прототипів. Для цієї ситуації домінуючим буде висхідний процес розробки (Навіщо винаходити велосипед наново?). Використовування типових рішень може істотно скоротити час розробки і уникнути можливих помилок при реалізації проекту.
При розробці проекту нової системи, процес функціонування якої заснований на нових технологічних рішеннях, ситуація представляється складнішою. А саме, до початку роботи над проектом можуть бути невідомі не тільки деталі реалізації окремих деятельностей, але і сам зміст цих деятельностей стає предметом розробки. В даному випадку домінуючим буде низхідний процес розробки від більш загальних схем до уточнюючих їх діаграм. При цьому досягнення такого рівня деталізації всіх діаграм, який достатній для розуміння особливостей реалізації всіх дій і деятельностей, може служити ознакою завершення окремих етапів роботи над проектом.
На закінчення слід помітити, що діаграма діяльності, так само як і інші види канонічних діаграм, не містить засобів вибору оптимальних рішень. При розробці складних проектів проблема вибору оптимальних рішень стає вельми актуальною. Раціональне витрачання засобів, що затрачують на розробку і експлуатацію системи, підвищення її продуктивності і надійності часто визначають кінцевий результат всього проекту. В такій ситуації можна рекомендувати використовування додаткових засобів і методів, орієнтованих на аналитико‑ імітаційне дослідження моделей системи на етапі розробки її проекту.
Зокрема, при побудові діаграм діяльності складних систем можуть бути успішно використані різні класи мереж Петрі (класичні, логико‑ алгебра, стохастичні, нечіткі і ін.) і нейронних мереж. Вживання цих формализмов дозволяє не тільки одержати оптимальну структуру поведінки системи на її моделі, але і специфікувати цілий ряд додаткових характеристик системи, які не можуть бути представлені на діаграмі діяльності і інших діаграмах UML.
РОЗДІЛ 8
Діаграма послідовності (sequence diagram)
Як було відзначено в частині I книги, однією з характерних особливостей систем різної природи і призначення є взаємодія між собою окремих елементів, з яких утворені ці системи. Йдеться про те, що різні складові елементи систем не існують ізольований, а роблять 'определенное вплив один на одного, що і відрізняє систему як цілісне утворення від простої сукупності елементів.
В язиці UML взаємодія елементів розглядається в інформаційному аспекті їх комунікації, т. е. взаємодіючі об'єкти обмінюються між собою деякою інформацією. При цьому інформація приймає форму закінчених повідомлень. Іншими словами, хоча повідомлення і має інформаційний зміст, воно придбаває додаткову властивість робити направлений вплив на свого одержувача. Це повністю узгоджується з принципами ООАП, коли будь-які види інформаційної взаємодії між елементами системи повинні бути зведені до відправки і прийому повідомлень між ними.
Для моделювання взаємодії об'єктів в язиці UML використовуються відповідні діаграми взаємодії. Кажучи про ці діаграми, мають у вигляді два аспекти взаємодії. По-перше, взаємодії об'єктів можна розглядати в часі, і тоді для представлення тимчасових особливостей передачі і прийому повідомлень між об'єктами використовується діаграма послідовності. Цей вид канонічних діаграм є предметом вивчення справжнього розділу.
Раніше, при вивченні діаграм стану і діяльності, була відзначена одна важлива обставина. Хоча розглянуті діаграми і використовуються для специфікації динаміки поведінки систем, час в явному вигляді в них не присутній. Проте часовий аспект поведінки може мати істотне значення при моделюванні синхронних процесів, що описують взаємодії об'єктів. Саме для цієї мети в язиці UML використовуються діаграми послідовності.
По-друге, можна розглядати структурні особливості взаємодії об'єктів. Для представлення структурних особливостей передачі і прийому повідомлень між об'єктами використовується діаграма кооперації. Цей вид канонічних діаграм є предметом вивчення розділу 9.
8.1. Об'єкти
На діаграмі послідовності зображаються виключно ті об'єкти, які безпосередньо беруть участь у взаємодії і не показуються можливі статичні асоціації з іншими об'єктами. Для діаграми послідовності ключовим моментом є саме динаміка взаємодії об'єктів в часі. При цьому діаграма послідовності має як би два вимірювання. Одне – зліва направо у вигляді вертикальних ліній, кожна з яких зображає лінію життя окремого об'єкту, що бере участь у взаємодії. Графічно кожний об'єкт зображається прямокутником і розташовується у верхній частині своєї лінії життя (мал. 8.1). Усередині прямокутника записуються ім'я об'єкту і ім'я класу, розділене двокрапкою. При цьому весь запис підкреслюється, що є ознакою об'єкту, який, як відомо, є екземпляром класу.
Примітка
Не виключається ситуація, коли ім'я об'єкту може бути відсутній на діаграмі послідовності. В цьому випадку указується тільки ім'я класу, а сам об'єкт вважається анонімним.
Мал. 8.1. Різні графічні примітиви діаграми послідовності
Крайнім зліва на діаграмі зображається об'єкт, який є ініціатором взаємодії (об'єкт 1 на мал. 8.1). Правіше зображається інший об'єкт, який безпосередньо взаємодіє з першим. Таким чином, всі об'єкти на діаграмі послідовності утворюють деякий порядок, визначуваний ступенем активності цих об'єктів при взаємодії один з одним.
Друге вимірювання діаграми послідовності – вертикальна тимчасова вісь, направлена зверху вниз. Початковому моменту часу відповідає сама верхня частина діаграми. При цьому взаємодії об'єктів реалізуються за допомогою повідомлень, які посилаються одними об'єктами іншим. Повідомлення зображаються у вигляді горизонтальних стрілок з ім'ям повідомлення і також утворюють порядок за часом свого виникнення. Іншими словами, повідомлення, розташовані на діаграмі послідовності вище, ініціюються раніше тих, які розташовані нижче. При цьому масштаб на осі часу не указується, оскільки діаграма послідовності моделює лише тимчасову впорядкованість взаємодій типу «раньше‑ позже».
Лінія життя об'єкту
Лінія життя об'єкту (object lifeline) зображається пунктирною вертикальною лінією, асоційованою з єдиним об'єктом на діаграмі послідовності. Лінія життя служить для позначення періоду часу, протягом якого об'єкт існує в системі і, отже, може потенційно брати участь у всіх її взаємодіях. Якщо об'єкт існує в системі постійно, то і його лінія життя повинна продовжуватися по всій площині діаграми послідовності від самої верхньої її частини до самої нижньої (об'єкти 1 і 2 на мал. 8.1).
Окремі об'єкти, виконавши свою роль в системі, можуть бути знищені (зруйновані), щоб звільнити займані ними ресурси. Для таких об'єктів лінія життя обривається у момент його знищення. Для позначення моменту знищення об'єкту в язиці UML використовується спеціальний символ у формі латинської букви «X» (об'єкт 3 на мал. 8.1). Нижче за цей символ пунктирна лінія не зображається, оскільки відповідного об'єкту в системі вже немає, і цей об'єкт повинен бути виключений зі всіх подальших взаємодій.
Зовсім не обов'язково створювати всі об'єкти в початковий момент часу. Окремі об'єкти в системі можуть створюватися в міру необхідності, істотно економлячи ресурси системи і підвищуючи її продуктивність. В цьому випадку прямокутник такого об'єкту зображається не у верхній частині діаграми послідовності, а в тій її частині, яка відповідає моменту створення об'єкту (об'єкт 6 на мал. 8.2). При цьому прямокутник об'єкту вертикально розташовується в тому місці діаграми, яке по осі часу співпадає з моментом його виникнення в системі. Очевидно, об'єкт обов'язково створюється з своєю лінією життя і, можливо, з фокусом управління.
Мал. 8.2. Графічне зображення різних варіантів ліній життя і фокусів управління об'єктів
Фокус управління
В процесі функціонування об'єктно-орієнтованих систем одні об'єкти можуть знаходитися в активному стані, безпосередньо виконуючи певні дії або в стані пасивного очікування повідомлень від інших об'єктів. Щоб явно виділити подібну активність об'єктів, в язиці UML застосовується спеціальне поняття, що одержало назву фокусу управління (focus control). Фокус управління зображається у формі витягнутого вузького прямокутника (див. об'єкт 1 на мал. 8.1), верхня сторона якого позначає початок отримання фокусу управління об'єкту (початок активності), а її нижня сторона – закінчення фокусу управління (закінчення активності). Цей прямокутник розташовується нижче за позначення відповідного об'єкту і може замінювати його лінію життя (об'єкт 4 на мал. 8.2), якщо на всьому її протязі він є активним.
З другого боку, періоди активності об'єкту можуть чергувати з періодами його пасивності або очікування. В цьому випадку у такого об'єкту є декілька фокусів управління (об'єкт 5 на мал. 8.2). Важливо розуміти, що одержати фокус управління може тільки існуючий об'єкт, у якого у цей момент є лінія життя. Якщо ж деякий об'єкт був знищений, то знов виникнути в системі він вже не може. Замість нього лише може бути створений інший екземпляр цього ж класу, який, строго кажучи, буде іншим об'єктом.
В окремих випадках ініціатором взаємодії в системі може бути актор або зовнішній користувач. В цьому випадку актор зображається на діаграмі послідовності найпершим об'єктом зліва з своїм фокусом управління (мал. 8.3). Частіше всього актор і його фокус управління існуватимуть в системі постійно, відзначаючи характерну для користувача активність в ініціації взаємодій з системою. При цьому сам актор може мати власне ім'я або залишатися анонімним.
Іноді деякий об'єкт може ініціювати рекурсивну взаємодію з самим собою. Йдеться про те, що наявність в багатьох язиках програмування спеціальних засобів побудови рекурсивних процедур вимагає візуалізації відповідних понять у формі графічних примітивів. На діаграмі послідовності рекурсія позначається невеликим прямокутником, приєднаним до правої сторони фокусу управління того об'єкту, для якого зображається ця рекурсивна взаємодія (об'єкт 7 на мал. 8.3).
Мал. 8.3. Графічне зображення актора, рекурсії і повідомлення рефлексії на діаграмі послідовності