Die methodische Grundlage des IBM-Konzepts AD/Cycle basiert auf der strukturierten Analyse (SA). Die SA stellt eine funktions- beziehungsweise tranformationsorientierte Analysemethode dar, die sich nicht sinnvoll in Programmstrukturen umsetzen laßt. Thorsten Spitta* empfiehlt statt dessen objektorientierte Methoden für die Analysephase.

Methoden sind das wichtigste Thema bei der Software-Entwicklung; denn Werkzeuge implizieren immer auch Methoden. Methoden sind gewissermaßen die Spezifikation der Werkzeuge, weshalb die Wahl der falschen Methode auch die Wahl des falschen Werkzeugs nach sich zieht. Diese Tatsache hat im Rahmen des IBM-Konzepts AD/Cycle ein besonderes Gewicht.

Die IBM hat mit ihrem Konzept für die Anwendungsentwicklung einen zweifellos richtigen, allerdings keineswegs neuen Weg gewiesen: Software als komplexes technisches Produkt ist demnach ausschließlich konstruktiv zu entwickeln und werkzeugunterstützt zu warten. Allerdings stellt sich die Frage, welche Methoden den empfohlenen Werkzeugen zugrunde liegen beziehungsweise welche Werkzeuge unvollkommen sind oder ganz fehlen.

Wie die in Deutschland äußerst geringe Zahl empirischer Veröffentlichungen zu diesem Thema zeigt, ist die wissenschaftliche Disziplin des - Software-Engineering einerseits ein ungeliebtes Kind der Hochschul-Informatik. Das Fach gilt als praxeologisch und unwissenschaftlich. Andererseits bevölkern - meinst noch recht junge - Softwaretechnologen und Datenadministratoren die DV-Abteilungen der Großanwender; sie versuchen mit viel Elan, das an der Hochschule erworbene Wissen anzuwenden und durchzusetzen, ohne zu ahnen, daß viele der dort gelehrten Methoden empirisch nie erprobt wurden.

Durch die Tagungslandschaft, die Fachliteratur und vor allem Werbung der DV-Industrie, speziell in der Sparte Schulung, geistern methodische Schlagwörter wie "Top-down-Entwurf", "Benutzerbeteiligung", "wissensbasiert", "Prototyping" etc. Offenbar sind dort nicht wenige Dozenten beschäftigt, die noch nie ein größeres Softwareprojekt durchgeführt haben.

Wir brauchen eine Methodenentsorgung

Es besteht konkreter Handlungsbedarf in der Erprobung von Methoden, mit denen nicht nur Programme, sondern Softwaresysteme entwickelt werden können. Außerdem brauchen wir eine Art Methodenentsorgung, die uns von Methoden befreit, die praktisch nicht verwendbar sind. Hierzu gehören auch die derzeit für AD/Cycle empfohlenen Methoden beziehungsweise die entsprechenden Werkzeuge. Unpraktikable Methoden verursachen Fehlinvestitionen oder günstigstenfalls unnötig hohe Kosten.

Alle gängigen Methoden des Software-Engineering schlagen im Prinzip folgende Vorgehensweise vor: Funktionen beziehungsweise Prozesse werden gesammelt und geordnet. Die Ordnung erfolgt meist top-down im Zuge einer schrittweisen Verfeinerung. Entweder werden die Daten bei der Darstellung der Funktionen mitbetrachtet, wobei die Funktionen als Transformationsprozesse für Daten gelten, oder die Funktionen werden als Funktionshierarchie und die Daten als Datenhierarchie angesehen - so beispielsweise in der Structured Analysis Design Technique (SADT) oder dem Jackson System Development (JSD).

Ein Rückgriff auf Methoden zur Datenmodellierung (Relationenmodell, Entity-Relationship-Methode) ist nicht vorgesehen oder wird, wie beispielsweise in AD/Cycle, an alte Methoden "angehängt". Eine objektorientierte Systembildung in den frühen Phasen findet ebenfalls nicht statt.

Je nach Schwerpunkt heißen die Methoden daten- oder funktionsbezogen. Der Streit, welche die besseren Methoden seien, ist müßig, da wir es hier mit einem typischen "Henne-und-Ei-Problem" zu tun haben: Funktionen erzeugen Daten, diese werden von Funktionen benutzt.

Funktionsorientierte Methoden modellieren einen Daten- oder Steuerfluß nach dem primitiven Schema einer erweiterten Wertzuweisung (EVA-Prinzip). Bei der Structured Analysis and Design Technique (SADT) und der Information Systems Work and Analysis of Changes (ISAC) ist ein Verfeinerungsmechnismus eingebaut, der die Darstellung bis etwa zur dritten Verfeinerungsebene besser handhabbar und übersichtlicher macht als bei der System Analysis (SA) oder der Research System Language (RSL).

Doch wehe dem, der zu tief verfeinert! 30 Diagramme auf Ebene 3 erzeugen 120 bis 200 Diagramme auf Ebene 4. Niemand kann das noch überblicken oder gar Änderungen nach Inbetriebnahme der Software durchführen.

Objektorientierte Software besteht aus Modulen, die Operationen auf Datenstrukturen bereitstellen. Module interagieren durch Benutzung der Operationen anderer Module. Datenstrukturen repräsentieren Datenobjekte, die temporär im Hauptspeicher oder dauerhaft auf Datenträgern gehalten werden. Dank D.L. Parnas wissen wir das seit 1972, nur realisiert das kaum jemand!

Die Klammerung von Datentyp und Operationen ist für die Objektorientierung notwendig, wenn auch nicht hinreichend. Sie muß in der Analyse unbedingt eingehalten werden. In der Datenbankwelt ist dies so selbstverständlich, daß reale Datenbanksysteme eigentlich nur nach diesem Prinzip konstruiert sind. Die Methoden der Datenanalyse sind hervorragend für eine objektorientierte Systemanalyse geeignet, man muß sie, allerdings weitergehend nutzen als nur zur reinen Datenmodellierung.

Eine hinreichende Bedingung für eine echte Objektorientierung stellt, der, Vererbungsmechanismus dar. Das Vererbungsprinzip ist in der Datenbankwelt als Abstraktion, Generalisierung oder Aggregation bekannt. Datenanalyse-Methoden benutzen den Begriff Vererbung nicht oder wenig, da er den Kern des Problems in einer Analysephase nicht trifft: Vererbung suggeriert Hierarchie und Top-down-Entwurf. Die Konstruktion von Datenhierarchien geschieht jedoch fast immer bottom-up, nämlich durch Abstraktion; top-down lassen sich Datenhierarchien nur intuitiv erstellen.

Funktionsorientierte Spezifikations-methoden zwingen bei einem objektorientierten DV-Entwurf immer zu einer Umstrukturierung von Funktionen. In der Sachlogik sind Daten als Input oder Output an Funktionen gebunden, beim Software. Entwurf müssen Funktionen den Datentypen als Operationen zugewiesen werden. Dieser Strukturbruch führt zu Doppelaufwand, Umsetzungsfehlern und Diskrepanzen zwischen der tatsächlichen Implementierung und dem, worauf sich Benutzer und Entwickler geeinigt hatten.

Paradigmenwechsel hat noch nicht stattgefunden

Leider hat ein Paradigmenwechsel im Software-Engineering bis heute nicht stattgefunden. Beweis ist die Aufnahme eines Werkzeugs wie IEW in das strategischen Softwarekonzept AD/Cycle. Die Methodik des Werkzeugs ist funktionsorientiert. Daß eine erschreckende Redundanz und ein enormer Umfang der Grafiken den Entwickler vom Wesentlichen ablenken, ist methodisch bedingt.

Neueste Lehrgangsankündigungen der Yourdon Inc. lassen allerdings hoffen. Der Vermarkter von Structured Analysis/ Structured Design hat eine radikale Kehrtwendung vollzogen. So läßt sich die von mir geäußerte Kritik an SA/SD inzwischen auch bei Coad und Yourdon nachlesen. Es wir Zeit, daß diese Erkenntnis auch in AD/Cycle "offiziell" Eingang findet.

Für die Konstruktion objektorientierter Systeme genügt es nicht, der Funktionsanalyse ein Entity-Relationship-Modell anzuhängen. Vielmehr muß man schon zu Beginn der Analyse die datenerzeugenden Operationen zu den Objekttypen finden, die vorerst nur primäre Daten enthalten sollten. Auswertende Operationen oder die Erzeugung sekundärer Daten sind für den ersten Schritt, die Systembildung, irrelevant.

Detenmodelle lassen sich nicht top-down entwerfen

Das von mir entwickelte Vorgehensmodell Obas (vergleiche CW Nr. 5 vom 31. Januar 1992, Seite 11: "Anwender beschreibt eigenes Entwicklungsmodell") nenne ich objektorientiert, obwohl das Wort Vererbung in der Beschreibung dieses Modells nicht einmal vorkommt. Offen bleibt in diesem Modell die Beziehung zwischen den generalisierten Datenobjekten, der Vererbung von Operationen und den Sprachen, mit denen man Vererbung gar nicht implementieren kann, also beispielsweise Ada, Cobol oder Pascal.

Obas bricht mit einem weit verbreiteten Paradigma des Software-Engineering: Die Entwicklung erfolgt nicht top-down. Ich bezweifle entschieden, daß es überhaupt möglich ist, Datenmodelle top-down zu entwerfen, auch wenn dies bis in die jüngste Zeit behauptet wird - so beispielsweise 1990

von Vetter sowie 1991 von Beetz und Lambers. Vielmehr lassen sich höher in einer Hierarchie angesiedelte Objekttypen eher bottom-up finden, nämlich durch Generalisierung oder Abstraktion. Vorsicht ist bei Analoglen zwischen objektorientierter Analyse und objektorientierten Sprachen geboten. Wenn von einem Top-down-Entwurf die Rede ist, werden oft Produkt und Entwurf verwechselt.

Bei der Spezifikation verwendet Obas Prototypen als Kommunikationshilfe für die Abstimmung mit dem Benutzer, der mit geschriebenen Spezifikationen meist nichts anfangen kann - schon gar nicht mit Papierbergen von Detailfunktionen, wie sie für AD/Cycle empfohlen werden. Zur Konstruktion von Systemen sind Prototypen allerdings gänzlich ungeeignet. Für einen Systementwurf braucht man zunächst Skizzenblock und Bleistift, eine Tafel sowie Diskussionspartner und vor allem einen Kopf.

Eine gute, das heißt wartbare, Software-Architektur, die auf einer objektorientierten Analyse beruht, ist so ziemlich das Anspruchsvollste, was es bei der Software-Entwicklung zu tun gibt. Auf der Basis einer solchen Architektur kann man dann auch daran denken, aus Prototypen inkrementell Echtsysteme zu entwickeln, wie dies in unserem Unternehmen - wenn auch nur bei einfachen Systemen - bereits erfolgreich und kostengünstig geschieht.