Діаграма діяльності UML | Планерка: онлайн-школа креативності

1. Діаграма діяльності UML Для чого використовується техніка креативності
2. План дій
3. Зауваження (опис)
4. Як застосовувати техніку креативності
5. як навчитися
6. приклад використання
7. Декомпозиція операції в діаграмі діяльності
8. Розділи діаграми діяльності
9. Сигнали діаграми діяльності
10. Маркери діаграми діяльності
11. Потоки і ребра діаграми діяльності
12. Контакти та перетворення
13. області розширення
14. закінчення потоку
15. описи об'єднань

Діаграма діяльності UML

Для чого використовується техніка креативності

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

План дій

У розділі «Опис» вивчіть основний набір символів діаграми діяльності UML, необхідний для того, щоб вміти читати цей тип діаграм.

Після ознайомлення з іншими розділами ( «Приклад», «Застосування») ви можете спробувати свої сили в самостійному складанні діаграм діяльності.

Зауваження (опис)

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

ТермінЗображенняОпис

Початковий вузол Старт діаграми Галуження Розгалуження (fork), має один вхідний потік і кілька вихідних паралельних потоків. операція Див. Розділ «Приклад» Потік / ребро В UML 2 паралельно вживаються терміни потік (flow) і ребро (edge) для позначення зв'язку між двома операціями. Самий про стій вид ребра - це звичайна стрілка між двома операціями. Рішення Кожен раз при достиже ванні рішення вибирається тільки один з вихідних потоків, тому захисту повинні бути взаємно виключають. злиття Злиття означає завершення умовного поведінки, яке було
розпочато рішенням. об'єднання При наявності паралелізму необхідна синхронізація. Ми не закритому ваем замовлення, поки він не оплачений і не доставлений. Це показується з по міццю об'єднання Кінець діяльності Закінчення діаграми Ім'я діяльності вхідний параметр вихідний параметр «Граблі» Операції можуть бути реалізовані або як вкладені діяльності
або як методи класів. Вкладену діяльність можна позначити за допомогою символу «граблів». виклик методу тимчасової сигнал Тимчасової сигнал (time signal) приходить з часом. Та кі сигнали можуть означати кінець місяця в звітному періоді або
приходити кожну секунду в контролері реального часу. ухвалення сигналу посилка сигналу прийом сигналу роз'єм вузол об'єкта Контакт Процедури, як і методи, можуть мати параметри. Показувати на діа грамі діяльності інформацію про параметри не обов'язково, але при бажанні можна відобразити параметри за допомогою контактів (pins)

вираз перетворення Якщо потрібно намалювати точну діаграму діяльності, то необхідно забезпечити відповідність вихідних параметрів однієї процедури вхідних параметрів інший. Якщо вони не збігаються, то можна вказати перетворення (transformation) (рис. 11.8) для переходу від од ної процедури до іншої. Ключове слово Вихідний список контактів область розширення Область розширення (expansion region) зазначає область діаграми діяльності, де операції виконуються один раз для кожного елемента колекції. закінчення потоку Закінчення потоку (flow final) означає завершення конкретного потоку без завершення всієї активності. опис об'єднання Опис об'єднання (join specification) - це логічний вираз, приєднане до об'єднання.

Як застосовувати техніку креативності

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

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

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

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

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

як навчитися

Тут ми спробували надати якомога простіший спосіб вивчення діаграми діяльності мови UML.

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

Далі ми б рекомендували перейти в розділ «Приклад», щоб спробувати свої сили в читанні різних діаграм цього типу. Потім варто вивчити розділ «Застосування», так як, хоча і кількість типів діаграм в UML невелика, максимум переваг від їх використання ви зможете отримати тільки якщо будете застосовувати відповідні діаграми за призначенням.

приклад використання

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

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

На рис. 11.1 показаний приклад простий діаграми діяльності. Ми стартуємо з початкового вузла (initial node), а потім виконуємо операцію Receive Order (Прийняти замовлення). Потім йде розгалуження (fork), яке має один вхідний потік і кілька вихідних паралельних потоків.

З рис. 11.1 видно, що операції Fill Order (Заповнити заявку), Send Invoice (Послати рахунок) і наступні за ними виконуються паралельно. По суті, в даному випадку це означає, що послідовність операцій не має значення. Я можу заповнити заявку, надіслати рахунок, доставити товар (Delivery), а потім отримати оплату (Receive Payment); або я можу послати рахунок, отримати оплату, заповнити заявку, а потім доставити товар. Подивіться на малюнок.

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

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

При наявності паралелізму необхідна синхронізація. Ми не закриваємо замовлення, поки він не оплачений і не доставлений. Це показується за допомогою об'єднання (join) перед операцією Close Order (Закрити замовлення). Вихідний з об'єднання потік виконується тільки в тому випадку, коли всі вхідні потоки досягли об'єднання. Тому ви можете закрити замовлення, тільки коли прийнята оплата і замовлення доставлений.

В UML 1 діяли певні правила для балансування розгалужень і об'єднань, так як діаграми діяльності представляли особливий випадок діаграм станів. В UML 2 в такій балансуванню вже немає необхідності.

Зауважте, що вузли на діаграмі діяльності називаються операціями (actions), а не активностями (activities). Строго кажучи, діяльність відноситься до послідовності дій, тому діаграма представляє діяльність, що складається з операцій.

Умовне поведінку схематично позначається за допомогою рішень (decisions) і злиттів (merges). Рішення, яке в UML 1 називалося гілкою, має один вхідний потік і кілька захищених вихідних потоків. Кожен вихідний потік має захист - умовний вираз, поміщене в квадратні дужки. Кожен раз при досягненні рішення вибирається тільки один з вихідних потоків, тому захисту повинні бути взаємно виключають. Застосування [else] в якості захисту означає, що потік [else] використовується в тому випадку, коли інші захисту даного рішення приймають помилкове значення.

На рис. 11.1 рішення розташовується після операції заповнення заявки. Якщо у вас термінове замовлення, то він виконується протягом доби (Overnight Delivery); в іншому випадку проводиться звичайна доставка (Regular Delivery).

Злиття (merge) має кілька вхідних потоків і один вихідний. Злиття означає завершення умовного поведінки, яке було розпочато рішенням.
На нашій діаграмі кожна операція має один вхідний в неї потік і один виходить. В UML 1 малося на увазі, що кілька вхідних потоків мають злиття. Іншими словами, операція виконувалася, якщо запускався будь-який потік. В UML 2 це було змінено, так що замість злиття передбачається об'єднання; таким чином, операція виконується, тільки якщо всі потоки пройдені. Тому рекомендуємо застосовувати операції з єдиним вхідним потоком і єдиним вихідним, а також явно показувати все об'єднання і злиття; це позбавить вас від плутанини.

Декомпозиція операції в діаграмі діяльності

Операції можуть бути розбиті на вкладені діяльності (subactivities). Я можу взяти алгоритм доставки, показаний на рис. 11.1, і визначити його як самостійну діяльність (рис. 11.2), а потім викликати його як операцію (рис. 11.3).
Операції можуть бути реалізовані або як вкладені діяльності або як методи класів. Вкладену діяльність можна позначити за допомогою символу «граблів».

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

Розділи діаграми діяльності

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

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

На рис. 11.4 представлено просте одномірне розбиття. Цей спосіб зі зрозумілих причин часто називають плавальними доріжками (swim lanes), і така форма була єдиною в UML 1. В UML 2 сітка може бути двовимірної, тому «плавальна» метафора більше не містить води. Крім того, можна взяти кожне вимір і розділити рядки на стовпці, створюючи тим самим ієрархічну структуру.

Сигнали діаграми діяльності

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

Тимчасової сигнал (time signal) приходить з часом. Такі сигнали можуть означати кінець місяця в звітному періоді або приходити кожну секунду в контролері реального часу.

На рис. 11.5 показана діяльність, в якій очікуються два сигналу. Сигнал показує, що дана діяльність приймає повідомлення про подію від зовнішнього процесу. Це означає, що діяльність постійно прослуховує ці сигнали, а діаграма визначає, як діяльність на них реагує.

У випадку, показаному на рис. 11.5, до мого відльоту залишається два годин (Two hours before flight), і мені пора збирати багаж. Якщо я спакую його завчасно, то все одно не зможу поїхати, поки не прибуде таксі. Якщо таксі приходить (Taxi Arrives) до того, як я встигну зібрати багаж (Pack Bags), то воно повинно чекати мене, поки я не закінчу.

Ми можемо як приймати сигнали, так і посилати їх. Це корисно, коли ми посилаємо повідомлення, а потім повинні чекати відповіді, перед тим як продовжити.

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

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

Маркери діаграми діяльності

Сміливці, які ризикнули зануритися в глибину специфікацій UML, виявлять, що в розділі, присвяченому активності, багато говориться про маркери (tokens), їх створення та використання.

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

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

Потоки і ребра діаграми діяльності

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

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

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

Передачу об'єкту уздовж ребра можна показати, поміщаючи на ребро прямокутник класу. Можна також зображати контакти (pins) на операціях, хоча використання контактів має деякі хитрощі.

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

Контакти та перетворення

Процедури, як і методи, можуть мати параметри. Показувати на діаграмі діяльності інформацію про параметри не обов'язково, але при бажанні можна відобразити параметри за допомогою контактів (pins).

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

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

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

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

області розширення

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

На рис. 11.9 процедура Choose Topics (Вибрати теми) генерує список тем. Потім кожен елемент цього списку стає маркером для входу процедури Write Article (Написати статтю). Подібним чином кожна операція Review Article (Рецензувати статтю) генерує єдину статтю, яка додається до вихідного списку області розширення. Коли все маркери в області розширення діаграми діяльності досягають вихідний колекції, область розширення генерує єдиний маркер для списку, який передається процедурі Publish Newsletter (Опублікувати інформаційний бюлетень).

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

На рис. 11.9 всі статті пишуться і рецензуються паралельно, що відзначено ключовим словом «concurrent». Область розширення також може бути итеративной. Ітеративні області повинні повністю обробляти кожен вхідний елемент за один раз.

Якщо є тільки одна операція, яку треба викликати кілька разів, то застосовується нотація, показана на рис. 11.10. Такий спосіб запису передбачає паралельне розширення, оскільки воно найбільш загальне. Ця нотація відповідає концепції динамічного паралелізму, прийнятої в UML 1.

закінчення потоку

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

На рис. 11.11 показана модифікована версія рис. 11.9, в якій статті можуть бути відкинуті. Якщо стаття відхилена, то маркер ліквідується закінченням потоку. На відміну від закінчення активності, в даному випадку інша активність може тривати. Цей підхід дозволяє областям розширення діяти в якості фільтрів, в результаті чого вихідна колекція буде менше вхідний.

описи об'єднань

За замовчуванням об'єднання дозволяє виконання вихідного потоку, коли все вхідні потоки досягли об'єднання. (Або, кажучи більш формальною мовою, воно породжує маркер вихідного потоку, коли приходять маркери всіх вхідних потоків.) У деяких випадках, зокрема, коли є потік з кількома маркерами, корисно мати більш складне правило.

Опис об'єднання (join specification) - це логічний вираз, приєднане до об'єднання. Кожен раз, коли в об'єднання прибуває маркер, обчислюється опис об'єднання, і якщо його значення істинне, то породжується маркер. Тому на рис. 11.12, незалежно від того, вибираю я напій (Select Drink) або кидаю монетку (Insert Coin), автомат оцінює визначення об'єднання. Автомат втамовує мою спрагу, тільки якщо я кинув достатню кількість грошей. Якщо, як в даному випадку, ви хочете показати, що ви прийняли маркер в кожному вхідному потоці, то необхідно іменувати потоки і включити їх в опис об'єднання.

Підписуйтесь на новини сайту, форму підписки ви можете знайти в правій колонці сайту.

Якщо ви хочете навчитися працювати на фрілансі професійно, запрошуємо на курс « Як заробляти на фрілансі ».

Перейти на сторінку курсу

Якщо вам сподобалася стаття - поділіться посиланням з друзями!