Archiv für den Monat: September 2011

Sequenzdiagramme und Frames – Bedingungen und Iterationen

UML2 stellt das Konstrukt „Frames“ bereit, um Variationen im Kontrollfluss zu modellieren. Ein Frame besteht aus einem Operator und einer „Guard condition“. Hier einige Beispiele für Operatoren:

  • opt: Das Fragment innerhalb des Frames wird ausgeführt, wenn die guard condition erfüllt wird ( entspricht einem „if“)
  • alt: Der Frame beinhaltet mehrere Alternativen, von denen eine ausgeführt wird (verschachtelte „ifs“ order „if-else“)
  • region: Kritischer Abschnitt, der zu jedem Zeitpunkt nur von einem Thread ausgeführt werden kann („synchronized“)
  • par: Die Fragmente des Frames werden parallel ausgeführt
  • loop: Ausführung des Fragments, solange die guard condition erfüllt ist („while“)
  • ref: Aufruf eines anderen Interaktionsdiagramms

Frames können beliebig geschachtelt werden, und erlauben somit eine detaillierte Beschreibung von Interaktionen. Hier ist es dem Modellierer überlassen, die richtige Abstraktionsebene zu wählen.
Das folgende Bild zeigt eine Verschachtelung von Frames, als Beispiel soll eine Person über ihre Adressen iterieren und alle ShippingAddresses als Value-Objects zurückgeben. Die „loop“ iteriert über alle Addressobjekte der Person, der innere Frame arbeitet auf der von der loop selektierten Addresse, und führt das in dem Frame beschriebene Fragment aus, wenn die Adresse vom Typ „ShippingAddress“ ist.

frames

GRASP Creator

Das GRASP Creator-Pattern gibt Antworten auf die Frage „Wer ist zuständig für die Erzeugung einer neuen Instanz einer bestimmten Klasse?“. Die Lösung soll folgende Eigenschaften besitzen:
– Lose Kopplung
– gute Verständlichkeit
– Kapselung
– Wiederverwendbarkeit

Das Creator-Pattern stellt einige Kriterien auf, die eine gute Lösung charakterisieren (auch hier darf man das Pattern nicht isoliert anwenden, sondern muß auch die anderen GRASP-Pattern berücksichtigen). Gegeben die Klassen A und B. A soll Instanzen von B erzeugen, wenn:
– A B enthält (Komposition oder Aggregation)
– A B verwaltet
– A B sehr eng benutzt
– A alle Informationen zur Erzeugung von B besitzt (Information Expert)
Je mehr dieser Kriterien zutreffen, desto deutlicher der Hinweis, das A Instanzen von B erzeugen soll.

Damit beantwortet das Creator-Pattern meiner Meinung nach auch folgende Frage (die zu Glaubenskriegen führen kann):
Wenn die Klasse A Instanzen von B erzeugt, und B eine obligatorische Kompositionsbeziehung zu C hat:

GRASP_creator
Eine Instanz von B muss immer eine Instanz von C enthalten, dies wird über den Konstruktor von B sichergestellt. Wenn A nun eine Instanz von B erzeugt, übergibt es dann als Konstruktor-Argument eine Instanz von C, oder aber alle einzelnen Informationen, die B zur Erzeugung von C benötigt?

Die Kriterien des Creator-Pattern liefern den Hinweis: Während die erste Lösung (A übergibt eine Instanz von C an den Konstuktor von B) lediglich den Punkt „besitzt alle Informationen, um C zu erzeugen“ erfüllt, deckt die andere Lösung alle Kriterien ab, und unterstützt somit die am Anfang dieses Texts genannten Eigenschaften der Lösung besser.