Von Hanns-Martin Meyer*
Im Boom der Objektorientierung ist eine differenzierte Betrachtung aus der Sicht des DV-Managements notwendig, um den Stellenwert kuenftiger objektorientierter Software aufzuzeigen. Dabei stellen sich die Aspekte Anwendernutzen, Qualitaet, Wartbarkeit sowie Produktivitaet bei der Erstentwicklung der Programme und Standardisierung von Objekten in einem anderen Licht dar.
Gemeinhin gilt die Objektorientierung als aeusserst nuetzlich fuer die Software-Entwicklung. In manchen Darstellungen gewinnt man sogar den Eindruck, Objektorientierung koenne diesen Prozess so weit vereinfachen, dass komplexere Programme mit weit weniger Aufwand als bisher zu erstellen seien.
Derart pauschal sind diese Aussagen genauso richtig wie falsch. Ausserdem steht vor dem potentiellen Nutzen zunaechst einmal die nicht niedrige Huerde der Lern- und Einarbeitungsphase. Das gilt insbesondere im Hinblick auf das Design objektorientierter Architekturen. Selbst ein erfahrener Entwickler braucht ein bis zwei Projekte mittlerer Groessenordnung unter Anleitung, bevor er sicher und selbstaendig eine solche Architektur entwerfen kann.
Laesst man die Lernphase ausser acht, so bleibt der Nutzen weiterhin undeutlich. Erst die Aufteilung des Komplexes Objektorientierung auf verschiedene Komponenten erlaubt eine differenzierte Betrachtung der Folgen und Konsequenzen.
Zusaetzlich ist fuer diese Betrachtung eine Differenzierung des potentiellen Nutzens hilfreich. Bei der Analyse des Software- Entwicklungsprozesses ueber den gesamten Lebenszyklus unterscheiden wir dazu den Anwendungsnutzen, die Produktivitaet bei der Erstentwicklung und der Entwicklung neuer Komponenten, die Qualitaet der Software sowie deren Wartbarkeit. Diese Aspekte gelten allgemein als die Erfolgskriterien der Software- Entwicklung.
Differenziert nach den einzelnen Komponenten und Prinzipien der Objektorientierung ergibt sich ein unterschiedlicher Einfluss auf die einzelnen Erfolgsfaktoren (vgl. Tabelle). Bei den Erfolgsfaktoren steht an vorderster Stelle der Nutzen fuer den Anwender. Die Betrachtung unter diesem Gesichtspunkt zeigt, dass die klassischen Komponenten der Objektorientierung - OO- Architektur, Vererbung, Mehrfachvererbung und Reuse - eigentlich gar keinen Einfluss auf den Anwendungsnutzen haben. Der Anwender merkt ueberhaupt nicht, ob seine Software nach diesen Prinzipien entworfen und implementiert ist.
Dafuer haben die Komponenten objektorientiertes User Interface und Objektintegration massive Auswirkungen auf die Bedienbarkeit sowie die Qualitaet und Guete der Einzelfunktionalitaet. Beim Einsatz von Objektintegration kann sich der Entwickler des einzelnen Objektes auf dessen Funktionalitaet konzentrieren, er muss nicht auf die Abdeckung von Funktionalitaet in der Breite achten. Das besorgen andere, gleich hoch spezialisierte Entwickler mit anderen Objekten. Alle diese Objekte lassen sich dann zu einer individuellen Anwendungsumgebung zusammenfuehren.
Im Extremfall laesst sich ein Objekt entkernen
Betrachtet man die Kosten der Software-Entwicklung ueber den Lebenszyklus, so ist Wartbarkeit der wichtigste Faktor. Die differenzierte Analyse offenbart hier, dass objektorientierte Architektur und Wiederverwendung den groessten Erfolg bringen.
Eine saubere objektorientierte Architektur erlaubt es, Aenderungen an einer Software nur innerhalb eines Objektes oder an einigen wenigen Objekten vornehmen zu muessen, ohne Quereffekte auf andere Objekte zu beachten. Denn letztere finden nach der Aenderung wieder die gleichen Methoden vor wie zuvor. Im Extremfall laesst sich ein Objekt "entkernen". Das heisst, sein Inneres wird unter Beibehaltung der bisherigen Methoden voellig neu entwickelt.
Dabei ist es dann moeglich, dass es nach der Entkernung und Neuimplementierung zusaetzlich zu den bisherigen Methoden den anderen Objekten voellig neue Methoden anbietet. Unuebersehbar ist auch der Nutzen in der Wartungsphase, den eine objektorientierte Architektur fuer die Verstaendlichkeit und Uebersicht lichkeit der Software erzeugt.
Der positive Effekt der Wiederverwendung ist offensichtlich. Er wirkt sich sowohl auf die Produktivitaet in der Erstentwicklung als auch spaeter auf zusaetzliche Komponenten und damit auf die Wartungsphase aus. Dies gilt allerdings nur, solange die Wiederverwendung in reiner Form geschieht, also kein vorhandener Sourcecode veraendert und dann wieder eingesetzt wird. Wiederverwendung erzielt die groessten Effekte, wenn sie sich bis auf die Ebene des Binaercodes zurueckverfolgen laesst.
Vererbung spielt fuer die Erfolgsfaktoren der Software-Entwicklung eine zwielichtige Rolle. In ihrer einfachen Form kann sie, wenn sie nicht zu tief gestaffelt ist, einen positiven Einfluss auf die Qualitaet und die Struktur einer Software haben. Dosierter Einsatz im Sourcecode kann Programme schlanker machen.
Gleichzeitig erfordert der Einsatz von Vererbung bei gleichbleibenden Anspruechen an die Qualitaet mehr Sorgfalt beim Design. Dies hat zur Folge, dass die Verbesserung der Produktivitaet und der Wartbarkeit eher gering ausfallen.
Nicht selten jedoch wird Vererbung sehr intensiv genutzt. Sie findet auf vielen Stufen in grosser Tiefe statt; womoeglich werden sogar alle Klassen einer Software aus einer Root-Klasse abgeleitet. In diesen Faellen konterkariert die Vererbung die Moeglichkeit der Wiederverwendung: Denn Vererbung ist nur dann moeglich, wenn man alle Elternklassen durch alle Generationen, also im Extremfall bis zur Root-Klasse, mitverwendet.
Die zweite negative Konsequenz beim Einsatz von Vererbung ist, dass dieser Mechanismus in reiner Form nur innerhalb einer einzigen Implementierungssprache nutzbar ist. OLE 2.x verzichtet in seinem Objektmodell auf konsequente Vererbung. Die Microsoft- Schnittstelle implementiert vielmehr nur eine schwaechere Form der Vererbung, die Aggregation, mittels derer sich komplexere Objekte aus einfacheren zusammensetzen lassen.
Methoden der einfacheren Objekte werden dabei eher durchgereicht als vererbt. Das Konzept der Aggregation bleibt aber auch dann erhalten, wenn die zu aggregierenden Objekte in verschiedenen Sprachen implementiert sind.
Noch zwielichtiger ist der Einfluss der Mehrfachvererbung auf die Erfolgsfaktoren der Objektorientierung. Sie kann sehr nuetzlich sein, um allgemeine Systemmechanismen - zum Beispiel Methoden fuer die Fehlerbehandlung - allen Klassen quasi automatisch mitzugeben. Zusaetzlich zu den potentiell negativen Wirkungen der einfachen Vererbung tritt jedoch bei der mehrfachen Vererbung Unklarheit darueber ein, woher ein Objekt eigentlich seine Eigenschaften und Methoden ererbt hat.
Betrachtet man die Wirkung von Objektorientierung auf die Erfolgsfaktoren der Software-Entwicklung, so ist zu erkennen, dass sich durch bestimmte Komponenten die Produktivitaet der Entwicklung steigern laesst. Gleichzeitig entsteht jedoch bei Ausschoepfung des potentiellen Anwendungsnutzens zunaechst ein Mehrbedarf an Programmierarbeit. Dieser wird wahrscheinlich die Produktivitaetssteigerung neutralisieren. Lediglich in der so wichtigen Wartungsphase lassen sich Verbesserungen erwarten.
Nachhaltigere Veraenderungen jedoch wird die zunehmende Wiederverwendung von Objekten erzeugen. Die klaren Methoden- Interfaces erlauben es, die Anforderungen an ein Objekt (an eine Klasse) vor seiner Implementierung zu spezifizieren, ohne sich um die Details der Implementierung zu kuemmern.
Das ermoeglicht eine verteilte Entwicklung jeweils spezialisierter Domains von Objekten in oertlich getrennten Teams. Die Software- Entwicklung wird international und kann Standortvorteile nutzen.
Gleichzeitig entsteht damit ein Markt fuer wiederverwendbare Objekte. Die Groesse der Software-Einheiten reduziert sich von den heutigen Anwendungspaketen (Textverarbeitung, Tabellenkalkulation etc.) auf spezialisierte Objekte (Textviewer, Imageviewer, Tabellenviewer, Rechtschreibpruefung etc.).
Damit kommen neue Fragen der Logistik, Preisfindung und Lizenzierung von Programmen auf, die heute nicht einmal andiskutiert sind. Entscheidend fuer solche Veraenderungen wird sein, ob eines der verschiedenen Objektmodelle sich durch die groessere Verbreitung als Standard durchsetzen kann - und zwar quer ueber die verschiedenen Plattformen, also ueber die gesamte Client- Server-Architektur hinweg.