Eine Interaktion beschreibt eine Reihe von Nachrichten, die eine ausgewählte Menge von Beteiligten in einer zeitlich begrenzten Situation austauscht.

Zur Darstellung von Interaktionen definiert die UML 2.1 drei unterschiedliche Diagramme:

  • Sequenzdiagramme (Sequence Diagram) betonen die Reihenfolge des Nachrichtenaustauschs.
  • Kommunikationsdiagramme (Communication Diagram) betonen die Beziehungen zwischen den Beteiligten.
  • Zeitdiagramme (Timing Diagram) betonen die Zustandswechsel der Beteiligten in Abhängigkeit von der Zeit und den ausgetauschten Nachrichten.

Beim Sequenzdiagramm steht der zeitliche Verlauf der Nachrichten im Vordergrund. Die Reihenfolge der Nachrichten entspricht ihrer horizontalen Position im Diagramm. Es wird festgelegt, wann ein Objekt erstellt wird und wann Nachrichten zu welchem Objekt gesendet werden.

Die beteiligten Objekte werden durch ein Rechteck und eine senkrechte gestrichelte Linie repräsentiert. Beides zusammen wird Lebenslinie (Lifeline) genannt. Nachrichten (Messages) werden durch Pfeile zwischen den Lebenslinien dargestellt. Die Zeit verläuft von oben nach unten. Der zeitliche Verlauf der Nachrichten wird dadurch hervorgehoben.

Das Sequenzdiagramm in der folgenden Abbildung zeigt eine Interaktion von drei Objekten. Zu beachten ist, dass das ganze Diagramm eine Interaktion repräsentiert und eine Interaktion nicht nur ein einzelner Nachrichtenaustausch ist.

Abb. 53: Einfaches Beispiel eines Sequenzdiagramms

Im Kopf der Lebenslinie steht der (optionale) Elementname mit der zugehörigen Klasse in der üblichen Deklarationsnotation: name : typ.

Wenn zwischen Lebenslinien Nachrichten ausgetauscht werden, muss auch ein Verhalten in den zugehörigen Elementen ausgeführt werden. Das wird durch die länglichen Rechtecke auf der Lebenslinie dargestellt. Die Rechtecke repräsentieren den sogenannten Ausführungsfokus (ExecutionOccurence). Anfang und Ende des Ausführungsfokus sind durch sogenannte Ereignisauftritte definiert. Einfacher gesagt, das Senden und Empfangen von Nachrichten bestimmt Anfang und Ende des Ausführungsfokus.

Die Übertragung einer Nachricht wird mit Pfeilen notiert. Die Beschriftung der Nachrichten erfolgt mit den Namen der zugehörigen Operationen. UML kennt verschiedene Arten von Nachrichten, die durch unterschiedliche Pfeilnotationen dargestellt werden. In der nachfolgenden Abbildung werden die verschiedenen Nachrichtenarten und zugehörige Notationsformen gezeigt.

  • Synchrone Nachrichten (Synchronous Messages) haben eine gefüllte Pfeilspitze. Synchron bedeutet, dass der Aufrufer wartet, bis das aufgerufene Verhalten beendet wurde. Die Antwort (Reply Message) auf einen synchronen Aufruf wird mit einer gestrichelten Linie und offener Pfeilspitze dargestellt.
  • Asynchrone Nachrichten (Asynchronous Messages) haben eine offene Pfeilspitze. Asynchron bedeutet, dass der Aufrufer nicht wartet, sondern unmittelbar nach dem Aufruf fortfährt. Entsprechend gibt es auf asynchrone Aufrufe auch keine Antwortpfeile.
  • Verlorene Nachrichten (Lost Messages) haben eine offene Pfeilspitze, die auf einen ausgefüllten Kreis zeigt. Der Kreis ist nicht mit einer Lebenslinie verbunden. Bei einer verlorenen Nachricht ist der Sender der Nachricht bekannt, aber nicht der Empfänger.
  • Gefundene Nachrichten (Found Messages) haben eine offene Pfeilspitze. Die Linie geht von einem ausgefüllten Kreis aus. Der Kreis ist nicht mit einer Lebenslinie verbunden. Bei einer gefundenen Nachricht ist der Empfänger der Nachricht bekannt, aber nicht der Sender.
  • Eine Nachricht, die ein neues Exemplar erzeugt, wird mit einer Linie und offener Pfeilspitze dargestellt. Die zu dem Exemplar gehörende Lebenslinie beginnt erst an dieser Stelle im Diagramm, d. h., der Pfeil zeigt auf den Kopf der Lebenslinie.

Abb. 54: Notationsformen der verschiedenen Nachrichtenarten

Durch Voranstellen des Zeichens * modelliert man das wie­derholte Senden der Nachricht. Die Nachricht erhält in diesem Fall das Zei­chen * vorangestellt.

Auf den Nachrichtenpfeilen wird die Nachricht notiert. Die Syntax lautet

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

Wobei

  • attribut eine lokale Variable der Interaktion oder ein Exemplar einer Lebenslinie sein kann. Die Attributzuweisung wird nur bei synchronen Nachrichten mit Rückgabewert verwendet.
  • name der Name der aufzurufenden Nachricht oder der Name des Signals, das gesendet wird, ist. Das Senden eines Signals hat immer asynchronen Charakter.
  • argumente eine kommaseparierte Liste der Parameterwerte ist, die der Nachricht übergeben werden.

Wird über das Absetzen einer Botschaft ein Objekt er­zeugt (z. B. über den Aufruf der Methode new), beginnt die Lebenslinie des Objekts erst an dieser Position. Die Auflösungeines Objektes wird durch ein Kreuz auf der Lebenslinie dargestellt.

Die folgende Tabelle enthält die Symbole der Sequenzdiagramme.

Symbol/Name

Verwendung

Systemgrenze

Die Systemgrenze isoliert den betrachteten Programmteil vom übrigen Programm. Sie dient meist als Ausgangspunkt des auslösenden Methodenaufrufs. Nicht immer wird der Programmfluss von einem Objekt außerhalb des betrachteten Bereichs ausgelöst, sodass in diesem Fall keine Systemgrenze eingezeichnet werden muss.

Objekt

Ein Objekt wird mit einem Rechteck, das den Namen enthält, dargestellt. Das Unterstreichen des Namens kann hier entfallen, da keine Verwechselung mit dem Klassennamen auftreten kann. Klassen werden in diesem Diagramm nicht dargestellt. Die Objekte werden entlang der oberen Blattkante nebeneinander angezeigt.

Lebenslinie

Jedes Objekt liegt auf einer senkrechten Linie, der Lebenslinie. Die Lebensdauer des Objekts nimmt in Richtung der unteren Blattkante zu. Für Objekte, die zu Beginn des Programmteils bereits existieren, werden die Objektsymbole an der oberen Blattkante gezeichnet. Für Objekte, die innerhalb des Programmteils neu erstellt werden, wird das Symbol in Höhe des Methodenaufrufs gezeichnet, in dessen Folge das Objekt erstellt wird.

Objekt-Aktivität

Ist ein Objekt an einem Methodenaufruf beteiligt, wird es aktiv. Die Lebenslinie verdickt sich. Ruft ein Objekt eine eigene Methode auf, verdickt sich die Lebenslinie ein weiteres Mal. Diese Aktivitäten werden nicht immer mitgezeichnet.

Methodenaufrufe

Ruft ein Objekt eine Methode eines anderen Objekts auf, wird das über einen durchgehenden Pfeil symbolisiert, der auf das Objekt zeigt, dessen Methode aufgerufen wird. An dieses Symbol wird der Methodenname geschrieben. Diesem Namen kann in Klammern die Parameterliste angefügt werden.

Rückkehr einer Methode

Prinzipiell werden nur die Methodenaufrufe in das Sequenzdiagramm eingezeichnet. Möchten Sie dennoch die Rückkehr der Methoden einzeichnen, können Sie dies mit einem Pfeil und unterbrochener Linie vornehmen.

Objekt-Erstellung

Erstellt eine Methode ein Objekt, endet der Pfeil der Methode an dem rechteckigen Symbol des Objekts. Die Lebenslinie beginnt bei diesem Symbol.

Objekt-Zerstörung

Wird durch den Aufruf einer Methode ein Objekt zerstört, endet die Lebenslinie des Objekts mit einem Kreuz unterhalb des Symbols des Methodenaufrufs.

In einem Ticketsystem für ein Schauspielhaus werden auf einer Internetseite Eintrittskarten aus dem Saalplan heraus verkauft. Der Saalplan verwaltet die Sitzplätze einer Veranstaltung.

Wird ein Platz von einem Besucher ausgewählt, ruft das betreffende Objekt aPlatz die Methode „kaufen“ des Objekts aBestellung auf und übergibt eine Referenz auf sich selbst im Parameter. Das Objekt der Klasse Bestellung ruft die Methode „istFrei“ der Klasse Saalplan auf, um zu überprüfen, ob der im Parameter übergebene Platz noch frei ist. Ist der Platz noch frei, ruft das Saalplan-Objekt seine eigene Methode „reservieren“ auf. Damit wird der Platz zunächst reserviert.

Nachdem dies erfolgt ist, wird die Rechnung für den Platz erstellt. Dazu ruft das Saalplan-Objekt die Metho­de „buchen“ mit dem ausgewählten Platz als Parameter auf. Die Methode „buchen“ gehört zum Objekt aVerkauf. Dieses stellt eine Liste der Rechnungspositionen dar, was hier nicht modelliert ist. Nachdem die Rechnungspositionen vom Verkaufs-Objekt zusammengestellt wurden, ruft dieses die Methode „erstelleRechnung“ des Objekts aBestellung auf. Um dem Internetbesucher den Erfolg seines Kaufes mitzuteilen, ruft das Bestellungs-Objekt die Methode „bestätigt“ der Klasse Platz auf. Der Besucher bestätigt die Bestellung, und die Methode „bestätigt“ kehrt mit dem Wert „true“ (wahr) zurück. Die Bestellung ist ab­geschlossen.

Das Kommunikationsdiagramm entspricht dem Kollaborationsdiagramm der UML 1.x. Es ist umbenannt worden, da der Name Kollaborationsdiagramm irreführend ist. Es gibt in der UML auch das Modellelement Kollaboration, das aber nichts mit Kollaborationsdiagrammen zu tun hat.

Das Kommunikationsdiagramm stellt die Fakten eines Sequenzdiagramms unter einer anderen Betrachtungsweise dar. In diesem Diagramm wird besonderes Augenmerk auf die Zusammen­arbeit der Objekte untereinandergelegt. Dazu werden ausgewählte Nachrichten verwendet, mit denen die zeitliche Abfolge der Kommunikation zwischen den Objekten erfolgt. Es stellt somit in kompakterer Form die Aussagen des Sequenzdiagramms zu­sammen.

In der folgenden Abbildung ist gut zu sehen, dass das Kommunikationsdiagramm die Beziehungen zwischen den Beteiligten in den Vordergrund stellt und nicht wie das Sequenz­diagramm die zeitliche Abfolge des Nachrichtenaustauschs.

Abb. 56: Beispiel Kommunikationsdiagramm „Verfügungsberechtigten identifizieren“

Die grafische Darstellung besteht aus einem Rechteck, das den Objektnamen und die zugehörige Klasse ent­hält. Ein Doppelpunkt trennt beide Namen. Die Objekte werden mit Assoziationslinien verbunden. Ein klei­ner Pfeil zeigt jeweils die Richtung der Nachricht vom Sender zum Empfänger an. Wenn mit der Nachricht Ar­gumente übergeben werden, sind diese aufgeführt. Mögliche Rückgabewerte können ebenfalls in der Form

antwort := Nachrichtenname (Parameterliste)

angegeben werden.

Um den zeitlichen Ablauf zu modellieren, er­halten die Nachrichten Nummern. Durch eine Nachricht können weitere Nachrichten ausgelöst werden. Sie erhalten Unternummern der auslösenden Nachricht (z. B. 1.2).

Wird eine Nachricht mehrfach ausgelöst, kann durch ein Zeichen * vor dem Nachrichtennamen diese Iteration modelliert werden.

Objekte, die innerhalb des dargestellten Szenarios erzeugt werden, können Sie mit dem Stereotyp new kennzeichnen. Für Objekte, die innerhalb des dargestellten Szenarios zerstört werden, erfolgt die Bezeichnung mit dem Stereotyp destroy. Objekte, die innerhalb des Szenarios erzeugt und zerstört werden, erhalten das Stereotyp transient.

Die folgende Tabelle enthält die Symbole der Kommunikationsdiagramme.

 

Symbol/Name

Verwendung

Objekt

Das Rechteck ist das Symbol eines Objekts und enthält den Objektnamen. Da keine Verwechselung mit Klassen eintreten kann, mussder Name nicht unterstrichen sein.

Kommunikation

Kommunizieren zwei Objekte über einen Methodenaufruf miteinander, wird diese Ver­bindung mit einer durchgängigen Linie dargestellt, die beide Objekte verbindet.

Kommunikations­richtung

Zusätzlich zur Verbindungslinie wird nach dem Methodennamen durch einen Pfeil ange­zeigt, zu welchem Objekt die Methode gehört. Die Pfeilspitze zeigt auf dieses Objekt.

Beschriftung der Kommunikations­linien

Die Linie wird mit dem Methodennamen und der Parameterliste beschriftet. Eine Nummerierung wird zur Kennzeichnung der zeitlichen Reihenfolge der Methodenaufrufe vor dem Me­thodennamen angezeigt und durch einen Doppel­punkt von diesem getrennt. In einer Bedingung können Sie die Nummern der Methoden angeben, die als Voraussetzung bereits abgearbeitet wurden. Das Zeichen * vor dem Methoden­namen kennzeichnet eine Wiederholung der Me­thode. Die Bedingung für die Wiederholung können Sie nach dem Zeichen * angeben.

Das Beispiel modelliert den Kauf eines Tickets über das Internet. Der Internetkunde wählt einen Platz auf der Internetseite eines Schauspielhauses aus und ruft damit die Methode auswählen auf. Die Interaktion wird ge­startet. Das Objekt aPlatz ruft die Methode kaufen des Bestellung-Objekts auf und übergibt eine Refe­renz auf sich selbst im Parameter. Das Objekt aBestellung ruft die Methode IsFrei des Saalplanobjekts auf. Diese Methode ruft zum einen die Methode reservieren und zum anderen die Methode buchen auf. Sie unterscheiden sich deshalb nur in der Unternummer. Das Saalplanobjekt ruft die Methode buchen des Objekts aVerkauf auf. Dieses Objekt ruft die Methode erstelleRechnung des Bestellung-Objekts auf und übergibt die Rechnungsposition des gebuchten Platzes. Nachdem die Rechnung vom Objekt aBestellung erstellt wurde, erfolgt die Benachrichtigung des Internetkunden über die erfolgreiche Buchung. Dazu wird die Methode bestätigt aufgerufen, die die Bestätigung des Kunden erfragt und zurückgibt.

Abb. 57: Beispiel Kommunikationsdiagramm „Ticketkauf über Internet“

Sequenz- und Kommunikationsdiagramme sind sehr ähnlich und können auch in einigen UML-Tools ineinander übergeführt werden. Der Fokus beim Sequenzdiagramm liegt auf dem zeitlichen Aspekt, beim Kommunikationsdiagramm liegt er hingegen auf den Beziehungen zwischen den Objekten. Der größte Vorteil der Sequenzdiagramme und gleichzeitig größte Nachteil der Kommunikationsdiagramme ist der deutlich sichtbare zeitliche Ablauf, der bei Kommunikations­diagrammen zwar prinzipiell auch durch ein Nummerierungsschema visualisierbar ist, aber weniger deutlich sichtbar. Dafür muss beim Erstellen nicht sofort die Ausführungsreihenfolge festgelegt werden, was die Erstellung der Sequenzdiagramme manchmal etwas trickreich gestaltet. Andererseits ist in einem umfangreichen Kommunikations­diagramm die Reihenfolge schlecht lesbar, der Leser muss durch eine Suche herausfinden, ob z. B. auf 1.1 2, 1.2 oder gar 1.1.1 folgt!

Das Interaction Overview Diagramm ist neu in UML 2.0/2.1.Es stellt jedoch lediglich eine Mischung aus Aktivitäts- und Sequenzdiagramm dar, wobei sowohl Aktivitätsblöcke in ein Sequenz­diagramm gemischt werden können, als auch umgekehrt. Da es darüber hinauskeinerlei Neuheiten enthält, wird hier nicht näher darauf eingegangen.

Das folgende Beispiel zeigt den Ablauf „Überweisung tätigen“, wobei hier das Hauptdiagramm ein Aktivitätsdiagramm ist und eine Aktion (Auftrag speichern) durch ein Sequenzdiagramm genauer beschrieben wird.

Abb. 58: Beispiel Interaction Overview Diagram

Komponentendiagramme zeigen die Beziehungen der Komponenten untereinander. Eine Komponente ist eine ausführbare und austauschbare Softwareeinheit mit definierten Schnittstellen und eigener Identität. Eine Komponente ist ähnlich einer Klasse instanziierbar und kapselt eine komplexe Funktionalität.

Abb. 59: Notation Komponentendiagramm

Die Komponente Component2 stellt über ihre Schnittstelle eine Funktionalität zur Verfügung. Die Kompo­nente Component1 kommuniziert über die von der Komponente Component2 angebotene Schnittstelle Interface1 und verwendet deren Funktionalität.

Die folgende Tabelle enthält die Symbole der Komponentendiagramme.

Name/Symbol

Verwendung

Komponente

Das Symbol der Komponente besteht aus einer Anordnung von drei Rechtecken. Zwei Rechtecke werden auf der linken Seite des dritten, größeren Rechtecks gezeichnet. In diesem steht der Name der Komponente. Die Komponenten erfüllen vollständig die Auf­gaben eines abgesteckten Bereiches, für die sie entwickelt wurden.

Schnittstelle

Eine Komponente kann eine Schnittstelle anbieten. Über diese erfolgt ein verwalteter Zugriff auf die Funktionalität der Komponente. Die Schnittstellen machen diese Elemen­te austauschbar.

Eine Schnittstelle wird mit einem Kreis dargestellt. Dieser Kreis wird mit der Klasse, dem Paket oder der Komponente durch eine durchgezogene Linie verbunden. Der Name der Schnittstelle wird neben dem Symbol angegeben.

Abhängigkeit

Der Pfeil mit gestrichelter Linie symbolisiert den Zugriff auf die Schnittstelle. Der Pfeil zeigt auf den Kreis des Schnittstellensymbols. Er kann aber auch direkt auf eine Kom­ponente zeigen, wenn nicht über die Schnittstelle zugegriffen wird.

 

Im Beispiel werden vier Komponenten zu einer Anwendung verknüpft, um Daten einer Datenbank in einem Fenster anzuzeigen. Die Datenbank-Verbindungs-Komponente ist für den Aufbau, die Verwaltung und den Ab­bau der Verbindung zur Datenbank verantwortlich. Über eine Schnittstelle stellt sie Methoden zur Verfügung, über welche die Daten-Container-Komponente Daten aus der Datenbank anfordern kann.

Die Daten-Container-Komponente verwaltet die angeforderten Datensätze. Gleichzeitig wird bei jedem Daten­transfer eine Transaktion über die Schnittstelle der Transfersteuerungskomponente gestartet. Die Komponen­te für die grafische Darstellung ruft über die Schnittstelle der Daten-Container-Komponente die Datensätze ab und stellt sie auf dem Bildschirm dar.

Ändert der Anwender die Daten, so übergibt die Komponente die Änderungen an die Daten-Container-Komponente. Die geänderten Daten werden von dieser über die Verbindungs­komponente in die Datenbank geschrieben und die neuen Daten werden über die Transfer­steuerungskomponente bestätigt, woraufhin die ge­startete Transaktion beendet wird.

In diesem Diagramm werden Abhängigkeiten zwischen Knoten, die Knoten selbst, deren Inhalte und Kommunikationen gezeigt. Ein Knoten ist eine physische Einheit, die über Speicherplatz und Rechenleistung verfügt (z. B. ein PC) auf denen wiederum Komponenten laufen. Die Knoten werden als Qua­der gezeichnet. In den Quadern können Komponenten oder Laufzeitobjekte (Prozesse) eingetragen werden. Statt der Quader können auch Bilder verwenden werden, die den Knoten grafisch darstellen. Verteilungsdia­gramme zeigen, welche Komponenten und Objekte auf welchen Knoten (Computer, Prozesse) laufen, d. h., wie diese konfiguriert sind und welche Kommunikations­beziehungen bestehen.

Die folgende Tabelle enthält die Symbole der Einsatz- und Verteilungsdiagramme.

Symbol/Name

Verwendung

Knoten

Ein Knoten wird mit einem Quader dargestellt. Die Beschriftung, die innerhalb des Quaders angegeben wird, erhält den Namen des Knotens, z. B. einen Rechnernamen, einen Client- oder einen Prozessnamen.

Teilsystem

Wird auf einem Knoten eine Anwendung im Speicher ausgeführt, wird diese Anwen­dung als Knoteninstanz modelliert. Zur Unterscheidung mit dem Knotensymbol wird die Beschriftung im Quader unterstrichen. Dieses Symbol wird in das Knotensymbol einge­fügt, auf dem der Teilprozess abläuft.

Komponente

Eine Komponente ist vom Umfang kleiner als ein Teilsystem, übernimmt aber für einen festgelegten Anwendungsbereich die Aufgaben der Anwendung. Das Komponenten­symbol wird in das Knotensymbol eingefügt, auf dem die Komponente installiert wurde.

Komponenteninstanz

Die Komponenteninstanz ist ein Sammelbegriff für die Objekte, deren Klassen zur Datenstruktur der Komponente gehören und von dieser instanziiert werden. Das Symbol unterscheidet sich nicht vom Symbol der Komponenten. Im Unterschied zum Komponentensymbol wird der Name der Instanz unterstrichen dargestellt. Das Symbol wird in das Komponentensymbol eingefügt, dessen Instanz es darstellt.

Beziehungslinie

Die Beziehungen zwischen den Knoten werden mit einer durchgezogenen Linie dargestellt, die die Knoten verbindet.

Bei einem Ticketsystem für Lichtspieltheater kann aus verschiedenen Anwendungen heraus auf die Ticket­daten zugegriffen werden. Die Daten liegen auf einem zentralen Server, der mit weiteren PCs vernetzt und mit dem Internet verbunden ist. Auf dem Server ist eine Komponente zur Administrierung der Datenbank instal­liert. Der Datenbankserver Interbase ist auf dem Server eingerichtet.

  • Der Verkauf an der Abendkasse wird über einen PC in der Kassenhalle abgewickelt. Damit dieser sehr schnell auf die Daten zugreifen kann, wurde eine Clientanwendung entwickelt, die speziell auf die Anforderungen des Verkaufs an der Abendkasse angepasst wurde.
  • Der Systembetreuer hat für seine Aufgaben einen PC, z. B. im Bereich der Buchhaltung. Auch er hat eine Clientanwendung, die es ihm ermöglicht, Veranstaltungen anzulegen und auszuwerten.
  • Die Vorverkaufsstelle wird mit einer eigenen Clientanwendung betrieben, die über das Internet mit dem Server verbunden ist.
  • Der Internetkunde ruft von einem PC aus Daten vom Ticketsystem über das Internet ab. Dafür ist eine auf diese Kunden zugeschnittene Clientanwendung des Ticketsystems nötig.

Abb. 61: Beispiel Verteilungsdiagramm

Das Timing Diagram wird vor allem in der hardwarenahen Programmierung oder in zeitlich kritischen Organisationsprojekten eingesetzt, um die Prozesse anhand der Zeitachse auf einen optimalen Ablauf hin zu untersuchen.

Die folgende Abbildung zeigt ein Zeitdiagramm. Hier steht der Zustand der Beteiligten in Bezug zu einer linearen Zeitachse im Vordergrund.

Abb. 62: Beispiel Zeitdiagramm

Die interne Struktur einer Klasse kann mit dem Kompositionsstruktur­diagramm beschrieben werden. Das Diagramm ist neu in der UML 2.0 / 2.1. Auf den ersten Blick kann das Diagramm leicht mit einem Kommunikationsdiagramm verwechselt werden. Die folgende Abbildung zeigt ein Kompositionsstrukturdiagramm und ein zugehöriges Klassendiagramm mit Kompositionen. Die Aussage beider Diagramme ist gleichbedeutend.

Abb. 63: Kompositionsstrukturdiagramm und zugehöriges Klassendiagramm

Das Objektdiagramm hat eine gewisse Ähnlichkeit mit dem Klassendiagramm, mit dem entscheidenden Unterschied, dass hier nur Instanzen und keine Klassen dargestellt werden. Es zeigt einen bestimmten Ausschnitt des Programms zur Laufzeit. Es werden die einzelnen Objekte dargestellt, ebenso die Verbindungen und auch die Multiplizitäten. Eingesetzt wird dieser Diagrammtyp beispielsweise bei der Nachstellung eines Fehlers im laufenden System. Wenn nur unter bestimmten Voraussetzungen ein bestimmtes Verhalten der Software auftritt, kann das mit dem Objektdiagramm beschrieben werden, indem die für diesen Sachverhalt relevanten Eigenschaften und deren Werte in den Objekten dargestellt werden.

Im folgenden Beispiel ist links ein Klassendiagramm abgebildet und rechts das zugehörige Objektdiagramm.

Abb. 64: Beispiel Objektdiagramm(rechts) und zugehöriges Klassendiagramm