Два підходи до структурування діаграми Activity

Порівняння двох підходів структурування діаграми Activity (за мотивами "Білки")

В 1-ої частини статті «Від моделювання процесів до проектування автоматизованої системи» ми моделювали процеси «казкової» предметної області — рядки про білку з «Казки про царя Салтана, про сина його славного і могутнього богатиря князя Гвідона Салтановича і про прекрасну царівну Лебеді» А.С.Пушкіна. І почали ми з діаграми Activity, домовившись про структурування поля діаграми за допомогою «плавальних» доріжок – Swim lanes. Ім'я доріжки відповідає типу елементів діаграми, які присутні на цій доріжці: «Вхідні та вихідні артефакти», «Кроки процесу», «Учасники» та «Бізнес-правила». Цей підхід відрізняється від стандартного, коли доріжки позначаються іменами учасників процесу, закріплюючи за ними певні зони відповідальності в процесі.

У цьому прикладі я використовую середовище Enterprise Architect від австралійської компанії Sparx Systems [1].
Докладніше про застосовувані підходи до моделювання див. [2].
Повну специфікацію UML див. тут [3].

Повторю варіант діаграми з минулої статті (Малюнок 1) та покажу перемальовану діаграму зі «стандартними» доріжками (Малюнок 2), постараюся плюси та мінуси позначити, можливо, і трохи суб'єктивно.

Рисунок 1. Діаграма Activity – загальний вигляд процесу

Малюнок 2. Діаграма Activity – стандартне структурування діаграми

1. Слід визнати, що кількість стрілок трохи менше на другій діаграмі.
2. Але на другій діаграмі об'єкти «розмазані» по всьому полю діаграми, що, на мій смак, не дуже зручно.
3. Та сама історія із примітками — правилами. А ще щоб правило про призначення диякона вставити, довелося всі елементи діаграми рано чи пізно рухати вниз.
4. Довелося клонувати крок «прийому/передачі…», щоб показати, що кілька учасників на цьому кроці є.
5. У другому варіанті довелося відмовитися від одного розгалуження та одного злиття процесу, ну зовсім не виходило їх «красиво» укласти! На добро, треба було б тоді повісити коментар — правило.

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

Список джерел

1. Сайт Sparx Systems. [Електронний ресурс] Режим доступу: Веб: https://sparxsystems.com
2. Золотухіна Є.Б., Вишня А.С., Краснікова С.А. Моделювання бізнес-процесів. - М.: КУРС, НІЦ ІНФРА-М, ЕБС Znanium.com. - 2017.
3. OMG Unified Modeling Language (OMG UML) Спеціалізація. Version 2.5.1. [Електронний ресурс] Режим доступу: Веб: https://www.omg.org/spec/UML/2.5.1/PDF

Джерело: habr.com