Als der Trend in der Software-Entwicklung wird derzeit fast unisono die Programmiersprache Java gehandelt. Der Ansatz, den Sun damit propagiert, findet immer größere Beachtung. Er berücksichtigt Grundsätze der Objektorientierung (OO), netzwerkeigene (Internet-)Applets lassen sich relativ einfach erstellen und stabiler Programmcode schnell erzeugen, Offenheit wird relativ großgeschrieben etc.
Einige Optimisten malen bereits folgendes kühne Szenario aus: Durch die enorme Entwicklungspower rund um den Globus entstehen Tausende von Java-Anwendungen für nahezu jeden Zweck im Rahmen unternehmenskritischer Anwendungen. Nähme man all diese Applikationen zusammen, würden sie Anwendungssoftware-Klassiker in puncto Funktionalität bei weitem übertreffen. Sei es im Logistikbereich, in der Administration oder in ganz speziellen Anwendungsfeldern - wegen der Verfügbarkeit von kostengünstigen und leistungsfähigen Java-Applikationen über das Internet könnte man sein eigenes auf die dezidierten Firmengegebenheiten und -belange abgestimmtes, modular und flexibel aufgebautes Anwendungssystem zusammenstellen.
Derlei Visionen wecken natürlich Interesse. Doch helfen sie den Anwendern bei ihren aktuellen Problemstellungen nicht unbedingt weiter. Ob mit Java wirklich jemals große Anwendungssysteme entstehen werden, ist - jedenfalls aus heutiger Sicht - stark zu bezweifeln. Immerhin: Gerade vor dem Hintergrund des sehr interessanten Ansatzes von Objektorientierung in Verbindung mit dem Internet darf die weitere Java-Entwicklung keinesfalls aus den Augen gelassen werden.
Im Blickfeld ist und bleibt die Objektorientierung beziehungsweise die objektorientierte Software-Entwicklung. Wo immer es heutzutage um neue Anwendungssysteme geht, kommt OO ins Spiel oder wird ins Kalkül mit einbezogen. Zwar ist es für Kunden im allgemeinen unerheblich, ob OO-Techniken zur Lösung von Problemstellungen Verwendung finden oder nicht. Doch machen Schlagworte wie Wiederverwendung, Modularisierung, Flexibilität oder geringerer Wartungsaufwand Anwender hellhörig. Insbesondere die Aussicht auf bessere Software erregt ihre Aufmerksamkeit.
Wenn sich mittels objektorientierter Programmiertechniken in Verbindung mit Prototyping selbst komplexe Anwenderbedürfnisse schnell abklären lassen, ist gelegentlich regelrecht Begeisterung zu spüren. Dabei wird allerdings gern übersehen, daß die rasche Realisierung von Anforderungen (Quick and dirty) durch objektorientierte Entwicklungsprozesse das bekannte Phasenmodell aus Spezifikation, Entwurf, Realisierung und Test nicht ersetzt.
Auch sollten nicht die Fehler der Vergangenheit gemacht werden, als man sich ausschließlich auf die Objektorientierung verließ und mit einer eingeschränkten, ideologischen Sichtweise an Projekte heranging. Denn nicht die Welt an sich ist objektorientiert. Man betrachtet sie nur unter einem besonderen, in diesem Fall objektorientierten Blickwinkel. Je nach Problemstellung kann der eine oder andere Fokus (Prinzipien prozeduraler, traditioneller Software-Entwicklung) sinnvoller und auch geschickter sein.
Grundsätzlich lassen sich alle Probleme mit allen Paradigmen bearbeiten. Gleichwohl können bestimmte Anforderungen aber im jeweils "passenden" Paradigma besser gelöst werden. Pragmatik statt religiöser Glaubenskämpfe sollte die Devise lauten.
Daß die Objektorientierung einen weiteren Schub erfahren wird, davon ist auszugehen, und zwar in allen Bereichen der Software-Entwicklung. Der qualitativ wie quantitativ verbesserte Nutzen bei der Wiederverwendung durch Frameworks und Standard-Schnittstellen, die Vorteile einfacherer Entwürfe durch Muster (Design Patterns) und Standardarchitekturen, die bessere Qualität durch mehrfache Verwendung von Komponenten sowie der damit verbundene geringere Wartungsaufwand steigern die Akzeptanz der Objektorientierung bei den Anwendern deutlich.
Dabei findet vor allem der Einsatz der bereits erwähnten Frameworks immer größere Beachtung und stellt somit einen Haupttrend bei der derzeitigen OO-Verwendung dar. Frameworks (Rahmen) liefern eine recht breite Basis an Grundfunktionen und sind in weiten Problembereichen nützlich. Dadurch müssen selbst große Anwendungssysteme nicht von Grund auf und in Eigenarbeit entwickelt werden, sondern auch in der Individualprogrammierung läßt sich auf erprobte und bewährte, am Markt verfügbare Standardbausteine zurückgreifen.
Diese vorgefertigten Teile stellen die bei der Objektorientierung verwendeten Klassenbibliotheken dar. Die Möglichkeit der Unterklassenbildung paßt Klassenbibliotheken in aller Regel leicht an die jeweils speziellen Bedürfnisse an. Typische Vertreter sind dabei Datenbank- oder Oberflächen-Frameworks für Windowing-Systeme.
Welche Frameworks Verwendung finden und welche Aufgaben sie übernehmen, muß im Systementwurf, der das Zusammenspiel aller Klassen in einem System festlegt, fixiert sein. So läßt sich wie bei einem Sandwich zwischen Interaktions- und Datenhaltungsschicht (Frameworks) eine Werkzeug- und eine Materialschicht legen.
Hierbei stellt die Materialschicht die eigentlichen Objekte zur Bearbeitung bereit, die Werkzeugschicht wiederum Mittel zu deren Bearbeitung. Die Interaktionsschicht andererseits bildet die Oberfläche zur Kommunikation mit dem Anwender.
Typischen Problemstellungen wird diese Strukturierung voll gerecht. Dies belegen beispielsweise Erfahrungen bei der Entwicklung des objektorientierten Konzernbilanzierungssystems "Kapis" für die Daimler-Benz AG. Dieses "Konzern-, Abschluß-, Planungs- und Informationssystem" hat einen Umfang von rund 300000 Lines of Code.
Hierbei sind die Bilanzierungsdaten das Material; Werkzeug sind die Prüf- und Konsolidierungsfunktionen. Für die Interaktion und Datenhaltung stehen eigenentwickelte Frameworks gerade. Allein das Datenbank-Framework umfaßt dabei insgesamt über 200 Klassen und regelt unter anderem die harmonische und effiziente Kooperation von verwendeten OO-Techniken und praktikablerweise eingesetzter relationaler Datenbank, in diesem Fall Oracle.
Design-Patterns als Retter in der Not
Für den Anwender beziehungsweise Kunden in aller Regel quasi unsichtbar, allerdings von nicht unerheblicher Relevanz, ist der Klassenentwurf eines OO-Systems. Er legt definitiv die Vererbungs- und Kommunikationsstruktur der Objekte untereinander fest. Ferner gibt er Auskunft darüber, mit welcher Komplexität ein objektorientiertes Anwendungssystem behaftet ist. Diese Punkte sind bei möglichen späteren Programmänderungen und -erweiterungen von großer Bedeutung.
Dreh- und Angelpunkte sind im Kern die zahlreichen neuen Arten von Schnittstellen, die durch die Vererbung entstehen. Der Knackpunkt ist hier: Während bei traditionellen prozeduralen Programmiertechniken durch klar eingegrenzte Module in aller Regel Service-Schnittstellen vorherrschen, entstehen bei der Objektorien- tierung zusätzlich sogenannte Hooks. Sie bewirken Änderungen des durch Oberklassen spezifizierten Verhaltens durch Überschreiben des Verhaltens in Unterklassen (siehe Abbildung). Die daraus resultierende Komplexität der Schnittstellen, die durch die Vererbung per se gegeben ist, sollte auf keinen Fall unterschätzt werden.
Die Crux dabei ist, daß diese Vererbungs-Schnittstellen bisher schwer zu dokumentieren und zu beherrschen sind, denn die Abhängigkeiten können sich über zahlreiche indirekte Stufen hinwegziehen. Dennoch steht man nicht auf verlorenem Posten.
Eine Unterstützung bei diesen Problemen (und auch anderen Klassenstrukturierungen) bieten die schon erwähnten Design-Patterns, zu deutsch Entwurfsmuster, die neben den Frameworks einen weiteren Trend bei der objektorientierten Software-Entwicklung darstellen. Für bestimmte und überschaubare Problemkonstellationen, etwa bei den genannten Vererbungs-Schnittstellen, fallen sie ebenfalls in die Kategorie Standardlösungen. Auch werden inzwischen in größerer Zahl Design-Patterns als quasi vorgedachte Minientwürfe vorgestellt.
Genau diese Design-Patterns sind es auch, die manche Anwenderherzen schneller schlagen lassen, insbesondere wenn es die Problemstellung zu lösen gilt, OO-Programme mit in prozeduraler Technik erstellter Software effizient zu verbinden. Dabei geht es um nichts anderes, als darum, Software-Investitionen zu schützen, gleichzeitig aber neuere Techniken einzusetzen. Für die eigentliche Abkapselung der Altprogramme wird dann ein spezielles Codestück namens "Wrapper" verwendet.
Vereinfacht ausgedrückt, werden mittels Wrapper traditionelle Programme als Objekte "eingewickelt". Der Wrapper delegiert dann die Aufrufe der alten und neuen Objekte. Allerdings hat der Einsatz von Wrappern und Design-Patterns im allgemeinen Grenzen. Vor allem bei der Einkapselung großer Individualprogramme ist unbedingt eine Kosten-Nutzen-Betrachtung vonnöten.
Seien es Frameworks, Design-Patterns, Analyse- und Entwurfsmethoden, stabilere und leistungsstärkere Programmiersprachen oder ein Fortschreiten allgemeiner und spezieller Standards: Allenthalben nimmt der Reifegrad in Sachen Objektorientierung zu. Damit wächst auch die Chance, Kunden bessere Software als in der Vergangenheit zur Verfügung zu stellen. Ihren Wünschen bei der Programmerstellung läßt sich mit einem erwarteten Aufwand in der geplanten Zeit und einer definierten Qualität mittels OO besser entsprechen, als dies in der Vergangenheit mit traditionellen Software-Entwicklungstechniken der Fall war - ein ausgefeiltes Projekt-Management vorausgesetzt.
Unterm Strich hat sich in den bisherigen OO-Projekten gezeigt: Um das Nutzenpotential, das sich durch die Verwendung objektorientierter Techniken bietet, auszuschöpfen, sind schon eine Portion an Aufwand und Zeit sowie unter Umständen mehrere Iterationszyklen erforderlich. Eine allzu verkürzte Denkweise konterkariert Nutzenvorteile, die durch die Objektorientierung erzielbar sind, nicht nur spürbar, sondern ganz massiv.
Angeklickt
Längst sind die Zeiten passé, in denen Programmiermannschaften mit der Attitüde von Künstlern Code kreierten. Heute steht bei der Software-Entwicklung die Erfüllung der Kundenwünsche mit dem erwarteten Aufwand in der geplanten Zeit und in einer definierten Qualität an oberster Stelle. Wo immer der Einsatz objektorientierter Softwaretechniken Sinn macht, bieten sich Chancen, bessere Anwendungsprogramme zu schaffen und so den Nutzen für die Kunden zu erhöhen. Der Autor skizziert, von welchen praktisch belegten Neuerungen Anwender bei der Objektorientierung profitieren können und welche Problemkreise dabei zu beachten sind. Eine Schwierigkeit sind dabei insbesondere neue Schnittstellen-Typen.
*Dr. Markus Deininger ist Softwarespezialist bei Debis Systemhaus, Leinfelden, und Mitarbeiter im "Kapis"-Projekt der Daimler-Benz AG.