6.1 Zusammenwirken durch Nachrichtenverkehr

Von Anbeginn an war das Konzept des Nachrichtenaustausches zwischen Objekten Gegenstand der objektorientierten Theorie. Botschaften, wie sie auch genannt werden, wiesen auch schon fast alle Vorgänger der UML auf (vgl. [Stein 1994, S. 78]). Sie wurden gesehen als Werkzeug zur „Interobjektkommunikation“ [ebenda, S. 179].

Mit dem Konzept des Nachrichtenaustausches wird die Ebene der Strukturbeschreibung (wie in den obigen Kapiteln vorgestellt) verlassen und die der Verhaltensbeschreibung erreicht, denn Nachrichten sind Ausdruck der „Funktionalität eines objektorientiert entwickelten Systems“ und die gesamte Funktionalität beruht auf dem Nachrichtenaustausch [Schader und Rundshagen 1994, S. 16].

Von der Struktur- zur Verhaltens-
beschreibung

Der Übergang zu den „Verhaltensaspekten“ führt auch dazu, dass in diesem Kapitel einige neue Grundbegriffe erläutert werden müssen, Kollaborationen, Rollen und Lebenslinien, bevor dann der eigentliche Gegenstand (Nachrichten, Kommunkationsdiagramme) vorgestellt werden kann.

6.2 Hintergrund

Wie oben gezeigt, sind bei den Objektklassen Methoden hinterlegt, mit denen die Objekte der jeweiligen Klasse bearbeitet werden können.

Hinterlegte Methoden

Genauer:

Verarbeitet werden die Ausprägungen der Attribute, durch die die Objekte beschrieben sind. Die interne Repräsentation der Objekte.

Dabei handelt es sich um Methoden, die zur Erfüllung einer Teilaufgabe in der Gesamtanwendung dienen. Für viele Aufgaben ist es aber notwendig, dass die Methoden verschiedener Objektklassen im korrektem Zusammenspiel aufgerufen werden. Dies wird so realisiert, dass Objekte der einen Objektklasse Methoden einer anderen aufrufen können. Modellierungstechnisch wird dies mit dem Konzept von Nachrichten, die zwischen den Objekten und Objektklassen ausgetauscht werden, realisiert.

Methoden im Zusammenspiel

Den einfachsten Fall eines solchen Nachrichtenaustausches können wir bereits darstellen: Die Kommunikation zweier Objekte miteinander.

Der einfachste Fall

Stellen wir uns vor, bei einer Klasse Rechnungsköpfe sei die Methode für das Erstellen und den Ausdruck von Rechnungen hinterlegt. Dann gibt es eine Stelle in diesem Ablauf, an dem das jeweilige Objekt (in der folgenden Abbildung als anonymes Objekt dargestellt) von einem Objekt der Klasse Kunden die Kundendaten (Name, Adresse, usw.) anfordert. Dies kann wie in der folgenden Abbildung gezeigt, dargestellt werden (zur grafischen Darstellung vgl. unten).

Rechnungskopf braucht Kundendaten

Voraussetzung für das Gelingen ist, dass in der Klasse Kunde eine entsprechende Methode kundendaten() vorhanden ist.

Begriffe

Meist werden in der deutschsprachigen Literatur die Begriffe Nachricht und Nachrichtenaustausch verwendet. Bei einigen Autoren (so z.B. bei den beiden Balzerts) auch Botschaft. Die UML und die übrige englischsprachige Literatur verwenden die Begriffe message und message passing.

Nachricht oder auch Botschaft

Nachrichten

Hier eine erste Klärung des Nachrichtenbegriffs, mehr dazu in Abschnitt 7.5. Nachrichten stehen in einem engen Zusammenhang mit Methoden und Operationen. Definiert man, wie in Kapitel 2 geschehen, Operationen als Dienste, die von einem Objekt angefordert werden können, und als Methoden die Implementierungen der Operationen, dann können Nachrichten so definiert werden:

Nachrichten fordern Operationen an

„Eine Nachricht überbringt einem Objekt die Information darüber, welche Aktivität von ihm erwartet wird, d.h. eine Nachricht fordert ein Objekt zur Ausführung einer Operation auf.“ [Oestereich 2004, S. 355]

Nur unwesentlich verkürzt bei Meier und Wüst:

„Unter einer Nachricht (engl. message) versteht man die Aufforderung eines Objektes an ein anderes, eine bestimmte Methode auszuführen.“ [Meier und Wüst 1997, S. 32]

Meldungsverkehr

Die Menge der Botschaften, auf die Objekte einer Klasse reagieren können, wird als Protokoll (protocol) der Klasse bezeichnet“ [Balzert 2001, S. 206f].

Protokoll

Unterschieden wird dabei der Aufruf von Instanzmethoden und von Klassenmethoden. Wie in Kapitel 2 gezeigt wurde, sind erstere Methoden, die einzelne Instanzen betreffen, z.B. eine Preisänderung bezüglich einer Instanz einer Objektklasse zu Produkten. Zweitgenannte betreffen Methoden, durch die alle Objekte einer Objektklasse angesprochen sind, z.B. die Feststellung der Gesamtzahl der Angestellten oder der Lohnsumme in einer Klasse zu den Angestellten.

Instanzmethoden
und
Klassenmethoden

Interaktion

Für die UML-Autoren fällt der Nachrichtenverkehr zwischen Objekten unter den Begriff der Interaktion. Für sie basiert eine Interaktion auf einem strukturierten Classifier oder auf einer Kollaboration. Die Interaktion kann im Rahmen der UML als Sequenz mit Sequenzdiagrammen oder als Kommunikation mit Kommunikationsdiagrammen beschrieben werden, die jeweils unterschiedliche Aspekte der Interaktion betonen [Rumbaugh, Jacobson und Booch 2005, S. 37].

Basis einer Interaktion: strukturierte Classifier oder Kollaborationen

Unter einem strukturierten Classifier kann man sich z.B. ein objektorientiertes Modell mit einem Kommunikationsdiagramm vorstellen, Kollaborationen werden im nächsten Abschnitt vorgestellt.

In den Originalquellen und bei den meisten sonstigen Autoren wird auch betont, dass als Versender wie auch als Empfänger von Nachrichten Rollen (vgl. unten) betrachtet werden und nicht die Klassen als solche (vgl. z.B. [Rumbaugh, Jacobson und Booch 2005, S. 39]). Deshalb erfolgt in Abschnitt 7.3 auch eine vertiefte Klärung des Rollenbegriffs.

Rollen gestalten den Nachrichten-
verkehr

6.3 Kollaborationen

6.3.1 Definition

Oben wurde es angeführt: Neben den strukturierten Classifiern (i.d.R. objektorientierte Modelle die sich als Klassendiagramme grafisch artikulieren) sind Kollaborationen die Basis für die Betrachtung des Nachrichtenverkehrs.

Dieses Theorieelement ist eigentlich nicht notwendig, da „Zusammenarbeit“ in vielen anderen Theorieelementen der UML modelliert wird. In Booch et al wird aber dann doch die Motivation deutlich, die hinter diesem Konstrukt steht. Es soll „Verhalten im Kleinen“ modellieren. Der Schlüssel(neben)satz für dieses Verständnis ist der folgende:

Verhalten „im Kleinen“

„Eine Kollaboration benennt eine Gemeinschaft von Klassen, Interfaces und anderen Elementen, die zusammenarbeiten, um ein kooperatives Verhalten hervorzurufen, das mehr ist als die Summe seiner Teile.“ ([Booch, Rumbaugh und Jacobson 2006, S. 425], Hervorhebung durch den Verfasser).

Also sinnvoll abgegrenzte Systemkomponenten (die Autoren denken nur an Systeme, das macht die Wortwahl deutlich), bei denen alles übrige, was nicht mit dem ausgewählten Verhalten zu tun hat, weggelassen wird.

Dies sind so etwas wie elementare Systembestandteile, die nicht nur jeweils einzeln mehr sind als die Summe ihrer Teile, sondern die auch jeweils einen wichtigen Beitrag zum Gesamtsystem leisten:

Elementare Systembestandteile

„Das Herz der Architektur eines Systems schlägt in seinen Kooperationen… alle gut strukturierten objektorientierten Systeme sind aus einer regulären Menge mittlerer Größe solcher Kollaborationen aufgebaut, ….“ [Booch, Rumbaugh und Jacobson 2006, S. 431]

Damit wird deutlich, dass es wesentlich um Systemdesign geht. Hier ist tatsächlich das Finden der elementaren Verhaltenseinheiten von entscheidender Bedeutung für die Qualität der dann entstehenden Software.

Die Beschreibung dieses eng umgrenzten Verhaltens soll dann auch die Rollen angeben, die die Partizipanten dabei einnehmen. Dies ist den UML-Autoren sehr wichtig. Die Betonung der Rollen geht so weit, dass die UML-Autoren hier die „collaborating elements“ und die Rollen gleichsetzen [ebenda].

Rollen

Eine Kollaboration kann damit z.B. eine Operation beschreiben oder aber einen Anwendungsfall (vgl. Kapitel 12), in dem die Classifier und Assoziationen angegeben werden, die für seine Leistung notwendig sind [OMG 2003a, S. 157].

Auch dies gibt Hinweise auf die Motivation für dieses doch etwas überraschende Theorieelement. Es geht wohl auch um den Wunsch, einzelne Anwendungsfälle näher zu beschreiben.

Auf jeden Fall aber sind die Grundlage von Kollaborationen Teile, die zusammenarbeiten (in UML-Sprache: Teile eines Classifier) und andere Elemente, die diese verknüpfen. Im Standardfall also Klassen und Assoziationen.

Auch bei diesem Konzept denken die UML-Autoren in erster Linie an Systeme: „Its primary purpose is to explain how a system works …” [ebenda]. Aber dies ist ja nicht überraschend, sondern im größten Teil der UML-Texte so.

Systeme

Kollaborationen haben nur eine eingeschränkte Aussagekraft. Will man genauer wissen, wie das Zusammenspiel und der dafür notwendige Nachrichtenverkehr erfolgt, dann sind Kommunikations- oder Sequenzdiagramme besser geeignet.

Begrenzte Aussagekraft

Booch et al. weisen noch darauf hin, dass es auch eine Beziehung zwischen Kollaborationen gibt, Verfeinern [Booch, Rumbaugh und Jacobson 2006, S. 431f]. Dabei wird in der „verfeinerten“ Kollaboration ein Teil des Verhaltens der anderen erfasst.

6.3.2 Grafische Darstellung

Eine Kollaboration wird als Ellipse mit gestrichelter Linie dargestellt. In der Ellipse wird die Bezeichnung der Kollaboration vermerkt.

Die interne Struktur der Kollaboration (Rollen und Konnektoren) kann ebenfalls in der Ellipse angegeben werden, getrennt von der Bezeichnung durch eine gestrichelte Linie. Vgl. dazu die Beispiele.

6.3.3 Beispiele

Im ersten Beispiel ist angedeutet, dass die Kollaboration Rechnung schreiben von den beiden Komponenten Rechnungskopf und Rechnungspositionen realisiert wird.

Beispiel Rechnungen

Alternativ kann ein Komponentendiagramm genutzt werden. In diesem Fall werden die beteiligten Classifier mit dem Symbol für die Kollaboration verbunden.

6.4 Rollen

Der Begriff Rolle wurde oben in dem Kapitel zu Assoziationen schon angesprochen. Dort wurden z.B. die Angestellten in ihrer Rolle als PC-Nutzer oder in ihrer Rolle als Gehaltsempfänger modelliert.

Benötigt wird der Begriff in der UML für Kollaborationen, für den Begriff „Part“ und für Assoziationen.

Die UML-Autoren definieren eine Rolle als eine Menge von Merkmalen, die benannt sind und die sich auf eine Sammlung von Entitäten beziehen, die in einem bestimmten Zusammenhang stehen [OMG 2003a, S. 14]. Bei der Fortsetzung der Definition unterscheiden sie zwischen Kollaborationen, „Parts“ und Assoziationen:

• Bei Kollaborationen sprechen sie von einer benannten Verhaltensmenge einer Klasse oder eines „Part“, die in einem bestimmten Zusammenhang stehen.
• Bei „Part“ von einer Teilmenge einer bestimmten Klasse, die einen Teil der Merkmale der Klasse besitzt.
• Bei Assoziationen stellt eine Rolle ein Synonym für ein Assoziationsende dar, das sich auf eine Teilmenge der Classifier-Instanzen bezieht, die an der Assoziation teilhaben [ebenda].

Für eine vertiefte Darstellung vgl. [Booch, Rumbaugh und Jacobson 2006, S. 432ff]

6.5 Lebenslinien

Während in populären Darstellungen (vgl. zum Beispiel [Balzert 2000, Abschnitt 4.4]) gleich von Objekten die Rede ist, die Nachrichten (bei den beiden Balzert: Botschaften) versenden oder empfangen, ist in den UML-Texten von lifelines als Trägern des Nachrichtenverkehrs die Rede.

Versender der Nachrichten

Lifeline

Wörtlich: Rettungsleine, fig. Lebensader im Sinne von Versorgungsweg, was hier wohl am besten passt. In diesem Buch wird die in [Booch, Rumbaugh und Jacobson 2006] vorgeschlagene Übersetzung Lebenslinie benutzt.

Eine Lebenslinie repräsentiert einen einzelnen Teilnehmer an der Interaktion. Dies kann ein beliebiger Classifier sein, also z.B. auch eine Instanz (ein Objekt) einer Klasse.

Grafische Darstellung

Eine Lebenslinie wird durch ein Rechteck und eine senkrechte gestrichelte Linie dargestellt. Das Rechteck bildet sozusagen den Kopf, darunter folgt die Linie (vgl. die folgende Abbildung). Die Linie repräsentiert – bei einer entsprechenden Darstellungstechnik (vgl. Sequenzdiagramme in Kapitel 11) – die Dauer der Existenz des Kommunikationsteilnehmers (also z.B. der Instanz einer Klasse).

Diese Darstellung wird in Sequenzdiagrammen benutzt. In den in diesem Kapitel betrachteten Kommunikationsdiagrammen wird die gestrichelte Linie nicht benötigt.

Vgl. Kapitel 11

Im Rechteck wird also die Bezeichnung der Lebenslinie festgehalten. Diese besteht aus einer Zeichenfolge, die nacheinander folgende Elemente enthält:

• Bezeichnung des verknüpfbaren Elements (so die Bezeichnung aller verknüpfbaren Elemente in der UML, zu der auch die Lebenslinien gehören).
• Eine Auswahl (selector), falls nötig (vgl. unten).
• Einen Doppelpunkt
• Die Bezeichnung des Classifiers, meist also die Bezeichnung der Klasse.

Handelt es sich bei den Lebenslinien um Instanzen (Objekte) einer Klasse, wird die Bezeichnung unterstrichen, wie es für Instanzen üblich ist (vgl. Abschnitt 3.11).

Instanzen als Lebenslinien

Beispiele:

• wire:Wire, left:Bead, right:Bead aus [Rumbaugh, Jacobson und Booch 2005, S. 243, Figure 14-64]
• c:Controller, :Cache aus [Booch, Rumbaugh und Jacobson 2006, S. 259, Abbildung 16.4]
• c:Kunde, p:ODBCProxy aus [Booch, Rumbaugh und Jacobson 2006, S. 295, Abbildung 19.1]

Lässt man die Bezeichnung des verknüpfbaren Elements weg, entstehen, in Anlehnung an den Begriff der anonymen Objekte, sog. anonyme Lebenslinien. Beispiele dafür:

Anonyme Lebenslinien

• :Controller, :Window, :Line aus [Rumbaugh, Jacobson und Booch 2005, S. 243, Figure 14-64]
• :OrderTaker, :TicketDB, :CreditBureau, aus [Rumbaugh, Jacobson und Booch 2005, S. 107, Figure 9-4]
• c:View, aus [Booch, Rumbaugh und Jacobson 2006, S. 259, Abbildung 16.4]
• :Transaktion aus [Booch, Rumbaugh und Jacobson 2006, S. 295, Abbildung 19.1]

Falls das zu verknüpfende Element mehrwertig ist (Wertigkeit größer 1), dann kann die Lebenslinie einen Ausdruck (den “selector”) haben, der festlegt, welcher Teil durch die Lebenslinie repräsentiert wird. Liegt bei einer Wertigkeit größer als eins keine Auswahl vor, bedeutet das, dass ein beliebiger Repräsentant genommen wird.

Auswahl

Ist die Bezeichnung der Lebenslinie das Schlüsselwort self, dann repräsentiert die Lebenslinie das Objekt des Classifiers, das die Interaktion umfasst, zu der die Lebenslinie gehört [OMG 2003a, S 428].

Schlüsselwort self

6.6 Nachrichten

6.6.1 Definition

Im ersten Abschnitt dieses Kapitels wurden Nachrichten bereits vorgestellt. Zu ergänzen ist noch, dass Nachrichten eine Bezeichnung und Parameter haben. Die Bezeichnungen der Nachricht und der Methode zusammen mit den Ein- und Ausgabeparametern werden als Signatur bezeichnet.

Da es wie oben ausgeführt tatsächlich so ist, dass meist Objekte von Klassen Nachrichten aussenden und empfangen, reduzieren viele Autoren den Nachrichtenbegriff auch darauf.

In der UML wurde dieses Konzept übernommen, präzisiert und ergänzt. Hier ist eine Nachricht eine Kommunikation zwischen den Lebenslinien einer Interaktion. Dies kann sein:

UML-Sichtweise

• Senden und Empfangen eines Signals
• Aufruf einer Operation
• Erzeugung oder Zerstörung einer Instanz

Die Nachricht legt nicht nur die Art der Kommunikation fest, sondern auch den Sender und den Empfänger.

Ergänzend wird in der UML ein Ereigniskonzept hinzugefügt. Ereignisse lösen einerseits die Nachrichten aus (beim Sender) und entstehen andererseits durch das Eintreffen der Nachricht beim Empfänger. Eine für Ablaufbeschreibungen naheliegende Ergänzung.

Ereigniskonzept

Die Bezeichnung der Nachricht spezifiziert das Ereignis [Grässle, Baumann und Baumann 2000, S. 211], die Argumente enthalten die Informationen, die der Nachricht mitgegeben werden, damit der Empfänger die geforderten Aktivitäten ausführen kann. Zu diesen Informationen gehören auch Kontroll- und Steuerungsinformationen.

In der UML kann eine Nachricht ein Signal oder der Aufruf einer Operation sein. Ein Signal kann als Empfänger auch mehrere Objekte haben, ein Operationsaufruf bezieht sich immer auf nur ein Objekt.

Unterschieden werden die Nachrichtentypen Call, Return, Send, Create und Destroy.

Die übersandten Nachrichten lösen typischerweise Aktivitäten aus und führen evtl. auch zur Übermittlung von Ergebnissen in der Antwort. So kann z.B. die Nachricht bestimmePosSu() (bestimme die Summe der Rechnungspositionen) an eine Klasse Rechnungspositionen zum Aufruf der entsprechenden Methode und zur Antwort mit dem berechneten Wert führen.

Rückgabewerte

Erhält ein Objekt einer Klasse eine Nachricht, führt es eine Operation aus. Im Rahmen der Ausführung dieser Operation ist es möglich, dass weitere Nachrichten erzeugt und versandt werden. Ein einfaches Beispiel zum Druck einer Rechnung ist unten angegeben. Wenn ein Objekt der Klasse Rechnungspositionen (bzw. RechPos) die Aufgabe erhält, die Rechnungspositionen zusammenzustellen, ruft es selbst eine Methode von Artikel auf.

Nachricht erzeugt Nachricht

6.6.2 Synchron und Asynchron

Nachrichten können synchron oder asynchron ausgetauscht werden. Dabei bedeutet ein synchroner Nachrichtenaustausch, dass der Sender wartet, bis der Empfänger den betreffenden Methodenaufruf beendet hat und erst dann wieder aktiv wird. In vollem Umfang, was eigene Verarbeitungsschritte angeht und was weitere auszusendende Nachrichten angeht.

Synchroner
Nachrichten-
austausch

Eine Operation, die durch eine synchrone Nachricht ausgelöst wurde, kann im Rahmen der Antwort Werte zurückgeben. Bei der Rückgabe erhält der Sender dann auch die Kontrolle (über den Kontrollfluss) zurück.

Asynchron dagegen bedeutet, dass das Senderobjekt mit seinem weiteren Tun nicht wartet, bis die aufgerufene Aktion durchgeführt ist, sondern gleich wieder irgendwelche Verarbeitungsschritte durchführen kann.

Asynchroner Nachrichten-
austausch

Gängige objektorientierte Programmiersprachen wie Java und C++ haben z.B. synchrone Operationsaufrufe. D.h., es existiert nur ein einziger Kontrollfluss, zu einem bestimmten Zeitpunkt wird immer nur eine einzige Anweisung ausgeführt.

Balzert führt aus, dass in Komponentenmodellen (wozu objektorientierte Modelle gehören) der synchrone Nachrichtenaustausch Standard ist, dass aber der asynchrone Austausch insbesondere in Verbindung mit Ereignissen sinnvoll ist, z.B. wenn die durch das Ereignis angesprochenen Empfänger nur informiert werden sollen [Balzert 2001, S.913].

Im Falle eines asynchronen Nachrichtenaustausches wird Nebenläufigkeit ermöglicht. Dies ist, so [Booch, Rumbaugh und Jacobson 2006, S. 259] von großer Bedeutung „für die heutige Welt von nebenläufiger Verarbeitung“.

Nebenläufigkeit

Exkurs: Einige einfache Beispiele

In der Datenübertragung: Erfolgt diese synchron, bleiben zeitliche Beziehungen zwischen den Daten bei der Übertragung erhalten. Dies ist z.B. notwendig bei der Übertragung von Filmen, weil da der zeitliche Abstand zwischen aufeinanderfolgenden Bildern wichtig ist. Bei einer asynchronen Datenübertragung müssen solche zeitlichen Bedingungen nicht streng eingehalten werden. Zum Beispiel bei einem File-Transfer.

Netze: Ein Beispiel für ein synchrones Netz ist das klassische Fernsprechnetz und das daraus abgeleitete ISDN-Netz. Ein Beispiel für ein asynchrones Netz ist das Internet.

6.6.3 Sequenznummern

Rumbaugh et al. weisen auf einen Schwachpunkt von Diagrammen hin, in denen einfach nur die auszuführenden Nachrichten vermerkt sind. Z.B. also bei einem Klassendiagramm, in dem die Nachrichten ergänzt wurden (vgl. Abbildung 7.7-2). In einem solchen Fall ist die Abfolge der Nachrichten (genauer: der Kontrollfluss) nur bei genauem Studium des Diagramms erkennbar, falls überhaupt. Das macht die Diagramme schwer lesbar. Deshalb geben sie die Abfolge der Nachrichten durch Sequenznummern (sequence numbers) an [Rumbaugh, Jacobson und Booch 2005, S. 241].

Keine zeitliche Dimension

Die Sequenznummern entsprechen einer Dezimalklassifikation, wie sie in Büchern oft verwendet wird (und auch in diesem Text). Die erste zu erfassende Nachricht erhält die Nummer 1, die zweite die Nummer 2, usw. Wird innerhalb der Abarbeitung von Nachricht 2 eine weitere aufgerufen, erhält diese die Nummer 2.1, eine weitere die Nummer 2.2, usw. Wird innerhalb der Ausführung der Operation von Nachricht 3 eine weitere Nachricht aktiviert (3.1) und sendet dieses im Rahmen ihrer Abarbeitung zwei Nachrichten aus, erhalten diese, gemäß ihrer Rangfolge, die Nummerierung 3.1.1 und 3.1.2.

Reihenfolge mit Hilfe der Dezimal-
klassifikation

Die Sequenznummern werden zusammen mit einem Doppelpunkt vor die Nachricht gesetzt. Z.B. also:

1: anfrageLagerbestand(anzahl)

1.1: abzählenWarengruppe()

2: berechnenGesamtsumme()

2.1: berechnenPositionssumme(anzahl, einzelpreis)

Dieses Konzept erlaubt also die Erfassung von Verschachtelungen, ein insgesamt doch sehr dürftiges Kontrollflusskonzept, das aber durch die zwei nachfolgenden Elemente (Wiederholung, Parallelität) etwas erweitert wird. Für die Vorbereitung der Programmierung gibt es aber zumindest Hinweise.

Syntax der Nachrichtenbezeichnung

Insgesamt ergibt sich dann folgender Aufbau für die Nachrichtenbezeichnung:

Sequenznummer attribut=Nachrichtenbezeichnung(Liste Parameter):Rückgabewert

Soll eine Nachricht wiederholt werden, kann dies in der Nachrichtenbezeichnung ausgedrückt werden. Dazu wird ein Stern (*) nach der Sequenznummer und vor der Nachrichtenbezeichnung eingetragen. Ein Beispiel ist die Nachricht bestimmtePos() an eine Klasse Rechnungspositionen, die so oft gesandt wird, bis alle Positionen abgearbeitet sind. Die wiederholte Ausführung kann auch genauer beschrieben werden, indem in eckigen Klammern eine Präzisierung erfolgt, z.B.

Schleife

*[i == 1..n]

Sogar eine parallele Ausführung kann angefordert werden. Dazu werden nach dem Stern zwei senkrechte Striche eingefügt:

Parallelität

*|| (vgl. [OMG 2003b, S. 447])

6.6.4 Grafische Darstellung

In der grafischen Darstellung objektorientierter Datenmodelle werden Nachrichten durch Pfeilsymbole zwischen den Sendern und Empfängern kenntlich gemacht. Die Richtung der Nachricht zeigt von der sendenden zur empfangenden Lebenslinie. Falls eine Rückantwort (vgl. unten) erfolgen soll, wird eine entsprechende Antwortnachricht modelliert.

Die konkrete Gestaltung des Pfeils variiert:

synchron
asynchron
Antwort

• Synchrone Nachrichten werden durch eine durchgezogene Pfeillinie und eine gefüllte Pfeilspitze gekennzeichnet.
• Asynchrone Nachrichten erhalten ebenfalls eine durchgezogene Pfeillinie sowie eine Pfeilspitze ohne Füllung (nur mit Strichen).
• Eine Antwort auf eine synchrone Nachricht wird durch eine gestrichelte Pfeillinie und eine Pfeilspitze ohne Füllung gekennzeichnet.

6.7 Kommunikationsdiagramme

6.7.1 Definition

Jetzt kann endlich das neue Theorieelement vorgestellt werden. Ein Kommunikationsdiagramm erfasst den für eine Aufgabenerfüllung notwendigen Nachrichtenaustausch zwischen Lebenslinien (im einfachsten Fall: zwischen Objekten). Die Abfolge der Nachrichten wird durch Sequenznummern erfasst.

Aufgabenerfüllung durch Nachrichten-
austausch

Sequenzen und Sequenzdiagramme (vgl. Kapitel 11) erfassen bzw. beschreiben dieselbe Information, stellen sie nur unterschiedlich dar. Booch et al. weisen auf die Motive für die beiden Visualisierungen hin. Sequenzdiagramme betonen die zeitliche Reihenfolge der Nachrichten, während Kommunikationsdiagramme die strukturelle Organisation der Nachrichten sendenden Objekte in den Vordergrund stellen [Booch, Rumbaugh und Jacobson 1999, S. 243]. Ansonsten betonen sie aber die semantische Gleichwertigkeit der beiden Konzepte.

Hinweis: Kommunikationsdiagramme wurden in früheren UML-Versionen Kollaborationsdiagramme genannt.

Sequenz- und Kommunkationsdiagramme werden auch unter dem Begriff Interaktionsdiagramm zusammengefasst.

Interaktions-
diagramme

Innere Struktur

Die innere Struktur wird dargestellt, indem die Kompenten (z.B. die Objekte), ihre semantischen Verknüpfungen (z.B. die Assoziationen) und dann eben der für die jeweilige Aufgabe notwendige Nachrichtenaustausch angegeben wird. Da im Rahmen einer Aufgabenerfüllung die Komponenten (z.B. Objekte) meist spezifische Rollen einnehmen, wird hier das oben eingeführte Rollenkonzept verwendet.

Im Falle von Objekten entsteht also ein Kommunikationsdiagramm aus einem Klassendiagramm, in dem die Nachrichten mit Hilfe der oben eingeführten Pfeile vermerkt sind.

Fowler weist darauf hin, dass standardmäßig in der UML in Klassendiagrammen keine Nachrichten angezeigt werden [Fowler 2004, S. 107], dass dies aber möglich ist. Geschieht es, werden an den Seiten von Assoziationen Pfeile hinzugefügt, die mit dem Namen der Nachrichten beschriftet sind (wie oben gezeigt). Er weist außerdem darauf hin, dass für einen Nachrichtenverkehr nicht unbedingt eine Assoziation vorliegen muss (ebenda).

Standardmäßig keine Klassendiagramme

6.7.2 Grafische Darstellung

Die folgende Abbildung zeigt die grafische Darstellung von Kommunikationsdiagrammen. Sie kann nicht so allgemeingültig sein wie sonst, da es für die unterschiedliche Anzahlen von Komponenten und für die unterschiedliche innere Struktur keine Abstraktionsmöglichkeit gibt.

Hier das Beispiel dreier Objekte, die zusammenwirken. Objekt 1 sendet zwei Nachrichten, die Reihenfolge ist durch die Sequenznummern angegeben. Die zweite Nachricht wird wiederholt versendet. Beide Nachrichten haben Parameter und damit Argumente.

6.8 Beispiel Rechnungsdruck

Das folgende Kommunikationsdiagramm zeigt den (vereinfachten) Nachrichtenaustausch rund um den Druck einer Rechnung (vgl. auch das nachfolgende Klassendiagramm mit diesem Nachrichtenverkehr):

Schritt um Schritt zur Rechnung

• Nach Eingehen der Aufforderung, die Rechnung zu drucken, fordert die Lebenslinie RechnKöpfe (Rechnungsköpfe) von der Lebenslinie Kunden die Kundendaten an.
• RechnKöpfe hat eine Methode zur Erstellung der Rechnung. Diese fordert von RechnPos (Rechnungspositionen) solange die Positionsdaten (Positionsnummer, Artikelbeschreibung, Anzahl, Positionssumme) an, bis alle Positionen abgearbeitet sind.
• Lebenslinie RechnPos schickt jedesmal eine Nachricht zu Artikel mit der Aufforderung, die Artikelbezeichnung und den Einzelpreis des durch die Artikelnummer (artNr) identifizierten Artikels zu liefern.
• Anschließend berechnet RechnPos durch Aufruf einer seiner Methoden die gewünschten Angaben und liefert sie an RechnKöpfe zurück.
• RechnKöpfe bestimmt dann durch Aufruf einer seiner Methoden die Rechnungssumme, MWSt und eventuelle weitere auf die Gesamtrechnung bezogene Daten.
• Nach Einholen aller notwendigen Informationen und Beendigung aller Berechnungen erstellt RechnKöpfe mit Hilfe seiner Methode druckeRechnung() die Rechnung.

Auch wenn dieses Beispiel den Vorgang nur andeuten kann, sollte es doch das diesem Theorieelement zugedachte Modulierungsziel verdeutlichen: Aufgabenerledigung im Kleinen (dazu unten mehr).

Aufgaben-
erledigung im Kleinen

Die folgende Abbildung zeigt nun diesen Nachrichtenverkehr in einem Klassendiagramm. Die Elemente sind hier die ganz normalen Klassen des objektorientierten Modells, deren Bezeichnungen aus Gründen der Anschaulichkeit länger gewählt wurden. Zusätzlich zu den Nachrichten sind hier noch die Antworten angegeben.

Nachrichtenverkehr im
Klassendiagramm

Auch hier ist natürlich der Kontrollfluss auf das verschachtelte Aussenden der Nachrichten mit Wiederholung und Parallelität beschränkt und insofern von eingeschränkter Aussagekraft.

Die grafische Darstellung zeigt außerdem, dass auch diese Darstellung des kooperativen Miteinanders nur bei kleinen Modellen interpretierbar ist.

.