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