Två tillvägagångssätt för att strukturera ett aktivitetsdiagram

Jämförelse av två metoder för att strukturera ett aktivitetsdiagram (baserat på "Squirrels")

В Del 1 av artikeln "Från processmodellering till automatiserad systemdesign" vi modellerade processerna för ett "sago" ämnesområde - rader om en ekorre från "Sagan om tsar Saltan, hans son, den ärorika och mäktiga hjälten Prins Gvidon Saltanovich och den vackra svanprinsessan" av A.S. Pushkin. Och vi började med aktivitetsdiagrammet och kom överens om att strukturera diagramfältet med hjälp av "simbanor". Spårnamnet motsvarar typen av diagramelement som finns i det spåret: In- och utdataartefakter, Processsteg, Deltagare och Affärsregler. Detta tillvägagångssätt skiljer sig från det vanliga, när spår utses med namn på processdeltagare, vilket tilldelar dem vissa ansvarsområden i processen.

I det här exemplet använder jag Enterprise Architect-miljön från ett australiensiskt företag. Sparx Systems [1].
För mer information om de tillämpade modelleringsmetoderna, se [2].
För den fullständiga UML-specifikationen, se här [3].

Jag kommer att upprepa versionen av diagrammet från föregående artikel (Figur 1) och visa ett omritat diagram med "standard" spår (Figur 2), jag kommer att försöka beskriva för- och nackdelar, kanske lite subjektivt.

Två tillvägagångssätt för att strukturera ett aktivitetsdiagram
Figur 1. Aktivitetsdiagram - allmän bild av processen

Två tillvägagångssätt för att strukturera ett aktivitetsdiagram
Figur 2. Aktivitetsdiagram - standarddiagramstrukturering

  1. Det måste erkännas att antalet pilar är något mindre i det andra diagrammet.
  2. Men i det andra diagrammet "smetas" objekten ut över hela diagrammets fält, vilket för min smak inte är särskilt bekvämt.
  3. Samma historia med anteckningar - regler. Och för att infoga regeln om utnämning av en diakon måste alla element i diagrammet flyttas ner någon gång.
  4. Jag var tvungen att klona "ta emot/sända..."-steget för att visa att flera deltagare är närvarande i detta steg.
  5. I det andra alternativet var jag tvungen att ge upp en förgrening och en sammanslagning av processen, ja, det var absolut omöjligt att ordna dem "snyggt"! Lyckligtvis, då skulle det vara nödvändigt att posta en kommentar - regeln.

Naturligtvis finns det inga kamrater i smak och färg, men det första alternativet förefaller mig också bekvämare för att samla in data om processen.
Men jag kommer inte att ljuga - ibland är det bättre att rita båda alternativen för att förstå processen.

Lista över källor

  1. Sparx Systems webbplats. [Elektronisk resurs] Åtkomstläge: Internet: https://sparxsystems.com
  2. Zolotukhina E.B., Vishnya A.S., Krasnikova S.A. Affärsprocessmodellering. — M.: KURS, SIC INFRA-M, EBS Znanium.com. — 2017.
  3. OMG Unified Modeling Language (OMG UML) specifikation. Version 2.5.1. [Elektronisk resurs] Åtkomstläge: Internet: https://www.omg.org/spec/UML/2.5.1/PDF

Källa: will.com

Lägg en kommentar