Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

07.04.1989 - 

Das Problem der laufenden Anwendungen ist noch nicht befriedigend gelöst:

CASE geht bislang nur auf der grünen Wiese

"Wie halten Sie es mit den laufenden Anwendungen?" So lautet die Gretchenfrage des Computer-Aided Software-Engineering. Die CASE-Anbieter bleiben die Antwort darauf bislang schuldig. Wie dieses Problem mit Hilfe von Source-Code-Analysatoren zu umgehen ist, beschreibt Günter Lau*.

Weltweit zögern die Anwender, CASE-Produkte einzusetzen. Nicht etwa, weil die Einsicht in die produktionstechnische Notwendigkeit einer Systematisierung und Standardisierung der Softwareentwicklung fehlt. Auch die befürchteten Akzeptanzprobleme bei den Entwicklern ließen sich durch geeignete Ausbildung und die Einbindung in die Entscheidungsprozesse voraussichtlich lösen. Selbst die Integration aller Teillösungen ist nur noch eine Frage der Zeit, versprechen die Hersteller. Völlig offen ist dagegen, wie bestehende Software in den Prozeß eingebunden werden soll. Bislang wissen die CASE-Anbieter darauf keine befriedigende Antwort.

Als Ingenieur freut man sich darüber, daß auch die Softwerker sich nun den Begriff "Engineering" auf ihre Fahnen geschrieben haben auch wenn sie mal wieder nicht umhin können, ihn noch mit einem "computer aided" zu versehen. Endlich, so denkt man, bewegen sie sich aus ihrer selbstgewählten elitären Klausur und bequemen sich, über ihren Tellerrand zu blicken.

Aber anstatt schön langsam Schritt für Schritt vorzugehen, versuchen die Softwareingenieure, gleich in einem Riesensprung über alle möglichen Zwischenstufen hinwegzusetzen. Arrogant ignorieren sie die leidvollen Erfahrungen ihrer Ingenieurkollegen und beginnen aus dem Stand heraus mit der Entwicklung.

In der ersten Euphorie und aus dem Zwang zum kurzfristigen Erfolg ihrer Investitionen heraus, schossen die Softwerker weit übers Ziel hinaus und bemerken erst jetzt, daß ihnen ihre Gemeinde nicht mehr folgt. Die gequälte Antwort auf ihre verständnislose Frage nach dem Warum ist die Gegenfrage: Was soll denn aus unseren Millionen Mark teueren laufenden Anwendungen werden?

Das ist die Gretchenfrage, vor der zur Zeit alle CASE-Hersteller stehen. Eine befriedigende Antwort weiß bislang keiner von ihnen. In der Terminologie der Softwareentwickler nennt man das einen kardinalen Spezifikationsfehler. Und das gleich weltweit - in der Tat ein kapitaler Bock.

Im Klartext heißt das: CASE funktioniert derzeit nur auf der "grünen Wiese", bei völlig neu zu schreibenden Anwendungen. Die meisten Systeme sind jedoch langjährig gewachsene, große Anwendungen. Selbst der gewiefteste Verkäufer wird seinen Kunden nicht dazu überreden können, diese völlig neu zu schreiben, nur um sein "buntbescreentes, supersupportendes" Tool einzufahren. Jede Wirtschaftlichkeitsrechnung führt unweigerlich zum Exitus einer solchen Lösung.

Was tun? - Solange Reverse-Engineering noch nicht funktioniert beziehungsweise seine möglicherweise berechtigten Akzeptanzprobleme nicht überwunden sind, ist guter Rat teuer.

So blieb denn kürzlich die "einfache" Frage eines Softwaremanagers an einen Software-Guru nur unvollständig beantwortet: "Schreibe ich mein System lieber ganz neu oder maintaine ich es weiter?" hatte der Anwender gefragt. Die "Wahrheit, guter Mann", so lautete die salomonische Antwort, "liegt sicher in der Mitte." Die Definition der Mitte mußte der Guru jedoch schuldig bleiben.

Ein bißchen mehr Rat wußte der US-Wartungsfachmann Nicholas Zvegintzov, der auf seiner jüngsten Europa-Tournee aus einer Artikelserie seines Kollegen Bob Wachtel von 1988 zitierte.

Wachtel schlägt folgende grundsätzliche Vorgehensweise vor: Am Beginn steht das "Understanding", auch Analysis genannt. Vier Fragen sind dabei zu beantworten, nämlich

- Where? - Wo ist das System? Wo befinden sich seine Teile?

- What? - Aus welchen Teilen besteht es (Source-Code, Object-Code, Dokumentationen, Testinformationen etc.)?

- How? - Wie ist eine bestimmte Aufgabe gelöst (zum Beispiel in Modulen wie SORT, LIST etc.)?

- Why - Warum ist diese Lösung gewählt worden?

Erst danach erfolgt das "Doing" (die Synthesis), die de facto ebenfalls im wesentlichen aus einer Analyse besteht. Die Lösung sieht in tabellarischer Form folgendermaßen aus:

Von dieser Methode zu erwarten sind unter anderem und sicherlich berechtigterweise eine kombinierte Aufruf- und Kontrollflußanalyse und die Ermittlung von Testfällen in Verbindung mit einer Datenflußanalyse.

Und das alles von Hand? - Für Kleinstsysteme mag das ja noch funktionieren; aber was ist mit großen Anwendungen? Selbst in den USA gibt es dafür nur erste weitgehend theoretische Ansätze.

Abhilfe schaffen hier sogenannte Source-Code-Analysatoren. Eine neue Art Tools? - Nein, ein rund zehn Jahre alter Hut. Zwar blühte diese Technik bislang weitgehend im Verborgenen; doch in jüngster Zeit wird ihr Wert in zunehmendem Maße auch vom Softwaremarketing erkannt.

Wartung wird auch für gute Leute interessant

Ein guter Source-Code-Scanner liefert nahezu alle benötigten Informationen computerunterstützt und vollautomatisch: Call-Pfade (-Graphen), Dateizugriffe, Includes und Cross-Reference-Listen geben einen Überblick über das System; Softwaremetriken indizieren "kaputt" gewartete Systemkomponenten.

Kontrollflußgraphen, Datenflußanalysen und Statement-Statistiken sezieren den Quelltext; sie legen toten Code, undefinierte und unverwendete Variablen frei; außerdem geben sie Aufschluß über die Qualität der Programmierung und über die Einhaltung von Programmierrichtlinien. Testbäume und Testpfade bereiten - möglichst in Verbindung mit dem Datenfluß -, die dynamische Analyse effektiv vor.

So lassen sich fundierte Entscheidungen treffen über eine Klassifizierung der Komponenten in drei Gruppen: "kann so bleiben", in die Wartung übernehmen" oder "neu schreiben" - ohne den eigenen hohlen Bauch" befragen zu müssen wie bisher. Softwarewartung bekommt ein professionelles Vorgehen, das auch gute Leute motiviert, sich damit zu befassen.

Politik der kleinen Schritte betreiben

Das Wichtigste dabei ist aber, daß man so ganz nebenbei die Möglichkeit für einen sanften Einstieg in die CASE-Welt erhält. Ein Source-Code-Analyser gibt dem Reverse- und Re-Engineering den Drall in die richtige Richtung, indem er mit graphischen und tabellarischen Ausgaben eine ingangsstufe für ein CASE-Tool liefert. Seine Möglichkeiten hauchen der CASE-Theorie praktisch nutzbaren Atem ein.

Ein Wermutstropfen bleibt allerdings vorläufig noch: Der Kunde muß mangels Schnittstellen die Ergebnisse manuell in seine CASE-Workbench übernehmen.

In der Art der Politik der kleinen Schritte lassen sich jetzt zunächst die wirklich neu zu schreibenden Komponenten, also kleinere Einheiten, in CASE-Umgebungen implementieren. Man kann sogar unvollständige CASE-Tools verkraften, wenn man nicht gezwungen ist, ganze Systeme komplett zu bearbeiten. Die fehlenden Teile sind bei kleineren Größenordnungen leichter zu überbrücken. Last but not least kann jetzt auch die Mitarbeiter-Crew scheibchenweise herangeführt werden, sozusagen im Auszeichnungsverfahren - die Besten zuerst.