Sequenzdiagramm: Asynchrone Nachrichten

Eine Nachricht kann man sich als einen Brief vorstellen, nach dessen Absenden der Briefschreiber mit seiner Beschäftigung fortfährt. Die weiterlaufende Beschäftigung wird erst dann unterbrochen, wenn er die Antwort auf seinen Brief benötigt, diese aber noch nicht eingegangen ist. In einem solchen Fall muss modelliert werden, dass der Sender nach dem Senden einer Nachricht weiter aktiv ist, also beide Objekte die Ablaufkontrolle innehaben. Solche Situationen bezeichnet man als asynchrone Nachrichten und die beiden (oder mehrere) Objekte als aktive Objekte.

Aktive Objekte werden in Sequenzdiagrammen durch ein fett gezeichnetes Rechteck markiert. Asynchrone Nachrichten werden durch Pfeile mit offener Spitze angegeben.

Bei einer asynchronen Nachricht werden zwei Fälle unterschieden:

1. Aktivierung eines Objekts: Hier zeigt der offene Pfeil auf den Anfang des Aktivierungsbalkens des angesprochenen Objekts
2. Nachricht an ein Objekt, das bereits aktiviert worden ist: Hierbei endet der offene Pfeil irgendwo innerhalb des Aktivierungsbalkens des angesprochenen Objekts.

Abbildung: Prüfung eines Geschäftsvorfalls

Beispiel (aus [1])
Im folgenden zeigt ein Sequenzdiagramm den Ablauf einer Prüfung eines zulässigen Geschäftsvorfalls. Zunächst bewirkt die Erzeugung des Geschäftsvorfalls automatisch die Erzeugung eines aktiven Objekts der Klasse Koordinator, dessen Aufgabe die Überprüfung der Zulässigkeit des Geschäftsvorfalls ist. Zu diesem Zweck erzeugt der Koordinator seinerseits zwei aktive Objekte der Klasse Prüfer, die jeweils genau eine der beiden Bedingungen prüfen, die ein Geschäftsvorfall erfüllen muss. Durch dieses Vorgehen wird die Hinzunahme weiterer Bedingungen sehr einfach, da die Prüfungen asynchron gestartet werden und parallel arbeiten.

Sobald eine Prüfung abgeschlossen ist, meldet das Prüferobjekt das Ergebnis über den Aufruf der Operation istOK() an den Koordinator zurück, führt Abschlussarbeiten durch und zerstört sich dann selbst. Dieser prüft daraufhin seinerseits, ob jetzt beide Prüfungen abgeschlossen sind. Ist das nicht der Fall, werden keine Aktionen veranlasst und der Koordinator wartet weiter auf die Beendigung der zweiten Prüfung. Meldet dagegen das zweite Prüferobjekt sein Ergebnis zurück, meldet der Koordinator an den Geschäftsvorfall, dass er zulässig ist.

Quellen
[1] G. Kösters, H.-W. Six, M. Winter: Coupling Use Cases and Class Models as a Means for Validation and Verification of Requirements Specifications. Requirements Engineering, Vol. 6, Nr. 1, Springer, London, 2001, S. 3-17
[2] OMG: Unified Modeling Language Specification V. 1.4, OMG, Sept. 2001