Den Aufwand, komplette Anwendungen von Grund auf zu entwickeln, kann sich heute kaum noch ein Programmierer leisten. Statt dessen kommen vorgefertigte Komponenten zum Einsatz, die sich den jeweiligen Anforderungen anpassen lassen. Rolf Heiler* beschreibt, welche Veraenderungen durch das Aufkommen eines Komponentenmarktes zu erwarten sind.
Bei den grossen Softwareherstellern ist man ja fast schon daran gewoehnt, dass angekuendigte Versionen verspaetet herauskommen. Dennoch arbeiten die Programmierer unter staendigem Zeitdruck. Gleichzeitig werden die Anwendungen immer komplexer, und die Preise sinken. Diesem Dilemma koennen Software-Entwickler nur entkommen, wenn sie verstaerkt vorgefertigte Komponenten einsetzen.
Daher ist die Verfuegbarkeit solcher Bausteine ein wichtiges Kriterium fuer die Wahl der Entwicklungsumgebung, denn noch sind diese Add-ins jeweils nur in einer Programmiersprache verwendbar. In verschiedenen Gremien haben sich interessierte Firmen zusammengeschlossen, um Schnittstellen auf binaerer Ebene zu schaffen, die von der verwendeten Programmiersprache und Entwicklungsumgebung unabhaengig sind.
Normen entstehen nicht am gruenen Tisch
Eine Schluesselposition nimmt dabei die Object Management Group (OMG) ein, an deren Vorgaben sich die verschiedenen Entwickler orientieren. Doch Normen lassen sich selten vom gruenen Tisch aus durchsetzen. Ueblich ist vielmehr, dass Firmenloesungen, die sich am Markt durchgesetzt haben, nachtraeglich zu allgemein anerkannten Standards erhoben werden.
Oft stellt sich auch die Frage nach der Normung erst bei einer gewissen Marktbedeutung. Eine solche hat Microsofts Windows zweifellos erlangt, daher werden die vom Hersteller vorgegebenen Schnittstellen verbindlich. Neben dem Component Object Model (COM) spielen hier die Dynamic Link Libraries (DLL) und das Object Linking and Embedding (OLE) eine Rolle.
Eingefuehrt wurden diese Bausteine von Visual Basic als Visual Basic Extensions (VBX). Der Programmierer klickt einfach das gewuenschte VBX an und zieht es mit der Maus in sein Entwicklungsfenster. Dann muss er allenfalls noch einige Zeilen Code hinzufuegen und hat bereits eine fertige Anwendung.
Weitergehende Moeglichkeiten als VBXe bieten die OLE Custom Controls (OCX). Sie werden auch in 32-Bit-Ausfuehrungen erhaeltlich sein, wohingegen die VBXe ueber das 16-Bit-Stadium nicht hinauskommen. In jeder Programmierumgebung, die die Unterstuetzung fuer OLE 2 implementiert hat, koennen Programmierer diese Bausteine einsetzen. Daneben gibt es noch andere Vorschlaege fuer solche Schnittstellen, die jedoch noch nicht so weit gediehen sind wie die OCXe und sich auch nicht auf eine so breite Marktbasis wie OLE stuetzen koennen.
Solche Komponenten koennen entweder haeufig benoetigte Funktionen ausfuehren, beispielsweise die eines Editors, oder sie stellen Spezialleistungen bereit, fuer die besonderes Know-how erforderlich ist wie etwa beim elektronischen Zahlungsverkehr. Vor allem in dem zuletzt genannten Fall muss sich der Programmierer darauf verlassen koennen, dass der Softwarebaustein richtig funktioniert, da er keinerlei Pruefmoeglichkeiten hat. Unverzichtbar ist daher grundsaetzlich eine vollstaendige Dokumentation aller Schnittstellen und Leistungsmerkmale. Schliesslich moechte kein Entwickler trojanische Pferde mit unbekanntem Inhalt in seine Anwendungen einfuegen.
Fuer den Auftraggeber einer individuellen Anwendung bleiben durch die Verwendung von Softwarebausteinen die Kosten und der zeitliche Aufwand in einem vertretbaren Rahmen. Der Entwickler kann aus den Komponenten relativ leicht einen Prototypen zusammenstellen, und daran gemeinsam mit dem Kunden Anforderungen und Sonderwuensche abstimmen. Dabei erweist sich dann so manche Feinheit als entbehrlich, die andernfalls doch wieder selbst programmiert werden muesste.
Die Zurueckhaltung, die sich ein Software-Entwickler bei der Programmierung eigener Zusaetze auferlegt, macht die Projekte ueberschaubarer und die Ergebnisse zuverlaessiger. Davon laesst sich auch ein Kunde durchaus ueberzeugen.
Standardisierung ist keineswegs gleichbedeutend mit Gleichmacherei - im Gegenteil. Erst einheitliche Schnittstellen schaffen die Grundlage fuer nuetzliche Vielfalt. Wenn Programme einander aehnlich werden, dann deshalb, weil die Hersteller sich gegenseitig die Features abschauen, und die Kunden ueberwiegend recht aehnliche Wuensche aeussern.
Die Rationalisierung der Herstellungsmethoden fuehrt, wie andere Rationalisierungen auch, vor allem zu kostenguenstigerer Produktion und mehr Flexibilitaet. Es ist jedoch unwahrscheinlich, dass dem Softwarekaeufer eines Tages nur noch eine Schachtel mit Softwarekomponenten uebergeben wird, aus denen er sich sein Programm selbst zusammenbaut.
Denkbar ist allerdings, dass er auch bei Standardsoftware Funktionen nachkaufen kann, die sich dank universeller Schnittstellen in das Programm einfuegen lassen. Benutzer freunden sich zunaechst mit den Grundfunktionen an und fuegen spaeter Leistungsmerkmale hinzu, die ihnen fehlen. Auch die Rueckgabe einer nicht benoetigten Funktion ist vorstellbar.
Ob es moeglich sein wird, Module von einem Hersteller gegen solche eines anderen auszutauschen, bleibt trotz einheitlicher Schnittstellen fraglich. Schliesslich muessen Bausteine, die auf binaerer Ebene vertraeglich sind, nicht auch auf hoeherer Ebene zueinander passen. Bei Autos sind ja auch die Gluehlampen zwischen verschiedenen Fabrikaten austauschbar, nicht aber die Leuchten.
Noch einen Schritt weiter ginge die Verteilung von Funktionen in Netzen. Das Programm als monolithischer Block existiert zwar schon seit den Zeiten nicht mehr, als die DOS-Grenze von 640 KB zu eng wurde, und Programme in Basisteile und Overlays aufgeteilt wurden. Doch weilte alles zusammen auf einer Platte, und jedes Programm hatte seine eigenen Overlays.
Mit Objekten kehrt das Marktprinzip ein
Mit verteilten Objekten wuerde hier sozusagen das Marktprinzip einkehren: Anbieterbausteine oder Server offerierten ihre Dienste und Kundenbausteine oder Clients naehmen diese in Anspruch. Zusaetzlich koennten die Anbieterbausteine auch ihrerseits Unterauftragnehmer einschalten, ohne dass der Auftraggeber davon notwendigerweise etwas erfahren muesste.
Wie auch der Textilhersteller die Hemden in Fernost naehen laesst, waere es dem aufrufenden Programm gleichgueltig, moeglicherweise nicht einmal bekannt, wo der Anbieterdienst residiert, den er in Anspruch nimmt. Damit wuerde das Netz zur Anwendung neuer Qualitaet, nicht mehr nur zum Transportmittel.
Da Standardsoftware immer leistungsfaehiger wird, stellt sich fuer viele Unternehmen die Frage, ob sich der erhoehte Aufwand fuer Individualsoftware tatsaechlich lohnt. Auch wenn die Antwort letztlich immer im Einzelfall gegeben werden muss, darf nicht vergessen werden, dass ein Standardprogramm in den seltensten Faellen so eingesetzt werden kann, wie es aus der Schachtel kommt. Zudem kommt es darauf an, wieviel von der mitgelieferten Funktionalitaet der Anwender jeweils braucht.
Auch wenn Funktionen in Standardprogrammen sozusagen vergleichsweise preiswert sind, muessen sie doch bezahlt und mit dem Aufwand fuer die Anpassung an die eigenen Anforderungen ins Verhaeltnis gesetzt werden. Wenn eine Individualsoftware mit modernen Werkzeugen erstellt wird, bleibt der Aufwand in einem vertretbaren Rahmen und schliesslich passt sie wie ein Massanzug.