Sammenligning af to tilgange til strukturering af Activity-diagrammet (inspireret af "Egerne")
I Vi modellerede processer fra den "eventyrlige" emneområde – linjerne om egernet fra "Eventyret om Tsar Saltan, hans berømte og mægtige helt, prins Gvidon Saltanovich, og den smukke prinsesse Svanen" af A.S. Pushkin. Vi startede med Activity-diagrammet og blev enige om at strukturere diagramfeltet ved hjælp af "svømmende" baner – Swim lanes. Navnet på banen svarer til typen af elementer i diagrammet, der findes på denne bane: "Indgående og udgående artefakter", "Procestrin", "Deltagere" og "Forretningsregler". Denne tilgang adskiller sig fra den standard tilgang, hvor banerne benævnes efter deltagerne i processen, hvilket derved fastsætter bestemte ansvarsområder i processen.
I dette eksempel bruger jeg miljøet Enterprise Architect fra det australske firma [1].
For mere information om de anvendte tilgange til modellering, se [2].
Den fulde specifikation af UML, se. [3].
Jeg gentager varianten af diagrammet fra den forrige artikel (Figur 1) og viser det omtegnede diagram med "standard" baner (Figur 2) og vil forsøge at påpege fordele og ulemper, muligvis også lidt subjektivt.
Figur 1. Activity-diagram – generelt udsigt over processen
Figur 2. Activity-diagram – standard strukturering af diagrammet
- Man må indrømme, at antallet af pile er lidt færre i det 2. diagram.
- Men i det 2. diagram er objekterne "udspredt" over hele diagramfeltet, hvilket, efter min mening, ikke er særlig praktisk.
- Det samme gælder for kommentare – reglerne. Og for at indsætte reglen om diakonens udnævnelse måtte jeg flytte alle elementer i diagrammet ned på et tidspunkt.
- Jeg måtte klone skridtet "modtagelse/overførsel…", for at vise, at flere deltagere er til stede i dette skridt.
- I den anden variant måtte jeg give afkald på en forgrening og en sammensmeltning af processen, for de kunne simpelthen ikke placeres "pænt"! Rigtigt set skulle der så hænges en kommentar op – reglen.
Smag og behag har selvfølgelig ikke noget at gøre, men jeg synes, at den første variant også er mere praktisk til indsamling af data om processen.
Men vil ikke skjule, at det nogle gange er bedst at tegne begge varianter for at forstå processen.
Liste over kilder
- Siden Sparx Systems. [Elektronisk ressource] Adgangsmodus: Internet:
- Zolotukhina E.B., Vishnya A.S., Krasnikova S.A. Modellering af forretningsprocesser. — M.: KURS, NIC INFRA-M, EBS Znanium.com. — 2017.
- OMG Unified Modeling Language (OMG UML) Specification. Version 2.5.1. [Elektronisk ressource] Adgangsmodus: Internet:
Kilde: habr.com
