Die Hersteller propagieren vollmundig objektorientierte Techniken. Dabei müssen sie jedoch aufpassen, daß sie in ihren verzweifelten Hoffnung auf einen lukrativen Zukunftsmarkt keine überzogenen Erwartungen wecken. Auf der Objekt World in Wiesbaden deuteten die Anwender an, daß sie sich nicht an der Nase herumführen lassen. So deckten die Besucher Schwachstellen in den Erfolgsgeschichten der Hersteller auf und bohrten nach, was sie denn tun müßten, um in den Genuß der objektorientierten Segnungen - vor allem von wiederverwendbaren Softwaremodulen - zu kommen. Schließlich wollten sie genau wissen, ob objektorientierte Vorgehensweisen tatsächlich in der Lage sind - wie oft behauptet -,die starren Organisationsformen der Mainframe-Epoche zugunsten von einer eng kooperierenden Teamwork-Organisation aufzubrechen.

Grundbegriffe der Objekttechnik

Verkapselung: In einem Objekt werden die drei Komponenten Daten, Zugriffsverfahren (Schnittstelen) und Methoden, sprich: Programmroutinen, zusammengefaßt,. Der Zugriff auf Daten erfolgt nie direkt, sondern ausschließlich mit Hilfe einer Methode über die definierten Zugriffsverfahren. Insofern sind Daten des einen Objekts von denen in anderen Objekten abgekapselt.

Vererbung: Diese Eigenschaft sorgt dafür, daß das Rad nicht immer neu erfunden werden muß. Durch die Vererbung finden sich Objekteigenschaften von Eltern-Objekten automatisch bei abgeleiteten Tochter- oder Sohn-Objekten wieder.

Nachrichten: Objekte kommunizieren miteinander über Nachrichten (Messages). Solche Nachrichten stoßen bei anderen Objekten Aktivitäten an, sie aktivieren also die dort eingeschlossenen Methoden.

Polymorphismus: Diese Eigenschaft ermöglicht es, mit einer Nachricht gleichzeitig Aktivitäten bei mehreren Objekten anzuregen. Auf diese Weise wird Parallelverarbeitung möglich.

Als eine Revolution, die weit über den Bereich Software-Entwicklung hinausweise, pries Robert Rockwell, Chief Technolgy Advisor der Softlab GmbH, München, die Objekttechniken. Ein Programm sei künftig kein "tayloristischer Ablaufmechanismus" mehr, sondern müsse eher als eine Art Vereinbarung betrachtet werden. Dies komme dadurch zustande, daß bei einer Anwendung verschiedene Komponenten, sprich: Objekte, über Messages intrigieren.

Diese utopisch anmutende These leitete der Softlab-Manager aus der Möglichkeit ab, Softwaremodule wiederzuverwenden. Darin sieht er den Hauptvorteil objektorientierter Programme, der sich daraus ergebe, daß diese nicht monolithisch seien, sondern optimalerweise aus vorhandenen Objekten zusammengestellt würden.

Damit dies geschehen kann, müßten allerdings die Software-Entwickler dazu gebracht werden, erst in Klassen- und Funktionsbibliotheken nach Lösungen zu suchen, bevor sie anfangen, Codes zu produzieren. Für unerläßlich hält Rockwell in diesem Zusammenhang auch den intensiven Erfahrungsaustausch mit den Kollegen über deren Projekte.

Mehrfachnutzung muß sich für Entwickler auszahlen

Rockwell fand mit dieser Argumentation Unterstützung bei Stephan Lücke, Projektleiter der Taylorix AG, Stuttgart. Lücke schlug vor, Entwickler doppelt zu belohnen: einmal, wenn sie ein bereits anderweitig eingesetztes Modul benutzten, zum zweiten Mal dann, wenn ein von ihnen erstelltes Objekt wiederverwendet wird. Aus einer derart geförderten kooperativen Vorgehensweise kann, so sieht es auch Rockwell, eine neue Firmenkultur erwachsen.

In den Organisationformen der Datenverarbeitung, führte Softlabs Technik-Guru aus, spiegelt sich die Firmenkultur wider. Diese sei lange Zeit von hierarchischen Modellen geprägt gewesen. Bisherigen Zielen wie Rationalisierung, Produktivität oder Sicherheit stellte Rockwell eine objektorientierte Zukunft entgegen, die er von Kooperation, Qualität und Offenheit geprägt sieht. In einer solchen Zukunft, so die Vision, wird der heute noch oft als Fehlerquelle apostrophierte Mensch wieder als Lösungsinstanz wahrgenommen, werden monolithische Strukturen durch modulare abgelöst. Ein solcher Wandel sei selbst dann zu erwarten, wenn keine Objekttechniken eingesetzt würden, denn Objektorientierung sei weniger ein Programmierverfahren als vielmehr eine Weltanschauung.

Dieser Ansicht trat Michael Peltzer, Chef-Consultant der IBM Unternehmensberatung GmbH, Hamburg, energisch entgegen. Die Objekttechnik sei, so brachte er seine Kritik auf den Punkt, "weder neu noch besonders menschlich oder gar eine Philosophie". Bei der Objektorientierung handele es sich um einen durchaus vernünftigen Ansatz zur Lösung bestimmter DV-Probleme. Peltzer wehrte sich gegen Gurus, die diese Technik als die kommende Generation einer humanen, weil anwenderfreundlichen Datenverarbeitung anpreisen. Im CAD-Bereich oder bei der Bürokommunikation, dort also, wo komplexe Daten anfallen, seien Objekttechniken durchaus angebracht. Für die meisten kommerziellen Daten hält Peltzer dagegen relationale Datenbanksysteme für weitaus besser geeignet.

In der Podiumsdiskussion zollten die Konferenzteilnehmer Peltzers Realismus zwar Beifall, widersprachen ihm jedoch in bezug auf die angeblich mangelnde Benutzerfreundlichkeit der Objekttechniken. Als Beispiel wurde die grafische Benutzeroberfläche der Macintosh-Rechner angeführt, die der Objekttechnik zu einiger Reputation verholfen habe. Peltzer erntete auch Widerspruch, als er insistierte, daß Software-Entwicklung Sache von Spezialisten sei und bleibe, wobei die Funktionalität vor der Benutzerfreundlichkeit rangiere.

Spreadsheets als Vorbild für Objektanwendungen

So sprach sich etwa Helmut Bensche, Marketing-Leiter CASE bei Hewlett-Packard, dafür aus, den Informatikern über kurz oder lang einen Großteil der Anwendungsentwicklung aus den Händen zu nehmen und ihn statt dessen von den Anwendern in den Fachabteilungen erledigen zu lassen. Die Endbenutzer würden schließlich ihre Anforderungen am besten kennen. Als Beispiel für die Entmachtung der zentralen Entwicklungsabteilung führte Rockwell Tabellenkalkulationsprogramme ins Feld. "Finazfachleute wissen oft gar nicht, daß sie sich längst als Programmierer betätigen", so der Softlab-Techniker, "wenn sie ihr Unternehmen am Spreadsheet abbilden."

Dank dieser Software brauchen die Anwender kein Programm mehr bei der zentralen DV-Abteilung zu bestellen, so das Argument, um zu erfahren, wie sich beispielsweise ein erhöhter Produktausstoß auf die Rohstoffpreise auswirkt. Diese Entwicklung betrachtet Rockwell als Paradebeispiel dafür, was von objektorientierten Techniken zu erwarten ist.

IBM-Berater Peltzer ließ sich von diesem Argument nicht beirren und wies noch einmal auf den Status quo hin, wonach der Mensch lediglich ein Anhängsel der Arbeitsabläufe sei. An dieser Stelle hagelte es Proteste aus dem Publikum: "Der Erfolg der Spreadsheets beruht doch gerade darauf, daß die Anwender damit ihre Probleme ohne die hochnäsigen Informatiker lösen können", warf Reinhold Thurner, Informatikberater aus dem schweizerischen Herrliberg ein. Für ihn repräsentiert das Programmierprivileg Informatiker die Herrschaftsstrukturen der Mainframe-Welt.

Die Referate über objektorientierte Projekte zeigten jedoch, daß es wohl noch einige Zeit dauern wird, bis Anwender diese Techniken so selbstverständlich einsetzen können wie Spreadsheet-Programme oder grafische Benutzeroberflächen. Deutlich wurde dies nicht zuletzt daran, daß sich die Hersteller noch nicht einmal darauf verständigen konnten, was Objekttechniken eigentlich sind.

Das Problemen der reinen objektorientierten Lehre

Als Wolfgang Martin, Director International Sales Marketing bei der Darmstädter Software AG (SAG), von einem auf Adabas basierenden Großprojekt bei dem spanischen Geldinstitut Banko Exterior berichtete, wurde er des Etikettenschwindels bezichtigt. Der SAG-Manager bezeichnete das verteilte Nachrichtensystem, das vor allem zum netzweiten Datenabgleich eingesetzt wird, als Object Request Broker (ORB). Auch wenn eine ähnliche Funktionalität vorliege, könne, so die Kritiker, von einer Implementation des ORB-Messaging-Verfahrens der Object Management Group keine Rede sein.

Bei der Software AG scheint allgemein ein Verständnis von Objektorientierung vorzuliegen, das sich weniger an technischen Definitionen als an funktionalen Anwenderforderungen ausrichtet. So rückte Hauptredner Peter Pagé, zum Zeitpunkt der Object World noch Vorstandsmitglied der Software AG, das von ihm seit Jahren vertretene Entity-Relationship-Modell von Chen in die Nähe der Objekttechniken, da es sich bei beiden Verfahren um über Nachrichten (Messaging) organisierte Relationen zwischen Objekten handle. Die Diskussion um mögliche Unterschiede überlasse er den Technik-Freaks. Er hält solche ideologische Auseinandersetzungen allerdings für fruchtlos.

Mut machte den Anwendern das Beispiel des Landschaftsverbands Rheinland. Hermann Schmitt, zuständig für Software-Management-System, realisierte dort ein objektorientiertes Softwarekonfigurations-Management-System auf Mainframe-Basis.

Da es für Großrechner zu Projektbeginn keine objektorientierten Entwicklungswerkzeuge gab, arbeitete Schmitt mit C/370 und verwendete als Ablaufumgebung TSO/ISPF. Gespeichert werden die Daten in DB2, wobei er das relationale IBM-Datenbanksystem dazu brachte, sich wie eine Objektdatenbank zu verhalten. Das System des Landschaftsverbands besteht heute aus 20 Klassen, 600 Methoden und 40 000 Zeilen Sourcecode. Selbst Vererbungseigenschaften wurden analog zu den "Self"- und "Super"-Funktionen von Smalltalk nachgebildet.

Problem bei Entwicklungsprojekten

HP-Marketier Bensche berichtete, daß sein Unternehmen inzwischen etwa 60 objektorientierte Projekte durchgeführt habe. Dabei sei es ebenso um Benutzeroberflächen gegangen wie um die eigene Entwicklungsumgebung "Softbench", um Netzwerk-Management-Techniken und opto-elektronische Anwendungen im medizinischen Bereich.

Bensche zeigte - bei einer grundsätzlich positiven Einstellung gegenüber der Objektorientierung - auch Probleme auf, die hier bei Entwicklungsprojekten auftreten. So warnte er vor dem immer beliebter werdenden Prototyping. Ein optisch gelungener Prototyp suggeriere den Kunden, das Produkt sei nahezu fertig. In Wirklichkeit könne es aber noch Jahre dauern, bis sich die Software produktiv einsetzen lasse. Der HP-Mitarbeiter riet deshalb zu inkrementellen Entwicklungsverfahren, wobei eine Kernapplikation entwickelt wird, die sich später um zusätzliche Funktionen, sprich: Objekte, erweitern läßt.

C + + hat sich bei HP durchgesetzt

Wie inzwischen bei einer Reihe von Unternehmen, hat sich auch bei Hewlett-Packard die Programmiersprache C+ + durchgesetzt - trotz aller Nachteile gegenüber klassischen objektorientierten Sprachen wie Smalltalk.

Der unzweifelhafte Vorteil, daß C-Entwickler leicht auf C+ + umsteigen können, schlage nicht selten in einen massiven Nachteil um. C-Spezialisten neigen laut Bensche dazu, C + + als besseres C zu verwenden und dabei die objektorientierten Möglichkeiten außer acht zu lassen.

In bezug auf den effizienten Einsatz von Objektorientierung betonte Raymond Vorwerk, Geschäftsführer der VC Software Construction GmbH, daß Produktivität bei der Software-Entwicklung durch die Vermeidung überflüssiger Aufgaben entsteht. In seinem Plädoyer für die Wiederverwendung von Softwaremodulen wies er darauf hin, daß es alles andere als sinnvoll ist, Dinge zu entwickeln, die es woanders im Unternehmen bereits gibt.

Die Idee der Wiederverwendbarkeit fand zwar offene Ohren, veranlaßte die Anwender allerdings zu der Frage, was denn konkret zu tun sei, damit sich ein Objekt mehrfach einsetzen lasse. Damit legten sie offenbar den Finger in eine offene Wunde, denn keiner der Hersteller konnte die Frage schlüssig beantworten.

Wiederverwendung als Qualitätskriterium

Wenig hilfreich, aber doch zutreffend brachte Gernot Ulrich, Leiter Vertriebsunterstützung bei Sun Microsystems, die Sache auf den Punkt: "Die Häufigkeit der Wiederverwendung bestimmt die Qualität eines Objekts." Zu deutsch: Erst das Ergebnis zeigt, ob man sinnvoll vorgegangen ist. Ähnlich argumentierte Vorwerk, gab aber zu bedenken, daß der Vorgang bei der Einführung neuer Techniken normal sei.

Mit jeder Wiederverwendung eines Objekts, so Vorwerk, steige die Qualität, und mit der Zeit kristallisierten sich Erfahrungen heraus, die als Grundlage für die Aufstellung von Qualitätskriterien gelten könnten. Außerdem werde sich mit der Zeit ein Markt für Objekte herausbilden, auf dem die Anwender sich mit den notwendigen Funktionen eindecken könnten.

Achselzuckend verwies HP-Mitarbeiter Bensche darauf, daß es zur Qualität von Objekten noch keine Untersuchungen gebe. Daher ließen sich auch keine Kriterien angeben, welche Eigenschaften ein Objekt als besser wiederverwendbar auszeichneten als ein anderes.

Trotz der offenkundigen Ratlosigkeit in dieser Frage schälten sich im Laufe der Diskussion einige Möglichkeiten heraus, auf die Qualität von Objekten Einfluß zu nehmen. So schlug Tehnologie-Berater Rockwell vor, mit den Objekten auch die Verantwortlichkeiten zu verteilen. Jeder Projektleiter solle für die unter seiner Regie entstandenen Objekte auch nach deren Fertigstellung geradestehen müssen. Eine solche Maßnahme würde so manche, durch dräuende Abgabetermine verursachte Schlamperei verhindern.

Kein Termindruck in der Startphase

Gerhard Müller, bei Siemens-Nixdorf, Berlin, verantwortlich für die Entwicklung objektorientierter Programmierwerkzeuge, hob das Thema Wiederverwendbarkeit und Qualität von Objekten auf die allgemeine Ebene des Projekt-Managements. Nach seiner Erfahrung ist die mangelhafte Durchführung der Hauptgrund für das Scheitern vieler Projekte.

Wie Müller sahen die meisten Diskussionsteilnehmer das Kernproblem von Softwareprojekten offenbar darin, daß Anwender dazu tendieren, aus Zeit- und Kostengründen zu schnell von der Planung zur Produktion überzugehen. Vor allem Unternehmensberater Peltzer warnt vor einem solchen Verhalten: "Termindruck wirkt sich in der Startphase von objektorientierten Projekten absolut tödlich aus."

Gründliche Analyse und formalisiertes Vorgehen

Bensche forderte in diesem Zusammenhang einen klar definierten Sofware-Entwicklungsprozeß. "Wenn der Projekt-Manager keine klare Vorgabe macht, aus welchen Schritten und Aufgaben sich der Entwicklungsprozeß zusammensetzt", so der HP-Techniker, "führt dies sehr viel schneller als bei der prozeduralen Vorgehensweise zum Softwarechaos."

Laut Bensche lassen sich Objektprogramme weit schwieriger lesen und damit warten als etwa Cobol-Code. Deshalb müsse Hauptaufwand in die abstrakte Spezifizierung von Analyse und Design gesteckt werden. Nach Bensches Erfahrung helfen entsprechende Tools dabei allerdings nur wenig. Wichtig sei vor allem, daß eine gründliche Analyse vorgenommen und eine formalisierte Vorgehensweise eingehalten werde.