Objektorientierte Software-Entwicklung ist der Koenigsweg zu transparenten und flexiblen Anwendungssystemen. Die Akzeptanz und Effektivitaet dieser Art der Systemerstellung haengt jedoch entscheidend davon ab, wie sie im Unternehmen eingefuehrt wird und inwieweit sie in der Lage ist, konventionell erstellte Applikationen zu integrieren. Ulrich Lindner* beschreibt Stolpersteine und Kreuzwege auf dem Weg zur Objektorientierung.

Das Verhaeltnis zur Informationstechnologie ist heute wesentlich nuechterner geworden, als es in den vergangenen Jahren war. Vom technischen Fetisch wurde die IT auf den Platz eines Werkzeugs verwiesen - eines Mittels, um Unternehmens- und Geschaeftsprozesse produktiver, transparenter, effizienter und flexibler zu gestalten.

In dieser Hinsicht hat sich die objektorientierte Software- Entwicklung in den vergangenen Jahren zu einem vielversprechenden Ansatz entwickelt. Auf dem Weg dorthin muessen IT-Organisationen allerdings mit vielen Stolpersteinen und Kreuzwegen rechnen.

Die objektorientierte Software-Entwicklung verspricht folgende Vorteile:

- Objekte sind das beste Modell fuer die reale Welt.

- Objektorientierung foerdert die Wiederverwendung.

- Die Entwicklung verteilter Anwendungen wird beherrschbar.

- Objektorientierte Software ist fuer Veraenderungen entworfen.

- Objektorientierung bringt bessere Qualitaet.

Wichtiger als die Auswahl einer Methode oder das Training der Entwickler ist eine durchdachte und wirksame Einfuehrungsstrategie. Sie muss Antworten auf folgende Fragen geben:

- Mit welchen Anwendungen sollte man beginnen, objektorientiert zu entwickeln?

- Welche Konsequenzen ergeben sich aus der Objektorientierung fuer die Plattform- und Anwendungsarchitekturen?

- Genuegt ein evolutionaerer Ansatz, oder bedarf es einer Neugestaltung der Softwareproduktionsumgebung (SPU)?

- Wie sind Teams fuer objektorientierte Software-Entwicklung zusammenzusetzen?

Grundsaetzlich gibt es zwei unterschiedliche Strategien, um neue Technologien einzufuehren. Die defensive Strategie sollte dann gewaehlt werden, wenn keine in objektorientierter Software erfahrenen Architekten und Designer beziehungsweise keine teamfaehige SPU verfuegbar ist. Die Risiken, die aus der neuen Technologie und vor allem aus fehlendem Know-how resultieren, lassen sich minimieren, indem zunaechst Pilotprojekte gestartet werden.

Fuer Pilotprojekte ist typisch, dass erste Entwuerfe der Architektur und der Klassenhierarchie spaeter meist ersetzt werden muessen. Ebenso typisch ist eine hohe Rate an Misserfolgen. Ein Fiasko laesst sich vermeiden, wenn gezielt mit "Durchstich"-Prototypen gearbeitet wird, also mit Ausschnitten aus der kuenftigen Anwendung, anhand derer sich die Funktionsfaehigkeit der Loesung beweisen laesst. Dieser Prototyp muss folglich alle unternehmenseigenen Architekturen sowie die Benutzeroberflaeche, die Speicherung persistenter Objekte und einen massgeblichen Teil der Klassenhierarchie beruecksichtigen.

Der Durchbruch fuer die Objektorientierung in der IT-Organisation laesst sich mit der defensiven Strategie selten erreichen. Um die Vorteile der Objektorientierung zu beweisen, bedarf es zumeist einer offensiven Strategie. Statt der Pilotprojekte werden hier unternehmenskritische Vorhaben gestartet, deren Neu- oder Weiterentwicklung dem Betrieb eine spuerbar bessere Wettbewerbsfaehigkeit verspricht.

Die Entwicklungszeiten sollten sich drastisch reduzieren, die Wartungskosten entscheidend vermindern und die Weiterentwicklungszyklen deutlich verkuerzen. Das Risiko eines Projektfiaskos laesst sich reduzieren, indem:

- Anwendung,

- Zusammensetzung des Teams,

- SPU und

- Architektur der Zielplattform richtig ausgewaehlt werden.

Hat die objektorientierte Softwareprogrammierung dann den Status eines strategischen Vorhabens, so muss die Zielplattform langfristig weiterentwickelt werden, damit konventionelle und objektorientierte Anwendungen nebeneinander existieren und moeglicherweise sogar zusammenarbeiten koennen. Es geht nicht nur um Fragen der Erweiterung der Netzwerk- und Rechnerarchitektur, sondern vor allem um Entscheidungen fuer die sich heute abzeichnenden Standards. An den Empfehlungen der Object Management Group (OMG) fuehrt dabei kein Weg vorbei.

Auch die Architektur der existierenden Anwendungslandschaft muss erweitert werden, damit Individualsoftware-Systeme und Standardanwendungspakete aus geschlossenen Welten mit der objektorientierten Software kooperieren koennen. Eine moegliche Loesung besteht im Einsatz von Schnittstellen-Software, die die Konvertierung zwischen Objekten und Daten beider Welten bewerkstelligen kann.

Der Job ist interessant, wird aber nicht einfacher

Zu entscheiden ist ausserdem, welche Anwendungssysteme langfristig "eingefroren" und "gekapselt" beziehungsweise welche Applikationen durch objektorientierte Neu- oder Re-Implementierungen ersetzen werden sollen.

Objektorientierte Software-Entwicklung ist nicht allein dadurch zu bewaeltigen, dass den Entwicklern C++- oder Smalltalk-Umgebungen an die Hand gegeben werden. Verteilte Zielumgebungen sowie massive Wiederverwendung und Integration in existierende Anwendungen machen den Entwicklerjob zwar interessanter, aber nicht einfacher.

Methoden- und Tool-Trainings fuer die an strukturierte Entwicklung gewoehnten Software-Entwickler sind sicher notwendig. Das Vorgehensmodell und damit die Projektorganisation fallen anders aus als bei der strukturierten Entwicklung. Evolutionaeres Prototyping, Iterationen zwischen Design und Realisierung sowie eine massive Wiederverwendung, die spaetestens mit dem Design beginnt, sind charakteristische Merkmale einer objektorientierten Vorgehensweise. Meist gehoert es mit zum Projektauftrag, wiederverwendungsfaehige Klassen sowie Komponenten und Loesungsmuster fuer Nachfolgeprojekte zu entwickeln.

Wie sollten OO-Teams konfiguriert werden? Ideal ist folgende Zusammensetzung:

- Fuer den Projektstart muss ein in der objektorientierten Anwendungsentwicklung erfahrener Systemarchitekt zur Verfuegung stehen, der detaillierte Kenntnisse ueber die Zielplattform und die Anwendungsarchitektur des Unternehmens mitbringt.

- Eine notwendige Voraussetzung fuer den Projekterfolg ist zudem ein ebenfalls OO-erfahrener Projektmanager.

- Nur ein im objektorientierten Entwurf erfahrener Chefdesigner kann Architektur und Klassenstruktur der Anwendung so gestalten, dass eine gute Wartbarkeit gesichert ist.

- Last, but not least werden Systemanalytiker benoetigt, die nicht nur das Fachwissen besitzen, sondern auch die Konzepte der objektorientierten Modellierung beherrschen.

Fuer die Projektplanung ist zu beruecksichtigen, dass die erfahrenen Experten viel Zeit fuer die Kommunikation mit den "objektorientierten Neulingen" benoetigen. Je nach Groesse des Teams koennen das bis zu 30 Prozent des veranschlagten Zeitrahmens sein. Die Wiederverwendung erfordert ebenfalls einen erhoehten Kommunikationsaufwand.

Ausserdem verringert sich der Aufwand keineswegs um denselben Prozentsatz, den die wiederverwendete Software am Gesamtumfang der Applikation ausmacht. Wenn zum Beispiel 30 Prozent der neuen Anwendung durch die Wiederverwendung existierender Software geschaffen werden koennen, vermindert sich der Entwicklungsaufwand nicht ebenfalls um 30, sondern hoechstens um 20 Prozent.

Die IT-Organisationen stehen heute vor der Entscheidung, entweder eine objektorientierte SPU aus einzelnen Werkzeugen selbst aufzubauen oder einen Loesungsanbieter zu suchen, der eine komplette Umgebung in petto hat. Objektorientierte Technologie fuer Neuentwicklung muss von der Analyse ueber das Design bis hin zur Implementierung alle Arbeiten der objektorientierten Software- Entwicklung unterstuetzen. Die Konstruktion von Anwendungen aus wiederverwendbaren Klassen, Komponenten und Loesungsmustern erfordert vor allem eine Werkzeugunterstuetzung fuer das Wiederauffinden und Wiederverwenden. Ein Online-Repository kann alle Tools miteinander integrieren (vgl. Abbildung 1).

Werkzeuge fuer objektorientierte Analyse und Design sind dafuer vorgesehen, objektorientierte Modelle der Software zu entwickeln. Die Methoden nach James Rumbaugh und Grady Booch beherrschen heute zum grossen Teil den Markt. Weil aber auch sie sich in den kommenden Jahren stark veraendern werden, muessen die eingesetzten Werkzeuge die Aenderungen schnell nachvollziehbar machen. Eine leistungsfaehige Meta-CASE-Technologie ist dafuer eine notwendige Voraussetzung.

Es gibt keinen Paradigmenbruch zwischen dem objektorientierten Designmodell und dem objektorientierten Quelltext. Dadurch wird es moeglich, wesentliche Informationen wie die Definition der Klassen und die Beziehungen zwischen diesen in beiden Darstellungen konsistent zu halten. Generatoren sind in der Lage, aus den Klassen und Beziehungen der Designmodelle Quellcode fuer C++, Smalltalk oder Object Cobol zu erzeugen. Sogenannte Parser leiten umgekehrt aus Quellcode-Klassen die Klassen fuer das Designmodell ab. So wird ein iterativer Wechsel zwischen Design und Realisierung moeglich, wie er fuer objektorientierte Software- Entwicklung typisch ist. Das Parsen ist auch die Technik, durch die sich Klassen aus Klassenbibliotheken fuer das Design erschliessen lassen.

Gegenwaertig entwickelt sich ein Markt fuer Middleware-Systeme, fuer branchenbezogene Klassenbibliotheken bis hin zu Loesungsmustern (Patterns) fuer ganze Problemklassen. Dazu kommen Rahmenwerke (Frameworks) fuer die Architektur von Anwendungssystemen ganzer Branchen. Diese Entwicklung berechtigt zu der Hoffnung, dass in naher Zukunft bis zu 70 Prozent der Kosten bei Neuentwicklungen durch massive Wiederverwendung eingespart werden koennen.

Die Wiederverwendung wird erst durch Wiederauffindungstechniken (Reuse Management) ueberhaupt beherrschbar. Um dieses Ziel zu erreichen, sollten es die Wiederverwendungswerkzeuge erlauben, Klassen, Komponenten und auch Patterns aus semantischer Sicht zu klassifizieren.

Prototyping- und Entwurfswerkzeuge fuer grafische Benutzeroberflaechen gehoeren ebenfalls zu einer objektorientierten Entwicklungsumgebung. Entweder werden GUI-Builder oder GUI- Klassenbibliothek der jeweiligen C++- beziehungsweise Smalltalk- Programmierumgebung genutzt, oder ein spezielles Prototyping- Werkzeug muss diese Aufgabe uebernehmen.

Die gaengigen Programmierumgebungen fuer C++, Smalltalk oder auch Object Cobol sollten in der Lage sein, ihre Ergebnis-Files in einem Repository abzulegen. Ausserdem ist es wichtig, dass sich aus den Objektmodellen Schemata fuer relationale Datenbank-Management- Systeme generieren lassen, damit die Objekte dort verwaltet werden koennen.

Ziel: Anwendungserstellung aus Komponenten

Die Zielstellung des objektorientierten Redevelopments reicht von der Wartung ueber das Redesign und die objektorientierte Kapselung existierender Software bis hin zur Montage objektorientierter Softwaresysteme am Bildschirm beziehungsweise allgemein zur Anwendungserstellung aus Komponenten.

Die objektorientierte Kapselung (vgl. Abbildung 2) soll konventionelle Cobol- oder C-Anwendungen so aufbereiten, dass sie sich objektorientiert weiterentwickeln lassen. Das geschieht heute allgemein durch die Technik des Wrapping, bei der die alten Anwendungen ein objektorientiertes Interface erhalten.

Um verteilte Anwendungen zu konstruieren, sind Middleware-Produkte wie APPC (Advanced Program-to-Program Communication), CICS (Customer Information Control System) und

EHLLAPI (Emulator High Level Language API) erforderlich, die den Nachrichten- und Objektaustausch zwischen den Teilapplikationen ermoeglichen. Auch dafuer gibt es Wrapper.

Relationale Datenbank-Betriebssysteme werden in den kommenden Jahren noch die dominierenden Datenhaltungssysteme fuer objektorientierte Anwendungen bleiben. Von daher werden auch Techniken benoetigt, mit denen sich SQL-Zugriffe auf relationale DBMS (Database Management System) objektorientiert kapseln lassen. Bevor aus Cobol-Programmen objektorientierte Applikationen werden koennen, muessen sie oft erst mit neuen, "sauberen" prozeduralen Schnittstellen versehen werden. Das ist die Aufgabe eines Redesign-Werkzeugs. Redesign ist auch erforderlich, wenn eine Host-Anwendung auf eine Client-Server-Architektur uebertragen werden soll.

Strukturierte Methoden und Techniken sind erprobt

Mittelfristig werden strukturierte Methoden weiterhin eine gewichtige Rolle spielen. Die Ursachen dafuer sind:

- Die strukturierten Methoden und Techniken sind erprobt und haben sich bewaehrt. Sie unterstuetzen die Entwickler schon heute durchgehend von der Analyse bis zur Codegenerierung.

- In allen IT-Organisationen existieren wertvolle Erfahrungen mit der Anwendung strukturierter Methoden und Techniken. Kein Unternehmen kann diese Erfahrungen und die umfangreichen Investitionen in die Ausbildung seiner Mitarbeiter kurzfristig voellig durch neue Ausbildung und Erfahrungen ersetzen.

- Die Erfahrungen aus der Einfuehrung der strukturierten Methoden und Techniken zeigen, dass es mehrere Jahre dauert, bis Methoden und Werkzeuge die entsprechende Reife fuer den professionellen Einsatz haben und sich als De-facto-Standards am Markt durchsetzen. Der sichere Weg in die Objektorientierung fuehrt deshalb ueber eine mehrjaehrige schrittweise Einfuehrung von Methoden und Werkzeugen.

Fazit: Die IT-Organisationen muessen sich auf eine Koexistenz zwischen strukturierter und objektorientierter Anwendungsentwicklung einstellen.

* Ulrich Lindner ist Mitarbeiter in der strategischen Planung der Softlab GmbH in Muenchen.