Сравнение на два подхода за структуриране на диаграма на дейността (на базата на „катерици“)
В моделирахме процесите на „приказна“ тематична област - линии за катерица от „Приказката за цар Салтан, неговия син, славния и могъщ герой княз Гвидон Салтанович и красивата принцеса Лебед“ от А. С. Пушкин. И започнахме с диаграмата на дейността, като се споразумяхме за структурирането на полето на диаграмата, използвайки „плуващи“ алеи - Swim lanes. Името на песента съответства на типа елементи на диаграмата, които присъстват в тази песен: входни и изходни артефакти, стъпки на процеса, участници и бизнес правила. Този подход се различава от стандартния, когато песните се обозначават с имената на участниците в процеса, като по този начин им се възлагат определени области на отговорност в процеса.
В този пример използвам среда Enterprise Architect от австралийска компания. [1].
За повече подробности относно прилаганите подходи за моделиране вижте [2].
За пълната UML спецификация вижте [3].
Ще повторя версията на диаграмата от предишната статия (Фигура 1) и ще покажа преначертана диаграма със „стандартни“ песни (Фигура 2), ще се опитам да очертая плюсовете и минусите, може би малко субективно.
Фигура 1. Диаграма на дейността - общ изглед на процеса
Фигура 2. Диаграма на дейността - стандартно структуриране на диаграмата
- Трябва да се признае, че броят на стрелките е малко по-малък във втората диаграма.
- Но във втората диаграма обектите са „размазани“ по цялото поле на диаграмата, което според мен не е много удобно.
- Същата история с бележки - правила. И за да се вмъкне правилото за назначаване на дякон, всички елементи на диаграмата трябваше да бъдат преместени надолу в някакъв момент.
- Трябваше да клонирам стъпката „получаване/предаване…“, за да покажа, че няколко участника присъстват на тази стъпка.
- Във втория вариант трябваше да се откажа от едно разклоняване и едно сливане на процеса, е, беше абсолютно невъзможно да ги подредя „хубаво“! За щастие тогава ще е необходимо да публикувате коментар - правилото.
Разбира се, няма другари по вкус и цвят, но първият вариант ми се струва по-удобен за събиране на данни за процеса.
Но няма да лъжа - понякога е по-добре да нарисувате и двете опции, за да разберете процеса.
Списък с източници
- Уебсайт на Sparx Systems. [Електронен ресурс] Режим на достъп: Интернет:
- Золотухина Е.Б., Вишня А.С., Красникова С.А. Моделиране на бизнес процеси. - M .: KURS, NITs INFRA-M, EBS Znanium.com. — 2017 г.
- Спецификация на OMG Unified Modeling Language (OMG UML). Версия 2.5.1. [Електронен ресурс] Режим на достъп: Интернет:
Източник: www.habr.com