<< zurück

MBSE Home

weiter >>

4.4 Methodische Verwendung von Objektdiagrammen

Der letzte Abschnitt hat die Grundlagen definiert, Objektdiagramme in verschiedenen Situationen einzusetzen und in Kombination mit der OCL Bedingungen zu spezifizieren. In diesem Abschnitt werden nun Standardsituationen anhand von Beispielen skizziert, um so einen besseren Einblick in die Fähigkeiten und den methodischen Einsatz von Objektdiagrammen zu illustrieren.

Die Beschreibungsmächtigkeit der aus OCL und Objektdiagrammen integrierten Notation ist dieselbe wie bei der OCL. Das liegt daran, dass jedes Objektdiagramm in eine, wenn auch relativ unleserliche OCL-Formel übersetzt werden kann. Entsprechend bietet die entstandene Integration besseren Komfort bei der kompakten und anschaulichen Beschreibung von Situationen. Umgekehrt hat die Beschreibungsmächtigkeit der Objektdiagramme zugenommen, weil zum Beispiel Alternativen, Kombinationen oder Verallgemeinerungen durch Nutzung abstrakter Werte möglich geworden sind.

Im vorangegangenen Abschnitt wurde gezeigt, wie beide Notationen, Objektdiagramme und OCL-Ausdrücke, in die jeweils andere Notation integriert werden können. Das Hinzufügen von OCL-Bedingungen in ein Objektdiagramm wurde zum Beispiel in Abbildung 4.22 demonstriert. Umgekehrt ist es möglich, Objektdiagramme als Kurzformen für Aussagen mittels OD.Name einzubinden. Dabei kann auf die freien Namen des Objektdiagramms, also Objektnamen und Variablen für abstrakte Werte, in der OCL-Bedingung Bezug genommen werden. Diese Bezüge und die Einbettung in die OCL-Logik erlauben eine flexible Verwendung von Objektdiagrammen. Dies wird für unterschiedliche methodische Anwendungen anhand von Beispielen diskutiert.

So können mithilfe der Operationen der Aussagenlogik &&, || und ! strukturelle Kombinationen von Objektdiagrammen, Alternativen oder unerwünschte Situationen modelliert werden.

4.4.1 Komposition von Objektdiagrammen

Die Kombination mehrerer Objektdiagramme zur Beschreibung einer größeren Objektstruktur kann mit dem &&-Operator vorgenommen werden. Die „Klebestellen“ der Objektdiagramme sind die Objekte mit gemeinsamen Namen. Dadurch kann eine große Objektstruktur in überschaubare Teile aufgebrochen und durch geeignete Objektdiagramme illustriert werden. Abbildung 4.25 zeigt mehrere Einzeldiagramme, die mit einer Konjunktion verbunden werden.

Die entstehende OCL-Bedingung Strom kann als komponiertes Objektdiagramm verstanden werden. Das benannte Auktionsobjekt strom dient als Verbindungselement, da es in allen Objektdiagrammen vorkommt.

Eine komplexere Zerlegung eines Objektdiagramms mit 100 ähnlich aussehenden Personen wurde bereits mit OCL-Aussage Test32 in Abbildung 4.24 gezeigt. Dieses Beispiel demonstriert, wie sich durch Kombination von Quantoren der OCL und Parametrisierung von Objektdiagrammen aus einfachen Darstellungen komplexe Datenstrukturen modellieren lassen. Dadurch lassen sich komplexere Objektstrukturen in modulare Teile zerlegen und diese Teile in unterschiedlichen Kombinationen wiederverwenden. Für den Aufbau von Tests ist es besonders sinnvoll, Bibliotheken von Objektdiagrammen zu erstellen, mit denen sich leicht Ausgangssituationen für Tests erstellen lassen.

4.4.2 Negation

Neben der Konjunktion lassen sich auch andere boolesche Operatoren nutzen. So können unerwünschte Situationen mit der Negation dargestellt werden. Allerdings ist die Negation eines Objektdiagramms relativ schwach, denn sie sagt nur aus, dass das Objektdiagramm nicht in genau dieser Form auftritt. Also nur ein Detail muss anders sein. Abbildung 4.26 zeigt, wie unter Nutzung eines Objektdiagramms gefordert wird, dass mit Ausnahme der ersten Nachricht (dem „Willkommen“) jede Nachricht maximal zu einer Auktion gehört.

Dabei wird Bezug zu den lokalen Variablen n und m des Objektdiagramms genommen, während die Objekte alle anonym bleiben. Wie bei Abbildung 4.21 diskutiert, sind anonyme Objekte intern als existenzquantifiziert zu betrachten. Die Aussage TwoAuctions ist in der OCL äquivalent zu

4.4.3 Alternative Objektstrukturen

Zur Darstellung von Alternativen ist die Disjunktion geeignet. Da in unserem Anwendungsbeispiel Auktionen in zwei primäre Arten zerfallen, die durch eine steigende beziehungsweise fallende Gebotskurve charakterisiert werden, werden zwei Klassen angeboten, die die Regeln für je eine Auktionsform realisieren. Jede Auktion besitzt genau eine dieser beiden Policy-Klassen. Abbildung 4.27 modelliert diese Alternative.

4.4.4 Objektdiagramme in einer Methodenspezifikation

Eine Methodenspezifikation stellt einen Kontrakt zwischen aufrufender und aufgerufener Methode dar: Stellt der Aufrufer eine der Vorbedingung genügende Umgebung bereit, so stellt die aufrufende Methode sicher, dass nach dem Aufruf die Nachbedingung erfüllt ist. So lässt sich zum Beispiel die in Abschnitt 3.4.3 definierte Methode changeCompany alternativ in Abbildung 4.28 beschreiben, wobei in dieser Vorbedingung angenommen wird, das neue Unternehmen sei bereits im System präsent. Gegenüber der Beschreibung in Abschnitt 3.4.3 hat hier das benutzte Objektdiagramm keine illustrative Rolle, sondern ist ein wesentlicher Bestandteil der Spezifikation.

Ein Objektdiagramm beschreibt also eine Situation im Ablauf eines Softwaresystems und kann damit sowohl als Charakterisierung der Vor- als auch der Nachbedingung eingesetzt werden. Ähnlich wie bei den Regeln der Graphgrammatiken [Roz99, EEKR99] sind zwei getrennte, aber in vielen Details übereinstimmende Diagramme notwendig. Graphgrammatiken erlauben diese Charakterisierung oft innerhalb eines Diagramms, indem sie zusätzliche graphische Konzepte zur Darstellung der Streichung von Objekten oder Links beziehungsweise die Erzeugung neuer Objekte und Links bieten. Objektdiagramme sind in der vorgeschlagenen Form weniger beschreibungsmächtig, aber auch weniger überladen. Für bestimmte Einsatzformen eignen sich dennoch Graphgrammatiken besser und können als interessante Erweiterung für den hier vorgestellten Einsatz von Objektdiagrammen zur Spezifikation von Methoden dienen [EH00, EHHS00].

Wird für die Vor- und Nachbedingung jeweils ein Objektdiagramm verwendet, so ist es nicht notwendig, alle Objekte der Vorbedingung in der Nachbedingung zu wiederholen. Dadurch wird die Nachbedingung deutlich schlanker. Im Objektdiagramm 4.28(b) hätte zum Beispiel das alte Company-Objekt weggelassen werden können. Bei Graphgrammatiken hätte dies bedeutet, dass das Company-Objekt zu löschen wäre.

Dieses Beispiel zeigt auch die verwendete Technik zur Bindung gemeinsamer Variablen in Objektdiagrammen. Während das Objekt this durch die Definition des Methodenkontexts eingeführt wird und deshalb für Vor- und Nachbedingung dasselbe ist, kann eine Identifizierung der mit c2 benannten Objekte beider Objektdiagramme durch die Benutzung des let-Konstrukts erreicht werden. Da dies für die beiden anonymen Objekte aus den Objektdiagrammen BeforeChange und AfterChange unterblieben ist, gibt es keine Bindung zwischen beiden Objekten, obwohl eine solche durch die Position im jeweiligen Objektdiagramm suggeriert wird. Während das anonyme Objekt in (a) noch durch den Link eindeutig identifizierbar ist, kann das anonyme Objekt in (b) ein beliebiges sein (mit Ausnahme c2).

Durch dieses Beispiel wird ein gewisses Defizit des Spezifikationsstils mit Vor- und Nachbedingungen sichtbar: Auf existenzquantifizierte Objekte der Vorbedingung kann in der Nachbedingung nicht zugegriffen werden. Dies wird bei Benutzung von Objektdiagrammen mit anonymen Objekten besonders deutlich. Ein derartiges Objekt muss deshalb wie das Objekt c2 explizit benannt und mit dem let-Konstrukt außerhalb beider Bedingungen festgelegt werden. Dies ist aber nur möglich, wenn dieses Objekt im let-Konstrukt eindeutig charakterisiert werden kann. Ansonsten muss gegebenenfalls die Charakterisierung in Vor- und Nachbedingung doppelt angegeben werden.

Abbildung 4.29 zeigt eine Abwandlung aus Abbildung 4.28, in der die anonymen Objekte mit c1 benannt und damit identifiziert werden. Dadurch wird der Zugriff auf die Anzahl der Mitarbeiter des Unternehmens möglich.

4.4.5 Objekterzeugung

In den Abbildungen 4.28 und 4.29 wurde von der Methode changeCompany das Verhalten für den Fall des existenten Company-Objekts c2 spezifiziert. Analog zum Beispiel in Abschnitt 3.4.3 wird in Abbildung 4.30 die Erzeugung eines neuen Company-Objekts modelliert. Dabei wird die Erzeugung des Objekts mit der OCL modelliert und nicht in den Objektdiagrammen ausgedrückt.

4.4.6 Gültigkeit von Objektdiagrammen

Ein Objektdiagramm kann eine exemplarische Situation beschreiben, kann aber auch wie oben gezeigt als Invariante eingesetzt werden. Ist jedoch die Struktur eines Objektdiagramms nicht immer gültig, so kann die Invariante durch eine OCL-Bedingung eingeschränkt werden. Typische „Gültigkeitsbereiche“ für Objektdiagramme sind:

1. immer (Invariante),
2. zu Beginn eines Methodenaufrufs (Vorbedingung),
3. nach einem Methodenaufruf (Nachbedingung),
4. wenn eine Variable (meist eine „Statusvariable“) einen bestimmten Zustand hat oder
5. zu Beginn der Existenz eines Objekts (initiale Struktur).

Die Verwendung von Objektdiagrammen in Invarianten, Vor- und Nachbedingungen wurde bereits ausreichend diskutiert. Die Einschränkung der Gültigkeit eines Objektdiagramms durch eine OCL-Bedingung wird in Abbildung 4.31 gezeigt. Dabei wird auf den Status des Applets Bezug genommen, das vom Anwender benutzt wird, um an Auktionen teilzunehmen. Das Applet hat mehrere Zustände, wobei einer der Initialzustand AppStatus.INITIAL ist.

Das Applet ist immer im Initialzustand, wenn der Anwender nicht angemeldet ist. In diesem Zustand kann der Anwender bereits allgemeine Einstellungen wie Sprache und Signale über das Optionspanel anpassen. Einige andere Panels sind jedoch auf null gesetzt. Entsprechend sind ihm nur die beiden in Abbildung D.3 links oben und rechts unten dargestellten Panel zugänglich.

Für jeden weiteren Zustand des Applets kann nun ein weiteres Objektdiagramm entworfen werden, das die Struktur dieses Zustands zeigt. Manche Zustände besitzen auch dieselbe Struktur oder zumindest eine deutliche Überlappung und können deshalb Teildiagramme gemeinsam nutzen.

4.4.7 Initialisierung von Objektstrukturen

Eine Reihe von Objekten triggern bei ihrer eigenen Erzeugung die Erzeugung weiterer Objekte und kombinieren diese zu einer komplexen Objektstruktur. Abbildung 4.31 zeigt einen Ausschnitt der Struktur, die im Initialzustand von Objekten der Klasse WebBidding existiert. Diese Struktur wird dementsprechend bereits bei der Erzeugung von WebBidding-Objekten erstellt.

Die Erzeugung dieser Objekte wird durch einen Konstruktor vorgenommen. Deshalb kann die initiale Objektstruktur in der Nachbedingung des Konstruktors beschrieben werden. Bei Applets werden allerdings die Erzeugung des Applet-Objekts und die Initialisierung getrennt vorgenommen. Deshalb ist der Konstruktor im Wesentlichen eine leere Hülle und eine eigenständige Methode init nimmt die Initialisierung vor. Abbildung 4.32 beschreibt einen Ausschnitt des Ergebnisses der Initialisierung mit einigen Details, bei dem auch die Belegung von Attributen charakterisiert wird. Dazu werden, wie für Applets üblich, Parameter mit der Funktion getParameter bestimmt, die als Query wirkt und deshalb hier eingesetzt werden kann.

Das Objektdiagramm WBinit ist so gestaltet, dass jedes einzelne Attribut darin effektiv berechenbar ist und die Link-Struktur automatisiert erstellt werden kann. Attributwerte können zum Beispiel weggelassen werden, wenn im Klassendiagramm ein Initialisierungswert für das Attribut angegeben ist. In der Tat ist Codegenerierung zur Erzeugung initialer Objektstrukturen eine hilfreiche Technik bei der effizienten Realisierung von Objektsystemen. Allerdings stößt diese Vorgehensweise schnell an ihre Grenzen, wenn bei der Initialisierung auch Effekte bei bereits vorhandenen Objektstrukturen beschrieben werden sollen oder wie im Auktionsbeispiel Effekte auf der graphischen Oberfläche und dem Serversystem nicht durch eine Objektstruktur beschrieben werden können. Wird daher die Beschreibung einer Initialisierung oder Strukturveränderung mittels Objektdiagrammen gewählt, ist zu entscheiden, ob eine vollständige (und damit zur Codeerzeugung geeignete) Modellierung mit einem Objektdiagramm möglich ist oder ob ein Objektdiagramm eher illustrierende Wirkung hat. Im letzten Fall können Objekte auch unvollständig dargestellt werden und es ist möglich, abgeleitete Attribute zu verwenden. In Abbildung 4.12 wurde zum Beispiel in Objekt max ein abgeleitetes Attribut eingesetzt, das Rückschlüsse auf den Inhalt mehrerer Einzelattribute erlaubt, ohne diese direkt darzustellen.

Die Darstellung neuer Objektstrukturen ist besonders dann von Interesse, wenn diese Objekte Datenstrukturen realisieren. So kann die Erzeugung eines neuen Personenobjekts mit seinen Abhängigkeiten wie in Abbildung 4.33 dargestellt werden. Dieser Konstruktor wird verwendet, um die Personendaten anzulegen, die über ein Webformular eingegeben wurden.

Das Objektdiagramm aus Abbildung 4.33 dient als Vorlage zur Erzeugung der notwendigen Objektstrukturen, wenn sich eine neue Person einträgt. Allerdings ist dieses Objektdiagramm nur gültig, wenn das Unternehmen ebenfalls neu eingetragen wird. Dies wird durch die Vorbedingung sichergestellt. Entsprechend kann ein weiteres Diagramm erstellt werden, in dem die Situation mit einem bereits vorhandenen Company-Objekt dargestellt wird.

Bernhard Rumpe. Agile Modellierung mit UML. Springer 2012

<< zurück

MBSE Home

weiter >>