Komponentenbasierte Entwicklung
In der angewandten Informatik ist die Komponentenbasierte Entwicklung (englisch Component Based Development, CBD oder auch Component Based Software Engineering, CBSE) ein aus früheren Ansätzen entwickeltes Paradigma. Grundlage dieses Konzeptes sind Software-Komponenten, die die Wiederverwendbarkeit von Software-Artefakten verbessern sollen. Über die Funktion, bzw. Prozedur in der Prozeduralen Programmierung, das Objekt in der Objektorientierten Programmierung und das CORBA Objekt beim Distributed Object Computing bis hin zur Komponente in der Komponentenbasierten Programmierung werden die zentralen Elemente immer komplexer und mächtiger. Objektorientierte Programmierung stellt dabei die Grundlage der Komponentenbasierten Programmierung dar. Der Grundgedanke komponentenbasierter Entwicklung ist die Unterteilung von Anwendungen in wiederverwendbare Komponenten, um möglichst wenig Code neu programmieren zu müssen. Mit der Zeit kann so ein „Komponentenmarktplatz“ entstehen, aus dem heraus Anwendungen nach dem Baukastenprinzip zusammengestellt werden. Zusätzliche Komponenten müssen nur für Funktionalität entwickelt werden, für die es bisher keine Implementierung gibt. Vorteile sind neben einer Zeitersparnis bei der Entwicklung auch eine erhöhte Qualität der Komponenten durch eine große Nutzeranzahl und verschiedene Anwendungsszenarien, die automatisch als Testszenarien dienen. In einem Softwaresystem werden in der Regel Annahmen über einen Kontext impliziert, in dem das System funktioniert. Die CBSE verlangt, dass alle diese Annahmen explizit definiert werden, damit das System in verschiedenen Kontexten (von Dritten) wiederverwendet werden kann. In der Praxis verschiedener Komponentenmodelle wie zum Beispiel CORBA, DCOM, CCA, JavaBeans, wird eine Trennung von Implementierung und Schnittstelle vorausgesetzt, was allerdings nur einer syntaktischen Kontextspezifikation entspricht. Der Begriff des Kontrakts fordert dagegen eine explizite Kontextspezifikation, die über die rein syntaktische Spezifikation hinausgeht. Die semantische Kontextbeschreibung zum Beispiel durch die Spezifikation von legalen Reihenfolgen von Methodenaufruf einer Komponente, werden von der Theorie vorausgesetzt, haben den Weg in die breite Praxis aber noch nicht gefunden. In der Praxis wird aus diesem Grund der Begriff der Softwarekomponente häufig auf zustandslose Dienste beschränkt, da für diese eine solche semantische Spezifikation technisch nicht unbedingt notwendig ist (siehe Service Oriented Architecture).
In der angewandten Informatik ist die Komponentenbasierte Entwicklung (englisch Component Based Development, CBD oder auch Component Based Software Engineering, CBSE) ein aus früheren Ansätzen entwickeltes Paradigma. Grundlage dieses Konzeptes sind Software-Komponenten, die die Wiederverwendbarkeit von Software-Artefakten verbessern sollen.
Über die Funktion, bzw. Prozedur in der Prozeduralen Programmierung, das Objekt in der Objektorientierten Programmierung und das CORBA Objekt beim Distributed Object Computing bis hin zur Komponente in der Komponentenbasierten Programmierung werden die zentralen Elemente immer komplexer und mächtiger. Objektorientierte Programmierung stellt dabei die Grundlage der Komponentenbasierten Programmierung dar.
Der Grundgedanke komponentenbasierter Entwicklung ist die Unterteilung von Anwendungen in wiederverwendbare Komponenten, um möglichst wenig Code neu programmieren zu müssen. Mit der Zeit kann so ein „Komponentenmarktplatz“ entstehen, aus dem heraus Anwendungen nach dem Baukastenprinzip zusammengestellt werden. Zusätzliche Komponenten müssen nur für Funktionalität entwickelt werden, für die es bisher keine Implementierung gibt.
Vorteile sind neben einer Zeitersparnis bei der Entwicklung auch eine erhöhte Qualität der Komponenten durch eine große Nutzeranzahl und verschiedene Anwendungsszenarien, die automatisch als Testszenarien dienen. In einem Softwaresystem werden in der Regel Annahmen über einen Kontext impliziert, in dem das System funktioniert. Die CBSE verlangt, dass alle diese Annahmen explizit definiert werden, damit das System in verschiedenen Kontexten (von Dritten) wiederverwendet werden kann.
In der Praxis verschiedener Komponentenmodelle wie zum Beispiel CORBA, DCOM, CCA, JavaBeans, wird eine Trennung von Implementierung und Schnittstelle vorausgesetzt, was allerdings nur einer syntaktischen Kontextspezifikation entspricht. Der Begriff des Kontrakts fordert dagegen eine explizite Kontextspezifikation, die über die rein syntaktische Spezifikation hinausgeht.
Die semantische Kontextbeschreibung zum Beispiel durch die Spezifikation von legalen Reihenfolgen von Methodenaufruf einer Komponente, werden von der Theorie vorausgesetzt, haben den Weg in die breite Praxis aber noch nicht gefunden. In der Praxis wird aus diesem Grund der Begriff der Softwarekomponente häufig auf zustandslose Dienste beschränkt, da für diese eine solche semantische Spezifikation technisch nicht unbedingt notwendig ist (siehe Service Oriented Architecture).
Siehe auch
[Bearbeiten | Quelltext bearbeiten]- CORBA Component Model (CCM)
Literatur
[Bearbeiten | Quelltext bearbeiten]- Andreas Andresen: Komponentenbasierte Softwareentwicklung mit MDA, UML und XML, Hanser Fachbuchverlag, 2003, ISBN 3-446-22282-0
- George T. Heineman, William T. Councill: Component-Based Software Engineering: Putting the Pieces Together, Addison-Wesley Professional, 2001, ISBN 0-201-70485-4