Objektorientierte Softwaretechniken werden immer beliebter, allerorten spriessen entsprechende Projekte aus dem Boden. Das Schulungs- und Beratungsgeschaeft boomt. Objekte im harten Einsatz, dort wo kritische Geschaeftsprozesse betroffen sind, oder gar das Tagesgeschaeft auf dem Spiel steht, findet man allerdings noch immer relativ selten. Einige Unternehmen haben allerdings selbst bei grossen Software-projekten objektorientierte Technik erprobt. Michael Wagner* beschreibt diese Beispiele und schildert die Erfahrungen, die diese Pilotanwender gewonnen haben.
Die objektorientierten Softwaretechniken treffen in der Wirtschaft entweder auf Begeisterung oder auf massive Kritik. Die Optimisten unter den Anwendern implementieren fleissig und experimentieren an der vordersten Front der Technologie. Die Skeptiker maekeln an den verfuegbaren Produkten herum, testen neue Software im kleinen Kreis und wagen den harten Einsatz nicht.
Je nach Stellung der Protagonisten in den Unternehmen und Institutionen wird Objektorien-tierung entweder in kleinen Projekten mit Alibifunktion beziehungsweise sehr innovativen Pilotprojekten eingesetzt, oder es werden strategische Systeme entwickelt, die als Basis fuer neues oder neuartiges Geschaeft dienen. Zur ersten Klasse gehoeren die Maulwuerfe, die C++ nur als besseres C einsetzen und fuer die ANSI C das hoechste der Gefuehle darstellt.
Die zweite Klasse fuehren Enthusiasten an, denen keine Entwicklung neuer Softwarewerkzeuge schnell genug voranschreitet. Die Visionaere unter den DV-Verantwortlichen wiederum haben es teilweise geschafft, die Unternehmensleitung von der strategischen Bedeutung der objektorientierten Technologie zu ueberzeugen. Diese Unternehmen haben sich bereits mit Hilfe der Objektorientierung einen Vorsprung vor ihrer Konkurrenz erarbeitet oder sind gerade dabei. Einige dieser Unternehmen sind auch in Deutschland zu finden.
Mit dem Anstieg der Dokumentationsanforderungen informationstechnischer Produkte war die Aufgabe der entsprechenden Abteilung von Digital Equipment nicht mehr zu schaffen. Die komplizierten Erklaerungen fuellten armdicke Handbuecher, die nicht minder kompliziert zu erstellen waren. Man arbeitete mit einem veralteten System von Teilenummern, die keiner den Produkten entsprechenden Systematik mehr folgten. Jede Dokumentation eines neuen Produktes, sogar jede neue Variante eines vorhandenen Produktes musste voellig neu aufgebaut werden, da die bisherigen Hierarchien nicht verwendet werden konnten.
Ein neues Softwaresystem fuer diese Aufgabe war daher unausweichlich. Die neue Software sollte aber zugleich internationalisiert sein, um auch in anderen Laendern einsetzbar zu sein und Handbuecher in fremden Spra-chen ebenfalls erstellt werden koennen. Digital entschloss sich zu einer Eigenentwicklung in C++ unter Motif mit regelbasierten Teilen in OPS5 und Speicherung der Objekte in der objekt-orientierten Datenbank Objectivity. Das Projekt fuehrte ein kleines, aber hocheffektives Team von drei Spezialisten durch. Vom Beginn des Entwurfes bis zum Einsatz verstrichen 18 Monate.
Kern des Systems ist eine neu gestaltete Produktnummer, die sich nun mit dem physikalischen Produkt in Einklang bringen laesst. Das Team erzeugte zwar nur etwa 30 Klassen, diese bedingen sich aber in einer komplizierten Hierarchie mit Versions- und Variantenverwaltung gegenseitig. Probleme gab es allerdings bei der Uebergabe des Systems vom Entwicklungs- an das Wartungsteam, das nicht genuegend auf die neue Aufgabe vorbereitet war. Ein fruehes Einbinden nachgeordneter Arbeitsgruppen in den Entwicklungsprozess ist also unbedingt notwendig.
Ein anderes Problem hatte das Umweltministerium des Landes Baden- Wuerttemberg: Man hatte die Erfassung von Umweltdaten weitgehend automatisieren koennen, aber die Datenstroeme kamen nicht nur in unterschiedlichen Datenformaten herein, sondern enthielten auch unterschiedliche Messgroessen und deckten nicht annaehernd identische geografische Einheiten ab. Kurz gesagt: Man versank in einem Datenchaos.
Schon bald war klar, dass diese Mengen heterogener Informationen nicht auf herkoemmlichem Wege zu bewaeltigen waren. Man war gezwungen, ein voellig neues Umweltinformations-System zu entwickeln, das unterschiedliche Quellen vereinheitlichen und zugleich ein geografisches Informationssystem (GIS) sein sollte. Erschwert wurde die Situation dadurch, dass man fuer die Erfassung und Auswertung der Umweltdaten auf die im Einsatz befindlichen Produkte von Drittanbietern zurueckgreifen musste.
Die Integration der verschiedenen Produkte war neben der Vereinheitlichung der Datenstroeme eine der Hauptaufgaben des Entwicklungsprojektes. Diese zwei gordischen Knoten liessen sich nur durch eine objektorientierte Hierarchie von Metadaten loesen, mit denen die Konvertierung der Datenformate und Masssysteme steuerbar war. Ein Team von 15 Software-Entwicklern benoetigte fast ein Jahr, um diese Aufgabe zu bewaeltigen. Sie entwickelten dafuer ein eigenes objektorientiertes Repraesentationssystem.
Die heute im Einsatz befindliche Software ermoeglicht es den Analytikern, am zentralen Farbbildschirm aktuelle Messwerte abzufragen und gemaess ihrer Intensitaet als farbliche Schattierung ueber eine Landkarte zu legen. Durch den Vergleich mehrerer Messgroessen lassen sich Korrelationen zwischen Schadstoffen erkennen und etwa die Auswirkungen des sauren Regens in der Hauptwindrichtung von Industriegebieten ermitteln. Das System erfreut sich bei den Benutzern grosser Beliebtheit und wurde inzwischen auch von anderen Umweltstellen adaptiert.
Als Dienstleister fuer kleine und mittelstaendische Unternehmen ist die Stuttgarter Taylorix AG stark auf die Qualitaet ihrer Softwarewerkzeuge angewiesen. Als sich Ende der 80er Jahre abzuzeichnen begann, dass eine neue Softwaregeneration notwendig werden wuerde, dachte man schon frueh ueber objekt-orientierte Ansaetze nach. Fuer diese im Sinne der Unternehmensstrategie kritischen Anwendungen waren Kriterien wie Zuverlaessigkeit, Portierbarkeit, Wartungsfreundlichkeit und Erweiterbarkeit entscheidend.
Man entschloss sich fuer die Entwicklung einer zukunftsweisenden Klassenbibliothek als Basis fuer die weitere Anwendungsentwicklung. Als Zielsysteme standen zunaechst Presentation Manager unter OS/2, Windows und Unix System V, Release 4, mit Motif fest. Als Implementierungssprache fiel die Entscheidung aus Gruenden der Portierbarkeit auf C++. Man entwickelte unter dem Namen "Touch" eine dreistufige Klassenbibliothek, die neben einer einheitlichen grafischen Benutzeroberflaeche und der Anbindung diverser Datenbanksysteme auch die Grundfunktionalitaet der geplanten Anwendungen bereitstellt.
Die Implementierung der Klassenbibliothek und die nachfolgende Anwendungsentwicklung waren so erfolgreich, dass bereits weitere Entwicklungen auf Basis dieses Werkzeuges in Angriff genommen wurden. Unter diesen Voraussetzungen faellt es leicht, mit Hilfe objektorientierter Analyse und Designmethodik in kuerzester Zeit Softwaresysteme zu entwickeln, die neue Geschaeftsfelder unterstuetzen oder besondere Anpassungen an Kundenwuensche enthalten.
Die Erfahrungen aus diesen und anderen objektorientierten Softwareprojekten in Deutschland lassen sich in wenigen Saetzen zusammenfassen: Der Einsatz kleiner, aber hochmotivierter und leistungsfaehiger Teams ist entscheidend fuer den Erfolg eines Projektes. Externes Training und internes Coaching sind auf keinen Fall zu vernachlaessigen. Idealerweise befindet sich ein interner Mentor vor Ort, der weniger erfahrene Softwerker anleiten kann.
In ersten objektorientierten Projekten zeigten sich so gut wie nie Einsparungen. Die Vorhaben gerieten eher aufwendiger und teurer als urspruenglich geplant, da es zunaechst die doch recht steile Lernkurve der Objekt-orientierung zu ueberwinden galt. Die Wiederverwendbarkeit von Softwarekomponenten zahlt sich fruehestens ab dem zweiten Projekt aus. Dann, so verdeutlicht das Beispiel Taylorix, lassen sich allerdings ungeahnte Synergien erzielen.
Ein Vorteil der Objekt-orientierung zeigt sich jedoch von Anfang an: Das Design der Software wird klarer, und - vielleicht das wichtigste Argument - Entwickler und Anwender sprechen ueber (nahezu) dieselben Dinge. Objekte sind sehr viel einfacher zu verstehen und sehr viel naeher an der Aufgabenstellung des Endanwenders als zum Beispiel relationale Datenbankschemata.
Die Einbindung der Endanwender in fruehen Phasen der Entwicklung ist daher nicht nur sinnvoll, sondern im Sinne der Benutzerakzeptanz notwendig.
Vorbehalte gegen objekt-orientierte Methoden entstehen meist durch ein falsches Herangehen. Meist bemueht sich eben kein Kern von wirklichen Koennern um die Grundlagen fuer das weitere Design. Prototypen lassen sich in der Folge zwar sehr schnell erstellen, muessen dann aber oft wegen mangelnder Tragfaehigkeit weggeworfen werden. Vorausschauend erstellte Prototypen benoetigen hingegen deutlich mehr Entwicklungszeit, sind aber ausbaufaehiger und lassen sich als Grundlage fuer weitere Entwicklungen heranziehen.
Jene Anwender, die ihr Lehrgeld bei objektorientierten Technologien bereits gezahlt haben, sparen nicht mit Kritik, vor allem an den verfuegbaren Werkzeugen. Objektorientierte Methoden werden mit umfangreichen grafisch gestuetzten Tools verkauft, aber nur selten bieten diese Systeme eine Unterstuetzung fuer die Implementation, die ueber Spielereien am Design hinausgeht. Kaum zu finden ist ein Round-Trip-Design, das Aenderungen am generierten Quelltext wieder in die Designrepraesentation zurueckspielen laesst. Entgegen allen Beteuerungen der Anbieter fuehlen sich die Entwickler in einer Einbahnstrasse gefangen, in der man zwar mit schnellen Flitzern in Richtung Codegenerierung fahren kann, zurueck aber zu Fuss gehen muss.
Der zweite Kritikpunkt spricht den Mangel an verlaesslichen objektorientierten Standards an. Kaum ein Projekt, das nicht unter dem Rekompilierungszwang bei der C++-Entwicklung leiden und ueber nicht eingehaltene Versprechen der Wiederverwendbarkeit von kommerziellen Klassenbibliotheken klagen wuerde. Die grosse Popularitaet von C++ bei gleichzeitiger Unvollkommenheit der Implementierungen ist die Achillesferse der Objekt-orientierung. Wenn hier nicht schnellstens Abhilfe geschaffen wird, koennte sich die positive Grundeinstellung vieler Anwender aendern.
Trotz harscher Kritik ziehen die meisten Anwender eine positive Bilanz ihrer Erfahrungen mit der Objektorientierung. Wenn die Erwartungen - insbesondere bei den ersten Projekten - nicht zu hoch geschraubt werden, duerfte wohl kaum jemand von ihr enttaeuscht werden. Nach allgemeiner Einschaetzung hat die Objektorientierung aber noch einen weiten Weg vor sich, der ueber Standards und die starke Verbesserung der Werkzeuge zur allgemeinen Akzeptanz fuehrt. Fuer viele Anwender besteht allerdings kein Zweifel, dass sich Objektorientierung in den 90er Jahren zur Software- Entwicklungsmethode der Wahl entwickeln wird.
* Michael Wagner promoviert ueber objektorientierte Groupware an der TU Muenchen und ist als freier Berater und Journalist taetig.
Ein Round-Trip-Design ermoeglicht die Uebernahme von Aenderungen im (generierten) Quelltext in das Ausgangsdesign.