In der Softwarebranche und Softwareliteratur wird der Begriff "Komponente" für viele verschiedene Dinge verwendet. Er
wird häufig im weitesten Sinne für "einen Bestandteil" verwendet. Häufig wird er auch im engeren Sinne verwendet, um
bestimmte Merkmale zu bezeichnen, die in größeren Systemen eingesetzt und ausgetauscht werden können.
In RUP wird der Begriff "Komponente" für einen gekapselten Teil eines Systems, idealerweise einen nicht trivialen,
nahezu unabhängigen und austauschbaren Teil eines Systems, der eine eindeutige Funktion im Kontext einer klar
strukturierten Architektur ausführt, bezeichnet. Dazu gehören:
-
Designkomponente: Ein bedeutender gekapselter Teil des Designs, der Designsubsysteme und manchmal bedeutende
Designklassen und Designpakete enthält.
-
Implementierungskomponente: Ein bedeutender gekapselter Teil der Implementierung, im allgemeinen Code, der eine
Designkomponente implementiert.
Im Idealfall spiegelt das Design die Implementierung wider, so dass man nur auf Komponenten verweisen kann, wobei jede
Komponente ein Design und eine Implementierung hat.
Die UML ([UML04]) definiert "Komponente" wie folgt:
Ein modularer Teil eines Systems, der seinen Inhalt kapselt und dessen Manifestation innerhalb seiner Umgebung
austauschbar ist. Eine Komponente definiert ihr Verhalten mit Hilfe von bereitgestellten und erforderlichen
Schnittstellen. Als solches dient eine Komponente als Typ, dessen Konformität durch diese bereitgestellten und
erforderlichen Schnittstellen (einschließlich ihrer statischen und dynamischen Semantik) definiert wird.
Eine Komponente ist als Subtyp einer strukturierten Klasse definiert, der einer Komponente mit Attributen und
Operationen ermöglicht, an Zuordnungen und Generalisierungen teilzunehmen und eine interne Struktur und Ports zu
verwenden. Ausführliche Informationen finden Sie im Artikel Konzept:
Strukturierte Klasse.
Es existieren verschiedene UML-Standardstereotypen für Komponenten, z. B. <<Subsystem>> für die
Modellierung umfangreicher Komponenten oder <<Spezifikation>> und <<Realisierung>> für die
Modellierung von Komponenten mit eindeutigen Spezifikations- und Realisierungsdefinitionen, wobei eine Spezifikation
mehrere Realisierungen haben kann.
Der Begriff "Komponente" ist in RUP weiter gefasst als in der UML-Definition. Anstatt Komponenten anhand von Merkmalen
wie Modularität, Implementierbarkeit und Austauschbarkeit zu definieren, wird in RUP empfohlen, diese Merkmale als
wünschenswert für eine Komponente zu sehen. Lesen Sie hierzu den folgenden Abschnitt zur Austauschbarkeit von
Komponenten.
Gemäß RUP- und UML-Terminologie müssen Komponenten austauschbar sein. Dies kann aber auch nur bedeuten, dass die
Komponente eine Reihe von Schnittstellen zugänglich macht, die eine zugrunde liegende Implementierung verdecken.
Es gibt jedoch auch andere und striktere Arten von Austauschbarkeit. Diese sind im Folgenden aufgelistet.
Austauschbarkeit von Quellendateien
Wenn zwei Klassen in einer Quellcodedatei implementiert sind, können diese beiden Klassen normalerweise nicht gesondert
über die Versionssteuerung verwaltet und kontrolliert werden.
Wenn mehrere Dateien jedoch eine einzelne Komponente vollständig und keine anderen Komponenten implementieren, kann die
Quellendatei der Komponente ausgetauscht werden. Damit ist es einfacher, den Quellcode der Komponente über eine
Versionssteuerung zu verwalten, eine Referenzversion zu erstellen und den Quellcode wiederzuverwenden.
Austauschbarkeit während des Deployment
Wenn zwei Klassen in einer ausführbaren Datei implementiert sind, können die beiden Klassen in einem implementierten
System nicht unabhängig voneinander ausgetauscht werden.
Ein wünschenswertes Merkmal von Komponenten mit größerer Granularität ist die "Austauschbarkeit während des
Deployment", die ermöglicht, dass neue Versionen der Komponente implementiert werden können, ohne die anderen
Komponenten erneut erstellen zu müssen. Dies bedeutet in der Regel, dass eine Datei oder eine Gruppe von Dateien nur
diese eine Komponente implementieren.
Austauschbarkeit zur Laufzeit
Wenn eine Komponente in einem aktiven System erneut implementiert werden kann, wird dies als "Austauschbarkeit zur
Laufzeit" bezeichnet. Dieses Merkmal ermöglicht einen Upgrade der Software ohne Verlust der Verfügbarkeit.
Standorttransparenz
Komponenten mit Schnittstellen, die über das Netz adressierbar sind, werden als "standorttransparent" bezeichnet.
Dieses Merkmal erlaubt die Verlagerung von Komponenten auf andere Server und die Replikation von Komponenten auf
mehreren Servern für die Unterstützung von Fehlertoleranz, Lastausgleich usw. Diese Arten von Komponenten werden häufig
auch als "verteilte" oder "verteilbare" Komponenten bezeichnet.
Die UML-Komponente ist ein Modellierungskonstrukt mit folgender Funktionalität:
-
Sie kann Klassen gruppieren, um ein Teil eines Systems mit größerer Unterteilung zu definieren.
-
Sie kann die sichtbaren Schnittstellen von der internen Implementierung abgrenzen.
-
Sie kann Instanzen haben, die zur Laufzeit ausgeführt werden.
Eine Komponente hat eine Reihe bereitgestellter und erforderlicher Schnittstellen, auf deren Basis Komponenten
miteinander vernetzt werden können. Eine bereitgestellte Schnittstelle ist eine Schnittstelle, die entweder direkt von
der Komponente oder einer ihrer realisierenden Klassen oder Unterkomponenten implementiert wird, bzw. der Typ eines
bereitgestellten Port der Komponente. Eine erforderliche Schnittstelle wird durch eine Nutzungsabhängigkeit der
Komponente oder einer ihrer realisierenden Klassen oder Unterkomponenten bestimmt oder gibt den Typ eines
erforderlichen Port an.
Eine Komponente hat über ihre öffentlich sichtbaren Eigenschaften und Operationen eine externe Sicht (oder
"Blackbox"-Sicht). Optional kann einer Schnittstelle, einem Port oder der Komponente selbst ein Verhalten, wie z. B.
eine Protokollzustandsmaschine, zugeordnet werden, um die externe Sicht genauer zu definieren, indem dynamische
Vorgaben in der Reihenfolge der Operationsaufrufe explizit gemacht werden. Die Vernetzung zwischen den Komponenten in
einem System oder einem anderen Kontext kann strukturell mit Hilfe von Abhängigkeiten zwischen
Komponentenschnittstellen (typischerweise in Komponentendiagrammen) definiert werden.
Optional kann anhand von Teilen und Verbindungen in zusammengesetzten Strukturen eine detaillierter Spezifikation der
strukturellen Kollaboration vorgenommen werden, um die Kollaboration zwischen den Komponenten auf Rollen- oder
Instanzebene zu definieren, d. h. die interne Sicht der Komponente (oder "Whitebox"-Sicht) anhand ihrer privaten
Eigenschaften und realisierenden Klassen oder Unterkomponenten. Diese Ansicht veranschaulicht, wie das externe
Verhalten intern realisiert wird. Die Zuordnung von externer und interner Sicht wird mit Hilfe von Abhängigkeiten (in
Komponentendiagrammen) oder Delegierungsverbindungen zu internen Teilen (in zusammengesetzten Strukturdiagrammen)
verdeutlicht.
RUP empfiehlt, Komponenten als Darstellung für Designsubsysteme zu verwenden. Ausführliche Informationen finden Sie in
Arbeitsergebnis: Designsubsystem, Aufgabe:
Subsystemdesign und Richtlinie:
Designsubsystem. Lesen Sie außerdem die Definitionen in Konzept:
Strukturierte Klasse.
Eine Komponente kann zur Laufzeit direkt instanziert werden.
Eine indirekt instanzierte Komponente wird anhand von Klassen, Unterkomponenten oder Teilen implementiert bzw.
realisiert. Die Komponente selbst erscheint nicht in der Implementierung. Sie dient als Design, dem eine
Implementierung folgen muss. Die realisierenden Klassen, Unterkomponenten bzw. Teile müssen die gesamten Operationen
abdecken, die in der bereitgestellten Schnittstelle der Komponente angegeben sind. Die Art und Weise, in der die
Komponente implementiert wird, liegt in der Zuständigkeit des Implementierenden.
Eine direkt instanzierte Komponente gibt ihre eigene gekapselte Implementierung an. Sie wird als adressierbares Objekt
instanziert. Das bedeutet, dass eine Designkomponente ein entsprechendes Konstrukt in der Implementierungssprache hat,
damit sie explizit referenziert werden kann.
UML 1.5 definiert den Begriff "Komponente" wie folgt:
Ein modularer, implementierbarer und austauschbarer Teil eines Systems, das seine Implementierung kapselt und eine
Reihe von Schnittstellen bereitstellt. Eine Komponente wird in der Regel durch eine oder mehrere Klassen oder
Unterkomponenten angegeben, die in der Komponente enthalten sind, und kann von einem oder mehreren Artefakten (z.
B. Binärdateien, ausführbare Dateien oder Script-Dateien) implementiert werden.
Beachten Sie, dass in UML 1.3 und früheren Versionen der Begriff "Komponente" für die Darstellung von Dateien in der
Implementierung verwendet wurde. In den neuesten UML-Definitionen werden Dateien nicht mehr als "Komponenten"
betrachtet. Allerdings verwenden viele Tools und UML-Profile weiterhin den Begriff "Komponente" für die Darstellung von
Dateien. Nähere Informationen zur Darstellung von Dateien in UML finden Sie im Artikel Richtlinie: Implementierungselement.
Aus der Modellierungsperspektive werden Komponenten in UML 1.5 mit UML-Subsystemen verglichen, weil sie Modularität,
Kapselung und Instanzen unterstützen, die zur Laufzeit ausgeführt werden können. RUP betrachtet das
UML-1.5-Modellierungskonstrukt für Komponenten als alternative Notation für die Darstellung von Designsubsystemen.
Nähere Einzelheiten finden Sie in den Artikeln Arbeitsergebnis: Designsubsystem und Richtlinie: Designsubsystem.
Lesen Sie auch den Artikel Unterschiede zwischen UML 1.x und UML 2.0.
|