Die komponentenbasierte Software-Entwicklung (CBD) trifft derzeit - stärker noch als die Objektorientierung - bei Kunden und Herstellern auf wachsendes Interesse. Unternehmen wie Microsoft und SAP kündigen die Zerstückelung ihrer monolithischen Standardsoftware wie MS Office oder SAP R/3 in einzelne Bestandteile, sprich Komponenten, an, oder haben diese in neuen Versionen bereits umgesetzt. Im Internet werden mittlerweile zahlreiche Active-X-Komponenten oder Javabeans frei gehandelt, und viele Software-Entwicklungs-umgebungen schmücken sich werbewirksam mit dem Label "Component-Based Development".
Allerdings läßt sich bei aller Geschäftigkeit in der Branche keine erschöpfende Definition dafür finden, was Komponenten sind und wie sie sich von Objekten unterscheiden. Eine allgemeine Beschreibung für "Komponente" ist die der Definition von Schnittstellen und die Festschreibung der Dienste, die die Komponenten mit anderen austauschen soll. Da bei Komponenten das, was sie tun, von dem, wie sie es tun, getrennt ist, werden sie idealerweise plattformunabhängig. Voraussetzung ist, daß die gewünschte Applikation in der Architektur intelligent in Komponenten zerteilt wurde. Damit können diese entweder durch bereits vorhandene oder durch gekaufte Softwareteile implementiert oder aber in nachfolgenden Projekten wiederverwendet werden. Die Art der Implementierung der jeweiligen Komponente tritt in den Hintergrund, solange sie über die richtigen Dienste und Schnittstellen verfügt.
Dadurch eröffnen sich im Vergleich zur reinen Objekttechnologie neue Möglichkeiten der Wiederverwendung. Die weitaus meisten Unternehmen haben schon fast alle Abläufe in irgendeiner Form durch Software abgebildet. Einige Teile mögen überholt sein, andere wiederum haben nichts an Gültigkeit verloren - in ihnen stecken wahrscheinlich die grundlegenden Geschäftsprozesse des Unternehmens. Die Möglichkeit, diese Teile in einer neuen Applikation mit moderner Technologie weiter nutzen zu können, ist der große Vorteil, den Komponententechnologie bietet. Eine 20 Jahre alte Cobol-Komponente, gekapselt und mit der entsprechenden Schnittstelle, kann beispielsweise mit einem zugekauften C++-Pendant interagieren. Das Rad wird nicht mehr neu erfunden, es wird an eine neue Achse gehängt.
Die Prinzipien, die CBD zugrunde liegen, sind aber weder neu noch revolutionär, sondern sehr stark von Objekten inspiriert. Diese stellen per Definition eine Kombination von Daten und Methoden dar, die zu einer logisch geschlossenen Einheit verknüpft sind und mit anderen Objekten über eine Schnittstelle kommunizieren können. Objekte stehen für eine Idee, ein Ding oder ein Ereignis; Applikationen können somit intuitiver als mit strukturierten Methoden entwickelt werden. Insbesondere bei Anwendungen wie CAD-Programme oder Steuerungssysteme ist Objekttechnologie nicht mehr wegzudenken.
Anfang der 90er Jahre versprach man sich von Objekttechnologie die Wiederverwendung von Code im großen Stil, austauschbare Softwareteile und als großes Ziel das Zusammensetzen von Anwendungen aus bestehenden Teilen. Doch schon bald stieß man an die Grenzen: Beispielsweise lassen sich nur Objekte kombinieren, die in derselben Programmiersprache geschrieben sind. Mit dem Ziel, eine Basis für verteilte Anwendungen zu schaffen, wurden nachfolgend neben der Erweiterung bestehender OO-Programmiersprachen besonders Standardkommunikations-Infrastrukturen vorangetrieben, die angefangen bei RPC (Remote Procedure Call) über DCE (Distributed Computing Environment) bis zu den heute konkurrierenden Standards COM und Corba führten. Letztere werden weitgehend für verteilte Objekttechnologie genutzt. Es bleiben bei reiner Nutzung von Objekttechnologie derzeit aber noch einige Wünsche offen. So läßt sich ein Kunde nicht so problemlos als Objekt darstellen wie ein Zahnrad - in komplexen betriebswirtschaftlichen Anwendungen waren OO-Projekte deshalb nur begrenzt erfolgreich. Weiterhin muß bei Ablösung einer bereits bestehenden Legacy-Anwendung diese komplett ausgetauscht werden.
Der Grundgedanke komponentenbasierter Software ist heute hingegen die Kombination in sich geschlossener Softwarebausteine unterschiedlicher Herkunft, die unter Nutzung einer gemeinsamen Infrastruktur maßgeschneiderte Applikationen bilden eine Weiterentwicklung der Objektorientierung. Unterschiedlicher Herkunft heißt aber nicht nur gekauft oder selbst entwickelt, sondern kann auch die Kapselung eines Teils einer Altanwendung bedeuten. Allerdings verwendeten Software-Entwickler schon vor etwa 20 Jahren Objekte in ihren MVS-Umgebungen und konstruierten Mainframe-Applikationen aus Komponenten (Building Blocks). Die Softwarewelt war damals jedoch noch viel homogener - Client-Server-Strukturen und die mit ihnen einhergehende Heterogenität gab es schlichtweg noch nicht. Komponenten für Mainframes waren damals zwar auch Bausteine einer Applikation, wurden aber in der gleichen, homogenen Software-Infrastruktur verwendet.
Friedliche Koexistenz
Komponentenbasierte Software-Entwicklung wird oft als eine komplett neue Methode oder sogar als die Ablösung von Objektorientierung gepriesen. Der Komponentenansatz ist aber eine Erweiterung von Objektorientierung, fokussiert allerdings mehr darauf, wie Komponenten interagieren, als auf deren Inneres. Er bedient sich dabei jedoch vieler Konzepte und Technologien, die objektorientiert sind. Die Definition der "Schnittstelle", zentral für Komponenten, ist zwar auch standardmäßiger, notwendiger Bestandteil eines OO-Konzepts. Doch muß im Rahmen von CBD mit noch mehr Sorgfalt vorgegangen werden, weil es das Ziel ist, plattformunabhängig austauschbare, plug-and-play-fähige Code-Einheiten zu erhalten. Es gibt aber eine Reihe von Einsatzbereichen, für die CBD keine oder kaum Bedeutung haben wird, besonders im Bereich Embedded Systems und Systemsoftware. Für betriebswirtschaftliche Systeme aller Couleur kann CBD jedoch das werden, was OO für technische Systeme schon ist: der schnellere Weg zu flexibleren Applikationen.
Äpfel und Birnen
Die Komponententechnologie nutzt viele in der Objektentwicklung verwendete Verfahren wie beispielsweise die Kommunikation über Schnittstellen. Ein direkter Vergleich beider Konzepte entspricht allerdings dem zwischen Äpfel und Birnen. Eine Komponente ermöglicht das Erstellen von Objekten und entspricht damit eher einer OO-Programmierklasse. Klasse wäre in der OO-Welt zum Beispiel "Kunde", das dazugehörige Objekt "Egon Meier" eine weitere Instanz der Klasse Kunde.
Der gravierende Unterschied ist allerdings, daß eine Klasse bei der objektorientierten Entwicklung in einer bestimmten Programmiersprache implementiert wurde und nur mit einer anderen Klasse derselben Programmiersprache kommunizieren kann. Komponenten unterschiedlicher Implementierungen können dagegen durch Infrastrukturelemente wie COM oder Corba interagieren.
Erstellung und Einsatz von Komponenten
Die Erstellung und der Einsatz von Komponenten gleicht dem Fertighausbau. Hier werden vorgefertigte Module verwendet, etwa für Wände oder Türen, die dann auf der Baustelle nur noch zusammengefügt werden müssen. Ganz ähnlich gestaltet sich die komponentenbasierte Entwicklung, zum Beispiel für ein Auftragsverwaltungssystem mit telefonischer Bestellannahme, Lagerbestandsverwaltung und Versandmitteilung ans Lager. Das Auftragsverwaltungssystem arbeitet nicht isoliert. Es wird höchstwahrscheinlich mit einer Anzahl anderer Systeme zusammenwirken, um Informationen zu erhalten (beispielsweise Kundendaten) und zur Verfügung zu stellen (etwa zur Rechnungsstellung). Ein großer Teil des Entwurfs würde sich mit der Beschreibung der Interaktionen zwischen Schnittstellen dieser Systeme befassen.
Das Auftragsverwaltungssystem stellt mehrere getrennte Teile von Verhalten zur Verfügung, die zusammenarbeiten, um die gesamte benötigte Funktionalität zu gewährleisten. Beispiele von Verhalten können die Prüfung der Kreditwürdigkeit eines Kunden oder die Lagerverwaltung sein. Es gibt mehrere Gründe, das Auftragsverwaltungssystem mit einer strengen Trennung dieser Teile zu entwerfen und aufzubauen: Einige könnten bereits vorhanden sein. Und eventuell gibt es kommerzielle Fertigpakete, die geeignet sind.
Angeklickt
Die Begriffe Komponente und Objekt werden heutzutage je nach Betrachtungswinkel häufig miteinander vermischt. Beiden Konzepten ist gemeinsam, daß sie flexiblere Applikationen mit der Möglichkeit zur Wiederverwendung bereits vorhandener Softwareteile versprechen. Der Komponentenansatz konzentriert sich dabei mehr darauf, wie einzelne Teile über standardisierte Schnittstellen interagieren können, als auf deren Inneres. Sie können in beliebigen Sprachen entwickelt sein und sind in verschiedenen Umgebungen wiederverwendbar. Objekte hingegen werden stark von den Standards der Implementierungssprache geprägt und sind nur an der richtigen Stelle lauffähig.
*Nicola Wulff ist Leiterin Marketing bei Sterling Application Development Software.