Wikipedia · einfach zusammengefasst · Stand
Komponentenbasierte Entwicklung
Grundlage dieses Konzeptes sind Software-Komponenten, die die Wiederverwendbarkeit von Software-Artefakten verbessern sollen. Diagramm über die Entwicklung von …
Inhalt5 Abschnitte
Grundidee
Die Komponentenbasierte Entwicklung, englisch Component Based Development (CBD) oder Component Based Software Engineering (CBSE), ist ein Paradigma der angewandten Informatik. Sie beruht auf Software-Komponenten, also wiederverwendbaren Software-Bausteinen. Ziel ist es, Software-Artefakte besser wiederverwendbar zu machen und Anwendungen nicht jedes Mal vollständig neu zu programmieren.
Der Grundgedanke ist, Anwendungen in wiederverwendbare Komponenten zu unterteilen. Aus vorhandenen Komponenten können neue Anwendungen nach dem Baukastenprinzip zusammengesetzt werden. Neue Komponenten müssen nur dann entwickelt werden, wenn eine benötigte Funktionalität noch nicht vorhanden ist.
Einordnung
Die komponentenbasierte Entwicklung entstand aus früheren Programmierparadigmen. In der prozeduralen Programmierung ist die Funktion oder Prozedur das zentrale Element, in der objektorientierten Programmierung das Objekt, beim Distributed Object Computing das CORBA-Objekt und in der komponentenbasierten Programmierung die Komponente.
Dabei werden die zentralen Elemente zunehmend komplexer und mächtiger. Die objektorientierte Programmierung bildet die Grundlage der komponentenbasierten Programmierung.
Vorteile
Ein wichtiger Vorteil ist Zeitersparnis: Wenn Komponenten bereits vorhanden sind, muss weniger Code neu geschrieben werden. Mit der Zeit kann ein „Komponentenmarktplatz“ entstehen, aus dem Entwickler passende Bausteine auswählen.
Ein weiterer Vorteil ist eine mögliche Qualitätssteigerung. Wenn viele Nutzer dieselbe Komponente in verschiedenen Anwendungsszenarien einsetzen, wirken diese Szenarien automatisch wie Tests. Fehler und Schwächen können dadurch eher auffallen.
Kontext und Kontrakt
In Softwaresystemen gibt es meist Annahmen über den Kontext, in dem das System funktioniert. CBSE verlangt, dass diese Annahmen explizit definiert werden. Nur so kann ein System auch in verschiedenen Kontexten und von Dritten wiederverwendet werden.
In Komponentenmodellen wie CORBA, DCOM, CCA und JavaBeans wird in der Praxis eine Trennung von Implementierung und Schnittstelle vorausgesetzt. Die Implementierung beschreibt, wie etwas intern funktioniert; die Schnittstelle beschreibt, wie eine Komponente von außen benutzt wird. Diese Trennung liefert aber nur eine syntaktische Kontextspezifikation, also vor allem Informationen über Form und Aufrufbarkeit. Der Begriff des Kontrakts geht weiter: Er fordert eine explizite Kontextspezifikation, die nicht nur syntaktisch ist.
Praxisgrenzen
Die Theorie verlangt auch eine semantische Kontextbeschreibung. „Semantisch“ bedeutet hier, dass nicht nur die äußere Form beschrieben wird, sondern auch die Bedeutung und die erlaubte Nutzung. Ein Beispiel ist die Spezifikation legaler Reihenfolgen von Methodenaufrufen einer Komponente.
Solche semantischen Beschreibungen haben sich laut Artikel in der breiten Praxis noch nicht durchgesetzt. Deshalb wird der Begriff Softwarekomponente praktisch häufig auf zustandslose Dienste beschränkt. Bei zustandslosen Diensten ist eine solche semantische Spezifikation technisch nicht unbedingt notwendig. Der Artikel verweist in diesem Zusammenhang auf Service Oriented Architecture.