Arbeitsergebnis: Kapsel
Dieses Artefakt ist ein spezielles Designmuster, das einen gekapselten Ausführungs-Thread im System darstellt.
Beziehungen
Eingabe fürVerbindlich:
  • Ohne
Optional: Extern:
  • Ohne
Hauptbeschreibung

Kapseln stellen ein bestimmtes Muster von Klassenstruktur und Komposition dar, das sich bei der Modellierung und beim Design von Systemen bewährt hat, die einen hohen Grad von Parallelität aufweisen. Die Verwendung einer Kapsel als Kurznotation für ein bestimmtes bewährtes Designmuster macht das Design verständlicher und weniger fehleranfällig.

Eine Kapsel wird als Klasse mit dem Stereotyp <<Kapsel>> (Capsule) dargestellt. Eine Kapsel ist, wie in der folgenden Abbildung gezeigt, ein zusammengesetztes Element.

Im Begleittext beschriebenes Diagramm

Kapselkomposition

Wie zuvor beschrieben, kann eine Kapsel Ports haben und passive Klassen und/oder Unterkapseln "enthalten". Sie kann außerdem eine Zustandsmaschine haben, die das Verhalten der Kapsel vollständig beschreibt. Eine spezifische Taxonomie von Kapseln und verschiedene Verwendungsmöglichkeiten von Kapseln werden in Richtlinie: Kapsel beschrieben.

Eigenschaften
Optional
GeplantYes
Anpassung
DarstellungsoptionenUML-Darstellung: Klasse mit Stereotyp <<Kapsel>> (Capsule). Diese Darstellung basiert auf der Notation von UML 1.5. Ein Großteil dieses Konzepts kann in UML 2.0 mit dem Konzept: Strukturierte Klasse dargestellt werden. Weitere Informationen finden Sie in Unterschiede zwischen UML 1.x und UML 2.0 .

Eine Kapsel ist, wie in der folgenden Abbildung gezeigt, ein zusammengesetztes Element.

Abbildung, die ein zusammengesetztes Element zeigt

Kapselkomposition

Eine Kapsel kann Ports haben und passive Klassen und/oder Unterkapseln "enthalten". Sie kann außerdem eine Zustandsmaschine haben, die das Verhalten der Kapsel vollständig beschreibt. Eine spezifische Taxonomie von Kapseln und verschiedene Verwendungsmöglichkeiten von Kapseln werden in Richtlinie: Kapsel beschrieben.

Eigenschaften

Eine Kapsel kapselt einen Steuerungs-Thread. Eine Kapsel ist eine Abstraktion eines unabhängigen Steuerungs-Thread im System. Sie ist die primäre Parallelitätseinheit im System. Eine zusätzliche Isolation von Steuerungs-Threads kann durch die Verwendung von Betriebssystemprozessen und -Threads erreicht werden, indem Kapseln bestimmten Betriebssystemprozessen und -Threads zugeordnet werden. Nachrichten an die Kapsel gehen an einem Port ein und werden sequenziell verarbeitet. Wenn die Kapselinstanz beschäftigt ist, werden die Nachrichten in eine Warteschlange eingereiht. Kapsel setzen eine umfassende Semantik ein, die bewirkt, dass ein empfangenes Ereignis vollständig verarbeitet wird, egal wie viele andere Ereignisse eintreffen und welche Priorität diese haben.

Eine Kapsel interagiert mit ihrer Umgebung über Ports. Ein Port ist ein signalbasiertes Grenzobjekt. Er vermittelt die Interaktion der Kapsel an die Außenwelt. Ein Port implementiert eine bestimmte Schnittstelle und kann von einer bestimmten Schnittstelle abhängig sein. Eine Kapsel kann keine Operationen oder anderen öffentlich sichtbaren Teile als Ports haben, die das exklusive Interaktionsmedium mit der Außenwelt sind.

Jeder Port spielt eine bestimmte Rolle in einer Kollaboration. Die Kollaboration beschreibt, wie die Kapsel mit anderen Objekten interagiert. Um die komplexe Semantik dieser Interaktionen zu erfassen, werden Ports einem Protokoll zugeordnet, das den zulässigen Informationsfluss (Signale) zwischen verbundenen Ports der Kapseln definiert. Das Protokoll erfasst die vertraglichen Verpflichtungen, die zwischen Kapseln existieren. Da Kapseln dazu gezwungen sind, über Ports zu kommunizieren, können die internen Implementierungen der Kapsel vollständig von der Umgebung der Kapsel entkoppelt werden. Dies macht Kapseln in einem hohen Maße wiederverwendbar.

Die Funktionalität einer einfachen Kapsel wird direkt durch die Zustandsmaschine der Kapsel realisiert. Komplexere Kapseln kombinieren die Zustandsmaschine mit einem internen Netz kollaborierender Unterkapseln, die durch Konnektoren verbunden werden. Diese Unterkapseln sind eigenständige Kapseln und können selbst wieder in Unterkapseln zerlegt werden. Diese Art von Dekomposition kann bis zur erforderlichen Tiefe betrieben werden und ermöglicht die Modellierung beliebig komplexer Strukturen mit lediglich diesem Grundstock struktureller Modellierungskonstrukte. Die Zustandsmaschine (die für zusammengesetzte Kapseln optional ist), die Unterkapseln und ihr Verbindungsnetz stellen Teile der Implementierung der Kapsel dar und bleiben externen Beobachtern verborgen.

Eine Kapsel kann ein zusammengesetztes Element sein. Kapseln können sich aus anderen Kapseln und passiven Kapseln zusammensetzen. Kapseln und passive Klassen werden durch Konnektoren oder Verbindungen in einer Kollaboration verbunden. Diese Kollaboration definiert die 'Struktur' der Kapsel und wird deshalb als 'Spezifikationskollaboration' bezeichnet. Eine Kapsel kann eine Zustandsmaschine haben, die über die End-Ports der Kapsel Signale senden und empfangen kann und die gewisse Elemente der internen Struktur steuern kann. Diese Zustandsmaschine implementiert sozusagen reflektives Verhalten, d. h. Verhalten, das die Operation der Kapsel selbst steuert.

Ports 

Ports sind Objekte, die als Grenzobjekte für eine Kapselinstanz auftreten. Ports "gehören" der Kapselinstanz insofern, als sie zusammen mit ihrer Kapsel erstellt und gelöscht werden, wenn die Kapsel gelöscht wird. Jeder Port hat eine Identität und einen Zustand, die von der Identität und dem Zustand der Kapselinstanz, die ihn enthält, verschieden ist (so wie sich jedes Teil von seinem Container unterscheidet).

Obwohl Ports Grenzobjekte sind, die als Schnittstellen auftreten, werden sie UML-Schnittstellen nicht direkt zugeordnet. Eine UML-Schnittstelle hat reinen Verhaltenscharakter und ist keine Implementierungsstruktur. Ein Port hingegen enthält Struktur und Verhalten. Er ist ein zusammengesetzter Teil der Struktur der Kapsel und keine reine Vorgabe für das Verhalten der Kapsel. Er realisiert das Architekturmuster, das wir "Manifestschnittstelle" nennen könnten.

In UML wird ein Port als Klasse mit dem Stereotyp <<Port>> modelliert. Wie bereits erwähnt, wird der Typ eines Port durch die Protokollrolle definiert, die dieser Port spielt. Da Protokollrollen abstrakte Klassen sind, ist die eigentliche Klasse dieser Instanz eine Klasse, die die Protokolle implementiert, die dem Port zugeordnet ist. In UML wird die Beziehung zwischen dem Port und der Protokollrolle als Realisierungsbeziehung bezeichnet. Diese Realisierungsbeziehung wird als gestrichelte Linie mit einer ausgefüllten dreieckigen Pfeilspitze am Spezifikationsende dargestellt. Sie ist eine Form der Generalisierung, bei der das Quellenelement - der Port - nur die Verhaltensspezifikation des Ziels - die Protokollrolle - erbt, aber nicht seine Struktur.

Eine Kapsel steht mit ihren Ports in einer Kompositionsbeziehung. Wenn die Multiplizität des Zielendes dieser Beziehung größer als eins ist, bedeutet dies, dass mehrere Instanzen des Ports gleichzeitig existieren und jeder an einer anderen Instanz des Protokolls beteiligt ist. Wenn die Multiplizität ein Wertebereich ist, bedeutet dies, dass die Anzahl der Ports zur Laufzeit variieren kann und dass Ports dynamisch (möglicherweise unter Vorgaben) erstellt und gelöscht werden können.

Abbildung, die eine Kapsel mit Ports zeigt

Ports, Protokolle und Protokollrollen

Die vorherige Abbildung zeigt ein Beispiel für einen einzelnen Port mit dem Namen b, der zur Kapselklasse KapselKlasseA gehört. Dieser Port spielt die Hauptrolle des Protokolls, das durch die Protokollklasse ProtokollA definiert wird. Die eigentliche Port-Klasse PortKlasseX, eine Implementierungsklasse, die je nach Implementierung variieren kann, ist normalerweise für den Modellierer erst in der Implementierungsphase von Interesse. Es ist die Protokollrolle, die dieser Port implementiert, die von Interesse ist. Aus diesem Grund und aus Notationsgründen wird die in Abbildung 1 gezeigte Notation normalerweise nicht verwendet und durch die kompaktere Form ersetzt, die im folgenden Abschnitt beschrieben wird.

Notation

In Klassendiagrammen werden die Ports einer Kapsel wie gezeigt in einem speziell beschrifteten Listenabschnitt aufgeführt. Der Listenabschnitt Ports erscheint normalerweise hinter den Listenabschnitten Attribut und Operator. Diese Notation nutzt den Vorteil des UML-Feature, das das Hinzufügen speziell benannter Abschnitte unterstützt.

Klassendiagramm für Ports

Port-Notation - Klassendiagramm

Alle externen Ports (Relay-Ports und öffentliche End-Ports) sind öffentlich sichtbar, während die internen Ports geschützt sind und die Sichtbarkeit "protected" haben (z. B. Port b2). Die Protokollrolle (Typ) eines Port wird normalerweise mit einem Pfadnamen angegeben, da die Namen von Protokollrollen nur innerhalb des Bereichs eines bestimmten Protokolls eindeutig sind. Port b spielt beispielsweise die Hauptrolle, die in der Protokollklasse ProtokollA definiert ist. Bei den häufig verwendeten binären Protokollen wird eine einfachere Notationskonvention verwendet: Mit einer Tilde ("~") als Suffix wird die konjugierte Protokollrolle (z. B. Port b2) angegeben. Der Name der Basisrolle hingegen ist implizit und hat keine spezielle Annotation (z. B. Port b1). Bei Ports mit einer Multiplizität größer als 1 wird der Multiplizitätsfaktor zwischen eckigen Klammern angegeben. Beispielsweise hat Port b1[3] einen Multiplizitätsfaktor von exakt 3, während ein Port, der mit b5[0..2] angegeben wird, eine variable Anzahl von Instanzen, maximal aber 2.

Konnektoren

Ein Konnektor stellt einen Kommunikationskanal dar, der die Übertragungseinrichtungen für die Unterstützung eines bestimmten signalbasierten Protokolls bereitstellt. Ein Schlüsselmerkmal von Konnektoren ist, dass sie nur Ports verbinden können, die in dem Protokoll, das dem Konnektor zugeordnet ist, komplementäre Rollen übernehmen. Prinzipiell müssen die Protokollrollen nicht unbedingt zu demselben Protokoll gehören. Wenn sie nicht zu demselben Protokoll gehören, müssen sie jedoch mit dem Protokoll des Konnektors kompatibel sein.

Konnektoren sind abstrakte Sichten signalbasierter Kommunikationskanäle, die zwei oder mehr Ports verbinden. Die von einer Verbindung gebundenen Ports müssen zwar komplementäre, aber kompatible Rollen in einem Protokoll spielen. In Kollaborationsdiagrammen werden sie durch Assoziationsrollen dargestellt, die die entsprechenden Ports miteinander verbinden. Wenn Sie die Ports aus dem Bild abstrahieren, sind es die Konnektoren, die die wichtigen Kommunikationsbeziehungen zwischen Kapseln beschreiben. Diese Beziehungen sind architektonisch von Relevanz, da sie die Kapseln angeben, die einander durch direkte Kommunikation beeinflussen können. Ports werden verwendet, um die Kapselung von Kapseln nach den Prinzipien der Informationsausblendung und Trennung von Problemstellungen zu ermöglichen.

Die Ähnlichkeit zwischen Konnektoren und Protokollen könnte die Vermutung nahe legen, dass die beiden Konzepte äquivalent sind. Dies ist jedoch nicht der Fall, das Protokolle abstrakte Spezifikationen gewünschten Verhaltens sind, wohingegen Konnektoren physische Objekte sind, die lediglich die Funktion haben, Signal von einem Port an den anderen zu vermitteln. Gewöhnlich sind die Konnektoren selbst passive Übertragungskanäle. (In der Praxis können physische Konnektoren manchmal vom angegebenen Verhalten abweichen, z. B. wenn ein Konnektor in Folge einer internen Funktionsstörung Nachrichten verliert, umsortiert oder dupliziert. Diese Art von Störung tritt bei verteilten Kommunikationskanälen häufiger auf.)

Ein Konnektor wird durch eine Assoziation zwischen zwei oder mehr Ports der entsprechenden Kapselklassen modelliert. (Für intelligente Anwendungen, in denen der Konnektor physische Eigenschaften hat, kann eine Assoziationsklasse verwendet werden, da der Konnektor ein Objekt mit einem Zustand und einer Identität ist. Wie bei Ports ist die Klasse, die einen Konnektor realisiert, ein Implementierungselement.) Die Beziehung zum unterstützten Protokoll ist über die verbundenen Ports implizit. Deshalb sind keine UML-Erweiterungen für die Darstellung von Konnektoren erforderlich.

Spezifikationskollaboration

Die komplette interne Struktur einer Kapsel wird durch eine Spezifikationskollaboration dargestellt. Diese Kollaboration enthält eine Spezifikation aller Ports, Unterkapseln und Konnektoren. Wie bei Ports besteht zwischen Unterkapseln und Konnektoren eine strenge Eignerbeziehung zur Kapsel, d. h. sie können nicht unabhängig von der Kapsel existieren. Sie werden erstellt, wenn die Kapsel erstellt wird, und gelöscht, wenn die Kapsel gelöscht wird.

Einige Unterkapseln in der Struktur können nicht gleichzeitig mit der übergeordneten Kapsel erstellt werden. Diese werden anschließend bei Bedarf von der Zustandsmaschine der Kapsel erstellt. Die Zustandsmaschine kann solche Kapseln auch jederzeit löschen. Dies entspricht den URL-Regeln für Komposition.

Die Struktur einer Kapsel kann so genannte Plug-in-Rollen enthalten. Diese sind eigentlich Platzhalter für Unterkapseln, die dynamisch eingebunden werden. Diese Rollen sind erforderlich, weil es im Vorfeld nicht immer bekannt ist, welche spezifischen Objekte diese Rollen zur Laufzeit übernehmen. Sobald diese Informationen verfügbar sind, kann die entsprechende Kapselinstanz (deren Eigner eine andere zusammengesetzte Kapsel sein kann) einen solchen Platz einnehmen. Die Konnektoren, die die Ports der Kapselinstanz mit anderen Unterkapseln in der Kollaboration verbinden, werden automatisch eingerichtet. Wenn die dynamische Beziehung nicht mehr benötigt wird, werden die Kapsel aus dem Plug-in-Steckplatz und die Konnektoren zu dieser Kapsel entfernt.

Mit dynamisch erstellten Unterkapseln und Plug-ins können Sie dynamisch variierende Strukturen modellieren und gleichzeitig sicherstellen, dass alle gültigen Kommunikations- und Containment-Beziehungen zwischen Kapseln explizit spezifiziert werden. Dies ist der Schlüssel für die Gewährleistung der architektonischen Integrität in einem komplexen Echtzeitsystem.

Ports können auch in Spezifikationskollaborationsdiagrammen dargestellt werden. in diesen Diagrammen werden Objekte durch die entsprechenden Klassifikatorrollen dargestellt, d. h. Unterkapseln von Kapselrollen und Ports von Port-Rollen. Zur besseren Übersichtlichkeit werden Port-Rollen generell als Symbole angezeigt, die die Form kleiner schwarzer oder weißer Vierecke haben. Öffentliche Ports werden, wie in der vorherigen Abbildung gezeigt, durch Port-Rollensymbole auf der Grenze der entsprechenden Kapselrollen dargestellt. Durch diese vereinfachte Notation können sie von innen und außen der Kapsel verbunden werden, ohne unnötigerweise Grenzen zu überschreiten. Außerdem definiert sie dies eindeutig als Grenzobjekte.

Abbildung mit öffentlichen Ports und Kapselrollen

Port-Notation - Spezifikationskollaborationsdiagramm

Die Beschriftungen sind Verzierungen der Port-Rollen und dürfen nicht mit den Namen der Assoziationsenden des Konnektors verwechselt werden. Da Ports eindeutig anhand ihrer Namen identifizierbar sind, können die öffentlichen Port-Rollen zur Vereinfachung der grafischen Darstellung in beliebiger Reihenfolge um den Rahmen einer Unterkapsel herum angeordnet werden. Auf diese Weise können Überschreitungen von Konnektorlinien verringert werden.

Bei binären Protokollen kann ein weiteres Stereotypsymbol verwendet werden: Der Port, der die konjugierte Rolle spielt, wird mit einem gefüllten weißen (im Gegensatz zu einem gefüllten schwarzen) Rechteck dargestellt. In diesem Fall reichen der Protokollname und das Tildensuffix aus, um die Protokollrolle als konjugierte Rolle auszuweisen. Der Name der Protokollrolle ist redundant und muss weggelassen werden. Der Protokollname allein in einem schwarzen Rechteck repräsentiert die Basisrolle des Protokolls. Wenn die "Hauptrolle" im Protokoll ProtQ beispielsweise als Basis deklariert ist, sind die Diagramme in der folgenden Abbildung und in der vorherigen Abbildung identisch. Aufgrund dieser Konvention lässt sich leicht erkennen, wenn komplementäre Protokollrollen verbunden sind.

Abbildung mit Protokollrolle

Notationskonventionen für binäre Protokolle

Ports mit einem Multiplizitätsfaktor größer als eins können grafisch auch mit der UML-Mehrobjektnotation dargestellt werden. Schauen Sie sich dazu die nächste Abbildung an. Diese Notation ist nicht verbindlich (die Multiplizitätszeichenfolge ist ausreichend), betont aber die Möglichkeit mehrerer Instanzen des Ports.

UML-Diagramm für mehrere Objekte

Ports mit einem Multiplizitätsfaktor größer als 1

Zustandsmaschine

Die einer Kapsel zugeordnete optionale Zustandsmaschine ist nur ein anderer Teil der Kapselimplementierung. Sie hat jedoch bestimmte spezielle Eigenschaften, die sie von den anderen Bausteinen einer Kapsel unterscheiden:

  • Eine Zustandsmaschine kann nicht in weitere Unterkapseln zerlegt werden. Sie spezifiziert Verhalten direkt. Zustandsmaschinen können jedoch mit UML-Standardfunktionen in Hierarchien einfacherer Zustandsmaschinen zerlegt werden.
  • Es kann maximal eine solche Zustandsmaschine pro Kapsel geben (obwohl Unterkapseln eigene Zustandsmaschinen haben können). Kapseln, die keine Zustandsmaschinen haben, sind einfache Container für Unterkapseln.
  • Eine Zustandsmaschine behandelt Signale, die an einem End-Port einer Kapsel ankommen, und kann über diese Ports Signale senden.
  • Sie ist die einzige Entität, die auf die internen, geschützten Teile ihrer Kapsel zugreifen kann. Damit kann eine Zustandsmaschine als Controller aller anderen Unterkapseln auftreten. Als solche kann sie Unterkapseln, die als dynamische Kapseln ausgewiesen sind, erstellen und löschen und bei Bedarf externe Unterkapseln einfügen und entfernen.

Dynamisch erstellte Unterkapseln werden einfach durch einen variablen Multiplizitätsfaktor angezeigt. Wie Plug-in-Plätze können sie auch durch einen reinen Schnittstellentyp spezifiziert werden. Zur Instanzierungszeit kann damit jede Implementierungsklasse, die diese Schnittstelle unterstützt, instanziert werden. Dies unterstützt die Allgemeingültigkeit in strukturellen Spezifikationen.

Trotz ihrer zusätzlichen Einschränkungen wird die Zustandsmaschine, die einer Kapsel zugeordnet ist, durch die Standardverbindung zwischen einem UML-Klassifikationsmerkmal und einer Zustandsmaschine modelliert. Die Implementierung/Dekomposition einer Kapsel wird durch ein UML-Standardkollaborationselement modelliert, das einem Klassifikationsmerkmal zugeordnet werden kann. 

Weitere Informationen
Prüflisten
Richtlinien