Zwei Ansätze zur Strukturierung des Aktivitätsdiagramms

Vergleich zweier Ansätze zur Strukturierung eines Aktivitätsdiagramms (inspiriert von "Eichhörnchen")

Im Im ersten Teil des Artikels „Von der Prozessmodellierung zur Gestaltung automatisierter Systeme“ Wir haben die Prozesse des "märchenhaften" Themenbereichs modelliert – die Zeilen über das Eichhörnchen aus "Das Märchen vom Zaren Saltan, von seinem ruhmreichen und mächtigen Helden Fürsten Gwidon Saltanowitsch und der schönen Zarin Schwäne" von A.S. Puschkin. Wir begannen mit einem Aktivitätsdiagramm und einigten uns darauf, das Diagrammfeld mithilfe von "Schwimmenden" Bahnen – Swim Lanes – zu strukturieren. Der Name der Bahn entspricht dem Typ der Diagrammelemente, die in dieser Bahn vorhanden sind: "Eingangs- und Ausgangsartefakte", "Prozessschritte", "Teilnehmer" und "Geschäftsregeln". Dieser Ansatz unterscheidet sich vom Standard, bei dem die Bahnen mit den Namen der Prozessbeteiligten gekennzeichnet werden, wodurch bestimmte Verantwortungsbereiche im Prozess zugewiesen werden.

In diesem Beispiel verwende ich die Umgebung Enterprise Architect von der australischen Firma. Sparx Systems [1].
Weitere Informationen zu den angewendeten Modellierungsansätzen finden Sie unter [2].
Die vollständige UML-Spezifikation siehe. hier [3].

Ich wiederhole die Variante des Diagramms aus dem vorherigen Artikel (Abbildung 1) und zeige das neu gezeichnete Diagramm mit "Standard"-Bahnen (Abbildung 2), wobei ich versuche, Vor- und Nachteile zu kennzeichnen, vielleicht auch etwas subjektiv.

Abbildung 1. Aktivitätsdiagramm – Gesamtansicht des Prozesses

Abbildung 2. Aktivitätsdiagramm – Standardstrukturierung des Diagramms

1. Man muss zugeben, dass die Anzahl der Pfeile auf dem zweiten Diagramm um zwei geringer ist.
2. Aber im zweiten Diagramm sind die Objekte "auf dem gesamten Diagrammfeld verteilt", was ich persönlich als nicht sehr bequem empfinde.
3. Die gleiche Geschichte gilt für die Anmerkungen – Regeln. Und um das Regelwerk zum Diakon einzufügen, musste ich alle Elemente des Diagramms irgendwann nach unten verschieben.
4. Ich musste den Schritt "Empfang/Übertragung..." klonen, um zu zeigen, dass mehrere Teilnehmer in diesem Schritt anwesend sind.
5. Im zweiten Vorschlag musste ich auf einen Zweig und einen Zusammenfluss des Prozesses verzichten, da es völlig unmöglich war, sie "schön" anzuordnen! Im Idealfall hätte man dann einen Kommentar – eine Regel – anbringen sollen.

Natürlich gibt es Geschmack und Farbe, aber mir scheint die erste Variante auch praktischer für die Datensammlung zum Prozess.
Aber ich will nicht lügen – manchmal ist es besser, beide Varianten zu zeichnen, um im Prozess Klarheit zu schaffen.

Literaturverzeichnis

1. Website von Sparx Systems. [Elektronische Ressource] Zugangsmodus: Internet: https://sparxsystems.com
2. Zolotukhina E.B., Vishnya A.S., Krasnikova S.A. Modellierung von Geschäftsprozessen. — M.: KURS, NIЦ INFRAM, EBS Znanium.com. — 2017.
3. OMG Unified Modeling Language (OMG UML) Spezifikation. Version 2.5.1. [Elektronische Ressource] Zugangsmodus: Internet: https://www.omg.org/spec/UML/2.5.1/PDF

Quelle: habr.com