Softwarekomponenten sind ein Mittel zur kompositorischen Wiederverwendung von Softwareartefakten. Sie ermöglichen es, die im Rahmen der Softwaresystementwicklung bestehenden Kostenreduzierungs- und Qualitätssteigerungspotentiale besser auszuschöpfen.
Leitbild
Softwarekomponenten, die als Konzept des Software Engineering erstmals im Jahr 1968 [McIlroy 1968] Erwähnung finden, liegt als Leitbild die kompositorische, Plug-and-play-artige Wiederverwendung von Black-Box-Softwarebausteinen zu Grunde. Dabei wird darauf abgezielt, die durch eine Mehrfach- oder Wiederverwendung gleicher Softwarebausteine in unterschiedlichen Softwaresystemen erreichbaren Kostenreduzierungs- und Qualitätssteigerungspotentiale auszuschöpfen.
Das Adjektiv Plug-and-play-artig deutet dabei darauf hin, dass das Zusammensetzen von Softwarebausteinen zu neuen Softwaresystemen (deren Komposition) mit geringem Aufwand möglich sein soll. Der Black-Box-Idee wird gefolgt indem für den Verwender eines Softwarebausteins lediglich die Spezifikation seiner Außensicht offengelegt wird. Insbesondere muss ein Verwender, der einen bestimmten Softwarebaustein in ein Softwaresystem integriert, die Implementierung des Softwarebausteins nicht kennen – und soll dies auch nicht. Damit wird vermieden, dass der Verwender Annahmen trifft, die Weiterentwicklung oder Austausch des Softwarebausteins dadurch erschweren, dass mit einer Änderung der Implementierung des Softwarebausteins Softwaresysteme die diesen beinhalten fehlerhaft werden könnten.
Kurz: Es wird versucht die sich aus Plattformkonzept und Modularisierung ergebenden Vorteile reiferer Ingenieursdisziplinen auf logisch/inhaltlich korrespondierende Konzepte des Software Engineering zu übertragen bzw. diese zu entwickeln.
Definition
In enger Anlehnung an [Ackermann et al. 2002, S. 1] wird definiert:
Eine Softwarekomponente besteht aus verschiedenartigen (Software-)Artefakten. Sie ist wiederverwendbar, abgeschlossen und vermarktbar, stellt Dienste über wohldefinierte Schnittstellen zur Verfügung, verbirgt ihre Realisierung und kann in Kombination mit anderen Komponenten eingesetzt werden, die zur Zeit der Entwicklung nicht unbedingt vorhersehbar ist.
Zu den (Software-)Artefakten zählen der ausführbare Code, darin verankerte Grafiken, Textkon-stanten usw., die einen initialen Zustand der Softwarekomponente beschreibenden Daten, z. B. Voreinstellungen oder Parameter, sowie Spezifikation, (Anwender-)Dokumentation und (automatisierte) Tests.
Das Kriterium der Wiederverwendbarkeit erfüllt eine Softwarekomponente dann, wenn sie, mit Ausnahme einer vom Entwickler vorgesehenen Parametrisierung, ohne Modifikation der zugehörigen (Software-)Artefakte für verschiedene Softwaresysteme mit geringem Integrationsaufwand einsetzbar ist.
Grundvoraussetzung hierfür ist das Vorhandensein vollständig und intersubjektiv eindeutig nachvollziehbar beschriebener Schnittstellen (wohldefinierte Schnittstellen). Um dies zu erreichen werden Standards benötigt, die eindeutig festlegen was (die Spezifikationsgegenstände) im Einzelnen wie (die Spezifikationstechniken) zu beschreiben ist, um eine Softwarekomponente vollständig zu spezifizieren [Turowski 2001].
Als abgeschlossen wird eine Softwarekomponente dann bezeichnet, wenn ihr ihre Bestandteile (die (Software-)Artefakte) eindeutig zuordenbar sind, sodass sie als Ganzes klar von anderen Teilen des Softwaresystems abgegrenzt werden kann. Damit ist die Abgeschlossenheit einer Softwarekomponente eine wesentliche Voraussetzung für ihre Vermarktbarkeit. Hierbei wird unter Vermarktbarkeit verstanden, dass Softwarekomponenten prinzipiell über die Eigenschaft verfügen, als für sich selbst stehendes Gut identifizierbar zu sein, sodass sie sowohl auf einem offenen als auch auf einem unternehmensinternen Markt gehandelt werden können.
Dienst-Definition und verwandte Ansätze
Grundlegend für die Definition der Softwarekomponente ist der Begriff des Dienstes.
Ein Dienst ist eine Aktion eines Softwaresystems, welche die Bewältigung einer bestimmten Menge von Aufgaben der jeweiligen Anwendungsdomäne unterstützt.
Softwarekomponenten bieten Dienste an und legen damit eine Beziehung zu später entstandenen Ansätzen nahe, die ebenfalls den Begriff des Dienstes in den Vordergrundstellen und unter dem Begriff Serviceorientierte Architekturen subsumiert werden.
Das wesentliche Unterscheidungsmerkmal (aus der Sicht eines Komponentenverwenders) zu diesen Ansätzen besteht in der weiteren potentiellen Auslagerung von Verantwortung. Mit Softwarekomponenten wird von der Idee her primär Entwicklungsverantwortung delegiert. Die Betriebsverantwortung verbleibt beim Verwender. Demgegenüber gehen Serviceorientierte Architekturen einen Schritt weiter, indem ein Dienstverwender von der Verantwortung für den Betrieb des Softwarebausteins entbunden wird, der den Dienst letztlich zur Verfügung stellt [Overhage, Turowski 2007, S. 4-9].
Literatur
Ackermann, Jörg ; Brinkop, Frank ; Conrad, Stefan ; Fettke, Peter ; Frick, Andreas ; Glistau, Elke ; Jaekel, Holger ; Kotlar, Otto ; Loos, Peter ; Mrech, Heike ; Ortner, Erich ; Raape, Ulrich ; Overhage, Sven ; Sahm, Stephan ; Schmietendorf, Andreas ; Teschke, Thorsten ; Turowski, Klaus: Vereinheitlichte Spezifikation von Fachkomponenten. In: Turowski, Klaus (Hrsg.): Memorandum des Arbeitskreises 5.10.3 Komponentenorientierte betriebliche Anwendungssysteme, Universität Augsburg, 2002. http://www.fachkomponenten.de/docs/MEMO/Memorandum-final-2-44-mit-literatur-Web.pdf (Abruf 22.07.2013).
Mcllroy, M. Douglas: Mass Produced Software Components. In: Naur, Peter ; Randell, Brian (Hrsg.): Software Engineering: Report on a Conference by the NATO Science Comittee, Brüssel 1968, S. 138-150.
Overhage, Sven ; Turowski, Klaus: Serviceorientierte Architekturen – Konzept und methodische Herausforderungen. In: Nissen, Volker ; Petsch, Matthias ; Schorcht, Hagen (Hrsg.): Service-orientierte Architekturen. Wiesbaden : Deutscher Universitätsverlag, 2007. S. 3-17.
Turowski, Klaus: Spezifikation und Standardisierung von Fachkomponenten. In: Wirtschaftsinformatik 43 (2001), Nr. 3, S. 269-281
