Vergangenheit und Zukunft der CASE-Methoden (Teil 1)

CASE - Auf dem Weg zur industriellen SW-Fertigung

27.09.1991

Der Begriff "Software Engineering" wurde vor über 20 Jahren geprägt. Trotz einer Reihe von Fortschritten sind die Forderungen der Industrie nach einer ingenieursmäßigen Planung bei der Software-Entwicklung nur zu einem geringen Teil erfüllt. Der Beitrag von Johann Wagner* beschreibt im ersten Teil die Schwierigkeiten bei der Einführung von Computer Aided Software Engineering (CASE) und im zweiten Teil die Perspektiven, die sich daraus für die Zukunft ergeben.

Software war früher ein notwendiges Beiwerk zur Hardware. Inzwischen ist sie zu dem industriellen DV-Erzeugnis geworden, von dem sich die Branche die höchsten Gewinne erhofft. Höhere Produktivität beziehungsweise geringere Kosten und die Beherrschung der Komplexität haben ihren Ursprung in der Vereinfachung, Standardisierung und Zuverlässigkeit von Konstruktionselementen. Die Standardisierung von Software ist erst am Anfang.

Wegen des fast unbegrenzten Spielraums, in dem sich der Software entwickelnde Geist bewegt, ist kaum zu erwarten, daß Standards allein durch deren Verständlichkeit und Nützlichkeit entstehen. Massive wirtschaftliche Interessen stehen deutlich im Vordergrund, wenn auch das Phänomen Unix nachdenklich, ja versöhnlich stimmt.

Ein Abriß der CASE-Geschichte

Animiert von Vorstellungen der mechanischen industriellen Fertigung kehren die Vorstellungen von Halb- und Fertigfabrikaten immer wieder: Software-Bausteine, Subsysteme, Standard-Bibliotheken, Software-ICs und offene Systemplattformen.

Nach dem gleichen Denkmodell (Wasserfallmodell) des schrittweisen Zusammenbaus von Produkten wird seit langer Zeit der Prozeß der industriellen Softwarefertigung gesehen. Davon leiten sich die Phasenmodelle aller bisher praktizierten Softwareprozeßordnungen ab. Das Modell ist nützlich, aber heute nicht mehr unumstritten.

Seit fast zwanzig Jahren gibt es den Begriff Software Engineering, seit etwa fünf Jahren den Begriff des Computer Aided Software Engineering. CASE sollte die Methode der industriellen Softwarefertigung sein. Es sollte die Antwort der USA und Europas auf die japanische Herausforderung werden. Heute müssen wir uns fragen, ob wir mit dem bisher Erreichten zufrieden sein können.

In der Mitte der 80er Jahre, in einer Zeit als es üblich war, die Entwicklung von Software großenteils außer Haus durchführen zu lassen, und als offensichtlich wurde, daß die damit verbundenen Werkverträge eher auf Vertrauen als auf konkreten Vorgaben beruhten, haben Pioniere von CASE wie Yourdon und deMarco beobachtet, was die Entwickler bei ihren Vorüberlegungen und Teamabsprachen an die Tafel malten: Es waren Funktionsblöcke, Speicher (Tonnen) und Kommunikationswege (Blitze).

Ablaufdiagramme oder Zustandsdiagramme waren seit längerem bekannt, aber für die abstraktere Darstellung eines Systems fehlte der entsprechende Formalismus. Hinzu kamen die ersten Workstations und bald Grafikanwendungen auf dem PC, die man als Zeichenhilfe einsetzen konnte. Die Möglichkeiten im CAD-Bereich nährten die Idee, nun auch grafische Sprachen für die Software-Entwicklung zu verwenden. Kurioserweise wurde im Bereich der Hardware-Entwicklung zur gleichen Zeit wegen der steigenden Komplexität des Gegenstandes immer mehr die textuelle Ausdrucksweise, etwa ein Ada-Dialekt verwendet.

Die CASE-Einführung war verbunden mit dem Glauben, daß mit der Hilfe des grafischen Ausdrucks Software-Entwürfe leichter verstanden und damit besser überprüft werden können. Die Blaupausen-Durchsprache für Software sollte beginnen. Der Appell der CASE-Gurus richtete sich vornehmlich an das Management der Unternehmen.

Heute verwenden laut einer im vergangenen Jahr von den Ovum-Marktforschern herausgegebenen Statistik in den USA nur etwa vier Prozent der Software produzierenden Firmen die klassischen CASE-Tools für die Systemanalyse. Bei den übrigen Firmen, - zirka 40 Prozent haben diese Tools gekauft - sind diese Tools sogenannte Shelfware geworden.

Ist CASE der Flop der 80er Jahre? Was sind die eigentlichen Gründe, welche die Ausbreitung von CASE und damit des Software-Engineering behindern?

Der wissenschaftliche und industrielle Fortschritt geht Hand in Hand mit der Entwicklung sprachlicher Mittel zur Beschreibung der dabei relevanten Gegenstände. Dies gilt auch für die Software. Darüber hinaus benötigt die Software-Entwicklung als arbeitsteiliger Prozeß sprachliche Mittel zur Beschreibung der von den einzelnen Projektbeteiligten zu erstellenden Komponenten des Produkts, sowie die Vereinbarung der Vorgehensweise, des Prozeßablaufes, selbst.

CASE ist ein Kind der Industrie und damit ein Mittel zur Rationalisierung der Fertigung. Der Bedarf an Software wächst ständig, und obwohl die Wiederverwendung vorhandener Software, also bereits vorhandenen Ideengutes nahe läge, scheitert diese Idee immer wieder an folgenden Gründen:

- Software ist schwer zu beschreiben.

- Die Wiederverwendbarkeit verursacht zusätzliche Projektkosten und unerwünschte Abhängigkeiten von den Lieferanten.

- Bei vielen Systemkomponenten wie dem Betriebssystem oder Datenbanken und neuerdings den Grafiksystemen ist eine weitgehende Standardisierung beziehungsweise Wiederverwendung bereits erreicht.

- Innerhalb vieler Firmen ist noch genug Rationalisierungspotential auf anderen Gebieten vorhanden.

CASE-Techniken unterstützen die Absicht, Software einheitlicher zu beschreiben als in der Vergangenheit und damit schon in der Entwurfsphase die Wiederverwendung von Konzepten zu ermöglichen. Dies ist der tiefere Sinn von CASE.

CASE schafft damit Öffentlichkeit und demnach einen Verlust der Privatsphäre. Wäre dieser sozialethische Grund der einzige, an dem ingenieursmäßige Software-Entwicklung bisher gescheitert wäre, so müßte man dies dem Management anlasten.

Wir sollten einige andere grundsätzliche Probleme in Betracht ziehen, ehe wir von eigenen Erfahrungen sprechen und Hinweise auf mögliche Auswege aus dem CASE-Dilemma geben.

Software-Entwicklung ist das kreative, geschickte und mutige Ausprobieren neuer Lösungen. Jedes Stück Software, das geschrieben wird, ist etwas grundsätzlich Neues. Die wichtige Frage ist, ob die von den derzeitigen CASE-Methoden empfohlenen Vorgehensweisen dabei mit den Gewohnheiten und Möglichkeiten des Intellekts konform gehen.

Argumente gegen den CASE-Einsatz

So sollte man Leuten, die eine strikte Top-down-Vorgehensweise empfehlen, eher mißtrauen. Neuere Feldstudien haben ergeben, daß selbst in den frühesten Phasen eines Projekts das Detail von eminenter Wichtigkeit ist, die Vorstellung zwischen den verschiedenen Abstraktionsebenen eher pendelt als kontinuierlich fortschreitet.

Der menschliche Geist besitzt die außerordentliche Fähigkeit der Abstraktion, das heißt die Möglichkeit die für eine Situation wichtigen Dinge hervorzuheben, um diese zum Beispiel für andere zu dokumentieren. Die bei CASE geforderten Abstraktionsebenen beziehungsweise Verfeinerungsebenen sind Ebenen der Dokumentation. Wenn wir Top-down vorgehen, dokumentieren wir dann nicht Dinge, die wir noch gar nicht kennen oder die, weil wir Erfahrung haben, vollständig überblicken? Zäumen wir mit CASE nicht das Pferd vom Schwanz auf?

Als Mittel der Ablaufanalyse einer bestehenden Organisation haben sich CASE-Methoden durchaus bewährt, wobei das Aufspüren der involvierten Datenobjekte und Prozesse (Funktionsträger) eher anhand von Ereignissen geschieht: "Wenn-dann-Befragung" anstelle einer geheimnisvollen Zerlegung von Datenflüssen Top-down. Das Ergebnis ist eine Dokumentation des Istzustandes. Damit hat man jedoch noch kein neues System.

Die nun folgende Phase ist für ernsthafte CASE-Anwender die schmerzlichste. Die ersten Vorstellungen vom neuen System werden amorph erkennbar und zeitigen viele, viele andere Möglichkeiten. Viele Produkte, selbst solche mit nur wenigen Mitarbeitern, schleppen sich in diesem Stadium gegenteiliger Auffassungen dahin. Wer kann mit Sicherheit sagen, daß die neue Architektur die richtige ist? Wer übernimmt die Verantwortung dafür?

Zusammenbruch der Top-down-Architektur

Eine derartige Stagnation kann zum Abbruch des Projektes führen, wenn nicht ein erfahrener Mitarbeiter die Führung übernimmt und beispielsweise den Vorschlag für die Strukturierung der Datenverwaltung der neuen Anwendung auf den Tisch legt. Dies bedeutet oft auch den Zusammenbruch der Top-down-Architektur (Ist-Organisation) und geschieht deswegen meist gegen heftigen Protest von Mitarbeiterseite.

Diese kritische Phase der Systementwicklung, die mit dazu beiträgt, daß der Einsatz von CASE die Kosten reduziert, fordert vom Entwickler ein meditatives In-sich-gehen. Die Validierung der vorgeschlagenen Lösung erfolgt allein im Kopf. Dort findet gleichsam eine Art Prototyping statt.

In letzter Zeit ist immer mehr der Wunsch nach ausführbaren Spezifikationen zu hören. Was ist das anderes als der Wunsch nach einem Prototyping oder einer Simulation, um die Fehler in einem Konzept früher zu erkennen. Dazu ist die Qualität der beim Entwurf verwendeten Sprachmittel von entscheidender Bedeutung.

CASE in der heutigen Form ist eine äußerst abstrakte Dokumentationshilfe für Software-Systemkonzepte. Haben wir mehr erwartet? Wenn nein, warum hat sich dieses Mittel nicht schneller durchgesetzt?

CASE ist derzeit zu abstrakt, zu universell. Dieser Ansatz setzt eine intensive Schulung des Denkens voraus; die mehr oder minder guten Zeichenhilfen, die wir als CASE-Tools kennen, hassen oder lieben sind dafür kein Ersatz.

Für den klassischen Programmierer ist CASE etwas Unvertrautes. Er kennt den Dschungel der Anwendung, den er betreut, die Fallen der Sprache, in der sie geschrieben ist und den Unrat, den seine Vorgänger hinterlassen haben. Sein Wissen ist eher intuitiv und topologisch orientiert. Er ist vergleichbar mit einem Experten, der sein Wissen nicht weitergeben kann, weil er nie eine Sprache zur Beschreibung seines Wissens gelernt hat.

CASE ist heute ein Ausdrucksmittel für ausgebildete Ingenieure. Für einzelne typische Anwendungen gibt es diese Methode noch nicht. Die Unternehmensmodelle sind noch im Entstehen begriffen.

Die Softwaremacher von heute - es gibt zirka zwei Millionen Cobol-Programmierer - scheuen von Natur aus die Abstraktion. Abstraktes Denken ist vielen unangenehm.

Bei dem Versuch, die reine CASE-Lehre anzuwenden, stehen dem Programmierer plötzlich sämtliche vertrauten Ungereimtheiten eines Softwareprodukts, mit denen er täglich zu tun hat, fremdartig gegenüber. Der erste Wutanfall geht über in dauerhafte Frustration. Der Antrieb erlahmt auch dadurch, daß die notwendige Überarbeitung eines ablauffähigen Programms oftmals als "polishing apples" gesehen wird.

Die Vehemenz, mit der sich sogenannte Sprachen der vierten Generation (4GL) neben (oder innerhalb) CASE einen Markt erobert haben, zeigen, daß wir eher an kurzfristig verfügbaren Lösungen interessiert sind als an einer übersichtlichen Softwarearchitektur. Über die Produktivität von Sprachen der vierten Generation wird sagenhaftes berichtet. Über die Wartbarkeit der damit erstellten Programme schweigt man sich aus.

Keine von diesen Sprachen ist zu einem Standard geworden. Dennoch signalisiert der Einfluß dieser Sprachen einen Bedarf an eingeschränkten und damit einfachen aber mächtigen Sprachmitteln.

Wenn Software nicht von Dauer ist, und wenn kommerzielle Software sowieso immer nach dem gleichen Schema entwickelt wird, wozu dann überhaupt CASE? Was ist dann CASE? Kurz nachdem Ed Yourdon seine Firma verkauft hatte, meinte er scherzend, daß CASE nur zur Beherrschung der mongolischen Horden gut wäre, wenn sie über das amerikanische Verteidigungsministerium herfielen.

(wird fortgesetzt)