Softwarekomponente

Eine Komponente ist im Kontext der Softwarearchitektur ein Teil einer Software, der mit anderen Softwareteilen gemäß den Regeln eines Komponentenmodells zusammenwirken kann.

Definition

Das Wort Komponente leitet sich vom lateinischen componere (zusammensetzen) ab. In der Softwaretechnik wird der Komponentenbegriff jedoch inhaltlich unterschiedlich verwendet. Oft wird damit fälschlicherweise ein Software-Modul bezeichnet, was die Ähnlichkeit beider Begriffe verdeutlicht (siehe Kapitel Komponenten-Schnittstellen).

1996 wurde die Softwarekomponente bei der European Conference on Object-Oriented Programming (ECOOP) folgendermaßen definiert:

“A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third parties.”

„Eine Softwarekomponente ist ein Element des Zusammenbaus mit vertraglich festgelegten Schnittstellen und ausschließlich expliziten Kontextabhängigkeiten. Eine Softwarekomponente kann unabhängig ausgeliefert werden und ist Baustein für Dritte.“[1]

Allgemeiner und im Zusammenhang mit dem neuen Konzept der komponentenbasierten Entwicklung wird eine Komponente beispielsweise folgendermaßen definiert:

„Eine Software-Komponente ist ein Software-Element, das konform zu einem Komponentenmodell ist und gemäß einem Composition-Standard ohne Änderungen mit anderen Komponenten verknüpft und ausgeführt werden kann.“[2]

Eine Komponente zeichnet sich also dadurch aus, dass sie ein Element einer komponentenbasierten Anwendung darstellt und definierte Schnittstellen zur Verbindung mit anderen Komponenten besitzt. Die genaue Form einer Komponente ist abhängig vom jeweiligen Komponentenmodell.

Komponenten-Schnittstellen

Das Interface der Komponente ist eine verbindliche Schnittstelle (Interface) zum Rest der Software. Die Schnittstelle kann daher mit einem Vertrag zwischen der Komponente und dem Rest der Software verglichen werden. Durch die explizite Definition der Kontextabhängigkeiten wird deutlich, wie unabhängig eine Komponente tatsächlich von ihrer Umgebung ist.

Die Schnittstellen und die wohldefinierten Kontextbedingungen ermöglichen die Wiederverwendung der Komponente. Je geringer die Kontextabhängigkeiten einer Komponente sind, desto weniger Anforderungen müssen für den Einsatz einer Komponente erfüllt werden. Daraus folgt: je weniger Abhängigkeiten, desto einfacher ist die Wiederverwendung. Zugleich ermöglichen die geringen Abhängigkeiten eine entsprechend unabhängige Pflege und Entwicklung der Komponente. Andererseits führt die Unabhängigkeit der Komponenten dazu, dass diese Redundanzen beinhalten. Der Entwickler einer Komponente muss daher einen Kompromiss finden.

Die Schnittstelle kann mit einem Vertrag zwischen der Komponente und dem Rest der Software verglichen werden. Ein Interface definiert daher, wie eine Komponente wieder verwendet werden kann. Zugleich definiert sie, wie andere Komponenten mit dieser Komponente interagieren können.

Komponenten, die eine Software erweitern, werden in manchen Fällen auch als Add-on, Modul oder Plug-in bezeichnet. Dabei ist zu beachten, dass dies umgekehrt nicht notwendigerweise der Fall sein muss. So ist es beispielsweise möglich, eine Ansammlung von verschiedenen mathematischen Funktionen als Modul zu bezeichnen. Das Modul ist möglicherweise in seinen Funktionen unabhängig. Wenn es keine allgemein verbindliche Schnittstelle besitzt, genügt das Modul allerdings nicht den Anforderungen einer Komponente.

Schnittstellen können in verschiedene Typen unterschieden werden. Beispiele unterschiedlicher Sorten von Schnittstellen sind:

  • Grafische Benutzeroberfläche (GUI), auch human machine interface (HMI) genannt: Gestattet eine Interaktion der Komponente mit dem Benutzer durch eine grafische Benutzeroberfläche. Sie wird beispielsweise über die Maus oder den Bildschirm bedient.
  • Kommandozeile (CLI): Insbesondere dann von Interesse, wenn Komponenten ohne Zutun des Benutzers durch das System aufgerufen werden sollen, beispielsweise, um in periodischen Abständen immer wiederkehrende Aufgaben abzuarbeiten. Eine solche Schnittstelle wird durch Eingabe von Befehlen in eine Kommandozeile angesprochen.
  • Daten-Schnittstellen: Erlauben das Ein- und Auslesen von Daten der Komponente. Auf diese Schnittstelle wird programmintern zugegriffen.
  • Programmierschnittstelle (API): Durch diese Schnittstelle ist es dem Programmierer und anderen Komponenten möglich, die von der Komponente angebotenen Funktionalitäten und Dienste durch Programmierbefehle anzusprechen. Soweit nicht anders angegeben wird mit Interface im Folgenden immer eine API gemeint sein.

Eine Komponente kann verschiedene Schnittstellen desselben Typs besitzen. Dies kann beispielsweise nötig sein, um ein und dieselbe Komponente in verschiedene Systeme einzubinden. Dadurch werden die Möglichkeiten einer Wiederverwendung vergrößert.

Vorteil und Nutzen

Komponentenentwicklung zielt auf Kostenreduktion sowie auf erhöhte Flexibilität in der Produktentwicklung.[3] Die Entwicklungskosten für Komponenten amortisieren sich durch ihre Wiederverwendung. Umgekehrt wird die Software-Entwicklung durch den Einsatz von Komponenten beschleunigt, da sie im Idealfall nur im Zusammenfügen und Parametrieren von Komponenten besteht (vergleiche auch Modularität).

Komponenten können fehlerhaft sein. Dies führt zu einer weiteren Forderung: Unabhängigkeit einer Komponente beinhaltet auch, dass die Komponente ihre möglichen Fehler selbst behandelt. Dadurch wird sie zu einer abgeschlossenen Einheit.[4] Im Fehlerfall ist der Fehler so leichter zu lokalisieren. Eine Ausnahme dieser Regel kann nur gemacht werden, wenn dieses Verhalten Teil des Schnittstellenvertrages ist. Dies führt dazu, dass ein Fehler in der Komponente nicht zu einem fehlerhaften Verhalten der ganzen Komponenten führt, da diese sich wie vertraglich festgelegt verhält. Auch hierdurch werden Entwicklungskosten reduziert.

Wiederverwendungsformen

Anhand der Wiederverwendungsform der Komponente kann diese wie folgt grob aufgeteilt werden:

blackbox
Die Komponente wird als eine abgeschlossene Einheit in das zu entwickelnde System aufgenommen. Diese Komponente kann nicht verändert werden. Über ihren internen Aufbau und ihre Funktionsweise kann ebenfalls keine Aussage gemacht werden. Die Verwendung der Komponente geschieht ausschließlich auf Basis der definierten Schnittstellen und Spezifikationen der Komponente.
whitebox
Die Komponente wird als eine offene Einheit wiederverwendet. Das Wort offen beschreibt, dass die Einheit veränderbar ist. Sie kann an die neuen Anforderungen angepasst werden. Dazu ist ihr interner Aufbau einsehbar und somit analysierbar. Die Komponente wird daher als Softwarefragment betrachtet. Die Verwendung der Komponenten geschieht nicht ausschließlich auf Basis der definierten Schnittstellen, sondern auch durch das Analysieren der aktuellen Umsetzung dieser Komponente.
greybox
Die Zwischenformen von black- und whitebox.

Komponenten zur Entwicklungszeit

Komponenten können beispielsweise in die Entwicklungsumgebung integriert werden. Dann zeigen sie ihre Eigenschaften und ihr Verhalten bereits zur Entwicklungszeit. Für den Programmierer ist dies ein großer Vorteil: Er sieht schon während des Programmierens, wie die Komponente aussehen oder arbeiten wird.

Beispiel einer Komponentenpalette

Erst durch das Verwenden von vorgefertigten Komponenten ist ein Rapid Application Development möglich.

Implementierungen

Standards

In der Software ist die Komponenten-Technologie in der Meinung Vieler ein Eckstein der Softwareentwicklung der nächsten Jahre.[4] Es koexistieren verschiedene Standards. Abgesehen von CORBA sind diese Standards im Allgemeinen programmiersprachen-, anwendungs- oder plattformspezifisch. Sie bilden so genannte Komponentenwelten oder -märkte. Beispiele solcher Welten sind:

Entwicklungswerkzeuge

Für komponentenbasierte Entwicklungen gibt es spezielle Entwicklungsumgebungen und Programmiersprachen, wie zum Beispiel:

Literatur

  • M. D. McIlroy: Mass produced software components. In: Software Engineering, Report on a conference sponsored by the NATO Science Committee, Garmisch, Germany, 7th to 11th October 1968. 1969, S. 138–155 (txt).
  • Olaf Zwintzscher: Software-Komponenten im Überblick, W3L, 2004, ISBN 3937137602
  • Clemens Szyperski: Component Software - Beyond Object-Oriented Programming, Second Edition, 2002, ISBN 0-201-74572-0

Weblinks

Quellen

  1. ↑ Clemens Szyperski: Component Software - Beyond Object-Oriented Programming, Second Edition, 2002, ISBN 0-201-74572-0, S. 41
  2. ↑ William T. Councill, George T. Heineman: Component-Based Software Engineering. Addison-Wesley, 2001, ISBN 0-201-70485-4
  3. ↑ Dumke, Reiner: Software Engineering. Friedr. Vieweg & Sohn Verlagsgesellschaft/GWV Fachverlage GmbH, 4. Auflage, Wiesbaden 2003.
  4. ↑ a b Snoopy; Müller, Martin (Deutsche Übersetzung): Open Source – kurz & gut. (Memento desOriginals vom 2. Februar 2020 im Internet Archive)  Info: Der Archivlink wurde automatisch eingesetzt und noch nicht geprüft. Bitte prüfe Original- und Archivlink gemäß Anleitung und entferne dann diesen Hinweis.@1@2Vorlage:Webachiv/IABot/www.oreilly.de