Konzept: Komponente
Eine Komponente ist ein gekapselter Teil eines Systems, idealerweise ein nicht trivialer, nahezu unabhängiger und austauschbarer Teil eines Systems, der eine eindeutige Funktion im Kontext einer klar strukturierten Architektur ausführt.
Beziehungen
Zugehörige Elemente
Hauptbeschreibung

Definition

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.

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.

Modellierung von Komponenten

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.

Instanzierung von Komponenten

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.x-Darstellung

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.