Die Frage: Neuentwickeln oder Weiterpflegen? muß demnächst neu gestellt werden. Erschien der Aufwand für eine komplette Neuentwicklung zumeist unangemessen hoch, so stellt Harry Sneed mit dem "Reverse-Engineering" eine Methode vor, existierende Programme umzustrukturieren und wartungsfreundlicher zu gestalten.

Alles Sein ist aus Vergangenem hervorgegangen. Es gibt nichts, was nicht schon einmal war. Neue Elemente entstehen 1 aus alten Elementen mit neuen Attributen. Neue Strukturen sind Zusammensetzungen alter Elemente mit neuen Beziehungen. Somit ist alles Neue stets nur ein Wiederentstehen des Alten in einer neuen Form. Die Substanz dieser Welt ist unvergänglich.

Software ist eine Substanz. Sie besteht aus zahlreichen winzigen Elementen - Daten und Funktionen - mit unterschiedlichen Attributten. Diese Elemente sind in Strukturen eingebettet: Daten in Sichten, Sätzen und Dateien, Funktionen in Modulen und Programmen. Es sind weniger die Elemente (die Daten und Funktionen), die sich ändern, als vielmehr die Strukturen, in denen sie eingebettet sind. Strukturen wie Module und Datenkapseln bilden die Objekte eines Softwaresystems.

Grundelemente wieder verwendbar

"Software Reusability" zielt auf die Wiederverdbarkeit vorhandener Software-Objekte. Aber nicht nur Objekte, sondern auch die Grundelemente lassen sich wiederverwenden. Dadurch wird der Aufwand für die Neuerstellung bereits existierender Objekte und Elemente (einschließlich Entwurf, Codierung und Test) gespart.

Einer Untersuchung von Caspar Jones zufolge sind nur 15 Prozent eines durchschnittlichen Anwendungsprogramms "einmalig". Die restlichen 85 Prozent sind redundant. Warum dann alles neu schreiben? Genügt es nicht, sich auf das Einmalige zu beschränken und das Andere wiederzuverwenden? Warum sollten alte Anwendungen neu entwickelt werden, wenn die gleiche Funktionalität wieder darin vorkommt?

Hier bietet sich das sogenannte Reverse-Engineering als Lösung an. Reverse-Engineering ist die Wiederaufbereitung alter Software mit dem Ziel, soviel nützliche Elemente und Objekte wie möglich daraus zu gewinnen. Software sollte wiederverwendet werden. Allerdings setzt die Wiederverwendung die Wiederaufbereitung voraus. Die Wiederaufbereitung von Daten und Funktionen auf der Code-Ebene ist jedoch schwierig.

Daher empfiehlt es sich, Code auf der semantischen Ebene der Spezifikation zu präsentieren. Hier ist es wesentlich leichter, die Spreu vom Weizen zu trennen; denn hier ist die Software in Form von einzelnen Dictionary-Einträgen gespeichert als Elemente, Beziehungen und Strukturen.

Von hier aus können neue Software-Objekte (Sichten, Sätze, Module und Makros) regeneriert werden. Und von hier aus können grafische Dokumente (Flußdiagramme, Ablaufpläne, Baumstrukturen, Zustandsgraphen) aufbereitet werden. Schließlich kann man hier die Funktionalität eines Systems am leichtesten und am sichersten ändern.

Auf der IFIP-Konferenz im Jahre 1971 stellte Professor Woodger vom National Physics Institute in England das Konzept der semantischen Ebenen in der Software-Entwicklung vor. Er erkannte damals schon drei verschiedene semantische Software-Ebenen:

- die Ebene der Problemdefinition,

- die Ebene der Lösungsdefinition und

- die Ebene der Codierung.

Ein ähnliches Modell schlug Dijkstra in seinem Plädoyer für top-down-strukturierte Programmierung durch schrittweise Verfeinerung über mehrere Abstraktionsstufen vor. Die gleichen semantischen Ebenen wurden später benutzt, um Software-Phasenkonzepte mit den Phasen Anforderungsspezifikation, Systementwurf und Realisierung zu modellieren. Diese Abstraktionsstufen beziehungsweise semantischen Ebenen und deren Darstellung sind inzwischen fester Bestandteil der Software-Engineering-Disziplin geworden und durch die Software-Engineering-Standards des IEEE zu Normen erhoben.

Das Konzept der semantischen Ebenen mit unterschiedlichem Abstraktionsgrad ist nicht nur ein Phänomen des Software-Engineering. Auf dem Gebiet der Datenbank-Technologie hat der ANSI-SPARC-Ausschuß ebenfalls drei Ebenen zur Modellierung von Informationssystemen vorgeschlagen. Diese sind die konzeptionelle Ebene, die logische Ebene und die physische Ebene.

Auf der konzeptionellen Ebene werden Daten als eine Menge von Entitäten mit Attributen und Beziehungen zueinander betrachtet, zum Beispiel im Entity-Relationship-Modell. Auf der logischen Ebene werden Daten als flache Tabellen normalisierter Relationen betrachtet, die über Schlüssel miteinander verknüpft sind, unabhängig von jeglicher physischen Implementierung, so beispielsweise im Relationenmodell.

Auf der physischen Ebene werden Daten als eine Menge von Sätzen behandelt, die durch Zeigerketten, Zeigertabellen, invertierte Listen oder durch Adreßberechnung miteinander verkettet sind. Das kommt zum Beispiel in den seriellen, hierarchischen, vernetzten und relationalen Datenbankmodellen zum Ausdruck.

Im Prinzip läßt sich das dreistufige ANSI-SPARC-Modell auch auf die Software selbst übertragen. Auf der physischen Ebene hat die Software die Form von diskreten Code-Gliedern unterschiedlicher Ausprägung wie Module, Maskenformate, Listenformate, Datenbeschreibungsmakros, Zugriffspfade, Datenbank- oder Dateibeschreibungen und Kormmando- beziehungsweise JCL-Prozeduren. Diese diversen Glieder werden entweder statisch, vor der Ausführung, oder dynamisch, während der Ausführung, durch Precompiler, Compiler, Link-Editoren, Loader oder Systemmonitore im Betriebssystem zu integrierten lauffähigen Programmen zusammengebunden.

Auf der logischen Ebene existiert Software in Gestalt einer Metasprache beziehungsweise einer Programmentwurfssprache (PDL), welche die Software-Verarbeitungseinheiten - die Prozesse, Programme, Module Lind Abschnitte sowie deren Datenkapseln und Schnittstellen - als ein Netzwerk querverbundener Objekte beschreibt.

Diese Objekte sind über Referenzen wie "benutzt", "erzeugt", "abfragt", "auslöst" miteinander verbunden. Die Objekte können selbst als Relationen betrachtet werden, wobei es von Vorteil wäre, sie auch als normalisierte Relationen im Sinne des Retationenmodells anzusehen.

Auf der konzeptionellen Ebene kann die Software wie die Daten als eine Menge abstrakter Entitäten mit vordefinierten Attributen und Beziehungen betrachtet werden. Die Entitäten sind hier Funktionsmengen statt Datenmengen, die Attribute sind die untergeordneten Funktionen. Die Beziehungen sind anderer Art als bei den Daten, mehr zeitlich als räumlich.

Das Modell ist jedoch gleich: ein Netz von Entitäten unterschiedlicher Ausprägung als abstrakte Darstellung der physischen Vorgänge auf dem Rechner. Diese konzeptionelle Sicht der Software als abstraktes Modell einer realen Anwendung ist gleich der Software-Spezifikation, die wiederum die operationalisierte Rückseite eines Fachkonzeptes ist.

In der Welt der formalen Methoden wird die konzeptionelle Sicht als Graphen, Bäume, Tabellen oder als formale Notation zwecks Darstellung, Validation und Fortschreibung festgehalten. Auf dieser Ebene wird die Software für die Menschen visualisiert.

Die Art der Repräsentation ist aber noch offen. Eine Normierung fehlt. Deshalb die Vielzahl von CASE-Tools mit unterschiedlichen Diagrammtechniken und die Vielzahl von Spezifikationssprachen mit unterschiedlichen Formalismen. PSL, RSL, SETL, Paisly, Z und VDL stehen nur stellvertretend für mehr als 100 verschiedene Spezifikationssprachen, die weltweit benutzt werden.

Außer den vielen Spezifikationssprachen und Diagrammtechniken gibt es mindestens zwei Ansätze - den operationalen Ansatz von Zave und den transformationalen Ansatz von Professor Bauer - bei denen die konzeptionelle Ebene als Basis für die Generierung der darunterliegenden Ebenen verwendet wird. Danach wird die Software auf der konzeptionellen Ebene erfaßt, dokumentiert und validiert, um anschließend auf der logischen Ebene transformiert zu werden. Dort reichert man sie entweder manuell durch eingebaute Regeln oder mit Hilfe einer Wissensbasis an und strukturiert sie entsprechend der Zielmaschine, um von dort aus die physische Ebene mit einem intelligenten Generator zu erzeugen.

Wenn dieser Transformationsprozeß von der Spezifikation über den Entwurf zum Code möglich ist, muß es ebenso möglich sein, rückwärts die Code-Ebene über die Entwurfsebene in die Spezifikationsebene zu transformieren. Denn im Code liegt die einzige vollständige und korrekte Beschreibung der Lösung. Nach Ferber ist die einzig richtige Programmbeschreibung das Programm selbst. Dieser Prozeß der Bottom-up-Transformation ist eine natürliche und notwendige Folge der Top-down-Transformation.

In Anbetracht der Ziele, die die Top-down-Entwicklung verfolgt, nämlich lauffähige, qualitativ hochwertige, korrekte Programme aus abstrakten, allgemeingültigen Spezifikationen mit einem minimalen manuellen Aufwand zu produzieren, ist das Ziel des Reverse-Engineering genau das Gegenteil, nämlich aus korrekten lauffähigen Programmen eine abstrakte, allgemeingültige Spezifikation mit einem minimalen manuellen Aufwand abzuleiten.

Dabei müssen die ursprünglichen Programme nicht unbedingt qualitativ hochwertig sein, denn ein weiteres Ziel des Reverse-Engineering ist es, aus korrekten aber qualitativ minderwertigen Programmen korrekte und qualitativ hochwertige Programme zu regenerieren. Diese qualitative Verbesserung oder Sanierung durch Restrukturierung wird oft mit Reverse-Engineering verwechselt, ist aber eigentlich ein Abfallprodukt der Invers-Transformation. (wird fortgesetzt)

Harry Sneed ist Geschäftsführer der SES GmbH, Neubiberg bei München.

Jungbrunnen statt Datenschrottplatz

Auch die IBM ist mittlerweile auf den Trichter gekommen: Eine finanzielle Beteiligung an der Bachman Information System Inc. sichert dem jetzt angekündigten Anwendungsentwicklungskonzept "Application Development Cycle" die Unterstützung eines der bislang wenigen Spezialisten für Re-Engineering-Tools. Allzu lange nämlich ist die sogenannte CASE-Diskussion am Thema vorbeigegangen, weil sich ihre visionären Modelle und Theorien nahezu ausschließlich an der Entwicklung neuer Anwendungssysteme orientiert haben. Tatsächlich können viele Entwicklungsabteilungen aber kaum noch neue Projekte in Angriff nehmen, weil ein großer Teil ihrer Kapazitäten durch wartugsintensive Alt- und Uraltprogramme gebunden ist. Andererseits bedeuten die vielzitierten Software-Altlasten für die Anwenderbetriebe durchaus schützenswerte Investitionen. Dieses Dilemma zu beheben, versprechen die Vorkämpfer einer Disziplin, deren Bezeichnung zum Branchenschlagwort des Jahres avancieren dürfte: des Rebeziehungsweise Reverse-Engineering. Was der Anwender davon erwarten kann, soll ein dreiteiliger Beitrag von Harry Sneed klären, mit dessen Abdruck wir auf dieser Seite beginnen. qua