Діаграма діяльності (activity diagram)

•7.1. Стан дії

•7.2. Переходи

•7.3. Доріжки

•7.4. Об'єкти

•7.5. Рекомендації по побудові діаграм діяльності

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

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

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

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

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

Стан дії

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

Графічно стан дії зображається “заокругленим” прямокутником (мал. 7.1). Усередині якого записується вираження дії (action-expression), який має бути унікальним в межах однієї діаграми діяльності.

Мал. 7.1. Графічне зображення стану дії

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

Інколи виникає необхідність представити на діаграмі діяльності деяку складну дію, яка, у свою чергу, складається з декількох простіших дій. В цьому випадку можна використовувати спеціальне позначення так званого стану под-деятельности (subactivity state). Такий стан є графом діяльності і позначається спеціальною піктограмою в правому нижньому кутку символу стану дії (мал. 7.2). Ця конструкція може застосовуватися до будь-якого елементу мови UML, яка підтримує "вкладеність" своєї структури. При цьому піктограма може бути додатково помічена типом вкладеної структури.

Мал. 7.2. Графічне зображення стану под-деятельности

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

Переходи

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

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

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

Приклад. Розглянемо фрагмент відомого алгоритму знаходження коріння квадратного рівняння. У загальному випадку після приведення рівняння другої порядку до канонічного вигляду: a*х*х+b*х+c=0 необхідно обчислити його дискримінант. Причому, в разі від’ємного дискримінанта рівняння не має розв’язків на множині дійсних чисел, і обчислення мають бути припинені. При додатному дискримінанті корені рівняння отримують за розрахунковими формулами.

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

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

Мал. 7.3. Фрагмент діаграми діяльності для алгоритму знаходження коріння квадратного рівняння

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

У наступному прикладі (мал. 7.4) розраховується загальна вартість товарів, що купуються по кредитній картці в супермаркеті. Якщо ця вартість перевищує $50, то виконується аутентифікація особи власника картки. В разі позитивної перевірки (картка дійсна) або якщо вартість товарів не перевищує $50, відбувається зняття суми з рахунку і оплата вартості товарів. При негативному результаті (картка недійсна) оплати не відбувається, і товар залишається у продавця.

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

Мал. 7.4. Різні варіанти галужень на діаграмі діяльності

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

Така риска зображається відрізком горизонтальної лінії, товстішою за основні суцільні лінії діаграми діяльності. При цьому розділення (concurrent fork) має один вхідний перехід і декілька вихідних (мал. 7.5, а). Злиття (concurrent join) – навпаки (мал. 7.5, б).

Мал. 7.5. Графічне зображення розділення і злиття паралельних потоків управління

Для ілюстрації особливостей паралельних процесів виконання дій розглянемо приклад з приготуванням напою. (мал. 7.6).

Мал. 7.6. Діаграма діяльності для прикладу з приготуванням напою

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

Доріжки

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

Для моделювання цих особливостей в мові UML використовується спеціальна конструкція, яка називається доріжка (swimlanes). (Візуальна аналогія з плавальними доріжками в басейні, якщо дивитися на відповідну діаграму.) При цьому всі стани дії на діаграмі діяльності діляться на окремі групи, які відділяються одна від одної вертикальними лініями. Дві сусідні лінії і утворюють доріжку, а група станів між цими лініями виконується окремим підрозділом (відділом, групою, відділенням, філією) компанії (мал. 7.7).

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

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

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

Мал. 7.7. Варіант діаграми діяльності з доріжками

Мал. 7.8. Фрагмент діаграми діяльності для торгівельної компанії

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

Об'єкти

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

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

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

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

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

Мал. 7.9. Фрагмент діаграми діяльності торгівельної компанії з об'єктом-замовленням

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

Мал. 7.10. Діаграма діяльності з синхронізацією паралельних дій

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

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

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

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

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

Діаграма діяльності будується для окремого класу, варіанту використання, окремої операції класу або цілої підсистеми.

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

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

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

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

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

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

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

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