UML-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.
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.
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 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.
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.
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.
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.
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.
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.
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.
Ports mit einem Multiplizitätsfaktor größer als 1
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.
|