Interaktionsdiagramme (Interaction Diagrams)
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.
Sequenzdiagramm (Sequence Diagram)
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.
Ausführungsfokus
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.
Nachrichtenarten
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 wiederholte Senden der Nachricht. Die Nachricht erhält in diesem Fall das Zeichen * 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 erzeugt (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.
Symbole
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. |
Beispiel
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 Methode „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 abgeschlossen.
Kommunikationsdiagramm (Communication Diagram)
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 Zusammenarbeit 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 zusammen.
In der folgenden Abbildung ist gut zu sehen, dass das Kommunikationsdiagramm die Beziehungen zwischen den Beteiligten in den Vordergrund stellt und nicht wie das Sequenzdiagramm 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 enthält. Ein Doppelpunkt trennt beide Namen. Die Objekte werden mit Assoziationslinien verbunden. Ein kleiner Pfeil zeigt jeweils die Richtung der Nachricht vom Sender zum Empfänger an. Wenn mit der Nachricht Argumente ü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, erhalten 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.
Symbole
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 Verbindung mit einer durchgängigen Linie dargestellt, die beide Objekte verbindet. |
Kommunikationsrichtung | Zusätzlich zur Verbindungslinie wird nach dem Methodennamen durch einen Pfeil angezeigt, zu welchem Objekt die Methode gehört. Die Pfeilspitze zeigt auf dieses Objekt. |
Beschriftung der Kommunikationslinien | Die Linie wird mit dem Methodennamen und der Parameterliste beschriftet. Eine Nummerierung wird zur Kennzeichnung der zeitlichen Reihenfolge der Methodenaufrufe vor dem Methodennamen angezeigt und durch einen Doppelpunkt von diesem getrennt. In einer Bedingung können Sie die Nummern der Methoden angeben, die als Voraussetzung bereits abgearbeitet wurden. Das Zeichen * vor dem Methodennamen kennzeichnet eine Wiederholung der Methode. Die Bedingung für die Wiederholung können Sie nach dem Zeichen * angeben. |
Beispiel
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 gestartet. Das Objekt aPlatz ruft die Methode kaufen des Bestellung-Objekts auf und übergibt eine Referenz 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“
Sequenzdiagramme vs. Kommunikationsdiagramme
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 Kommunikationsdiagrammen 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 Kommunikationsdiagramm 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!
Interaktionsübersichtsdiagramm(Interaction Overview Diagram)
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 Sequenzdiagramm 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
Komponentendiagramm (Component 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 Komponente Component1 kommuniziert über die von der Komponente Component2 angebotene Schnittstelle Interface1 und verwendet deren Funktionalität.
Symbole
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 Aufgaben 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 Elemente 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 Komponente zeigen, wenn nicht über die Schnittstelle zugegriffen wird. |
Beispiel
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 Abbau 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 Datentransfer eine Transaktion über die Schnittstelle der Transfersteuerungskomponente gestartet. Die Komponente 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 Verbindungskomponente in die Datenbank geschrieben und die neuen Daten werden über die Transfersteuerungskomponente bestätigt, woraufhin die gestartete Transaktion beendet wird.
Verteilungsdiagramm (Deployment Diagram)
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 Quader 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. Verteilungsdiagramme zeigen, welche Komponenten und Objekte auf welchen Knoten (Computer, Prozesse) laufen, d. h., wie diese konfiguriert sind und welche Kommunikationsbeziehungen bestehen.
Symbole
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 Anwendung als Knoteninstanz modelliert. Zur Unterscheidung mit dem Knotensymbol wird die Beschriftung im Quader unterstrichen. Dieses Symbol wird in das Knotensymbol eingefü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 Komponentensymbol 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. |
Beispiel
Bei einem Ticketsystem für Lichtspieltheater kann aus verschiedenen Anwendungen heraus auf die Ticketdaten 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 installiert. 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
Zeitdiagramm (Timing Diagram)
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
Kompositionsstrukturdiagramm (Composite Structure Diagram)
Die interne Struktur einer Klasse kann mit dem Kompositionsstrukturdiagramm 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
Objektdiagramm (Object Diagram)
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