ISSN 1436-3011

09.02.2010

Objektorientierung - State-of-the-Art
Einwurf

Gebt sie auf, die Wiederverwendung! Sie ist zu teuer! Sie spart nicht Kosten, sie macht unnötige Kosten. Schluß damit

Vorbei die Zeiten und hehren Ziele, die Software-Erstellung so zu gestalten, daß sie nicht nur für den einmaligen Einsatz konzipiert, programmiert und ausgetestet wird, sondern danach noch oft wieder verwendet werden kann

Wer ehrlich ist, muß zugestehen, so recht hat es auch diesmal wieder nicht funktioniert. Das Vorhaben ist wieder gescheitert. Bei der Suche nach Autoren für das vorliegende Heft war kein Autor außer zu vagen Angaben bereit, über Projekte zu schreiben, in denen Software erfolgreich und das heißt nachweislich Kosten sparend wieder verwendet wurde.

Gründe wurden viele genannt:

1. "Was wollen Sie? Wir verwenden doch unsere Software immer wieder, sie ist über tausendmal im Einsatz!"
   Aber klar doch: einfach kopiert zu werden, ist die Natur jeder Software. So war es nicht gemeint.
2. "Die Module sind zu klein, so daß es sich nicht lohnt, sie detailliert zu beschreiben und ihre Beschreibung in ein Retrievalsystem zu stellen."
   Das ist die seit Jahrzehnten wiederkehrende (ehrliche?) Ausrede. Dies ist mindestens eine Hürde, auch wenn sie nur psychologisch und angeblich nur in den Köpfen ist. Sie ist einfach da.
3. "Die Menge an brauchbaren Modulen ist noch zu klein, so daß das meiste sowieso neu zu erstellen ist. Da läßt sich der Effekt noch nicht messen."
   Dies ist die Antwort der Unverzagten. Wird sich das je ändern? Kann sich das überhaupt ändern?
4. "Doch - wir führen unsere Software einer Wiederverwendung zu. Wir verkaufen einzelne Module. Was? Wir verkaufen erfolgreich Tabellenkalkulation, Textsysteme, Grafikmodule, usw, die in andere Applikationen eingebaut werden."
   Naja, das ist Componentware. So war es eigentlich auch nicht gemeint. Schließlich lässt sich jede moderne Applikation mit anderen über Schnittstellen verbinden.

Warum scheint es mit Componentware eher zu klappen? Die Antwort ist zweifellos darin zu suchen, daß hier die Module so groß sind, fast so groß wie eigenständige Applikationen, daß es die kleinere Arbeit ist, sie gut zu beschreiben und nach solchen Modulen in einem Retrievalsystem oder in einer Verkaufspreisliste zu suchen, als sie neu zu erstellen.

Aber hätte es dazu der Objektorientierung bedurft? Zweifellos erleichert Objektorientierung dieses Verhalten. Aber sie erleichtert es in demselben Maße, wie sie auch die Programmerstellung erleichtert, weil sie ein an die Softwaretechnologie besser angemessenes Denken darstellt, als es früher je vorhanden war.

Wodurch wird denn mit Componentware der Wiederverwendungseffekt wirklich erreicht? Sind es nicht die allgemein verfügbaren Schnittstellen, die die Wiederverwendung eigentlich erst ermöglichen? Hätte man das nicht auch mit prozeduraler, alter Technik erreichen können?

Wenn ich weiter darüber nachdenke, so kommt mir ein Vergleich mit der Entwicklung der Hardware, mit der Siliziumtechnologie:

Zu Beginn der 70-er Jahre kamen die integrierten Chips zur breiten Anwendung: 4-fach AND, 8-fach XOR, etc.. schön verpackt in kleine schwarze Gehäuse, deren Inhalt und damit auch deren Beschreibung in den Datenblättern immer komplexer wurde. Man brauchte immer mehr Beinchen an den Chips, die über Leiterbahnen mit anderer Logik verbunden sein wollten. Die Zahl der Beinchen wuchs ins unerträgliche und stelle ein wachsendes Hindernis dar. So konnte das nicht weitergehen

Die Lösung: Man machte die Chips auf einen Schlag sehr, sehr viel komplexer und zwar so, dass die Zahl der benötigten Beinchen dann wieder sank. Der Microprozessor war erfunden

Für Hardware gilt: Bei kleiner Zahl steigt der Aufwand für Beinchen und Beschreibung stetig mit der Zahl von integrierten Transistoren, nimmt aber jenseits eines bestimmten Maximums wieder ab, wenn die Innereien nur kompliziert genug sind. Also konstruiert man zweckmäßigerweise von vornherein ganz komplexe integrierte Bausteine (Large Scale Integrated, LSI), die man frei programmieren kann, so daß man keine übermäßig komplexe Beschreibung mehr dafür benötigt.

Für Software gilt: Bei kleiner Anzahl steigt der Aufwand für Schnittstellen und Beschreibung stetig mit der Anzahl von Lines of Code, nimmt aber jenseits eines bestimmten Maximums wieder ab, wenn die Innereines nur kompliziert genug sind. Also konstruiere man zweckmäßigerweise von vornherein ganz komplexe Softwarebausteine (Componentware), die so gemacht sind, daß sie wiederum keiner übermäßig komplexen Beschreibung bedürfen, sondern eher intuitiv zu bedienen sind.

Selbstverständlich wird ein Ingenieur seine eigenen Softwareteile immer wieder neu in seine Programmierarbeit einbringen. Aber er muß sie auch immer wieder neu Tests unterwerfen, mindestens im Gesamtsystem. Und er muß sie im Rahmen des Gesamtsystems auch immer wieder neu beschreiben. Aber es ist unmenschlich, über die Grenzen des Teams hinaus, Wiederverwendung von (kleineren) Softwareteilen erreichen zu wollen. Es kostet nur Verwaltungsaufwand - auch soziopsychischen Aufwand, der nicht zu unterschätzen ist - und bringt daher keinen zusätzlichen Gewinn. Ob die Ingenieure im kleineren Rahmen Software weiderverwenden oder neu schreiben, sollte man getrost dem freien Spiel der Kräfte überlassen! Das ist preiswerter, weil mit weniger Zwang und Stress verbunden.

Wiederverwendung ist nicht mit einer bestimmten Technik zu erreichen, sondern nur mit Masse - Masse an Funktionalität über die damit verbundene Komplexität! Nur dann kann sich Wiederverwendung lohnen. Konkret sind das die "großen" Klassenbibliotheken mit eigener Oberfläche, die quasi selbsterklärend sind, eben die Module aus der Componentware. In diesem Sinne: Es lebe die Wiederverwendung

Dipl.-Physiker Michael Mörike
CRISTAL Software GmbH
Am Echazufer 24, Dominohaus
72764 Reutlingen
michael.moerike@gmx.de

PS: Der beschriebene Effekt gilt vermutlich für jede moderne Technologie. Wird er also eines Tages auch in der Gentechnologie eintreten? Was sind dann die ganz komplexen Teile? Etwa fertige neue Lebewesen vom Reißbrett?

HMD, Heft 210, Dezember 1999