Andreas Rothe, Landesgirokasse, Stuttgart
Die schnellen Technologiewechsel in der Software-Entwicklung machen es schwer, auf dem Stand der Technik zu bleiben. Allein die Neuerungen auf dem Gebiet der Netzwerke oder im Bereich Client- Server-Computing sind gewaltig und kaum noch zu ueberblicken. Deshalb wird es immer wichtiger, zumindest die Entwicklungen neuer Basistechnologien wie die der Objektorientierung oder der Komponententechnik zu verfolgen.
Ein Blick auf die Anbieter von Programmiersprachen und Anwendungsentwicklungssystemen zeigt deutlich, dass sich dort der OO-Ansatz bereits auf breiter Front durchgesetzt hat. Soll sich also der technologisch ohnehin hinterherhinkende Entwickler ueberhaupt noch mit der Objektorientierung beschaeftigen, wenn doch bereits die naechste Technologie, die Komponententechnik, von immer mehr Anbietern propagiert wird?
Ob diese Art der Software-Entwicklung eine Zukunft hat, haengt allerdings sehr stark von den Normungserfolgen der Object Management Group (OMG) ab, die sich darum bemueht, die Kommunikation zwischen Komponenten auch ueber verschiedene Hardwareplattformen hinweg zu ermoeglichen.
Obwohl noch nicht alle Standards definiert sind, fuellt sich der Komponentenkasten zum Beispiel fuer Banken dank endlich festgelegter Schnittstellen langsam, aber stetig. Ausserdem werden dem Endanwender mit der Verbreitung von Office-Paketen die notwendigen "Programmierumgebungen" gleich mitgeliefert. Brauchen wir also in Zukunft fast ueberhaupt nicht mehr zu programmieren, sondern lediglich "Software-Lego-Bausteine" alias Komponenten sinnvoll zu kombinieren oder, wie Microsoft es nennt, zusammenzukleben? Sollten wir gleich in die naechste Technologie einsteigen und die Objektorientierung auslassen?
Sicher nicht, denn letztere liefert die Basiskonzepte fuer die Komponententechnik. Zumindest hilft sie, diese Technik besser zu verstehen und anzuwenden. Die Objektorientierung erfordert, analog zum Konzept der strukturierten Programmierung, einen voellig neuen Entwurfs- und Ordnungsansatz. Nur derjenige, der seine Software nach diesem Ansatz strukturiert, wird ueberhaupt erkennen koennen, wo ein OO-Konzept sinnvoll ist.
Dabei ist es wesentlich, nicht mehr in Programm und Unterprogrammen, sondern in Objekten zu denken, die miteinander kommunizieren. Auf diesem Denkmuster von miteinander in Beziehung stehenden Client- und Server-Objekten baut letztlich auch die Komponententechnik auf. Eigenschaften werden auf Komponenten (Server) verteilt, und ein Client ruft sie in der richtigen Reihenfolge ab. Die Server-Objekte "wissen", wie diese Leistungen zu erbringen sind. Die Objektorientierung liefert fuer das Denken in Clients und Servern eine fundierte Grundausbildung und direkte Unterstuetzung.
Denn wer die Komponententechnik nutzen moechte, wird schnell feststellen, dass eine Komponente vielleicht nur 80 Prozent dessen abdeckt, was benoetigt wird, oder dass bestimmte Leistungen nicht so erbracht werden wie gewuenscht. Erst die Faehigkeit von Objekten, Eigenschaften zu vererben, macht es moeglich, Komponenten mit spezifischeren Merkmalen auszustatten, sie zu ergaenzen oder zu redefinieren, ohne innerhalb des Codings Aenderungen vornehmen zu muessen. Bei einer neuen Version der Komponente bleiben die Modifikationen erhalten. Das hinter der objektorientierten Vorgehensweise stehende Denkmodell ist dabei wichtiger als die Syntax einer bestimmten Sprache.
Um moeglichst viele Komponenten beziehungsweise Objekte wiederverwenden zu koennen, muss der Istzustand unter OO- Gesichtspunkten analysiert werden. Zwar unterstuetzen die gaengigen Analysetechniken das Denken in Komponenten und Objekten, aber bereits vorhandene Komponenten werden kaum beruecksichtigt.
Bleibt noch zu fragen, wie Objektorientierung, Komponententechnik und notwendige Standards wie ODBC, OLE, DCE etc. einer moeglichst breiten Basis von Anwendungsentwicklern vermittelt werden koennen, damit diese nicht jedesmal selbst etwas entwickeln, was bereits am Markt verfuegbar ist, oder sich durch Nichtnutzung von Standards diesen Weg von vornherein verbauen.
Bisher wurde zuviel ueber die Vor- und Nachteile der Technologie selbst gesprochen und zuwenig darueber, wie der immer rasanter werdende Wechsel zwischen den Technologien noch nachvollzogen werden kann. Hier sind neue Ideen der Aus- und Weiterbildung gefragt wie Softwarelabors, in denen Mitarbeiter zusammen mit Technologiegurus ein Projekt durchfuehren. Solche Ansaetze sind mit traditionellen Ausbildungskonzepten zu verknuepfen und rasch in die Praxis umzusetzen. Denn wenn die breite Basis der Anwendungsentwickler die neuen Technologien nicht versteht und anwendet, ist weder die Objektorientierung noch die Komponententechnik sinnvoll.