Konzept: Strukturierte Klasse
Eine strukturierte Klasse ist eine Klasse, die sich aus Teilen mit einer expliziten "verschachtelten" Notation zusammensetzt und zur Modellierung von Containerhierarchien, d. h. Klassen, die aus sich aus "Teilen" zusammensetzen, verwendet wird.
Beziehungen
Zugehörige Elemente
Hauptbeschreibung

Definition

In UML ([UML04]) ist eine Klasse ein Subtyp von EncapsulatedClassifier und der Metaklasse Class, die die Eigenschaften von Class und zusätzlich die Möglichkeit hat, eine interne Struktur und Ports zu besitzen. Auch eine Komponente ist in UML als Subtyp von Class definiert. Deshalb werden im RUP-Kontext Komponenten und Klassen als strukturierte Klassen bezeichnet.

Teil

Eine Instanz einer strukturierten Klasse enthält ein Objekt oder eine Gruppe von Objekten für jedes Teil. Diese Instanzen werden gelöscht, wenn die enthaltende strukturierte Klasseninstanz gelöscht wird.

Das folgende Beispiel zeigt zwei mögliche Sichten der Klasse Auto:

In der Abbildung (a) hat Auto eine Kompositionsassoziation mit dem Rollennamen Heck zu einer Klasse Rad und eine Kompositionsassoziation mit dem Rollennamen e zu einer Klasse Motor. Jede Instanz der Klasse Motor kann mit einer beliebigen Anzahl von Instanzen der Klasse Rad verbunden sein.

Abbildung (b) zeigt dasselbe und spezifiziert darüber hinaus Folgendes:

  • Heck und e gehören zur internen Struktur der Klasse Auto. Damit können Details angegeben werden, die nur für Instanzen der Klassen Rad und Motor im Kontext der Klasse Auto, aber nicht für Räder und Motoren im Allgemeinen gelten.

  • Im Kontext der Klasse Auto kann die Instanz, die die Rolle e einnimmt, nur mit zwei Instanzen verbunden sein, die die Rolle Heck innehaben. Außerdem können die Instanzen, die die Rollen e und Heck haben, nur verbunden werden, wenn sie Rollen derselben Instanz der Klasse Auto sind.

  • Anders ausgedrückt, es gelten zusätzliche Einschränkungen für die Instanzen der Klassen Rad und Motor, wenn sie die entsprechenden Rollen in einer Instanz der Klasse Auto spielen. Diese Einschränkungen gelten nicht für Instanzen der Klassen Rad und Motor im Allgemeinen. Andere Räder und Motoren können, wie in Abbildung (a) angegeben, beliebig verbunden werden.

Im Begleittext beschriebene Abbildung

Beispiel: Teile mit Rollen in einer strukturierten Klasse

Konnektor

Ein Konnektor ist eine Beziehungsinstanz zwischen zwei Teilen in einer strukturierten Klasse. Er ist eine Verbindung, die eine Kommunikation ermöglicht. Konnektoren können durch gewöhnlich Assoziationen oder durch transiente Beziehungen, wie z. B. Prozedurparameter, Variablen, globale Werte oder andere Mechanismen implementiert werden.

Die interne "Verkabelung" einer strukturierten Klasse wird mit Assemblierungskonnektoren und Delegierungskonnektoren angegeben:

  • In der Implementierung einer strukturierten Klasse verbinden Assemblierungskonnektoren Ports unterschiedlicher Teile. Eine Nachricht, die von einem Port einer strukturierten Klasse gesendet wird, wird an einem verbundenen Port einer anderen strukturierten Klasse empfangen. Mehrere Teile können durch ihre Ports miteinander verbunden werden. Ein Teil muss nichts von den anderen Teilen wissen, abgesehen davon, dass sie existieren, und die Einschränkungen an verbundenen Ports erfüllen. Die Kommunikation zwischen strukturierten Klassen wird durch ihre Ports modelliert.


  • Ein Delegierungskonnektor verbindet einen externen Port einer strukturierten Klasse mit einem Port eines seiner internen Teile. Eine vom externen Port empfangene Nachricht wird an den Port des internen Teils übergeben. Eine vom internen Port gesendete Nachricht wird an den externen Port und anschließend an die mit diesem verbundene strukturierte Klasse übergeben.

Port

Ein Port ist ein strukturelles Feature einer strukturierten Klasse. Die Kapselung kann erhöht werden, indem eingehende Kommunikation für die strukturierte Klasse über Ports geleitet wird, die deklarierten Schnittstellen entsprechen. Dies präzisiert die Spezifikation und die gegenseitige Verbindungen für diese strukturierte Klasse noch weiter.

Die erforderlichen und bereitgestellten Schnittstellen eines Port definieren alle erforderlichen Informationen für die Interaktionen über diesen Interaktions-Port. Wenn alle Interaktionen einer strukturierten Klasse mit ihrer Umgebung über Ports erfolgen, sind die Interna der strukturierten Klasse vollständig von der Umgebung isoliert. Damit kann eine solche strukturierte Klasse in jedem Kontext verwendet werden, der den Einschränkungen der Ports entspricht.

Es gibt keine Prämisse für die Implementierung eines Port. Der Port kann als explizites Objekt implementiert werden oder ein rein virtuelles Konzept sein, das in der Implementierung nicht explizit auftaucht.

Im Folgenden finden Sie verschiedene Beispiele für Ports:

Beispiel 1

Im Begleittext beschriebene Abbildung

Port eines Motors, der von einem Auto und einem Boot verwendet wird

Die Abbildung oben zeigt eine Klasse Motor mit einem Port p und zwei Schnittstellen:

  • Eine bereitgestellte Schnittstelle Triebwerk, die die Services angibt, die Motor an diesem Port anbietet (d. h. die Operationen und empfangenen Nachrichten, die für die Kommunikation an diesem Port zugänglich sind).
  • Eine erforderliche Schnittstelle Antriebskraft, die die Services angibt, die der Motor von seiner Umgebung erwartet.

An Port p ist die Klasse Motor vollständig gekapselt. Sie kann angegeben werden, ohne die Umgebung zu kennen, in die der Motor integriert wird. Solange die Umgebung die Einschränkungen der bereitgestellten und erforderlichen Schnittstellen des Motors erfüllt, funktioniert der Motor zuverlässig.

Zur Verdeutlichung werden die beiden Anwendungen der Klasse Motor im Beispiel gezeigt:

  • Die Klasse Auto verbindet den Port p des Motors über die Achse mit mehreren Rädern.
  • Die Klasse Boot verbindet den Port p des Motors über die Welle mit einem Propeller.

Solange die Interaktion zwischen dem Motor und dem Teil, das mit seinem Port p verbunden ist, die Einschränkungen der bereitgestellten und erforderlichen Schnittstellen erfüllt, funktioniert der Motor wie angegeben, egal ob der Motor zu einem Auto oder einem Boot gehört.

Selbst wenn Motor weitere deklarierte Ports hat, z. B. einen Port f für Kraftstoffverbrauch, würden die Räder eines Autos und der Propeller eines Boots trotzdem über den Port p auf den Motor zugreifen. Der Port f wäre für einen Kraftstoffmesser von Interesse, unabhängig davon, welche Art von Kraftstoff verwendet wird und welche Art von Kraftstoffmesser Autos und Boote haben.

Beispiel 2

Dieses Port-Beispiel basiert auf der API Java Logging ([JAV03]), einem Paket, das unter anderem die folgenden Klassen und Schnittstellen der Kernprotokollierungseinrichtungen der Java-2-Plattform bereitstellt:

  • Logger: Die Hauptentität, an die Anwendungen Protokollierungsaufrufe absetzen. Sie kann verwendet werden, um Nachrichten für ein bestimmtes System oder eine bestimmte Anwendungskomponente zu protokollieren.
  • Level: Eine Anleitung zur Bedeutung und Dringlichkeit einer Protokollnachricht.
  • Filter. Ermöglicht über die von den Protokollstufen unterstützte Steuerung hinweg eine differenzierte Steuerung der protokollierten Informationen.
  • Handler: Verwendet die Nachrichten aus einem Logger und exportiert sie an andere Zieladressen (Hauptspeicher, Ausgabedatenströme, Konsolen, Dateien und Sockets).
  • Formatter: Bietet Unterstützung für die Formatierung von Protokollsätzen.

Diese Klassen und Schnittstellen sind an zwei wichtigen Arten von Kollaborationen beteiligt. Einige Klassen und Schnittstellen werden verwendet, um in die Protokolldatei zu schreiben, während andere für die Verwaltung des Protokolls verwendet werden. Die folgende Abbildung zeigt zwei unterschiedliche Kollaborationen von Clients und Administratoren mit dem Protokoll, modelliert als UML-Kollaborationen:

  • Schreibende Kollaboration: Hier stellt die Rolle LogClient eine Verbindung zur Rolle LogWriter her, um in das Protokoll zu schreiben.
  • Administrationskollaboration: Hier stellt die Rolle LogAdministrator eine Verbindung zur Rolle LogController her, um auf die Einstellungen des Protokolls und Änderungsprotokolls zuzugreifen.

Im Begleittext beschriebene Abbildung

Unterschiedliche Kollaborationen von Clients und Administratoren mit dem Protokoll

Eine mögliche UML-2.0-Darstellung für die Modellierung der Protokollservices und der zugehörigen Kollaborationen ist die Verwendung einer Komponente mit Ports und deklarierten Schnittstellen wie in der folgenden Abbildung:

Im Begleittext beschriebene Abbildung

API-Paket Java Logging implementiert als Komponente mit API bereitgestellten Schnittstellen, die in Ports gruppiert sind

In der Spezifikation der API Java Logging werden verschiedene Protokollservices als Klassen und andere als Schnittstellen implementiert. In diesem Beispiel wird jeder dieser Services als bereitgestellte Schnittstelle implementiert, was durch Teile innerhalb der Komponente realisiert werden könnte. Die beiden unterschiedlichen Arten von Verhalten in Bezug auf die zuvor genannten Kollaborationen (Schreibende Kollaboration und Administrationskollaboration) könnten von Schnittstellen dargestellt werden, die logisch in Ports gruppiert werden. Dies bedeutet im Einzelnen:

  • Die Schnittstellen Logger und Level werden zum Port LogWriter gruppiert. Diese Schnittstellen werden von Protokollclients aufgerufen, um in das Protokoll zu schreiben.
  • Die Schnittstellen Handler, Filter und Formatter werden zum Port LogController gruppiert. Diese Schnittstellen werden von Protokolladministratoren aufgerufen, um auf die Einstellungen des Protokolls und Änderungsprotokolls zuzugreifen.

Mit dieser Modellierungsalternative können Aspekte getrennt werden, durch logische Gruppierung von Schnittstellen in unterschiedlichen Ports. Dies bringt zusätzliche Präzision für die Komponentenspezifikation und die Verbindung zur externen Welt.

Modellierung

Während des Designs können Klassen und Komponenten in verbundene Teile zerlegt werden, die dann noch weiter zerlegt werden können.

Ein zusammengesetztes Strukturdiagramm kann verwendet werden, um die Dekomposition einer strukturierten Klasse zu zeigen. Die folgende Abbildung zeigt beispielsweise ein zusammengesetztes Strukturdiagramm für die Kasse im Ticketsystem. Diese Klasse wird in drei Teile zerlegt:

  • Schnittstelle für Ticketverkauf
  • Veranstaltungskalender, der die Veranstaltungen nach Datum und anderen Kriterien sortiert abruft.
  • Verschiedene Datenbanken, die die Daten zu den Veranstaltungen und den Tickets enthalten.

Jedes Teil interagiert über eine klar definierte Schnittstelle, die in den Ports definiert ist. Die Kasse interagiert über einen Port mit der Außenwelt. Nachrichten an diesem Port werden an die Klasse Ticketverkauf verteilt, aber die interne Struktur der Klasse Kasse bleibt vor den Clients verborgen.

Im Begleittext beschriebene Abbildung

Beispiel: Zusammengesetztes Strukturdiagramm für ein Ticketsystem

UML-1.x-Darstellung

Eine strukturierte Klasse ist ein neues Konzept in UML 2.0.

Ein Großteil dessen, was RUP als Kapsel definiert, kann mit einer strukturierten Klasse dargestellt werden. Weitere Informationen hierzu finden Sie unter Arbeitsergebnis: Kapsel und Richtlinie für Arbeitsergebnis: Kapsel).

Wenn Ihr Tool nur UML 1.5 unterstützt, können Sie eine alternative Darstellung verwenden, die ebenfalls unter Arbeitsergebnis: Kapsel und Richtlinie für Arbeitsergebnis: Kapsel beschrieben ist.

Lesen Sie auch den Artikel Unterschiede zwischen UML 1.x und UML 2.0.