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