Durch die Kombination und Veredelung von Rohstoffen, Bauteilen und Baugruppen ein Produkt zu erzeugen hat sich in vielen Branchen bewährt. Warum sollte man es also nicht auch für die Produktion von Software einsetzen? Einige Faktoren erschweren das Verfahren allerdings.

Die Verwendung von Bauteilen in der Softwareproduktion ist nicht neu. So wurden bereits in den ersten Jahren der Programmierung Makros oder Cobol-Strecken eingesetzt. Über immer komplexere Funktions- oder Objektbibliotheken ist man heute bei Komponenten angelangt.

Komponenten lediglich als höher integrierte Module zu interpretieren, würde diesen jedoch nicht gerecht werden. Sofern das Modul ausschließlich als geschlossener Baustein und in geschlossenen Systemen arbeiten kann, stellt es in der Tat nur einen weiteren Evolutionsschritt dar. Anders ist die Situation aber, wenn sich das Modul durch geeignete Parametrisierung in einer Vielzahl von Entwicklungssystemen verwenden, in eigene Anwendungen einfügen läßt und es unabhängig von Sprache, Betriebssystem und Hardware ist. Dann kann die Komponente auch universell Verwendung finden.

Und noch ein weiterer Aspekt zeigt sich beim Einsatz von Komponenten. Die grundlegenden Bausteine, etwa einzelne Befehle einer Sprache, sind technisch orientiert. Das Ziel jeglicher Programmentwicklung liegt aber in der Schaffung von Hilfsmitteln zur Lösung geschäftlicher Aufgaben. Bis zur fertigen Anwendung durchlebt der Code eine Metamorphose.

Werden nun Komponenten, die Ausdruck von komplexeren Programmkonstrukten sind, erstellt, müssen sich diese zwangsläufig vom technischen Programm-Statement in Richtung Anwendungslösung entwickeln. Und darin steckt sowohl der besondere Nutzen als auch die Schwierigkeit beim Design der Komponenten.

Trotz aller Hürden kommt entgegen allen pessimistischen Stimmen Bewegung in den Prozeß der Schaffung von Geschäftsobjekten. Hierunter werden geschlossene Softwaremodule verstanden, die in einer sinnfälligen Kombination fertige Anwendungslösungen ergeben. So ist es durchaus denkbar, Branchenlösungen auf Basis dieser Komponenten zu bilden.

Ein Beispiel: Die Kunden einer Bank sollen ein schriftliches Angebot über die Tilgung eines Kredits erhalten. Die zugehörigen Zahlenwerte sollen sowohl als einfache Tabelle als auch als Grafik dargestellt werden. Das Dokument besteht folglich aus einem Verbund verschiedenartigster Informationselemente: der Adresse, dem Anschreiben, der Tabelle mit dem Tilgungsplan sowie einer korrespondierenden Grafik. Die dahinterliegenden Programme sind folglich ein Datenbanksystem, ein Textsystem, ein Kalkulationsprogramm und schließlich ein Tool, das die Zahlenwerte in eine Grafik umsetzt.

Um ein fremdes Modul in die eigene Anwendung einzufügen, sind jedoch mehrere Integrationsaspekte zu beachten. Die Datenhaltung muß, sofern vom Modul benötigt, ein Interface zu den weiteren Datenbanksystemen ermöglichen. Gleiches gilt für die Verknüpfung der Benutzer-Schnittstellen mit weiteren Bildschirmelementen. Und schließlich muß ein Programmier-Interface für die Verbindung der zugekauften Codemodule mit eigenen Programmstrecken zur Verfügung stehen.

Damit die Komponenten die ihr zugedachte Aufgabe erfüllen können, müssen sie folgende Basisdienste erfüllen:

Sie muß erstens ihre Interfaces nach außen publizieren. Dies ist Grundlage für die Anbindung der Komponente an den umgebenden Code. Mittels der Interfaces müssen auch die Funktionen des Objekts publiziert werden. Nach außen verborgen bleibt allerdings die Implementierung des Objekts.

Sie muß zweitens auf Ereignisse angemessen reagieren. Da alle modernen Softwaresysteme grafisch orientiert und damit ereignisgesteuert sind, muß die Komponente Event-handling beherrschen. Durch entsprechende Customizing-Funktionen erfolgt schließlich die Integration der Komponente. Die Verknüpfung der Module kann auch über Scripting-Sprache erfolgen.

Betrachtet man die Komponente aus Sicht der Objektorientierung, so stellt sie ein Objekt beziehungsweise einen Objektverbund dar. Dessen Aussehen oder Verhalten wird durch Attribute bestimmt. Mittels Methodenaufruf erfolgt die Aktivierung der Codemodule von Objekten.

Wie kommen Komponenten und Objekte nun zusammen? Eine Komponente kann die Ausprägung eines Objekts im Sinne der objektorientierten Programmierung sein. Bei der Verknüpfung von Objekten rückt zwangsläufig ein weiterer Begriff ins Blickfeld - das Objektmodell. Hiermit ist sowohl die Integration und Kommunikation von Objekten untereinander als auch mit dem Wirtssystem gemeint.

Wie bereits erwähnt, muß das Softwaremodul über definierte Schnittstellen mit der Umgebung kooperieren. Das kann auf vielerlei Weisen geschehen. Auf der untersten Ebene befindet sich das Interface auf der Stufe des Quellprogramms. Darüber liegen die komplexeren Interfaces.

Microsoft beabsichtigt hier mit Active-X in Verbindung mit COM/DCOM einen Standard zu schaffen. Offener hingegen ist der Weg, den die OMG mit der Common Object Request Broker Architecture (Corba) beschreitet. Einen dritten Weg hat Sun mit der Remote Method Innvocation (RMI) zur Kommunikation zwischen Java-Applets und -Anwendungen eröffnet.

Komponenten sind nicht nur Bausteine zum Programmieren von Anwendungen. Sie sind komplexe, aber generische Module, die durch die Integration in den eignen Anwendungsrahmen ihre spezielle Funktion entfalten. Daneben ist allerdings von Compontware auch dann die Rede, wenn der umgekehrte Weg, nämlich die Zerlegung von ehemals geschlossenen Anwendungspaketen in universelle kleinere Baugruppen gemeint ist.

So planen etwa SAP oder Baan die Aufteilung ihrer großen Standardlösungen in kleinere Einheiten. Auch Microsoft hat das Office-Paket bereits in eine Vielzahl von OLE-Controls heruntergebrochen. Die Komponenten sind zwar noch nicht separat zu erwerben, können allerdings als solche von anderen Programmen angestoßen werden. Der Weg ist damit vorgezeichnet.

Parallel gibt es einen Trend zur Verwendung von Standardprogrammen aus der PC-Welt. Ob Textsysteme, Kalkulationsprogramme oder Datenbanken - aus allen entstehen mittlerweile Anwenderlösungen. In den seltensten Fällen werden jedoch alle Funktionen der Mammutprogramme tatsächlich benötigt. Meist genügt es, einen Bruchteil der benötigten Funktionsvielfalt bereitzuhalten.

Dennoch beanspruchen die Programme ihren Platz auf den Festplatten, im Arbeitsspeicher und wirken sich negativ auf die Last im Netz aus. Und genau an dieser Stelle setzt die Zerlegung der Anwendungspakete in Komponenten an. Die Module sollten klein und überschaubar sein. Durch ihre Kombination lassen sich maßgeschneiderte Lösungen erzeugen.

Java hat neue Perspektiven eröffnet

Wohin die Reise geht, zeigt das Internet. Statt großer und geschlossener Komplettpakete werden kleinere Module aus dem Netz auf den Client geladen. Die Browser dienen dabei als Containeranwendungen, die eine Runtime-Umgebung für die ausführbaren Codestückchen darstellen.

Diese treten in zwei Ausprägungen, als Java-Applets oder Active-X-Controls, auf. Applets sind auf Java aufsetzende Module und haben keine so enge Plattformbeschränkung wie Microsofts Windows-orientierte Alternative. Sie scheinen die prädestinierte Umsetzung der Komponententechnik zu sein. Schließlich handelt es sich bei Applets um relativ kleine und dynamisch geladene Module, die zur Laufzeit in der Umgebung des Wirtssystems ausgeführt werden.

Darin liegt aber auch ein wesentlicher Unterschied zu den bisher behandelten Komponentenvarianten: Die Verbindung zwischen dem Wirtssystem und der nachgeladenen Codemodule geschieht dynamisch durch Benutzeraktionen. Im Gegensatz dazu sind die Komponenten, die die Bausteine für eine fest verbundene Anwendung bilden, durch den Entwickler verknüpft. Die dynamische Verknüpfung einzelner und unabhängiger Applets aus dem Internet ist ungelöst.

Recht einfach ist es noch, wenn es sich bei den Applets um separate und abgeschlossene Arbeitsschritte handelt, etwa das schon klassische Tele-Banking oder die Pizzabestellung via Internet. Für sich genommen sind beide Anwendungen äußerst einfach und erfordern keine speziellen Integrationsarbeiten. Doch wenn das Applet Bestandteil eines größeren Ganzen sein soll, steigt der Aufwand. Soll die bestellte Pizza etwa mittels der separaten Banking-Komponente bezahlt werden, so müssen Kommunikations-Interfaces existieren.

Es besteht also durchaus die Verlockung, Programmentwicklung durch die Kombination vorhandener Bausteine zu betreiben. Gleichwohl ist festzuhalten, daß die Componentware am Anfang ihrer Entwicklung steht und sich in der Praxis erst bewähren muß.

AngeklicktEine PC-Software im Verbund mit anderen Programmen gilt als Komponente. Ebenso findet sich das Wort, wenn ein monolithisches Programm in voneinander unabhängige Module aufgebrochen wird. Die Definition von Componentware ist strittig. Es ist allerdings unstrittig, daß es nicht damit getan ist, in einem System ein Anwendungsmodul bereitzustellen. Der Nutzen einer Komponente entscheidet sich nicht an ihrer Granularität, sondern steigt mit ihrer Integration in eine Umgebung aus vielerlei Teilmodulen. Die Entwicklung um Java zeigt den Weg auf.

*Johann Baumeister ist Leiter Benutzerservice bei Pro 7 in München-Unterföhring.