Back To Top

Interaktionsdiagramme mit der UML


Comelio-Blog UML InteraktionsdiagrammeInteraktionsdiagramme helfen Entwicklern und Planern, den Informationsaustausch zwischen den Kommunikationspartnern aufzuzeigen. Die einzelnen Kommunikationspartner tauschen dabei Daten und Nachrichten aus.

Eines der Interaktionsdiagramme ist das Sequenzdiagramm. Hiermit werden der Nachrichtenfluss zwischen einzelnen Objekten beschrieben und die chronologischen Abläufe dargestellt. Die Beziehung zwischen den einzelnen Kommunikationspartnern ist nicht Thema des Sequenzdiagramms, hier findet der Entwickler im Kommunikationsdiagramm der UML 2.0 mehr Informationen.

Dabei können Kommunikationspartner sowohl Objekte als auch Systeme sein. Häufig werden Sequenzdiagramme als Interaktionsdiagramm verwendet, wobei noch weitere Interaktions­diagramme existieren, bspw. das Kommunikationsdiagramm. Das Kommunikationsdiagramm hat seinen Schwerpunkt in der Darstellung der Beziehung der Kommunikationspartner zueinander.

In der UML 2.0 wird ein spezielles Ereignismodell beschrieben, das das Auftreten von Ereignissen semantisch erklärt. Anhand des Metamodells in der Abbildung Events möchten wir Ihnen diese Begrifflichkeiten näher bringen.

Der zugrunde liegende Typ wird Event genannt. Es gibt ein Sendeereignis (Spezifikation: SendOperationEvent) und ein Empfangsereignis beim Empfänger (Spezifikation: CallEvent).

Wie Sie in der Abbildung Events sehen können, gibt es mehrere Formen der Ereignisauftritte.

Eventtyp Bedeutung
ExecutionEvent Ein Ereignis, das bei der Ausführung ausgelöst wird
CreationEvent Ein Ereignis, das ein neues Objekt instanziert
MessageEvent Ein Ereignis, das eine Nachricht generiert
DestructionEvent Ein Ereignis, das ein Objekt zerstört


Die UML 2.0 ist bemüht, einzelne Aspekte der Interaktion mit verschiedenen Interaktions­diagrammen hervorzuheben und andere mehr oder weniger auszublenden, um die Vorgänge zu vereinfachen. Es gibt zu diesem Zweck mehrere Diagramme, die alle zu den Interaktionsdiagrammen zählen:

  • Sequenzdiagramme
    Das Sequenzdiagramm (Spezifikation: Sequence Diagram) ist neben dem Timingdiagramm ein wichtiges und von der Aussagekraft her das umfangreichste Interaktionsdiagramm. Hierbei geht es vor allem um die genaue chronologische Reihenfolge des Nachrichtenaustausches.
  • Kommunikationsdiagramme
    Das Kommunikationsdiagramm (Spezifikation: Communication Diagram) zeigt die Beziehung zwischen den Kommunikationspartnern auf. Mithilfe des Kommunikationsdiagramms kann der Austausch von Nachrichten, die zur Lösung einer Aufgabe innerhalb eines Systems oder systemübergreifend notwendig sind, dargestellt werden.
  • Timingdiagramme
    Mit dem Timingdiagramm (Spezifikation: Timing Diagram) können Zustandswechsel analysiert werden. Hier können vor allem technische Probleme beschrieben werden, wobei Automaten der häufigste Anwendungsfall für ein Timingdiagramm sind.
  • Interaktionsübersichtsdiagramme
    Interaktionsübersichtsdiagramme zeigen, wie die verschiedenen Interaktionen zusammenarbeiten.

Die Abhängigkeiten der Interaktionspakete sind in der Abbildung Abhängigkeiten des Pakets Interaktionen aus der Spezifikation zusammengestellt.

Wie Sie in der Abbildung deutlich sehen können, bezieht das Paket BasicInteractions das Paket BasicBehaviors und das Paket InternalStructures mit ein und importiert die BasicActions.

Dies bedeutet, dass die Basis-Interaktionen direkt das Basisverhalten implementiert haben und nutzen können.

 

Einsatz des Sequenzdiagramms

Comelio-Blog UML InteraktionsdiagrammeAnhand des Sequenzdiagramms lässt sich der zeitliche Verlauf der Nachricht sehr gut veranschaulichen. Die Sequenzdiagramme können Sie in sehr verschiedenen Abstraktionsniveaus modellieren. Es ist möglich, die Geschehnisse in einer Klasse selbst zu modellieren, aber auch die Geschehnisse zwischen Komponenten oder im System.

Die große Stärke der Sequenzdiagramme entfaltet sich im Projekt während der Implementierungsphase. Sinnvoll sind sie z.B. bei einigen Vorüberlegungen und bei der Fehleranalyse, allerdings sind sie auch in jeder Phase des gesamten Projekts einsetzbar. Sich über die genaue Kommunikation Gedanken zu machen, kann sehr zeitaufwändig sein. Dies führt häufig zu Nachlässigkeit bei der Dokumentation.

Häufig nutzt man das Aktivitätsdiagramm dazu, sich die gezeichneten Anwendungsfalldiagramme genauer anzusehen und sich den objekt- und datenorientierten Klassen-, Fach- oder Analysemodellen zu widmen. Hier geht es darum, komplexere Reihenfolgen und Abläufe und die verschiedenen Varianten darzustellen.

Das Metamodell

Comelio-Blog UML InteraktionsdiagrammeZunächst einmal zum Metamodell der UML 2.0, das in der Abbildung Lebenslinien genau erläutert wird. 

Eine Lebenslinie (Spezifikation: Lifeline) beschreibt ein Objekt und dessen Lebenszeit im Kontext des Kommunikationsprozesses. Sie dient, wie Sie in der Abbildung: Lebenslinien des Metamodells erkennen, der Interaktion.

Eine Interaktion kann mehrere Lebenslinien besitzen, umgekehrt kann die Lebenslinie selbst nur zu einer Interaktion gehören. Auf einer Lebenslinie können Ereignisse auftreten, die im Modell als OccurrenceSpecification dargestellt werden. Es gibt auch Zustände oder Referenzen auf andere Nachrichten, die hier übergeordnet Interaktionsfragment (Spezifikation: InteractionFragment) genannt werden.

Ein solches Fragment kann, wie Sie in der Abbildung Lebenslinien sehen, zu mehreren Lebenslinien gehören. Des Weiteren kann eine Lebenslinie zu mehreren Fragmenten gehören.

Die Zustandsinvariante (Spezifikation: StateInvariant) ist eine Bedingung (Spezifikation: Constraint), die sich auf Kommunikationsteilnehmer der Interaktion bezieht. Eine Lebenslinie kann direkt mit einer Bedingung behaftet werden, die zur Laufzeit vor dem nächsten Ereignis beachtet wird. Sie gibt Bedingungen vor, die in geschweiften Klammern oder als Kommentar an die Lebenslinie geheftet werden.

Die Interaktionsfragmente sind Teil der Interaktion und davon abgeleitet gibt es die verschiedenen Spezifikationen: ExecutionSpecification, OccurenceSpecification und StateInvariant.

Jedes Interaktionsfragment ist selbst ein benennbares Element.

Die ExecutionOccurrenceSpecification ist direkt von der OccurrenceSpecification abgeleitet.

Die OccurrenceSpecification ist direkt mit einem Ereignis verbunden.

Die Abbildung Occurrences listet die Möglichkeiten der verschiedenen Events auf.

Die eigentliche Ausführung (Spezifikation: ExecutionSpecification) wird durch die ExecutionOccurrenceSpecification beschrieben.

Hier werden auch der Start und das Ende notiert und die Events zugeordnet.

Die ExecutionSpecification leitet die Aktionen beziehungsweise das Verhalten ab, die in den ActionExecutionSpecifications und den BehaviorExecutionSpecifications genau beschrieben werden.

Die Abbildung Message zeigt die Interaktion, die die Message besitzt. Eine Interaktion kann mehrere Messages erhalten, umgekehrt kann eine Message aber nur einer einzigen Interaktion zugeordnet sein. Die Message kann durch verschiedene Typen repräsentiert sein. Diese Typen werden durch die folgenden beiden Aufzählungstypen (Spezifikation: Enumerations) definiert:

  • MessageSort
  • MessageKind

Für das Sendeereignis und das Empfangsereignis gibt es im Metamodell die Klasse MessageEnd. Die Multiplizität 0..1 gibt es, weil es Nachrichten gibt, die gefunden oder verloren oder gemäß des Aufzählungstyps MessageKind lost oder found sind. Die Klasse MessageEnd steht in einer Assoziationsverbindung zur Klasse Message, weil das Ende der Nachricht meist mit einer Rücknachricht verbunden ist.

Die MessageOccurrenceSpecifications für Messages und MessageEvents dienen der Beschreibung von Ereignissen beim Auftreten der Messages. Dabei beschreibt sie im Gegensatz zur OccurrenceSpecification nur die Ereignisse vom Typ MessageEvents.

Die Signatur wird mit einem NamedElement dargestellt, das als Assoziation in der Rolle (+/signature) repräsentiert wird. Die Signatur besteht aus dem Namen und den Parametern einer Nachricht selbst. Die Parameter werden durch die Kompositionsbeziehung der Message mit den ValueSpecifications beschrieben.

Nachrichten können auch über Konnektoren verschickt werden (Spezifikation: Connector). Ein Konnektor stellt eine Kommunikationsverbindung zwischen connectable elements dar. Hierbei handelt es sich um Notationselemente des Kompositionsstrukturdiagramms, wie Parts und Ports.

Die Abbildung CombinedFragments des Metamodells beschreibt die kombinierten Fragmente (Spezifikation: combined fragments). Ein CombinedFragment definiert einen Ausdruck eines InteractionFragment. Mit einem CombinedFragment umschließt man einen Teilbereich einer Interaktion, in dem bestimmte Regeln gelten.

Im Modell besteht ein InteractionFragment aus Interaktionsoperanden (Spezifikation: InteractionOperand). Diese Interaktionsoperanden, von denen es in der UML 2.0 zwölf gibt, legen die gültigen Regeln fest.

Mit Hilfe der InteractionConstraints werden die Bedingungen festgelegt, mit denen die Interaktionsoperatoren gesteuert werden.

Notationen von Sequenzdiagrammen

Interaktion

Comelio-Blog UML InteraktionsdiagrammeEine Interaktion wird in den UML-Zeichnungen von einem Rahmen umschlossen. Durch diesen Rahmen, der grundsätzlich einen Interaktionsnamen trägt und Übergabe­parameter enthalten kann, kann man die Interaktion benennen, referenzieren und finden. Meistens wird das Kürzel sd dem Namen vorangestellt, was so viel heißt wie sequencediagram.

Lebenslinie

Comelio-Blog UML InteraktionsdiagrammeDie Zeit wird auf der Lebenslinie von oben nach unten notiert und dargestellt. Die Lebenslinie wird als rechteckiger Kasten mit einer gestrichelten Linie notiert.

Im Rechteck wird der Name des Kommunikationspartners angegeben. Oft handelt es sich dabei um ein Objekt, also eine Instanz.

Auch eine andere Symbolik ist gestattet, wenn bspw. dieses Objekt einen Akteur darstellen soll, dann darf auch die entsprechend erlaubte Notation benutzt werden. Wichtig ist, dass eine Lebenslinie einen Kommunikationsteilnehmer darstellt. Es darf hierbei auch nur ein einziger Teilnehmer mit einer Lebenslinie beschrieben werden.

In der UML 1.* waren Multiobjekte erlaubt, in der UML 2.0 nicht mehr. Ein Teilnehmer kann hierbei nur ein Teil oder eine Einheit eines Classifiers sein, der seinerseits mit anderen Teilnehmern kommunizieren kann. In der Spezifikation ist dies ein ConnectableElement, das z.B. durch einen Port innerhalb der UML 2.0 realisiert wird. Deswegen muss im Gegensatz zur UML 2.0 das Objekt an dieser Stelle nicht unterstrichen werden.

Eine Lebenslinie kann also enthalten:

  • Classifier
  • Attribute eines Classifiers
  • Operationen eines Classifiers
  • Ports
  • Parameter von Operationen

Eine Lebenslinie enthält in der UML 2.0 zwingend einen Namen des Kommunikationspartners, es ist nicht erlaubt, Lebenslinien anonym zu belassen. Im Kopf einer Lebenslinie steht der Elementname mit dem zugehörigen Classifier in der üblichen Deklarationsnotation, also:

[typ]: Objekt 1

Es kann auch das Schlüsselwort self vorangestellt werden. In diesem Fall repräsentiert die Lebenslinie ein Exemplar des Classifiers, dessen Interaktion sie darstellt.

Aktionssequenz

Comelio-Blog UML InteraktionsdiagrammeWährend des Zeitverlaufes wird ein Objekt in gewissen Abständen etwas tun. Bspw. werden Methoden ausgeführt, Werte gesetzt und vieles mehr. Die Phase, in der ein Objekt aktiv etwas tut, kann man auf der Lebenslinie notieren. Dies geschieht durch Aktionssequenzen (Spezifikation: ExecutionOccurences). Sie werden als zusätzliche Balken, die kaskadiert dargestellt werden können, sofern mehrere Aktivitäten gleichzeitig verlaufen, auf der Lebenslinie dargestellt (Abbildung Lebenslinie mit einer Aktionssequenz).

Der Anfang und das Ende des Ausführungsknotens werden durch Ereignisauftritte (Spezifikation: ExecutionEvents) definiert. Diese Ereignisauftritte sind vom Auftritt einer eingehenden Nachricht und dem Versenden eines Nachrichtenaustritts abhängig.

Beim Start und beim Ende werden die Ereignisse durch die ExecutionOccurrenceSpecifications beschrieben. Das Eintreffen eines Ereignisses kann auch bedeuten, dass eine neue Lebenslinie generiert wird.

Zustandsinvarianten auf Lebenslinien

Comelio-Blog UML InteraktionsdiagrammeEine Zustandsinvariante (Spezifikation: StateInvariant) wird auf der Lebenslinie notiert. Sie stellt eine Bedingung (Spezifikation: Constraint) dar. Vor Eintreten des zeitlich nächstgelegenen Ereignisses auf der Lebenslinie wird diese ausgewertet.

UML 2.0 – Interaktionsdiagramme: StateInvariant mit geschweiften Klammern UML 2.0 – Interaktionsdiagramme: StateInvariant als Kommentar UML 2.0 – Interaktionsdiagramme: StateInvariant mit Symbol

In den Abbildungen sind die gültigen Notationsformen dargestellt. Für welche Notation Sie sich in der Praxis entscheiden, bleibt Ihnen überlassen.

Nachrichten

Comelio-Blog UML InteraktionsdiagrammeNachrichten (Spezifikation: Messages) werden mit Pfeilen notiert. Hierbei unterscheidet man mehrere Möglichkeiten.
 

Synchrone Nachricht

Die synchrone Nachricht (Spezifikation: Synchronous Message) wird mit einer geschlossenen Pfeilspitze dargestellt. In diesem Fall wartet die aufrufende Lebenslinie, bis das aufgerufene Verhalten seine Aufgabe verrichtet hat.

Es gibt vom aufgerufenen Verhalten eine Antwort (Spezifikation: Reply Message), die mit einer gestrichelten Linie und einer offenen Pfeilspitze repräsentiert wird.

Asynchrone Nachricht

Im Gegensatz zur synchronen Nachricht (Synchronous Message) wird bei der asynchronen Nachricht (Spezifikation: Asynchronous Message) nicht auf das aufrufende Verhalten gewartet.

Hier wird einfach mit dem eigenen Verhalten fortgefahren.

Logischerweise ist hier auch keine Antwort nötig.

Verlorene Nachricht

Eine verlorene Nachricht (Spezifikation: Lost Message) hat eine offene Pfeilspitze, die in einem gefüllten Kreis endet.

Dass die Pfeilspitze in diesem Fall nicht mit einer Lebenslinie verbunden ist, soll andeuten, dass die Nachricht verloren ist.

Der Empfänger ist zudem nicht bekannt, wohl aber der Sender.

Gefundene Nachricht

Der umgekehrte Fall ist auch notierbar und stellt eine gefundene Nachricht (Spezifikation: Found Message) dar.

Die Linie geht vom Kreis aus und trifft mit der Pfeilspitze eine Lebenslinie.

Der Empfänger ist hier bekannt, nicht aber der Sender.
 

Create

Comelio-Blog UML InteraktionsdiagrammeCreate ist eine Nachricht, die ein neues Objekt erstellt. Diese Nachricht wird durch einen gestrichelten Pfeil mit einer offenen Pfeilspitze repräsentiert. Man kann diesen Pfeil auch als normalen asynchronen Pfeil wie in der Abbildung Create-Nachricht notieren. Die neue Lebenslinie des neuen Objektes beginnt erst beim Versand der Nachricht. Somit ist es nur logisch, dass der Pfeil auf den Kopf der neuen Lebenslinie zeigt.

In der Spezifikation wird der Pfeil für Create gestrichelt angegeben. In vielen Programmen wird er aber durchgezogen dargestellt, was gängige Praxis ist.

Syntax einer Nachricht

Comelio-Blog UML InteraktionsdiagrammeDie Nachricht kann einige Syntaxelemente enthalten, die die Nachricht genauer beschreiben.
Eine Nachricht hat folgenden grundlegenden Aufbau: 

Nachrichtenname(Argument1, Argument2 ...)

Die genaue Syntaxbeschreibung lässt sich wie folgt darstellen:

[attribut=] name[(argumente)][:rückgabewert]|’*’

Die Tabelle Syntaxelemente einer Nachricht zeigt die verschiedenen Möglichkeiten.

Syntax Bedeutung
attribut Variable, die während der Interaktion übergeben wird. Das Attribut kann nur bei einem synchronen Aufruf mit einem Rückgabewert genutzt werden.
name Angabe des Namens der aufzurufenden Nachricht. Bei einem Signal wird hier der Name des Signals angegeben, wobei ein Signal immer asynchron ist.
argumente Mit Argumenten werden Nachrichten Parameter mitgegeben.


Die Argumente können Folgendes enthalten:

  • Attribute der sendenden Lebenslinie
  • Konstanten
  • Ein- und Ausgabeparameter
  • Attribute des Classifiers

Mit einem Sequenzdiagramm kann man ein Objekt erzeugen, wie Sie gelernt haben.

Man kann ein Objekt aber auch entfernen. Dies wird durch ein Kreuz auf der Lebenslinie dargestellt.

In der UML 2.0 wird die Zerstörung eines Objektes als Stopp (Spezifikation: Stop) bezeichnet, der wiederum einen speziellen Ereignisauftritt (Spezifikation: EventOccurence) darstellt.

Ereignisse bei Nachrichten

Comelio-Blog UML InteraktionsdiagrammeEreignisse treten unmittelbar nach dem Senden oder Empfangen von Nachrichten auf. Es gibt mehrere gültige Abfolgen von Nachrichten. Wenn Sie hier für klare Verhältnisse sorgen möchten, können Sie zusätzliche Anmerkungen anbringen.

In der UML 2.0 ist es zwingend, dass zuerst das Sendeereignis stattfindet. Danach erst kommt das zugehörige Ereignis, das den Empfang repräsentiert.

Entlang einer Lebenslinie ist die Reihenfolge eingehalten. Die gegenüberliegende Lebenslinie ist aber nur relativ dazu. Die Zeitachse kann (schneller oder langsamer) beschriftet werden.

Die Abbildung Abfolgen soll diesen Sachverhalt darstellen.

Schaut man sich die Abfolgen an, könnte man meinen, dass die Kommunikation von A nach B verläuft und dann von C nach D. Dies ist auch so weit richtig. Aber dass die Kommunikation von C nach D anfängt, bevor die Kommunikation von A nach B abgeschlossen ist, bleibt unklar. Somit kann das Sendeereignis A anfangen und dann das Sendeereignis C beginnen, noch bevor das Empfangsereignis B eingetroffen ist.

Wichtig ist, dass grundsätzlich erst ein Sendeereignis auftaucht, bevor das zum Sendeereignis gehörige Empfangsereignis eintritt.

Wichtig ist außerdem, dass auf einer Lebenslinie die Zeit chronologisch verläuft. Auf einer parallelen Lebenslinie kann die Zeit anders skaliert werden, sodass dieselbe Position in einem Diagramm auf zwei verschiedenen Lebenslinien nicht den gleichen Zeitpunkt darstellt.

Um diese Ungenauigkeit zu vermeiden, gibt es eine Möglichkeit, Ordnungsbeziehungen (Spezifikation: General Orderings) für dieses Problem zu nutzen. So wird die Reihenfolge der Abläufe genau dargestellt.

Bei der Ordnungsbeziehung handelt es sich um eine gepunktete Verbindung mit einem ausgefüllten Pfeil in der Mitte in einem Sequenzdiagramm zwischen zwei Ereignissen, meist Sende- und Empfangsereignis.

Die Abbildung Ordnungsbeziehung stellt die Ordnung so her, dass nun klar wird, dass das Startereignis C definitiv vor B stattfinden muss. Die einzige gültige Abfolge wäre hier

1. A
2. C
3. B
4. D