Sammenligning av to tilnærminger til å strukturere et aktivitetsdiagram (basert på "ekorn")
В vi modellerte prosessene til et "eventyr"-fagområde - linjer om et ekorn fra "Fortellingen om tsar Saltan, hans sønn, den strålende og mektige helten prins Gvidon Saltanovich og den vakre svaneprinsessen" av A.S. Pushkin. Og vi startet med aktivitetsdiagrammet, og ble enige om å strukturere diagramfeltet ved å bruke "svømmebaner". Spornavnet tilsvarer typen diagramelementer som er til stede i det sporet: Input- og Output-artefakter, Prosesstrinn, Deltakere og Forretningsregler. Denne tilnærmingen skiller seg fra standarden, når spor er utpekt med navn på prosessdeltakere, og dermed tildele dem visse ansvarsområder i prosessen.
I dette eksemplet bruker jeg Enterprise Architect-miljøet fra et australsk selskap. [1].
For mer detaljer om de anvendte modelleringsmetodene, se [2].
For den fullstendige UML-spesifikasjonen, se [3].
Jeg vil gjenta versjonen av diagrammet fra forrige artikkel (Figur 1) og vise et omtegnet diagram med "standard" spor (Figur 2), jeg vil prøve å skissere fordeler og ulemper, kanskje litt subjektivt.
Figur 1. Aktivitetsdiagram - generell oversikt over prosessen
Figur 2. Aktivitetsdiagram - standard diagramstrukturering
- Det må innrømmes at antall piler er litt mindre i det andre diagrammet.
- Men i det andre diagrammet er gjenstandene "smurt" over hele feltet av diagrammet, noe som for min smak ikke er veldig praktisk.
- Den samme historien med notater - regler. Og for å sette inn regelen om utnevnelse av en diakon, måtte alle elementene i diagrammet flyttes ned på et tidspunkt.
- Jeg måtte klone trinnet "motta/sende..." for å vise at flere deltakere er til stede på dette trinnet.
- I det andre alternativet måtte jeg gi opp en forgrening og en sammenslåing av prosessen, vel, det var helt umulig å ordne dem "pent"! Heldigvis, da ville det være nødvendig å legge inn en kommentar - regelen.
Selvfølgelig er det ingen kamerater i smak og farge, men det første alternativet virker for meg også mer praktisk for å samle inn data om prosessen.
Men jeg vil ikke lyve - noen ganger er det bedre å tegne begge alternativene for å forstå prosessen.
Liste over kilder
- Sparx Systems nettsted. [Elektronisk ressurs] Tilgangsmodus: Internett:
- Zolotukhina E.B., Vishnya A.S., Krasnikova S.A. Modellering av forretningsprosesser. - M .: KURS, NITs INFRA-M, EBS Znanium.com. – 2017.
- OMG Unified Modeling Language (OMG UML) spesifikasjon. Versjon 2.5.1. [Elektronisk ressurs] Tilgangsmodus: Internett:
Kilde: www.habr.com