In den letzten 25 Jahren wurden in die Software-Entwicklung Milliarden investiert. Vermutlich, so weiß Jürgen P. Schoon* zu berichten, sind etwa 120 Milliarden "Lines of Sourcecode" vorhanden - vorwiegend Cobol-Code. Die Pflege, Erweiterung und Verbesserung dieser bestehenden Anwendungssysteme blockiert in der Regel bis zu 80 Prozent der Software-Entwicklungskapazitäten eines Anwenders.

Für neue Entwicklungen werden in verstärktem Maße CASE-Tools eingesetzt. Diese Anwendungen sind in der Regel effizienter und flexibler als konventionell entwickelte Systeme und lassen sich leichter den veränderten Anforderungen anpassen. Die Wartung vorhandener Anwendungen macht dagegen vielen Unternehmen Sorgen. Die Kluft zwischen der Wartung bestehender Anwendungen und moderner CASE-basierter Software-Entwicklung scheint bis heute nicht überbrückt worden zu sein.

CASE-Tools lösen nicht die Wartungsprobleme

AD/Cycle, IBM-Repository und Forward-CASE-Tools versprechen Effizienz, Produktivität und anwendungsübergreifende Transparenz für Neuentwicklungen. Die Vorteile aus diesen neuen Technologien lassen sich aber nur dann komplett realisieren, wenn auch bestehende Anwendungen in diese moderne Software-Produktionsumgebung einbezogen werden können. Die Investitionen in bestehende Anwendungen sind zu schützen.

Ein DV-Manager, der zum Beispiel 2000 Cobol-Programme warten muß, ist mit den meisten gängigen CASE-Tools nur bei Neuentwicklungen gut bedient. Neue Anwendungen lassen sich effizienter entwikkeln, aufgrund methodischer Vorgehensweise wird die Anwendungsentwicklung produktiver. Dabei werden jedoch die aktuellen Probleme, nämlich der Schutz getätigter Investitionen, nicht gelöst.

In vielen Unternehmen können 80 Prozent der Anwendungsentwickler ihre modernen Tools nicht nutzen - sie sind mit der Pflege bestehender Programme beschäftigt. Dabei sind die 20 Prozent, die mit modernen Tools neue Programme entwickeln, in der Regel durchaus mit ihren Werkzeugen zufrieden. Wenig abwechslungsreich sieht dagegen der Alltag der Entwickler aus, die mit Wartungsaufgaben betraut sind. Diese Mitarbeiter suchen täglich 7,5 Stunden in Compile-Listings und nutzen die restliche halbe Stunde für Programmänderungen. Den DV-Manager interessiert also, wie er diese "blockierten Kapazitäten" freisetzen und in die Entwicklung neuer Systeme einbinden kann.

Ein weiteres Problem ergibt sich, wenn moderne CASE-Technologien wie das AD/Cycle Konzept und das IBM-Repository für die bestehenden Anwendungen genutzt werden sollen. Diese Anwendungen, in die oft Millionen investiert wurden, können schließlich nicht neu geschrieben werden. Hinzu kommt, daß auch für neue Anwendungen alte Datenbestände benötigt werden. Das bedeutet: Die "alte" muß mit der "neuen Welt" gemischt werden.

Reverse-Engineering gilt als Lösung dieses Problems. Tools, die ein teilweises Reverse-Engineering ermöglichen, sind jedoch kein Patentrezept. Auch das Reverse-Engineering von Ada in eine nicht standardisierte grafische Darstellung, um daraus C + + zu generieren, ist nicht unbedingt das, was ein Cobol-Anwender, der mit einem MVS-System arbeitet, benötigt.

Re-Engineering gelingt nicht auf Knopfdruck

Oft verwenden diese Unternehmen noch Batch-Anwendungen, die schon in den 70er Jahren geschrieben wurden mit allen denkbaren Schnörkeln, und die so strukturiert sind, wie das damals eben üblich war: Performance ging immer über Transparenz. Online-Anwendungen laufen unter CICS oder IMS/DC und sind ähnlich strukturiert. Die Daten sind in verschiedenen Formaten gespeichert: VSAM, IMS/DB und teilweise auch noch ISAM. Ein Reverse-Engineering-Tool ist also nur einsetzbar, wenn es diese Welt ersteht.

Ein Tool, das diese Probleme lösen kann; könnte in etwa folgende Eigenschaften haben: Aus der Analyse der Copybooks müssen in einem Repository die Records und Element Objects erstellt werden. Aus den Bibliotheken lassen sich die Bildschirm-Masken lesen, aus denen dann die Screen Objects abgeleitet werden können. Das gleiche muß mit den Listenbildern geschehen.

Außerdem sind die DB-Kontroll-Tabellen zu übernehmen und die JCL-Statements in diesen Prozeß einzubeziehen. Dann wird der "Spaghetti-Cobol-Code" restrukturiert, um daraus Structure Charts und Action Diagrams zu erstellen. Alle Elemente sind zu synchronisieren, so daß die nun in einer Enzyklopädie dokumentierten Anwendungen richtig untereinander verknüpft werden. Erst dann können mit entsprechenden CASE-Tools neue Anwendungen generiert werden, die mit DB2 laufen.

Bei einer Entscheidung für ein Forward-Engineering-CASE-Tool ist gleichzeitig zu bedenken, inwieweit sich die vorhandenen Applikationen in die moderne CASE-Technologie einbeziehen lassen. Re-Engineering bekommt damit zunehmend einen höheren Stellenwert in der Software-Entwicklung. Es gibt Experten, die glauben, daß es wirtschaftlicher ist, bestehende Anwendungen zu "recyclen", als sie unverändert in den nächsten 5 Jahren weiter zu warten.

Software-Re-Engineering ist kein Prozeß, der auf Knopfdruck funktioniert. Es muß sorgfältig analysiert werden, welche Aktivitäten für welche Anwendung sinnvoll erscheinen. Letztendlich bedeutet Re-Engineering Qualitätsverbesserung - aus diesem Grunde ist es wesentlich, daß die Qualität der bestehenden Programme analysiert wird. Programmqualität ist nicht als DIN-Norm vereinbart und muß daher benutzerindividuell definiert werden. Auf Basis dieser Definitionen kann in einer Portfolio-Analyse festgestellt werden, welche Programme sich in welchem Qualitätszustand befinden Daraus resultieren dann unterschiedliche Schlußfolgerungen für Folgeaktivitäten.

Oft genügt es, eine komplexe Anwendung durch programmübergreifende, maschinelle Dokumentation transparent zu machen. Wenn mit dieser Dokumentation erreicht wird, daß der Wartungsaufwand, der in der Regel zu 90 Prozent aus Analyse besteht, sich erheblich reduzieren läßt, beziehungsweise wenn durch maschinelle Dokumentationstransparenz eine fernwirkungsfreie Wartung und Autorenunabhängigkeit realisiert wird, dann ist diese Aktivität in vielen Fällen bereits ausreichend.

Die Ergebnisse einer Qualitäts-Portfolio-Analyse können allerdings auch zu dem Schluß führen, daß nur ein Recycling der bestehenden Anwendungen akzeptable Wartungsaufwendungen zur Folge hat. In diesem Fall wird der Sourcecode einer bestehenden Anwendung durch ein maschinelles Reverse-Engineering auf die Anwendungs- und Designspezifikationen zurückgeführt.

Dabei ist sehr wesentlich, daß in einem Reverse-Engineering-Prozeß eine Anwendung vollständig erfaßt wird. Das bedeutet, die semantische, syntaktische und lexikalische Analyse des vorhandenen Sourcecodes ist auf der Basis eines Expertensystems durchzuführen. Manuelle Nachbesserungen lassen sich so vermeiden.

CASE-lnformation-Modell ist zu entwickeln

Das Ergebnis dieses Prozesses ist ein Sourcecode-lnformation-Modell, das alle Informationen enthält, um daraus in einem weiteren Schritt ein CASE-lnformation-Modell zu entwickeln. Dieses maschinell erstellte Modell enthält alle Informationen, die ein Forward-CASE-Tool benötigt, um Redesign oder Wartung dieser Anwendung durchzuführen.

Die Informationen aus den bestehenden Anwendungen werden in der Design-Workstation eines Forward-Engineering-Tools zur Verfügung gestellt, um von dort eine Neugenerierung des Sourcecodes durchzuführen.

Erst die Verbindung der Reverse-Engineering-Technik mit den Möglichkeiten eines Forward-Engineering-CASE-Tools eröffnen dem Benutzer ein breites Spektrum technologischer Möglichkeiten, sowohl für bestehende Anwendungen wie auch bei der Entwicklung neuer Anwendungen, die mit den bestehenden Programmen verknüpft sind.