To tilgange til at strukturere et aktivitetsdiagram

Sammenligning af to tilgange til strukturering af aktivitetsdiagrammet (baseret på "Egern")

В Del 1 af artiklen "Fra procesmodellering til automatiseret systemdesign" vi simulerede processerne i et "fabelagtigt" emneområde - en linje om et egern fra Pushkins "Fortællingen om zar Saltan, hans herlige og mægtige søn prins Gvidon Saltanovich og den smukke svaneprinsesse". Og vi startede med Aktivitetsdiagrammet, hvor vi blev enige om at strukturere diagramfeltet ved hjælp af "svømme" baner - Svømmebaner. Banens navn svarer til typen af ​​diagramelementer, der er til stede på denne bane: Input- og outputartefakter, procestrin, deltagere og forretningsregler. Denne tilgang adskiller sig fra standarden, når banerne er udpeget med navnene på deltagerne i processen, og dermed tildeles visse ansvarsområder til dem i processen.

I dette eksempel bruger jeg Enterprise Architect-miljøet fra en australsk virksomhed. Sparx Systems [1].
Se [2] for detaljer om de anvendte modelleringsmetoder.
For den komplette UML-specifikation, se her [3].

Jeg vil gentage versionen af ​​diagrammet fra den forrige artikel (Figur 1) og vise et omtegnet diagram med "standard" spor (Figur 2), jeg vil forsøge at angive fordele og ulemper, måske lidt subjektivt.

To tilgange til at strukturere et aktivitetsdiagram
Figur 1. Aktivitetsdiagram - en generel oversigt over processen

To tilgange til at strukturere et aktivitetsdiagram
Figur 2. Aktivitetsdiagram - standarddiagramstrukturering

  1. Det må indrømmes, at antallet af pile er lidt mindre i 2. diagram.
  2. Men på det 2. diagram er objekterne "smurt" ud over hele diagrammets felt, hvilket efter min smag ikke er særlig bekvemt.
  3. Den samme historie med noter - regler. Og for at indsætte reglen om udnævnelse af en diakon, skulle alle elementerne i diagrammet på et tidspunkt flyttes ned.
  4. Jeg var nødt til at klone "modtag / transmit ..."-trinnet for at vise, at flere deltagere er til stede på dette trin.
  5. I den anden mulighed var jeg nødt til at opgive en gren og en sammenlægning af processen, ja, det var absolut umuligt at sætte dem på en "pæn" måde! I det hele taget ville det være nødvendigt at lægge kommentaren på - en regel.

Selvfølgelig er der ingen kammerater for smag og farve, men den første mulighed forekommer mig endnu mere bekvem til at indsamle data om processen.
Men jeg vil ikke skille ad - nogle gange er begge muligheder bedre at tegne for at forstå processen.

Liste over kilder

  1. Sparx Systems hjemmeside. [Elektronisk ressource] Adgangstilstand: Internet: https://sparxsystems.com
  2. Zolotukhina E.B., Vishnya A.S., Krasnikova S.A. Modellering af forretningsprocesser. - M .: KURS, NITs INFRA-M, EBS Znanium.com. – 2017.
  3. OMG Unified Modeling Language (OMG UML) specifikation. Version 2.5.1. [Elektronisk ressource] Adgangstilstand: Internet: https://www.omg.org/spec/UML/2.5.1/PDF

Kilde: www.habr.com

Tilføj en kommentar