it-swarm.com.de

Darstellung eines "Warten bis" in einem Aktivitätsdiagramm in UML

Wie kann ich im folgenden UML-Aktivitätsdiagramm ein "Warten, bis ein Kundenvertreter verfügbar ist" darstellen? Eine Lösung in UML 1 oder UML 2 ist akzeptabel.

Vorschlag 1

(wait state model

Die einfache Zeile zurück zur zweiten Bedingung "sieht" falsch aus.

Vorschlag 2

Ich habe mir auch diese "sauberere" Lösung ausgedacht.

(enter image description here

(Ich weiß, dass der letzte Punkt fehlt.)

7
problemofficer

IMHO besteht eigentlich keine Notwendigkeit, eine Bedingung oder "Schleife" für den "Warte" -Zustand aufzunehmen:

(Activitive_Example

Jede Aktivität benötigt eine bestimmte Zeit, bis sie abgeschlossen ist. Wenn ein Kundenvertreter sofort verfügbar ist, ist die Wartezeit Null. Wenn nicht, dauert die Aktivität nur einige Minuten oder Stunden. Die Potenz von "Null" ist jedoch, dass es oft wie jede andere Zahl gehandhabt werden kann, ohne dass künstliche Unterscheidungen erforderlich sind.

Wenn Sie die Aktivität "Warten" explizit modellieren möchten, weil in Ihrem System während eines "echten Wartens" etwas wesentlich anderes passiert, entscheiden Sie sich für Ihre Lösung 2.

10
Doc Brown

Sind Ihre Diagramme in Ordnung?

Der Schutz auf einem Entscheidungsknoten muss am Ende der Linie und nicht auf den Knoten platziert werden ( siehe UML 2.5 Abschnitt 15.2.4). Also wird [free customer representative available] Auf der Oberseite des Diamanten entfernt und die ausgehenden [yes] Und [no] In [customer representative available] Und [customer representative not available] Ändern.

Danach wären beide Diagramme formal in Ordnung:

  • Vorschlag 2 würde genau dann das erwartete Ergebnis liefern, wenn garantiert wird, dass ein Kundenvertreter verfügbar ist, wenn die Aktivität wait abgeschlossen ist. Dies ist nicht offensichtlich, also verzweigen Sie besser nach links und stellen Sie den Zusammenführungsdiamanten vor den Entscheidungsdiamanten, um sicherzugehen, dass Sie nicht fortfahren, bis ein Vertreter verfügbar ist.

  • Vorschlag 1 ist völlig richtig. Die Steuerknoten in einem Aktivitätsdiagramm sind entweder Entscheidungsknoten mit mehreren ausgehenden Flüssen oder Zusammenführungsknoten mit mehreren eingehenden Flüssen ( siehe UML 2.5, Abschnitt 15.3.2), aber glücklicherweise können beide kombiniert werden eine einzelne Raute im Diagramm ( siehe UML 2.5 Abbildung 15.34 in Abschnitt 15.3.4.3). Es ist jedoch etwas weniger lesbar als verschiedene Knoten.

  • Sie wissen es bereits, aber Sie benötigen einen Endknoten nach dem order.

Aber ist es wirklich der beste Weg?

Ihre Diagramme basieren auf dem menschlichen Verständnis der Aktivität wait (for representative). Aber ich denke, wir sind uns einig, dass Warten nicht wirklich eine Aktivität ist, sondern keine Aktivität.

Alternative 1: Verwenden Sie einen ereignisgesteuerten Ansatz mit Hilfe einer accept-event-action namens Customer representative available Das ist es, worauf Sie warten. Kombinieren Sie den aus ihm austretenden Fluss mit Ihrem normalen Fluss. Achtung: Verwenden Sie nicht das verlockende TimeEvent (Sanduhrsymbol): Es ist für Ereignisse gedacht, die zu einem bestimmten Zeitpunkt auftreten ( siehe UML 2.5, Abschnitt 13.4.10.1)

Alternative 2: stellen dar, was Sie wirklich tun: Sie finden einen Kundenvertreter. Dies ist die einfache Art, es zu zeigen.

(enter image description here

Alternative 3 (mein Favorit): repräsentiert die wahre Komplexität einer Multitasking-Welt unter Verwendung von eine Gabel und ein Join-Steuerelement = und dazwischen alles, was parallel passiert:

(enter image description here

4
Christophe

Wenn Sie Schwimmbahnen benutzen, brauchen Sie wahrscheinlich keinen Wartemechanismus. Dies bedeutet, dass der Kundenvertreter bereit sein muss, die Aufgabe zu erledigen.

Hier ist ein Vorschlag mit PlantUML/PlantText :

(enter image description here

[~ # ~] edit [~ # ~] Hier ist ein weiterer Vorschlag ( Quelle ) mit einer expliziteren Wartesemantik, die dies zulässt zum Auflegen.

(enter image description here

1
Fuhrmanator

Ein Wartezustand oder eine Warteaktivität ist nicht unplausibel und je nach Domäne auch nicht ungewöhnlich. Markieren Sie es als solches und definieren Sie, wie lange der Status aktiv sein wird (d. H. Wie lange er zum Entscheidungspunkt zurückkehrt).

Wenn der Entscheidungspunkt nicht explizit offengelegt werden muss, können Sie den Entscheidungs- und Wartezustand in eine einzelne Aktivität umwandeln, die sich nach der Verfügbarkeit eines Operators richtet.

Als Randnotiz; Wenn das OP eine "Demo" des tatsächlichen Flusses ist, der in Ihrem Projekt bewertet wird, gibt es andere Optionen für Modelle und die Modellierung dieses Verhaltens, die möglicherweise eine Untersuchung wert sind, wie z.

  • FSM, ein Status mit einem Ereignis, das die Maschine in den Status "Bestellung aufgeben" versetzt
  • Wenn mehrere Flows synchronisiert werden müssen, ist ein Join möglicherweise die bessere Idee

Manchmal sind andere Lösungen nur ein anderes Modell oder eine Art Neugestaltung, die den Wartezustand aufhebt. Die Lösung ist dann oft nur der Wartezustand, da dies das Verhalten des zu modellierenden Prozessflusses ist (sei es durch Design oder durch Analyse).


Bei der hinzugefügten zweiten Option erfordert das "Warten bis" von Natur aus einen Test, um festzustellen, ob die erforderliche Bedingung erfüllt ist. Ich bin mir nicht sicher, ob die zweite Option dies angemessen modelliert.

1
Niall

Sie sollten eine ReceiveSignalAction verwenden, um den Empfang eines Signals darzustellen, dass ein Berater bereit ist.

Leider ist derzeit kein Modellierungswerkzeug verfügbar. Ich werde das Diagramm hinzufügen, wenn ich an meinem Computer sitze.

0
Ister