Realismus und Standards sind gefragt

Objektorientierung ist nicht bloss eine Frage der Sprache

02.04.1993

Jeden Tag wollen uns mehr selbsternannte Propheten und Gurus weismachen, dass man nur objektorientiert vorgehen muesse, dann seien alle Probleme geloest. Mehr und mehr - auch altbekannte - Rezepte, Methoden und Tools nennen sich ploetzlich objektorientiert, damit sie auch zu den Heilsbringern gehoeren. Schon die kuenstliche Intelligenz und CASE wurden als Wundermittel angekuendigt, und so geschieht es nun auch bei der Objektorientierung.

Die Technik ist zunaechst einmal schon relativ alt. Sie begann mit der Idee der abstrakten Datentypen und dem Information hiding. Das sind auch heute noch die nuetzlichsten und damit wichtigsten Elemente der Objektorientierung.

Objektorientierung steht noch am Anfang

Die Erfahrungen in den Entwicklungsprojekten zeigen, dass diese Technologie sehr nuetzlich ist, aber auch, dass noch sehr viel zu tun und zu lernen ist. Sie steht noch am Anfang ihres Reifeprozesses, und sie ist nicht nur objektorientierte Programmierung. Sie laesst sich auch nicht einfach durch die Benutzung einer objektorientierten Programmiersprache einfuehren, sie will erlernt und erfahren sein.

Hinsichtlich Software-Engineering, Beherrschbarkeit von sehr grossen Software-Entwicklungsprojekten, Benutzerfreundlichkeit von Anwendungen sowie Konfigurierbarkeit von Anwendungsumgebungen durch den Anwender selbst kann die Objektorientierung eine sehr wichtige und zentrale Rolle spielen, wenn sie nur nicht vorher zum Allheilmittel hochstilisiert, aber totgeredet wird. Doch selbst dann werden die Elemente der Objektorientierung bei diesen Problemstellungen ueberleben und nutzbringend eingesetzt werden. Sie werden lediglich andere Namen bekommen. Nur als Marketing- Melkkuh ist die Objektorientierung dann tot.

Ein Walkman ist ein gutes Objekt. Er wird ueber Tasten bedient: fuer den schnellen Vorlauf, den schnellen Ruecklauf, fuer Play und fuer Stop. Er hat eine Buchse fuer den Kopfhoerer und eine Regelung der Lautstaerke. Ein hervorragendes User Interface also, und das ist ein wesentlicher Erfolgsfaktor. Der Walkman hat aber noch eine wesentliche Eigenschaft eines guten Objektes: Er verbirgt seine hochkomplizierte, innere Struktur. Haben sie sich schon einmal fuer den inneren Aufbau ihres Walkmans interessiert? Nein, Sie benutzen ihn nur.

So sollen gute Objekte sein: ein einfaches, einfach zu bedienendes Interface, das die Methoden des Objektes, die hochkomplizierte, innere Struktur verbirgt, die zudem unabhaengig von dem Rest der Welt ist. Fuer Software muss man hinzufuegen: Das Objekt soll moeglichst gut und einfach die reale Welt modellieren, und es soll gerade nicht seine inneren Strukturen nach aussen repraesentieren.

Wenn Sie nun meinen, ein Walkman sei ja keine Software, dann lassen Sie sich an das Thema Multimedia und dabei an Audiokomponenten erinnern. Dort haben die Software-Ingenieure von der Unterhaltungselektronik gelernt, wie man ein gutes Interface gestaltet.

Objekte sind also interoperable, wiederverwendbare, portable und abgeschlossene Softwarekomponenten, die die Business-Objekte der realen Welt abbilden und die Daten und Methoden des jeweiligen Objektes einkapseln (Unabhaengigkeit). So werden Objekte fuer die Problemstellungen der Software-Entwicklung nuetzlich. Alles, was uns von dem Ziel ablenkt, unsere Software aus solchen Objekten aufzubauen, die dann natuerlich wiederverwendbar sind, hat zumindest niedrigere Prioritaet.

Gute Objekte sollen also ruhig komplex sein, nur nicht an ihrer Schnittstelle, und sie sollen diese Komplexitaet verbergen. Objekte werden nicht nur, wie das haeufig in den Beispielen der Lehrbuecher zu finden ist, auf der Ebene von geometrischen Figuren nuetzlich, sondern gerade wenn solche Objekte Stuecklisten, Lieferprogramme, Montageprogramme, Abrufprogramme etc. sind, die ihre Funktionalitaet, sprich ihre Methoden, implizit mitbringen.

Die Objektorientierung ist so allgegenwaertig geworden, dass man differenzieren muss und auch kann. Mehr Klarheit in die Diskussionen bekommt man, wenn man drei Ebenen von Objektorientierung unterscheidet: das objektorientierte User Interface (OUI), die objektorientierte Software-Architektur (OSA) und die objektorientierte Programmierung (OOP).

Das User Interface ist klassisch DV-technisch gepraegt. Der Benutzer hat gelernt, dass in der Datenverarbeitung - der Name sagt es ja schon - Daten und Dateien von Programmen oder Anwendungen verarbeitet werden. Also ruft er zuerst das Anwendungsprogramm, ein Textverarbeitungs-Programm zum Beispiel, auf und waehlt dann, mehr oder minder schlecht durch das Anwendungsprogramm gefuehrt, die Daten oder die Datei aus, die er damit bearbeiten will. Das ist unnatuerlich.

Natuerlich ist dagegen eine Organisation des Arbeitsbereichs nach Objekten: Briefe, Artikel, Fax, Zeichnungen, Vertraege, Lieferscheine, Rechnungen. Ein Benutzer waehlt sich das Objekt, das er bearbeiten will, und erhaelt implizit die Methoden mit, die er dazu braucht.

Die Methoden, mit denen er seinen Vertrag bearbeiten kann, stehen ihm unmittelbar zur Verfuegung. Dazu gehoert dann nicht nur die Bearbeitung des Vertrages als Text, sondern vielleicht auch die Konsistenzpruefung mit anderen Vertraegen. Diese Kopplung der Funktionalitaet an das Objekt macht ein objektorientiertes User Interface aus.

Ein Softwaresystem besitzt eine objektorientierte Architektur, wenn es aus Objekten besteht, die unabhaengig voneinander sind und durch den gegenseitigen Aufruf von Methoden ausschliesslich zusammenwirken. Dabei werden auch neue Objekte geschaffen (instanziiert) oder bestehende geloescht.

Eine solche objektorientierte Architektur ist die Voraussetzung fuer die Wiederverwendbarkeit von Objekten. Software mit einem objektorientierten User Interface muss nicht notwendig eine objektorientierte Architektur haben, obwohl es naheliegend ist.

Objektorientierte Programmierung ist die Programmierung in einer objektorientierten Programmiersprache wie Smalltalk, C++, Objective C oder Eiffel. Die dabei entstehende Software muss keineswegs eine objektorientierte Architektur haben. Ohne eine solche gewinnt sie jedoch auch nicht die Vorteile der Objektorientierung: Wiederverwendbarkeit von Software, Ueberschaubarkeit, Robustheit etc. Haeufig wird Objektorientierung mit objektorientierter Programmierung gleichgesetzt. Das ist zu wenig, Programmierung gerade in C++ erzeugt noch nicht die Vorteile der Objektorientierung.

Die drei Ebenen der Objektorientierung OUI, OSA und OOP sind also unabhaengig voneinander. Die groesste Bedeutung hat die objektorientierte Software-Architektur. Nur sie fuehrt zu ueberschaubarer, wiederverwendbarer Software und damit ein gutes Stueck weiter aus der Softwarekrise heraus.

Dabei ist es zunaechst voellig unwichtig, in welcher Sprache die Objekte implementiert sind, einzelne koennen aus bestimmten Gruenden sogar in Assembler implementiert sein. Wichtig sind die Schnittstellen, die Methoden der Objekte. Objektorientierung ist ausschliesslich eine Designaufgabe.

Wenn man akzeptiert, dass nur die objektorientierte Software- Architektur einen Teil der Versprechen wahr machen kann, die die Gurus bereithalten, so ist schon klar, dass Objektorientierung eine Designaufgabe ist.

Wenn erfahrene C-Programmierer beginnen, in C++ zu programmieren, um objektorientierte Software zu entwikkeln, entsteht haeufig ein grausam verwobenes Programm. Den Programmierer fasziniert naemlich ein Nebeneffekt der Objektorientierung, die Vererbung. Sie soll hier gar nicht weiter erlaeutert werden, aber durch sie entsteht haeufig Software, die eher an klassische Spaghetti-Programmierung erinnert, als dass sie die Vorteile der Objektorientierung in sich tragen wuerde.

Ein gutes objektorientiertes Design ist vergleichbar mit einer effizienten Unternehmensorganisation. Jeder Mitarbeiter (jedes Objekt) hat seinen klaren Verantwortungsbereich. Die Interfaces zwischen den Mitarbeitern (zwischen den Objektensind klar und einfach. Die Organisation ist so, dass ein Minimum an Kommunikation notwendig wird. Die Verantwortungsbereiche sind abgeschlossen.

Die Mitarbeiter (Objekte) koennen unabhaengig voneinander arbeiten. Nicht jeder muss gleichzeitig auch das Spezialwissen des anderen besitzen, um seine Aufgaben durchfuehren zu koennen.

Die Vision der Objektorientierung ist, dass sich der Anwender zukuenftig frei auf dem Markt Klassen kauft. Klassen sind sozusagen die leeren Huellen der Objekte, die durch Instanziierung zu Objekten werden. Mehrere Objekte koennen dann der gleichen Klasse angehoeren und die gleichen Methoden haben.

Sie unterscheiden sich dadurch, dass sie andere Ergebnisse liefern, weil sie eine unterschiedliche Vorgeschichte haben und sich in verschiedenen Zustaenden befinden. So kann ich als Benutzer eine Vielzahl von Vertraegen haben, die alle von der Klasse Vertrag sind, aber ganz unterschiedliche Inhalte umfassen.

In der Vision konfiguriert sich der Anwender, durch ein komfortables Tool unterstuetzt, seine eigene objektorientierte Anwendungsumgebung. Alle gekauften Klassen arbeiten ueber ihre Methoden zusammen. Pakkaged Products werden zu Pakkaged Objects. Der Anwender ist nicht mehr auf die Funktionalitaet, die ihm von einzelnen Produkten geboten werden, angewiesen. Er sucht sich die Funktionalitaet individuell aus dem grossen Angebot der Packaged Objects aus.

OMG kuemmert sich um die Standardisierung

Packaged Objects sind in der Regel vom Umfang her kleiner als heutige Softwareprodukte. Da sie mit anderen Objekten integriert zusammenwirken, muessen sie weniger komplett sein als heutige Produkte. Dadurch werden sie auch leichter austauschbar. Ein Upgrade auf eine neue Version oder gar auf ein anderes Objekt ist wesentlich leichter und wirkt sich nicht stoerend auf die anderen, gewohnten Objekte aus.

Objektorientierung braucht Standards. Will man sich zukuenftig Objekte oder ihre Verallgemeinerung, Klassen, frei auf dem Markt kaufen, so muessen sie Standards im Zusammenspiel mit anderen Klassen genuegen.

Diesem Thema hat sich die Object Management Group (OMG) verschrieben. Die OMG ist ein Zusammenschluss von Hardware- und Softwarehaeusern. Sie hat das standardisierte Zusammenwirken von Objekten in einer verteilten Umgebung in Form des Common Object Request Brokers spezifiziert.

In der objektorientierten Architektur nach OMG geschieht der Methodenaufruf ueber den Object Request Broker. Er sorgt sich um alle technischen Notwendigkeiten des Aufrufs selbst ueber Rechnergrenzen hinweg. Er weiss den Ort, an dem er den Aufruf an das gerufene Objekt abgeben muss (Name Service). Bei ihm koennen sich neue Objekte anmelden und bestehende abmelden.

Die OMG definiert ferner allgemeine Object Services und Common Facilities. Nur durch eine solche Standardisierung ist zu verhindern, dass es Packaged Objects lediglich jeweils fuer bestimmte proprietaere Umgebungen gibt. Nur so kann ein allgemeiner Markt fuer Packaged Objects entstehen, der auch gross genug ist.

Die Vision von den Packaged Objects ist gut, aber es ist noch viel Arbeit bis zu ihrer Realisierung zu tun. Einige Anbieter haben angekuendigt, OMG-kompatible Object Request Broker auf den Markt zu bringen. Bis dahin kann man diesen Ansatz in geschlossenen Umgebungen, beispielsweise in Projekten, sehr gut nutzen und die OMG-Spezifikationen als Leitfaden verwenden.

Soll die Objektorientierung in vollem Umfang erfolgreich werden, so benoetigen wir dafuer eine ganze Reihe von Standards. Die OMG kann sie definieren, aber die Software-Anbieter muessen sich nach ihnen richten. Andernfalls entstehen viele zersplitterte, kleine objektorientierte Welten und dazwischen ein paar groessere, neue, geschlossene Bereiche mit den bekannten Abhaengigkeiten, die durch offene Systeme gerade beendet werden sollten.

* Dr. Hanns-Martin Meyer ist Geschaeftsfuehrer der Ixos Software GmbH, Grasbrunn bei Muenchen.