Тема 9. Діаграми дій
При моделюванні поведінки проектованої або аналізованої системи виникає необхідність не тільки представити процес зміни її станів, але й деталізувати особливості алгоритмічної і логічної реалізації виконуваних системою операцій. Традиційно для цього використовувались блок-схеми або структурні схеми алгоритмів. Кожна така схема акцентує увагу на послідовності виконання певних дій або елементарних операцій, які в сукупності приводять до отримання бажаного результату.
Для моделювання процесу виконання операцій в UML використовуються так звані діаграми діяльностей. Їх графічна нотація в дечому схожа з нотацією діаграми станів. Відмінність полягає в семантиці станів, які використовуються для представлення не діяльностей, а дій, і у відсутності на переходах сигнатури подій. Кожен стан на діаграмі діяльності відповідає виконанню деякої елементарної операції, а перехід до наступного стану спрацьовує тільки при завершенні цієї операції в попередньому стані. Графічно діаграма діяльності представляється в форму графу діяльності, вершинами якого є стани дії, а дугами - переходи від одного стану дії до іншого.
Таким чином, діаграми діяльності можна вважати частковим випадком діаграм станів. Основним напрямком використання діаграм діяльності є візуалізація особливостей реалізації операцій класів, коли необхідно представити алгоритми їх виконання. При цьому кожен стан може бути виконанням операції деякого класу або її частини, дозволяючи використовувати діаграми діяльності для опису реакцій на внутрішні події системи.
В контексті мови UML діяльність (activity) представляє собою деяку сукупність окремих обчислень, які виконує автомат. При цьому окремі елементарні обчислення можуть приводити до деякого результату або дії (action). На діаграмі діяльності зображається логіка або послідовність переходу від однієї діяльності до іншої, при цьому увага фіксується на результаті діяльності. Сам же результат може привести до зміни стану системи або повернення деякого значення.
Стан дії (action state) є спеціальним випадком стану з деякою вхідною дією і хоча б одним вихідним із стану переходом. Цей перехід неявно передбачає, що вхідна дія вже завершилась. Стан дії не може мати внутрішніх переходів, оскільки він є елементарним. Звичайне використання стану дії полягає в моделюванні одного кроку виконання алгоритму (процедури) або потоку управління.
Графічно стан дії зображається фігурою, яка нагадує прямокутник, бокові сторони якого замінені випуклими дугами. В цій фігурі записується вираз дії (action-expression), який повинен бути унікальним в межах однієї діаграми діяльності.
Дія може бути записана на природній мові, деякому псевдокоді або мові програмування. Жодних додаткових або неявних обмежень при записі дій не накладається. Рекомендується як ім'я простої дії використовувати дієслово з пояснювальними словами. Якщо ж дія може бути представлена в деякому формальному виді, то доцільно записати її на тій ж мові програмування, на якій передбачається реалізувати конкретний проект.
Іноді виникає необхідність представити на діаграмі діяльності деяку складну дію, яка, в свою чергу, складається з декількох більш простих дій. У цьому випадку можна використати спеціальне позначення так званого стану піддіяльності (subactivity state). Такий стан є графом діяльності і позначається спеціальною піктограмою в правому нижньому куті символу стану дії.
Кожна діаграма діяльності повинна мати єдиний початковий і єдиний кінцевий стан. Вони мають такі ж позначення, як і на діаграмі станів. При цьому кожна діяльність починається в початковому стані і закінчується в кінцевому стані. Саму діаграму діяльності прийнято розміщати таким чином, щоб дії слідували зверху до низу. У цьому випадку початковий стан буде зображатися в верхній частині діаграми, а кінцевий - в її нижній частині.
При побудові діаграми діяльності використовуються тільки нетригерні переходи, тобто такі, які спрацьовують відразу після завершення діяльності або виконання відповідної дії. Цей перехід переводить діяльність в наступний стан відразу, як тільки закінчиться дія в попередньому стані. На діаграмі такий перехід зображається суцільною лінією зі стрілкою.
Якщо з стану дії виходить єдиний перехід, то він може бути не помічений. Якщо ж таких переходів декілька, то спрацьовувати може тільки один із них. Саме в цьому випадку для кожного з таких переходів повинна бути явно записана сторожова умова в прямих дужках. При цьому для всіх вихідних із деякого стану переходів повинна виконуватися вимога істинності тільки одного з них. Подібний випадок зустрічається тоді, коли послідовно виконувана діяльність повинна розділитися на альтернативні гілки в залежності від значення деякого проміжного результату. Така ситуація отримала назву галуження.
Графічно галуження на діаграмі діяльності позначається невеликим ромбом, в якому немає жодного тексту. В цей ромб може входити тільки одна стрілка від того стану дії, після виконання якого потік управління повинен бути продовжений за однією з взаємно виключних гілок. Прийнято вхідну стрілку приєднувати до верхньої або лівої вершини символу галуження. Вихідних стрілок може бути дві або більше, але для кожної з них явно вказується відповідна сторожова умова в формі логічного виразу.
Один із найбільш вагомих недоліків звичайних блок-схем або структурних схем алгоритмів зв'язаний з проблемою зображення паралельних гілок окремих обчислень. Оскільки розпаралелення обчислень суттєво підвищує загальну швидкодію програмних систем, необхідні графічні примітиви для представлення паралельних процесів. У мові UML для цієї цілі використовується спеціальний символ для розділення і злиття паралельних обчислень або потоків управління - пряма риска.
Як правило, така риска зображається відрізком горизонтальної лінії, товщина якої дещо ширша основних суцільних ліній діаграми діяльності. При цьому розділення має один вхідний перехід і декілька вихідних. Злиття, навпаки, має декілька вхідних переходів і один вихідний.
Таким чином, діаграма діяльності є не що інше, як спеціальний випадок діаграми станів, в якій всі або більшість станів є діями або станами піддіяльності. А всі або більшість переходів є нетригерними переходами, які спрацьовують після завершення дії або піддії в станах-джерелах.
Діаграми діяльності можуть бути використані не тільки для специфікації алгоритмів обчислень або потоків управління в програмних системах. Не менш важлива область їх застосування зв'язана з моделюванням бізнес-процесів. Діяльність будь-якої компанії також представляє собою не що інше, як сукупність окремих дій, направлених на досягнення потрібного результату. Проте стосовно бізнес-процесів бажано виконання кожної дії асоціювати з конкретним підрозділом компанії. У цьому випадку підрозділ несе відповідальність за реалізацію окремих дій, а сам бізнес-процес представляється у виді переходів дій з одного підрозділу до другого.
Для моделювання цих особливостей в UML використовується спеціальна конструкція — доріжка (swimlanes). Мається на увазі візуальна аналогія з плавальними доріжками в басейні, якщо дивитися на відповідну діаграму. При цьому всі стани дій на діаграмі діяльності діляться на окремі групи, які відділяються одні від одних вертикальними лініями. Дві сусідні лінії і утворюють доріжку, а група станів між цими лініями виконується окремим підрозділом компанії.
Назви підрозділів явно вказуються в верхній частині доріжки. Перетинати лінію доріжки можуть тільки переходи, які в цьому випадку позначають вихід або вхід потоку управління у відповідний підрозділ компанії. Порядок слідування доріжок не несе жодної семантичної інформації і визначається зручністю.
Об'єкти на діаграмі діяльностей
У загальному випадку дії на діаграмі діяльності виконуються над тими чи іншими об'єктами. Ці об'єкти або ініціюють виконання дій, або визначають деякий результат цих дій. При цьому дії специфікують виклики, які передаються від одного об'єкта графу діяльності до іншого. Оскільки в такому ракурсі об'єкти відіграють певну роль в розумінні процесу діяльності, іноді виникає необхідність явно вказати їх на діаграмі діяльності.
Для графічного представлення об'єктів використовується прямокутник класу, з тією різницею, що ім'я об'єкта підкреслюється. Далі після імені може вказуватися характеристика стану об'єкта в прямих дужках. Такі прямокутники об'єктів приєднуються до станів дій відношенням залежності пунктирною лінією зі стрілкою. Відповідна залежність визначає стан конкретного об'єкта після виконання попередньої дії.
На діаграмі діяльності з доріжками розміщення об'єкта може мати деякий додатковий зміст. А саме, якщо об'єкт розміщений на межі двох доріжок, то це може означати, що перехід до наступного стану дій в сусідній доріжці асоційований з готовністю деякого документу (об'єкт в деякому стані). Якщо ж об'єкт цілком розміщений на доріжці, то і стан цього об'єкта цілком визначається діями даної доріжки.
На завершення варто зупинитися на необхідності синхронізації окремих дій на діаграмі діяльності. Така необхідність виникає кожен раз, коли паралельно виконувані дії впливають одна на одну.
Рекомендації до побудови діаграм діяльностей
Діаграми діяльності відіграють важливу роль в розумінні процесів реалізації алгоритмів виконання операцій класів і потоків управління в модельованій системі. Використовувані для цієї цілі традиційні блок-схеми алгоритмів мають серйозні обмеження в представленні паралельних процесів і їх синхронізації. Застосування доріжок і об'єктів відкриває додаткові можливості для наочного представлення бізнес-процесів, дозволяючи специфікувати діяльність підрозділів компаній і фірм.
Вміст діаграми діяльності в багато чому нагадує діаграму станів, хоча й не однаковий з нею. Тому більшість рекомендацій до побудови останньої виявляються справедливими стосовно діаграми діяльності. Зокрема, ця діаграма будується для окремого класу, варіанту використання, окремої операції класу або цілої підсистеми.
С одного боку, на початкових етапах проектування, коли деталі реалізації діяльностей в системі невідомі, побудова діаграми діяльності починають з виділення піддіяльностей, які в сукупності утворюють діяльність підсистем. Надалі, в міру розробки діаграм класів і станів, ці піддіяльності уточнюються у виді окремих вкладених діаграм діяльності компонентів підсистем, якими виступають класи і об'єкти.
З іншого боку, окремі ділянки робочого процесу в існуючій системі можуть бути добре налагоджені, і в розробників може виникнути бажання зберегти цей механізм виконання дій в системі. Тоді будується діаграма діяльності для цих ділянок, які зображають конкретні особливості виконання дій з використанням доріжок і об'єктів.
Таким чином, процес об'єктно-орієнтованого аналізу і проектування складних систем представляється як послідовність ітерацій низхідної і висхідної розробки окремих діаграм, включаючи й діаграму діяльності.