Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

06.11.1992

OOP zieht Könner und Scharlatane gleichermaßen an

Objektorientierte Programmierung (OOP) kann für viele Software-Entwickler das Aus bedeuten. Fällt die Entscheidung für dieses Vorgehensmodtell, so greift das darüber hinaus tief in die Struktur des betroffenen Unternehmens ein. Auch die notwendigen Vorinvestitionen in eine unternehmensweite Objektbibliothek können die Verantwortlichen kopfscheu machen. Software- Guru Harry Sneed* analysiert die teils gut begründete, teils bloß modische Tendenz.

Abgesehen von der Bekleidungsindustrie ist kaum eine Branche so sehr Modeströmungen ausgesetzt wie die Software-Industrie. In beiden Fällen haben die Schwankungen ihre Ursache im Markt. Der Anbieter angeblich neuer Produkte muß den Verbraucher überzeugen, daß er ohne das neue Produkt von gestern ist.

Kaum ist aber die Innovation installiert, kommt der nächste Anbieter und präsentiert etwas noch Neueres. Jeder behauptet, seine Lösung sei die langersehnte Wundermedizin gegen die üblichen Softwarekrankheiten wie hohe Kosten überzogene Termine, personelle Abhängigkeiten etc. All dies müssen die Anbieter propagieren, um ihre Produkte absetzen zu können. Sonst verlieren sie ihren Job, und es ist allemal angenehmer, Produkte zu verkaufen und Seminare darüber zu halten, als selber Projekte zu machen. Für Entwicklungsmethoden und CASE-Tools haben Hersteller und Händler denn auch entsprechend aggressiv geworben.

Ist objektorientierte Entwicklung nur eine weitere Modewelle, ausgelöst durch diejenigen, die etwas daran zu verdienen haben, oder stellt sie wirklich einen Paradigmenwechsel dar? Sie ist beides.

Einen echten Paradigmenwechsel bedeutet sie, insofern ein objektorientiertes Softwaresystem wirklich anders aussieht als ein konventionell prozedural orientiertes System.

Eindeutiges Verpackungskriterium

Ersteres besteht aus einer Vielzahl abgekapselter Module. Von jedem Modul kann es wiederum viele verschiedene Varianten geben. Untergeordnete Module erben nicht nur Attribute, sondern auch Verarbeitungsregeln von den übergeordneten. Außerdem kann jedes Modul mit jedem anderen Daten austauschen - etwas Undenkbares in klassischen Softwaresystemen mit starren Aufrufhierarchien. Am wichtigsten aber ist, daß es endlich ein eindeutiges Verpackungskriterium gibt, das in den funktional gegliederten Systemen immer gefehlt hat.

Die Verarbeitugsanweisungen werden mit den Daten, die sie verarbeiten, verknüpft. Sie bilden eine Einheit. Das ist eine entscheidende Neuerung der objektorientierten Systeme (Abbildung unten). Ob diese neue Struktur nur Vorteile in sich birgt, ist eine andere Frage. Dagegen spricht zum Beispiel die Komplexität der Schnittstellen und die hohe Anzahl der zu verwaltenden Komponenten.

Objektorientierung ist nicht nur eine Sache der Produktarchitektur, sie prägt auch den Entwicklungsprozeß. Das Ausmaß dieser Veränderung haben die meisten potentiellen Anwender noch gar nicht erkannt. Sie rüttelt an den Fundamenten des klassischen Projekt-Managements und reicht tief in die Struktur des Unternehmens hinein.

Wer objektorientirerte Entwicklung ernst nimmt, muß weit ausholen. Es wird unternehmensweit, abteilungsweit und schließlich anwendungsweit benutzte Objekte geben, und diese werden wiederum über verschiedene Rechner verstreut sein.

Im Sinne der Objektorientierung sollen lokale Objekte lediglich abgeleitete Varianten übergeordneter globaler sein, setzen deren Realisierung also voraus. Wer soll aber die globalen Objekte konzipieren, und wer soll das bezahlen?

Neue Vorgehensweise führt zu anderen Ergebnissen

Werden die Endanwender bereit sein, die Vorinvestition in eine unternehmensweite Objektbibliothek zu tragen? Das objektorientierte Vorgehensmodell hat zwar immer noch die klassischen Phasen Analyse, Design, Programmierung und Test, aber in jedem Abschnitt geht der Entwickler anders vor und liefert auch andere Ergebnisse:

- Statt Abläufe zu analysieren, analysiert er die Informations- Entitäten und ihre Lebensgeschichte.

- Statt Datenflußdiagrammen erstellt er Kollaborationsdiagramme

- Statt Programmieranweisungen in ihrer prozeduralen Folge aneinanderzureihen, bildet er molekulare Code-Bausteine, Methoden, die von außen angesteuert werden. - Statt unterschiedliche Pfade zu testen, testet er unterschiedliche Nachrichtenausprägungen.

Somit verändert sich die Arbeitsweise gravierend im Vergleich zur klassischen strukturierten Entwicklung. Die Entwickler müssen umlernen. Aus ihrer Sicht ist dies auf jeden Fall ein echter Paradigmenwechsel, den viele nicht mehr schaffen werden (siehe nebenstehende Abbildung).

Trotz alledem ist die objektorientierte Software-Entwicklung auch eine gigantische Modewelle, auf deren Kamm etliche Glücksritter, Opportunisten und Hochstapler reiten. Jeder will sein Geschäft machen. CASE-Werkzeuge, die bisher nur strukturierte Analyse und Design unterstützt haben, sind plötzlich objektorientiert. Bei Sprachen der vierten Generation, die weit entfernt vom objektorientierten Gedankengut sind, wird auf einmal entdeckt, daß sie schon immer quasi-objektorientiert waren. Und sogar manche Datenbanksysteme, die bisher nur als relational gegolten haben, sind inzwischen relational und objektorientiert. Kurzum: Der Markt nutzt das neue Adjektiv, um fad gewordene Produkte wieder schmackhaft zu macht. In ähnlicher Weise treten Plötzlich Berater für objektorientierte Entwicklung scharenweise aus der Dunkelheit hervor, als ob sie dort schon immer auf diese Stunde gewartet hätten.

Kaum einer wagt es, die aus Unwissenheit begeisterten Anwender auf die Schwierigkeiten der objektorientierten Entwicklung und Wartung hinzuweisen. Dies würde an Ketzerei grenzen. Denn Objektorientierung is nicht nur ein Paradigmenwechsel und eine Modewelle, sondern außerdem noch eine Religion, mit fanatischen Anhängern, die darauf aus sind, jeden Ungläubigen zu bekehren oder zu verbannen.

Objektorientierte Entwicklung ändert die Architektur der Software, die Arbeitsweise der Entwickler, den Markt und die Einstellung der Anwender. Am Ende wird sie auch die Struktur der Unternehmen umgestalten. Sie wird aber bestimmt nicht die letzte Verschiebung dieser Art sein. Jede Lösung erzeugt neue Probleme. Die Schwierigkeiten mit der objektorientierten Entwicklung werden nicht lange auf sich warten lassen. So bald sie da sind, werden enttäuschte Anwender behaupten, das Ganze sei nur eine Modeströmung gewesen. Nach dem Maßstab ihrer Erwartungshaltung werden sie auch recht haben. Objektorientierung ist keine Wundermedizin.