<< zurück

MBSE Home

weiter >>

4.2 Bedeutung eines Objektdiagramms

Um die methodische Verwendbarkeit von Objektdiagrammen richtig einzuschätzen, ist zunächst der exemplarische Charakter und die Beziehung zwischen den prototypischen Objekten des Objektdiagramms und den echten Objekten des Systems zu verstehen.

4.2.1 Unvollständigkeit und Exemplarizität

Wie bereits Klassendiagramme sind auch Objektdiagramme im Allgemeinen unvollständig. Aufgrund der dynamischen Erzeugung und Vernichtung von Objekten variiert die Anzahl der Objekte in einem System ständig. Im Gegensatz zur Anzahl der Klassen ist sie sogar unbeschränkt.²

Ein Objektdiagramm modelliert daher einen Systemausschnitt. Dieser Ausschnitt hat eine zeitlich limitierte Gültigkeit, die im Extremfall auf einen einzigen Zeitpunkt, einen Snapshot, zum Beispiel zwischen zwei Methodenaufrufen, reduziert ist. Ein Objektdiagramm illustriert diese Situation und enthält alle dafür notwendigen Daten, ohne eine Überladung zu bewirken. Es liegt im Ermessen des Modellierers, die richtige Abstraktionsstufe zu finden. Dabei können Attributwerte oder -typen, Links, Merkmale und ganze Objekte ausgelassen werden.

4.2.2 Prototypische Objekte

Die mit Objektdiagrammen modellierten Strukturen erhalten einen prototypischen, musterartigen Charakter. Sie zeigen exemplarisch eine Situation, ohne dass diese Situation notwendigerweise normativen Charakter annimmt. Deshalb werden in Beschreibungen von Entwurfs- und Architekturmustern [GHJV94, BMR⁺96, FPR01] gerne Objektdiagramme verwendet.³

Objektdiagramme können jedoch so mit konkreten Werten angegeben werden, dass aus dem Kontext ableitbar ist, dass das Objektdiagramm maximal an einer Stelle im System auftreten kann. Beispielsweise enthalten die Auktionsobjekte der vorangegangenen Abbildungen immer einen expliziten Wert für ihren Identifikator auctionIdent. Demgegenüber kann das in Abbildung 4.15 angegebene Objektdiagramm auf viele der Auktionen angewandt werden. Tatsächlich stellt dieses Diagramm ein Muster für viele Einkaufsauktionen dar, da konkrete Werte an den variierenden Stellen ausgelassen wurden.

Die im Objektdiagramm nicht spezifizierten Attribute können im System mit beliebigen Werten belegt sein. Um den möglichen Wertebereich zu präzisieren, können OCL-Bedingungen die freien Attribute genauer festlegen. So kann bestimmt werden, dass in diesem Muster der Minimalwert unter dem Maximalwert liegt und die Auktion zwei bis drei Stunden dauert.

Diese Bedingung ist im Kontext des Objektdiagramms aus Abbildung 4.15 zu sehen, weshalb nicht nur ein Objekt a des Typs Auction, sondern auch die Objekte min, bidPol, start, etc. namentlich zur Verfügung stehen und zum Beispiel min identisch zu a.bidPol.min ist.

Die dabei vorgenommene Integration von OCL-Bedingungen in Objektdiagramme und die Kombination von Objektdiagrammen unter Benutzung der OCL-Logik wird in Abschnitt 4.3 genauer besprochen.

Durch die Integration mit der OCL-Logik in Abschnitt 4.3 entsteht eine mächtige Notation im Einsatz bei der Modellierung und beim Test von Systemen. Diese erlaubt auch, zu beschreiben, unter welchen Bedingungen die durch Objektdiagramme beschriebenen Situationen eintreten, ob sie Allgemeingültigkeit haben, ob sie einmaligen oder musterartigen Charakter besitzen oder wie lange sie gültig sind.

4.2.3 Instanz versus Modellinstanz

Ein prototypisches Objekt eines Objektdiagramms ist ein Element eines Modells und kein Element des Produktionssystems. Zwischen dem prototypischen Objekt und seiner Klasse existiert jedoch eine Art Instanzbeziehung, die der Instanzbeziehung zwischen einer Klasse und den echten Objekten des Systems ähnlich ist. Für eine Klärung dieser Situation dient Abbildung 4.16, die zwischen einer Systemebene und einer Modellebene unterscheidet. Die Modellebene ist weiter unterteilt in Schichten, zwischen denen eine Modell-Instanziierung stattfindet. Ein Klassendiagramm ist dabei eine Schicht höher als das Objektdiagramm angesiedelt. Ein prototypisches Objekt ist daher eine Modellinstanz der ihr zugeordneten Klasse.

Diese Dreiecksbeziehung lässt sich noch erweitern, wenn die Manifestation einer Klasse zur Laufzeit als eigenständige Einheit akzeptiert wird. In Smalltalk sind Klassen zur Laufzeit sogar eigenständige Objekte, die beliebig manipuliert werden können. Auch Java repräsentiert Klassen als Objekte, allerdings mit nur eingeschränkten Manipulationsmöglichkeiten. Andere Programmiersprachen, wie zum Beispiel C++, haben ebenfalls Strukturen, die der Darstellung einer Klasse entsprechen. Diese sind aber normalerweise nicht durch den Programmcode zugreifbar. Die (zugängliche oder unzugängliche) Manifestation einer Klasse zur Laufzeit wird als Klassencode bezeichnet. Es entsteht die in Abbildung 4.17 illustrierte Beziehung.

Im System gibt es genau einen Klassencode für jede Klasse. Demgegenüber kann es im Modell mehrere unterschiedliche Darstellungen derselben Klasse geben. In jedem Klassendiagramm kann eine eigene Darstellung mit einem etwas anderen Focus angegeben sein und jeweils einen Teil des Klassencodes beschreiben.

Auch die Anzahl der prototypischen Objekte einer Klasse ist im Modell unbeschränkt. Es treten häufig sogar mehrere Objekte derselben Klasse innerhalb eines Objektdiagramms auf. Jedes dieser prototypischen Objekte muss zu jeder der Klassendarstellungen im Modell konform sein.

Die Anzahl der echten Objekte ist ebenfalls unbeschränkt. Deren Struktur und Funktionalität sind aber durch den Klassencode festgelegt und daher ebenfalls zu allen Klassendarstellungen des Modells konform. Da prototypische Objekte zusätzliche Information in Form konkreter Werte und Links enthalten, können echte Objekte zeitweise zu prototypischen Objekten konform sein. Im Prinzip wäre es auch möglich, dass dasselbe echte Objekt die Rollen zweier prototypischer Objekte in demselben Objektdiagramm übernimmt. Dies wird nur durch das Gleichbesetzungstabu verhindert.

Die Unterscheidung zwischen Objekten, prototypischen Objekten, Klassen und Klassencode mag für den praktischen Einsatz relativ künstlich wirken, führt jedoch zu einer wesentlich klareren und vor allem einfacheren Beschreibung, als es zum Beispiel die Metamodellierung mit ihrem vierschichtigen Modell kann. Dort sind Modell- und Systemebene vermischt und damit ist eine klare Trennung zwischen Syntax und Semantik erheblich erschwert. Im praktischen Einsatz können allerdings diese semantischen Feinheiten oft vernachlässigt werden, wenn sich die Nutzer einer Sprache diese Unterschiede bei Bedarf in Erinnerung rufen können.

Bernhard Rumpe. Agile Modellierung mit UML. Springer 2012

<< zurück

MBSE Home

weiter >>