Immer wenn eine neue Welle durch die DV-Welt rollt, ueberbieten sich die Hersteller mit Uebertreibungen, waehrend die Skeptiker vor ueberzogenen Hoffnungen warnen. Stephan Wolf* schildert anhand eines Projektes, unter welchen Umstaenden der Einsatz objektorientierter Techniken in der Praxis zum Erfolg fuehrt.

Weder bei den OO-Befuerwortern noch bei den Bewahrern traditioneller Denkweisen lassen sich mittlerweile die Weisen von den Scharlatanen unterscheiden. Eine sachliche Beurteilung des Status quo wird dadurch extrem schwierig. Deshalb soll dieser Beitrag einmal die praktische Seite des Methodenstreits beleuchten, indem er ein Projekt vorstellt, bei dem ausschliesslich objektorientierte Techniken und Werkzeuge zum Einsatz gekommen sind.

Geschildert werden Hoehepunkte und Fehlerfallen im Projekt "Top Control", das die Debis Systemhaus MGI GmbH gemeinsam mit der Innovative Software GmbH durchgezogen hat. Zwar konnten auch in diesem Projekt nicht alle Probleme mit Hilfe der Objektorientierung geloest werden; trotzdem entstand eine gute Software, die so nicht anders haette entwickelt werden koennen. Das Fazit sei vorweggenommen: Objektorientierung macht gute Mitarbeiter besser, sie will aber gelernt sein.

Gegenstand des Projekts war Top Control - ein PC-basiertes System zur Steuerung und Ueberwachung des Rechenzentrums. Die Einsatzschwerpunkte des Systems bilden die Aufgabenbereiche Remote-Operating, Home-Operating, automatische Konsolueberwachung, automatische Ueberwachung der RZ-Infrastruktur (beispielsweise der Klimaanlage) und automatische RZ-Steuerung inklusive Steuerung der Infrastruktur.

Die bis dato aktuelle Version 3.3 wurde aus einer urspruenglich zugekauften, in Basic geschriebenen Software weiterentwickelt. Wartung und Pflege der Software hat Debis beim Kauf der Software vom Hersteller uebernommen und einem internen Entwicklerteam uebergeben, das sich zunehmend mit technischen Details, Problemen und Hindernissen beschaeftigt.

Die Anwender forderten immer mehr Leistungsmerkmale, weshalb die Erweiterung des Basic-Codes immer aufwendiger wurde. Bei einzelnen Anforderungen war dann auch schnell klar, dass der Aufwand fuer die spezielle Aenderung jedes Mass ueberschreiten wuerde.

Andererseits befindet sich auch Debis im Wettbewerb mit anderen Anbietern. Die Software einzufrieren oder gar aufzugeben, stand deshalb niemals ernsthaft zur Debatte. Somit handelt es sich um eine typische Altlast, also um eine Anwendung, die zwar dringend benoetigt wird, aber kaum noch zu pflegen ist. Als Loesung empfahl sich die Neuentwicklung von Top Control unter Einbeziehung der geforderten zusaetzlichen Leistungsmerkmale.

Mit der Erstellung des Pflichtenheftes wurde das Top-Control-Team beauftragt. Zu den allgemeinen Forderungen wie Korrektheit, Stabilitaet, Wartungs- und Benutzerfreundlichkeit gesellte sich Folgendes:

- Flexibilitaet: Die Software muss unterschiedliche RZ- Konfigurationen unterstuetzen, also parametrisierbar sein.

- Plattformunabhaengigkeit: Das System soll weder von einer Hardware noch von einem Betriebssystem abhaengen. Ausserdem hat es modular aufgebaut und erweiterbar zu sein.

- Internationalitaet: Die Software soll spaeter in mehreren Sprachen angeboten werden, weshalb die Programmebene streng von der Darstellungsebene (Benutzeroberflaeche) getrennt sein muss.

- Connectivity: Die stationaere Einheit, also der fest mit einem RZ verbundene PC, muss mehrere Host- sowie Remote-PCs gleichzeitig bedienen koennen.

- Wachstum: Die Vernetzung mehrerer stationaerer PCs zu einer Top- Control-Einheit darf nicht von der Anwendung abhaengen. Diese Forderung resultiert aus der Ueberlegung, dass die Performance eines einzelnen stationaeren Systems stark von der Anzahl der verbundenen Host- und Remote-Systeme beeinflusst wird. Um auch groesseren Anforderungen entsprechen zu koennen, soll deshalb ein Verbund stationaerer PCs in einem LAN moeglich sein - fuer den Anwender transparent.

- Security: Ein unkontrollierter und unautorisierter Zugriff auf die Rechner des RZs darf nicht moeglich sein.

- Betriebssicherheit: Auch bei Stromausfaellen muss die Betriebssicherheit gewaehrleistet bleiben. Hinzu kommt die Forderung nach einem automatischen Rebooten, wenn der Stromausfall behoben ist und die System-Events protokolliert werden.

- Migration: Bestehende Konfigurationen sind in Konfigurationsdateien der Version 3.3 abgelegt. Diese Konfigurationen sollen auch bei einem Release-Wechsel gueltig bleiben.

- Ergonomie: Top Control soll eine moderne grafische Benutzeroberflaeche und eine kontextsensitive Hilfe erhalten.

Besondere Bedeutung kam der Programmiersprache zu. Die Vorgabe war, einerseits hardwarenah, andererseits unabhaengig von der Hardware und dem Betriebssystem zu programmieren. Diesen scheinbaren Widerspruch sollten die Entwickler ueber das Verkapseln von Systemfunktionen aufloesen. Aus diesem Grund wurde C++ gewaehlt.

Der Entwurf hatte zum Ziel, die zunaechst grobe Aufwandsschaetzung durch Festpreise zu ersetzen, zu denen externe Softwarehaeuser einen Beitrag zum Gesamtsystem leisten koennten. Zunaechst erfolgte der Systementwurf in einem sogenannten Schichtenmodell. Diese Entwurfstechnik erlaubt es, die Anwendung als Summe von System- Events zu beschreiben. Die oberste Schicht definiert allgemein die Summe der Events, die der Anwender ausloesen kann (seine "Geschaeftsvorfaelle"), die unterste Schicht beschreibt die System- Events, die auf die externe Technik wirken, beispielsweise die Ansprache der Emulationshardware.

Genauso kann diese Sicht fuer die externen Events gelten, die durch die Emulation ausgeloest werden. In diesem Fall stellt die oberste Schicht das korrespondierende Event an der Oberflaeche dar.

Im zweiten Teil des Systementwurfs wurden die Klassen, die zur Realisierung des Projekts notwendig sind, entworfen und den Schichten zugeordnet. Die Uebergabe von Parametern zwischen den Schichten wird als das Protokoll der Schicht bezeichnet und findet sich in den oeffentlichen Funktionen der jeweiligen Klassen einer Schicht wieder. Dieses Protokoll wird entsprechend detailliert dokumentiert.

Wichtig ist, dass diese Schichtenprotokolle so entworfen werden, dass sie im weiteren Entwicklungsprozess weitgehend stabil sind. Der Entwurf der Funktionalitaet leitet sich direkt von diesen Protokollen ab. In diesem Teilschritt steckt die eigentliche Kreativitaet.

Den dritten Teil des Systementwurfs bildet die Beschreibung der Schichten aus der Sicht des Projekt-Managements. Es sind Aufwaende zu schaetzen, Meilensteine zu setzen, Abhaengigkeiten zu erkennen und zu dokumentieren sowie ein Projektnetzplan zu erstellen. Spaetestens jetzt hat der Schichtenentwurf Vorteile gegenueber anderen Entwurfsverfahren, erlaubt er doch die zeitliche und personelle Unabhaengigkeit von Teammitgliedern in der Realisierung einzelner Schichten.

Die Gesamtaufwendungen fuer diese ersten drei Schritte des Systementwurfs sollten zehn Prozent des Projektumfangs nicht ueberschreiten. Weniger wichtig als beispielsweise ein detaillierter Klassenentwurf ist die praezise Definition der Schichtenprotokolle. Die Erfahrung zeigt, dass erste Klassenentwuerfe in der Realisierung oft ueberarbeitet werden muessen.

Top-down-Vorgehensweise laesst sich nicht realisieren

Unrealistisch ist also eine reine Top-down-Vorgehensweise nach dem Motto: "Alle Klassen in der Analyse entwerfen und anschliessend implementieren". Ausserdem sollte die Kreativitaet der Entwickler in der eigentlichen Programmierung nicht unterdrueckt werden. Darueber hinaus lassen sich bestimmte Entwurfsentscheidungen erst in der Programmierphase treffen. Objektorientierung bietet in Form des "Information Hiding" die Mittel an, um derart flexibel vorgehen zu koennen.

Spaetestens die Aufwandsschaetzungen sind direkt von der Art und Anzahl der zu verwendenden Software-Engineering-Werkzeuge abhaengig. Das Wissen um diese Tools ist deshalb unabdingbare Voraussetzung fuer eine realistische Schaetzung. Folgende Werkzeuge sollten nach dem Willen des Auftraggebers zum Einsatz kommen:

- als Programmiersprache Borland C++ 3.1 fuer Windows und Borland Cii 1.0 fuer OS/2 - ein Compiler mit identischem Sprachumfang und gleicher Benutzeroberflaeche fuer verschiedene Betriebssysteme,

- als Betriebssysteme OS/2 und Microsoft Windows - OS/2 wegen der Multitasking- und Connectivity-Aspekte, Windows als Alternative fuer den Laptop beim Home-Operating,

- als Entwicklungsumgebung The Object Engineering Workbench (OEW) von Innovative Software, ein Cii-Tool mit Codegenerator und Reverse-Engineering-Werkzeug,

- als Klassenbibliothek Star View fuer Benutzeroberflaechen von Star Division.

Die eigentliche Entwicklung wurde auf vier Teams verteilt: Neben den Entwicklern des Auftraggebers erhielten drei Softwarehaeuser - darunter die Innovative Software GmbH - den Auftrag, Teile des Projekts zu verwirklichen. Die Aufteilung erfolgte anhand der Softwareschichten.

Die Objektorientierung bestimmte den Rahmen fuer die Zusammenarbeit. Jedes Team sollte auf der Basis des groben Entwurfs zunaechst einen ersten Feinentwurf fuer die Klassenstruktur anfertigen. Vorgaben wie Entwuerfe wurden mit OEW erstellt und per Modem zwischen den Softwarehaeusern verschickt. Das Ziel war eine industrielle Fertigung der Software; die Zulieferer sollten als verlaengerte Werkbank des Auftraggebers fungieren.

Dieses Ziel liess sich auf Anhieb nicht erreichen. Das lag zum einen daran, dass in grossem Umfang Betatest-Versionen der Werkzeuge verwendet wurden. So lagen beispielsweise der OS/2-Compiler und die Klassenbibliothek noch nicht als Produkt vor. Auch die OEW wurde waehrend des Projekts stark veraendert. Neben Softwarefehlern bei allen Werkzeugen verzoegerte vor allem die Einarbeitungszeit sowie die permanente Umstellung auf neue Releases, beispielsweise bei den Betriebssystemen, die Arbeit.

Zum zweiten stellte sich heraus, dass die C++-Kenntnisse der Zulieferer teilweise nicht ausreichten. C++ ist eben nicht nur ein erweitertes C. Durch den Lernaufwand wurden einzelne Termine weit ueberschritten. Der Ausbesserungsversuch, die geforderte Funktionalitaet in C (ohne "++") zu entwickeln, scheiterte letztlich an der Schwierigkeit, Teile unabhaengig voneinander zu entwickeln, zu testen und anschliessend zu integrieren. Dieser Prozess ist in C ungleich schwerer und zeitaufwendiger als in C++.

Nach einer Revision des Projekts stiegen zwei der beteiligten Softwarehaeuser aus. Auf der Basis der eigenen Entwuerfe und Kostenvorgaben konnte nachgewiesen werden, dass das Vorhaben in der geplanten Form nicht realisierbar war. Entwurf und Implementierung der Klassen sollten nunmehr ausschliesslich in C++ erfolgen.

Die Software ist so geschrieben, dass weite Teile (mehr als 90 Prozent der Lines of code) sowohl unter Windows als auch unter OS/2 kompilierbar sind. Die einzelnen Events wurden durchgaengig implementiert und getestet. Diese Form der Projektarbeit kann als Vermischung von Prototyping und Realisierung bezeichnet werden. Zu keinem Zeitpunkt haben die Programmierer ausschliesslich entwickelt oder nur im Feld getestet. Im Augenblick befindet sich die Software im Betatest.

Die Objektorientierung hat sich bewaehrt. Ohne eine Entwicklung in Cii waere das Gesamtprojekt nicht durchfuehrbar gewesen. Die Sprache gestattete einerseits die systemnahe Programmierung von Low-level- Funktionalitaet, andererseits ermoeglichte sie durch die konsequente Einhaltung objektorientierter Prinzipien eine hochsprachliche Beschreibung und Modellierung des Problems. Verkapselung, Vererbung und Polymorphismus gestatten die Entwicklung eines sehr kompakten, redundanzfreien und damit leicht zu aendernden Codes.

Dieser Code ist in Klassen organisiert und modular aufgebaut; infolgedessen wurde eine weitgehend parallele Entwicklung durch verschiedene Bearbeiter moeglich. Die Konsolidierung von Teilen zu einem Ganzen erwies sich als unproblematisch. Von daher ist C++ gerade fuer Teamentwicklungen jeder nicht objektorientierten Programmiersprache und Methode ueberlegen.

Klassenbibliotheken "per Katalog" zugekauft

Die Wiederverwendung von selbsterstellten Klassen wirkt sich tendenziell erst zu einem spaeteren Zeitpunkt kostensenkend aus. Im Projekt Top Control wurde eine Fuelle von Klassen erarbeitet, die sofort in weiteren Projekten einsetzbar waeren. Dazu gehoeren weite Teile der Host-Connectivity, der seriellen Kommunikation sowie der Umsetzung von Events in Threads und Pipes.

Mit Hilfe der Wiederverwendung lassen sich kuenftige Entwicklungskosten massiv reduzieren. Einen Hinweis darauf geben die im Projekt eingesetzten zugekauften Klassenbibliotheken, die einen grossen Anteil des Sourcecodes ausmachen. Durch diesen Zukauf "per Katalog" konnten viele Entwicklungen eingespart werden, die die Entwickler sonst haetten durchfuehren muessen.

Nicht gelungen ist der Versuch, Mitarbeitern ohne detaillierte Kenntnisse der eingesetzten Techniken die Entwicklungsverantwortung zu uebertragen. Das Erlernen der Objektorientierung verursacht zeitlichen und materiellen Aufwand, der nicht unterschaetzt werden sollte.

In der Diskussion werden viele Gruende fuer oder gegen die Objektorientierung genannt. Wer sich fuer die Verwendung von Programmiersprachen wie C, Smalltalk oder Pascal entscheidet, wird allerdings um diese Technik nicht herumkommen. Ein fruehzeitiger Einstieg lohnt sich also fuer alle, die Anschluss an die Entwicklung halten wollen.

Mindestens genauso wichtig wie Kenntnisse in der verwendeten Programmiersprache ist die Projektorganisation. Die Festlegung von Verantwortlichkeiten, ein Schichtenentwurf mit Zuordnung von Kosten und Terminen, die fruehe Verfuegbarkeit laufender Versionen fuer Tests, die Verwendung von modernen Werkzeugen und - in besonderem Masse - hoch motivierte Mitarbeiter sind letztendlich ausschlaggebend.

Daraus lassen sich die folgenden vier Vorschlaege an das Management ableiten:

- Mitarbeiterausbildung hat erste Prioritaet - auch wenn sie teuer ist, also beispielsweise fuer das Beherrschen von C++ und der entsprechenden Werkzeuge mindestens drei Monate je Mitarbeiter veranschlagt werden muessen und das Erlernen der Objektorientierung noch einmal ein Vierteljahr in Anspruch nimmt.

- Think big and start small: Die Einfuehrung der Objektorientierung und einer Sprache wie C++ ist eine strategische Entscheidung und sollte nicht dem einzelnen Entwickler vorbehalten bleiben.

- Ohne Entwicklungswerkzeuge laesst sich Softwareproduktion nicht mehr rationell durchfuehren; ausserdem sind diese Tools heutzutage durchaus bezahlbar. Das Ausprobieren dieser Werkzeuge hilft nicht nur bei der Beurteilung des jeweiligen Einsatzgrades, sondern hilft auch den Entwicklern, quasi spielerisch mit den neuen Technologien vertraut zu werden. Deshalb sollte das Testen niemals einer zentralen Testabteilung vorbehalten sein, denn das Wissen gehoert in die Koepfe der Analytiker, Designer und Entwickler.

- Setzen Sie harte, aber machbare Vorgaben! Ein Projekt sollte immer einen gewissen Anspruch haben; es muss sich aber auch realisieren lassen. Andernfalls sind Frustrationen bei den Mitarbeitern sowie im Management und bei den Kunden vorprogrammiert.

Viele objektorientierte Projekte werden nicht deshalb abgebrochen, weil die Methoden oder Werkzeuge untauglich waeren, sondern weil viel zu euphorische Erwartungen bei allen Projektteilnehmern vorherrschten. Die Erfolge der Objektorientierung stellen sich erst allmaehlich ein - beispielsweise dann, wenn genuegend ausgebildete Mitarbeiter zur Verfuegung stehen und sich aus den Projekten Bibliotheken ableiten sowie wiederverwenden lassen.

*Stephan Wolf ist Geschaeftsfuehrer der Innovative Software GmbH, Frankfurt/Main.