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

Jämförelse av två tillvägagångssätt för strukturerande av aktivitetsdiagram (inspirerat av "Ekorren")

I Den första delen av artikeln "Från processmodellering till design av automatiserade system" Vi modellerade processerna i den "sagolika" ämnesområdet – raderna om ekorren från "Sagan om tsar Saltan, hans styrka och den mäktiga hjälten prins Gvidon Saltanovitj och den vackra prinsessan Svanen" av A.S. Pusjkin. Vi började med aktivitetsdiagrammet, där vi kom överens om att strukturera diagrammets fält med hjälp av "simnings" banor – Swim lanes. Namnet på banan motsvarar typ av diagramelement som finns på denna bana: "In- och utgångs artefakter", "Processsteg", "Deltagare" och "Affärsregler". Denna metod skiljer sig från den standardmetod där banorna benämns med deltagarnas namn och därigenom fastställer deras specifika ansvar i processen.

I detta exempel använder jag miljön Enterprise Architect från det australiensiska företaget Sparx Systems [1].
För mer information om tillämpade modelleringsmetoder se [2].
Den fullständiga specifikationen av UML finns i. här [3].

Jag upprepar diagrammet från den tidigare artikeln (Figur 1) och visar det omritade diagrammet med "standard"-banor (Figur 2), och försöker ange fördelar och nackdelar, vilket kanske blir något subjektivt.

Figur 1. Aktivitetsdiagram – allmän översikt av processen

Figur 2. Aktivitetsdiagram – standardstruktur för diagrammet

1. Det måste erkännas att antalet pilar är något mindre i det andra diagrammet.
2. Men i det andra diagrammet är objekten "spridda" över hela diagramfältet, vilket jag personligen tycker är ganska obekvämt.
3. Samma sak gäller för anteckningarna — reglerna. Och för att infoga regeln om utnämning av diakonen var jag tvungen att flytta alla diagramelement nedåt vid något tillfälle.
4. Jag var tvungen att duplicera steget "mottagande/överlämning..." för att visa att flera deltagare är närvarande i detta steg.
5. I det andra alternativet var jag tvungen att överge en förgrening och en sammanslagning av processen, det gick helt enkelt inte att "fint" ordna dem! För att vara ärlig borde jag ha satt upp en kommentar – en regel.

Det finns förstås inga vänner beroende på smak och färg, men jag tycker att det första alternativet verkar mer praktiskt för att samla in data om processen.
Men jag ska inte vara oärlig – ibland är det bättre att rita båda alternativen för att förstå under processen.

Källförteckning

1. Webbplats för Sparx Systems. [Elektronisk resurs] Åtkomstläge: Internet: https://sparxsystems.com
2. Zolotukhina E.B., Vishnya A.S., Krasnikova S.A. Modellerings av affärsprocesser. – M.: KURS, NII INFRA-M, EBS Znanium.com. – 2017.
3. OMG Unified Modeling Language (OMG UML) Specification. Version 2.5.1. [Elektronisk resurs] Åtkomstläge: Internet: https://www.omg.org/spec/UML/2.5.1/PDF

Källa: habr.com