- •Тема 1. Основні елементи мови uml
- •Загальна характеристика моделей об'єктно-орієнтованого аналізу і проектування
- •Пакети в мові uml
- •Канонічні діаграми мови uml
- •Особливості графічного зображення діаграм мови uml
- •Рекомендації по графічному зображенню діаграм мови uml
- •Тема 2. Елементи графічної нотації діаграми класів.
- •Графічне зображення класу, його атрибутів і операцій
- •Конкретні і абстрактні класи
- •Тема 3. Відношення та їх графічне зображення на діаграмі класів
- •Тема 4. Елементи графічної нотації діаграми кооперації
- •Призначення діаграми кооперації
- •Об'єкти та їх графічне зображення
- •Тема 5. Елементи графічної нотації діаграми послідовності
- •Призначення діаграми послідовності.
- •Об'єкти та їх зображення на діаграмі послідовності
- •Лінія життя та фокус управління
- •Особливості зображення моментів створення і знищення об'єктів.
- •Повідомлення на діаграмі послідовності
- •Рекомендації з побудови діаграм послідовності
- •Тема 6. Елементи графічної нотації діаграми станів
- •Особливості моделювання поведінки об'єктів у вигляді діаграм станів
- •Стан та його графічне зображення
- •Графічне зображення станів на діаграмі станів
- •Тема 7. Елементи графічної нотації діаграми діяльності
- •Тема 7. Елементи графічної нотації діаграми компонентів
- •Лабораторні роботи.
- •Змістовний модуль і. Введення в моделювання програмного забезпечення
- •Змістовний модуль іі. Вступ до мови uml
- •Змістовний модуль ііi. Основи моделювання поведінки
- •Змістовний модуль IV. Основи архітектурного моделювання
Тема 7. Елементи графічної нотації діаграми діяльності
План.
Діаграма діяльності та особливості її побудови.
Стани і переходи на діаграмі діяльності.
Розгалуження і розпаралелювання процесів на діаграмі діяльності.
Особливості зображення об'єктів на діаграмі діяльності.
Використання діаграм діяльності для опису моделей бізнес-процесів.
Діаграма діяльності та особливості її побудови
При моделюванні поведінки проектованої або аналізованої програмної системи виникає необхідність не тільки представити процес зміни її станів, але і деталізувати особливості алгоритмічної і процедурної реалізації виконуваних системою операцій. Для цієї мети, як правило, використовуються блок-схеми або структурні схеми алгоритмів. Кожна така схема акцентує увагу на послідовності виконання певних процедур або елементарних операцій, які в сукупності призводять до отримання бажаного результату.
Зі збільшенням складності системи суворе дотримання певної послідовності виконуваних дій набуває великого значення. Спроба заварити каву холодною водою може зіпсувати порцію напою. Порушення послідовності операцій при ремонті двигуна призводить до його поломки або виходу з ладу. Ще більш катастрофічні наслідки можуть статися в разі відхилення від встановленої послідовності дій при зльоті або посадці авіалайнера, запуск ракети, регламентних роботах на АЕС.
Для моделювання процесу виконання операцій в мові UML використовуються діаграми діяльності. Застосовувана в них графічна нотація багато в чому схожа на нотацію діаграми станів, оскільки на діаграмах діяльності також присутні позначення станів і переходів. Відмінність полягає в семантиці станів, які використовуються для представлення діяльності і дій, а також у відсутності на переходах сигнатури подій. Кожен стан на діаграмі діяльності відповідає виконанню деякої операції, а перехід в наступний стан відбувається тільки після завершення виконання цієї операції. Діаграма діяльності представляється у формі графа діяльності, вершинами якого є стани дії або діяльності, а дугами - переходи від одного стану дії до іншого.
Діаграми діяльності - окремий випадок діаграм станів. Вони дозволяють реалізувати в UML особливості процедурного і синхронного управління, обумовленого завершенням внутрішніх дій і діяльності. Основним напрямком використання діаграм діяльності є візуалізація особливостей реалізації операцій класів, коли необхідно представити алгоритми їх виконання. При цьому кожний стан може бути виконанням операції певного класу або її частини, дозволяючи використовувати діаграми діяльності для опису реакцій на внутрішні події системи.
В контексті мови UML діяльність являє собою сукупність окремих обчислень, виконуваних автоматом. При цьому окремі елементарні обчислення можуть приводити до результату або дії. На діаграмі діяльності відображається логіка або послідовність переходу від однієї діяльності до іншої, при цьому увага фіксується на результаті діяльності. Сам же результат може призвести до зміни стану системи або поверненню деякого значення. Діаграма діяльності призначена для моделювання поведінки систем, хоча час в явному вигляді відсутня на цій діаграмі. Ситуація тут багато в чому аналогічна діаграмі станів, однак має ряд особливостей.
Стани діяльності і дії
Стан діяльності (activity state) - стан у графі діяльності, яке служить для представлення процедурної послідовності дій, що вимагають певного часу.
Перехід зі стану діяльності відбувається після виконання специфікованої в ньому ду-діяльності, при цьому ключове слово do в імені діяльності не вказується. Стан діяльності не може мати внутрішніх переходів, оскільки воно є елементарним. Діяльність, описана в змозі діяльності, не може бути перервана ніякими зовнішніми подіями. Звичайне використання стану діяльності полягає в моделюванні підпроцесу виконання окремих алгоритмів або процедур.
Стан дії (action state) - спеціальний випадок стану з деяким вхідним дією і, принаймні, одним виходять зі стану переходом.
Перехід зі стану дії відбувається після завершення вхідного дії. Стан дії не може мати внутрішніх переходів, оскільки воно є елементарним. Звичайне використання стану дії полягає в моделюванні кроку виконання алгоритму чи процедури в рамках одного потоку управління.
Графічно стани діяльності і дії зображуються однаковою фігурою, що нагадує прямокутник, бічні сторони якого замінені опуклими дугами (рис. 11.1). Усередині цієї фігури записується ім'я стану діяльності (рис. 11.1, а) або дії (рис. 11.1, б) у формі вираження (expression), яке повинно бути унікальним в межах однієї діаграми діяльності.
Графічне зображення станів діяльності і дії
Рис. 11.1. Графічне зображення станів діяльності і дії
Дія може бути записано на природній мові, псевдокоді або мові програмування. Ніяких додаткових або неявних обмежень при записі дій не накладається. Рекомендується в якості імені простої дії використовувати дієслово з пояснювальними словами (рис. 11.1, а). Якщо ж дія може бути представлено у формальному вигляді, то доцільно записати його на тій мові програмування, на якому передбачається реалізовувати проект, що розробляється (рис. 11.1, б).
Іноді виникає необхідність представити на діаграмі діяльності складна дія, в свою чергу, складається з декількох більш простих. У цьому випадку можна використовувати спеціальне позначення так званого стану під-діяльності.
Стан під-діяльності (subactivity state) - стан у графі діяльності, яке служить для представлення неатомарної послідовності кроків процесу.
Цей стан є графом діяльності і позначається спеціальною піктограмою в правому нижньому кутку символу стану дії (рис. 11.2). Дана конструкція може застосовуватися до будь-якого елементу мови UML, який підтримує "вкладеність" своєї структури. При цьому піктограма може бути додатково позначена типом вкладеної структури.
Рис. 11.2. Графічне зображення стану під-діяльності
Кожна діаграма діяльності повинна мати єдиний початковий і кінцевий стан. Вони мають такі ж позначення, як і на діаграмі станів. При цьому кожна діяльність починається в початковому стані і закінчується в кінцевому стані. Саму діаграму діяльності прийнято розташовувати таким чином, щоб дії слідували зверху вниз або зліва направо. У цьому випадку початковий стан буде зображуватися у верхній або лівій частині діаграми, а кінцевий - в її нижній або правій частині. В інтересах зручності візуального представлення на діаграмі діяльності допускається зображати кілька кінцевих станів. У цьому випадку всі їх прийнято вважати еквівалентними один одному.
Переходи на діаграмі діяльності
Перехід як елемент діаграми станів було розглянуто раніше. При побудові діаграми діяльності використовуються тільки нетригерні переходи, тобто такі, які відбуваються відразу після завершення діяльності або виконання відповідної дії. Такий перехід передає управління у подальший стан відразу, як тільки закінчиться дія або діяльність в попередньому стані. На діаграмі такий перехід зображується суцільною лінією зі стрілкою.
Якщо із стану дії виходить єдиний перехід, то його можна ніяк не позначати. Якщо ж таких переходів декілька, то при моделюванні послідовної діяльності запускається тільки один з них. У цьому випадку для кожного з таких переходів має бути явно записано власна охоронна умова в прямих дужках. При цьому для всіх виходять з деякого стану діяльності переходів повинно виконуватися вимога істинності тільки одного з них. Подібний випадок зустрічається тоді, коли послідовно виконувана діяльність повинна розділитися на альтернативні гілки залежно від значення проміжного результату. Така ситуація отримала назву розгалуження, а для її позначення застосовується спеціальний символ рішення.
Графічно розгалуження на діаграмі діяльності позначається символом рішення (decision), зображуваного у формі невеликого ромба, всередині якого немає ніякого тексту (рис. 11.3 вгорі). У цей ромб може входити тільки одна стрілка від того стану дії, після виконання якого потік управління має бути продовжений за однією з взаємно виключають гілок. Прийнято вхідну стрілку приєднувати до верхньої або лівої вершини символу рішення. Виходять стрілок може бути дві або більше, але для кожної з них явно вказується відповідне охоронна умова у формі Булевського вирази.
Для графічного об'єднання альтернативних гілок на діаграмі діяльності рекомендується також використовувати аналогічний символ у формі ромба, який в цьому випадку називають з'єднанням (merge). Наявність цього символу, всередині якого також не записується ніякого тексту, спрощує візуальний контроль логіки виконання процедурних дій на діаграмі діяльності (рис. 11.3 внизу). Входять стрілок у символу з'єднання може бути кілька, вони виходять від станів дії, що належать до однієї з взаємно виключають гілок. Виходити з ромба з'єднання може тільки одна стрілка, при цьому ні вхідні, ні виходить стрілки не повинні містити охоронних умов. Винятком є ситуація, коли з метою скорочення діаграми об'єднують символ рішення з символом з'єднання. Порушення цих правил робить діаграму діяльності неспроможною (ill formed).
Діаграма діяльності (рис. 11.3) моделює ситуацію, що виникає в супермаркетах при оплаті товарів. Як правило, заплатити за покупки можна або готівкою, або по кредитній картці. Якщо покупцем вибраний варіант оплати по кредитній картці, то перевіряється сума балансу пред'явленої до оплати кредитної картки. При цьому оплата відбувається тільки в тому випадку, якщо загальна вартість придбаних товарів не перевищує суми балансу цієї картки. В іншому випадку оплати не відбувається, і товар залишається у продавця.
Рис. 11.3. Різні варіанти розгалужень на діаграмі діяльності
Один з найбільш значущих недоліків звичайних блок-схем або структурних схем алгоритмів пов'язаний з проблемою зображення паралельних гілок окремих обчислень. Оскільки розпаралелювання обчислень суттєво підвищує загальну швидкодію програмних систем, необхідні графічні примітиви для представлення паралельних процесів. У діаграмах діяльності з цією метою використовується спеціальний символ для розділення і злиття паралельних обчислень або потоків управління. Це пряма риска, аналогічна позначенню паралельних переходів для діаграм станів.
На діаграмах діяльності така риска зображується відрізком горизонтальної, рідше - вертикальної, лінії, товщина якої трохи ширше ліній простих переходів діаграми діяльності. При цьому поділ (fork) має один вхідний перехід і кілька вихідних (рис. 11.4, а), які зображуються відрізками вертикальних, рідше - горизонтальних, ліній. Злиття (join), навпаки, має кілька вхідних переходів і один вихідний (рис. 11.4, б). Паралельні переходи на діаграмі діяльності можна зображувати в подовженій формі, а вхідні та вихідні переходи вертикальними стрілками.
Графічне зображення розділення і злиття паралельних потоків управління на діаграмі діяльності
Рис. 11.4. Графічне зображення розділення і злиття паралельних потоків управління на діаграмі діяльності
Розглянутих переходів виявляється достатньо для моделювання різних за складністю ситуацій. Для ілюстрації особливості зображення розгалуження і паралельних діяльностей можна розглянути приклад реєстрації пасажирів в аеропорту (рис. 11.5). Спочатку виконується діяльність по перевірці квитка. У разі якщо квиток не дійсний, він повертається пасажиру, при цьому ніяких додаткових дій не виконується.
Рис. 11.5. Діаграма діяльності для прикладу реєстрації пасажирів в аеропорту
Якщо ж квиток дійсний, то пасажиру видається посадковий талон. На додаток до цього перевіряється громадянство і наявність багажу у пасажира. Якщо є багаж, то його перевірка може бути виконана паралельно, за результатами якої пасажиру видається талон на багаж. Якщо пасажир є іноземним громадянином, то додатково перевіряється наявність у нього візи. Якщо віза дійсна, то перевірка завершується успішно, і пасажир з повернутим йому квитком може пройти на посадку.
Якщо ж віза виявиться не дійсною, то для цього пасажира посадка на даний рейс виявляється неможливою. У цьому випадку йому не видається посадковий талон та талон на багаж, у разі його наявності, оскільки відбувається припинення всіх виконуваних співробітниками аеропорту дій. Доріжки
Діаграми діяльності можуть бути використані не тільки для специфікації алгоритмів обчислень або потоків управління в програмних системах. Не менш важлива область їх застосування пов'язана з моделюванням бізнес-процесів. У цьому контексті діяльність будь-якої компанії або фірми являє собою не що інше, як сукупність окремих дій, робіт, операцій, спрямованих на досягнення необхідного результату.
Однак стосовно до бізнес-процесів бажано виконання кожної дії асоціювати з конкретним підрозділом компанії. У цьому випадку підрозділ буде нести відповідальність за реалізацію певних дій, а сам бізнес-процес представляється у вигляді переходів дій з одного підрозділу до іншого. Для моделювання цих особливостей в мові UML запропонована спеціальна конструкція, яка отримала назву доріжки.
Доріжка (swimlane) - графічна область діаграми діяльності, що містить елементи моделі, відповідальність за виконання яких належить окремим підсистемам.
У даному випадку мається на увазі візуальна аналогія з плавальними доріжками в басейні, якщо дивитися на відповідну діаграму діяльності зверху. При цьому всі стани на діаграмі діяльності діляться на групи, розмежовані вертикальними лініями. Дві сусідніх лінії і утворюють доріжку, а група станів між цими лініями виконується організаційним підрозділом (відділом, групою, відділенням, філією) або співробітником компанії (рис. 11.6). В останньому випадку прийнято вказувати посаду співробітника, відповідального за виконання певних дій.
Назви підрозділів або посад явно вказуються у верхній частині доріжки. Перетинати лінію доріжки можуть тільки переходи, які в цьому випадку позначають вихід або вхід потоку управління у відповідний підрозділ компанії. Порядок проходження доріжок не несе жодної семантичної інформації і визначається міркуваннями зручності.
Рис. 11.6. Варіант діаграми діяльності з доріжками
В якості прикладу можна розглянути фрагмент діаграми діяльності торгової компанії, яка обслуговує клієнтів у формі замовлень. Підрозділами компанії звичайно є відділ приймання та оформлення замовлень, відділ продажів і склад. Цим підрозділам будуть відповідати три доріжки на діаграмі діяльності, кожна з яких специфікує зону відповідальності підрозділу. У цьому випадку діаграма діяльності укладає в собі не тільки інформацію про послідовність виконання робочих дій, але і про те, який підрозділ торгової компанії повинний виконувати ту чи іншу дію (рис. 11.7).
Рис. 11.7. Фрагмент діаграми діяльності для торгової компанії
З вказаної діаграми діяльності видно, що після прийняття замовлення від клієнта відділом прийому і оформлення замовлень здійснюється розпаралелювання діяльності на два потоки (перехід-розділення). Перший з них залишається в цьому ж відділі і пов'язаний з отриманням оплати від клієнта за замовлений товар. Другий ініціює виконання дії по реєстрації замовлення у відділі продажів (модель товару, розміри, колір, рік випуску та ін.) Однак видача товару зі складу починається тільки після того, як буде отримана від клієнта оплата за товар (перехід-злиття).
Об'єкти на діаграмі діяльності
Дії на діаграмі діяльності можуть проводитися над тими чи іншими об'єктами. Ці об'єкти або ініціюють виконання дій, або визначають результат цих дій. При цьому дії специфікують виклики, які передаються від одного об'єкта графа діяльності іншому. Оскільки в такому ракурсі об'єкти грають певну роль у розумінні процесу діяльності, іноді виникає необхідність явно вказати їх на діаграмі діяльності.
Слід нагадати, що базовим графічним предвідношення об'єкта в нотації мови UML є прямокутник класу, з тією відмінністю, що ім'я об'єкта підкреслюється. На діаграмах діяльності після імені може вказуватися характеристика стану об'єкта в прямих дужках. Такі прямокутники об'єктів приєднуються до станів дії відношенням залежності пунктирною лінією зі стрілкою. Відповідна залежність визначає стан конкретного об'єкта після виконання попередньої дії.
На діаграмі діяльності з доріжками розташування об'єкта може мати додатковий сенс. А саме, якщо об'єкт розташований на кордоні двох доріжок, то це може означати, що перехід до наступного станом дії в сусідній доріжці асоційований із знаходженням документа в деякому стані. Якщо ж об'єкт розташований усередині доріжки, то і стан цього об'єкта цілком визначається діями даної доріжки.
Стосовно діаграм діяльності об'єкти, як правило, є екземплярами класів сутностей або бізнес - сутностей. Варто також зауважити, що на діаграмі діяльності один і той же об'єкт може бути зображений кілька разів, при цьому для виключення непогодженості діаграми необхідно вказувати для них різні характеристики стану.
У попередньому прикладі з торговою компанією центральним об'єктом процесу продажу є замовлення чи вірніше стан його виконання. Спочатку до звернення клієнта замовлення як об'єкт відсутнє і виникає лише після контакту з клієнтом. В результаті фіксується отримане замовлення, після чого він реєструється у відділі продажів. Потім він передається на склад, де після отримання оплати за товар оформлюється остаточно. Нарешті, після того, як товар відправлений клієнту, ця інформація вноситься до замовлення, і він вважається виконаним. Ця інформація може бути представлена графічно у вигляді модифікованого варіанту діаграми діяльності торгової компанії (рис. 11.8).
Перевагою діаграми діяльності є можливість візуалізувати окремі аспекти поведінки даної системи або реалізації окремих операцій класів у вигляді процедурної послідовності дій. Таким чином, повна модель системи може містити одну або декілька діаграм діяльності, кожна з яких описує послідовність реалізації або найбільш важливих варіантів використання (типовий хід подій і всі виключення), або нетривіальних операцій класів.
Рис. 11.8. Фрагмент діаграми діяльності торгової компанії з об'єктом-замовленням
На закінчення слід зауважити, що діаграма діяльності, так само як і інші види канонічних діаграм, не містять засобів вибору оптимальних варіантів конфігурації власне діаграм. При розробці складних проектів проблема вибору оптимальних рішень стосовно до діаграм діяльності стає досить актуальною. Раціональне витрачання коштів, витрачених на розробку і експлуатацію системи, підвищення її продуктивності і надійності часто визначають кінцевий результат всього проекту.
