Waehrend Re-Engineering und Restrukturierung von Programmen in vielen Unternehmen Alltag geworden sind, gibt es beim komplexeren Reverse Engineering groesste Schwierigkeiten. Vielfaeltige werkzeug- und benutzerbedingte Defizite sind nach einer Untersuchung von Herbert Ritsch* dafuer verantwortlich, dass die entsprechenden Projekte immer wieder fehlschlagen.

In den meisten Unternehmen existieren kommerzielle Anwendungssysteme, die sich schwierig und nur mit grossem manuellen Aufwand warten lassen und ueberwiegend in Cobol geschrieben sind. Es handelt sich um "gewachsene Applikationen", die oft seit mehr als zehn Jahren eingesetzt werden - zumeist unstrukturiert und nicht selten unvollstaendig dokumentiert.

An zuverlaessigen Informationen ueber Inhalt oder Ablaeufe mangelt es in der Regel, oft existieren sie nur in den Koepfen einiger weniger Mitarbeiter. Die gewachsenen Applikationen koennen aus finanziellen oder technischen Gruenden nicht leicht ersetzt und neu geschrieben werden. Vielfach liegt der technische Grund darin, dass sie aufgrund von komplexen Modulen, unorthodoxen Codierungen, fehlender Trennung von Daten und Funktionen etc. keine Struktur aufweisen, die eine schrittweise Abloesung einzelner Bestandteile ermoeglichen wuerde.

Die Abloesung eines Anwendungssystems steht aber an, wenn beispielsweise die Hardware, auf der es laeuft, oder die Betriebssystem-Software geaendert werden muss - was etwa dann der Fall sein kann, wenn der Wartungsvertrag der Hardware auslaeuft und aus firmenpolitischen Gruenden nicht mehr verlaengert wird.

Schlechte Dokumentationen bereiten oft Probleme

Zudem wird die taegliche Wartung in vielen Unternehmen dadurch behindert oder kostspielig, dass keine ausreichende Dokumentation mehr vorhanden ist. Eine Dokumentation ist dann aussagekraeftig, wenn sie eine Semantik aufweist, die sogenannten Dritten - Personen, die keinen unmittelbaren Bezug zur untersuchten Applikation haben - als Hilfe bei der Analyse des aus ihrer Sicht fremden Programms dient.

In manchen Faellen kann auf Mitarbeiter zurueckgegriffen werden, die ueber die Bedienung des Anwendungssystems Bescheid wissen. Niemand im Unternehmen besitzt jedoch in der Regel ausreichende Informationen ueber den funktionalen Inhalt einer Applikation.

Reverse Engineering wird als ein Ansatz gesehen, der eine Antwort auf diese unbefriedigende Situation in Form einer Nachdokumentation von gewachsenen Applikationen anbieten soll. Es geht darum, ein logisches - nicht notwendigerweise das urspruengliche - Daten- und Verarbeitungsmodell aus dem Quellprogramm zu gewinnen.

Dabei sind werkzeug- von benutzerbedingten Problemen zu unterscheiden. Der Einsatz heutiger Reverse-Engineering-Werkzeuge laesst vier Teilprobleme erkennen, die bis heute ungeloest sind:

1. Das Problem der rekonstruierten Daten- und Funktionsmenge. Das Mengenproblem auf der Daten- und der Funktionsseite schraenkt den Reverse-Engineering-Prozess erheblich ein - man kann von einer Informationsexplosion sprechen.

Das Reverse-Engineering-Werkzeug "Specview" beispielsweise analysiert Programme auf ihrer elementaren Ebene. Dies gilt fuer den Bereich der Features wie fuer die Daten. Wenn Funktionen durch das Reverse-Engineering-Werkzeug als elementare Operationen beziehungsweise Zweige im Ablaufgraphen erfasst werden, reduziert sich beispielsweise der Funktionsinhalt auf durchschnittlich zwei bis drei Befehle. So entsteht eine Vielzahl von atomaren Funktions- und Datenelement-Eintragungen im jeweiligen Function und Data Dictionary.

2. Das Problem der Benennung. Das Erkennen und die richtige Deutung von nicht aussagekraeftigen Namen als ein Ergebnis des mit einem Werkzeug durchgefuehrten Reverse-Engineering-Prozesses ist fuer den Benutzer aeusserst wichtig. Fuer die Umbenennung von Daten wird von einem Werkzeug ein Katalog von Datennamen aus den Datendeklarationen im Programm erzeugt.

Diese werden in einer Datenbeschreibungstabelle zusammen mit ihrem Typ, der Laenge und der Verwendung gespeichert. Es obliegt jedoch dem Benutzer, die kurz codierten Bezeichnungen durch laengere, selbsterlaeuternde zu ersetzen. Durch die Aenderung eines Namens im Datenkatalog wird jener automatisch auch in allen Anweisungen des Programms, die sich auf diesen Namen beziehen, geaendert.

Programmen fehlt es an sprechenden Namen

Das Problem der richtigen "Benennung" zeigt die Grenzen eines automatischen Reverse-Engineering-Prozesses auf. Die Namen der Objekte und Datenattribute wurden meist unter DV-technischen Gesichtspunkten gewaehlt, ihre semantische Bedeutung ist fuer den Experten schwer zu verstehen. Die Namen der Funktionen werden in der Regel von Wartungswerkzeugen (statischer Analysator etc.) generiert und beziehen sich meist auf die Codeprozedur oder - Zeile.

3. Das Problem der unzureichenden Kommentierung. Der Mangel an aussagekraeftigen Funktions- und Datennamen impliziert meist auch eine fehlerhafte Dokumentation der Programme insgesamt. Wenn Daten und Prozeduren nicht kommentiert sind, generiert das Reverse- Engineering-Werkzeug lediglich Kommentarbloecke, die fuer den Benutzer wenig aussagekraeftig sind.

Reverse-Engineering-Werkzeuge bilden das Programm in rekonstruierten Modellen (Daten-, Kontrollfluss-Diagramm etc.) ab, koennen jedoch nur so viel an aussagekraeftigen Ergebnissen liefern, wie in den Programmen selbst vorhanden sind.

4. Das Problem der rekonstruierten Uebersichtsdokumentation. Durch Reverse Engineering wird eine Reihe von Detailinformationen produziert und im Repository bereitgestellt. Das entsprechende Werkzeug bietet dem Benutzer eine grosse Auswahl an Darstellungsmoeglichkeiten wie zum Beispiel Daten- und Prozessmodelle oder Aktionsdiagramme. Fuer den Benutzer waeren eine automatisch rekonstruierte Ueberblicksgrafik und eine leicht verstaendliche Praesentation der fachlichen Zusammenhaenge wuenschenswert. Die rekonstruierten Modelle, Tabellen und Diagramme bieten Informationen jedoch stets nur aus der Sicht der Implementierungsebene.

Der fachliche Zusammenhang der rekonstruierten Daten- und Funktionselemente ist ohne zusaetzliche Hilfe von den zustaendigen Autoren, Wartungsprogrammierern, Systemanalytikern, Domain- Experten etc. nicht ableitbar, wenn die Ergebnisse des Reverse Engineering aufgrund der wenig aussagekraeftigen Dokumentation keine weiteren Analyseschritte mehr zulassen.

Re-Engineering und Restrukturierung konnten gegenueber dem Reverse Engineering in der letzten Dekade einige Fortschritte erzielen, die auch durch verschiedene Fallstudien aus der Industrie belegt werden. Die augenscheinliche Divergenz in der Entwicklung der Re- Techniken liegt unter anderem daran, dass die Wege zu den gewuenschten Zielen bei Re-Engineering oder Restrukturierung im Gegensatz zu Reverse Engineering genau definiert sind.

Aufgabe des Re-Engineering ist es, ein Programm, eine hierarchische Datenbank oder eine Benutzer-Schnittstelle in ein anderes, bereinigtes Programm, eine relationale Datenbank oder eine eleganter definierte Benutzer-Schnittstelle zu transformieren. So laesst sich im Idealfall eine andere, qualitativ bessere Variante der untersuchten Software schaffen.

Mit Reverse Engineering soll es dagegen moeglich sein, Informationen in Form von Wissen aus den Programmen und Daten zu extrahieren und diese in einer hoeheren Abstraktionsebene abzubilden. Die Probleme werden schon hier offensichtlich: Unklar ist, welche Information rekonstruiert und in welcher Darstellungsform sie abgebildet werden soll.

Tester und Analytiker erwarten nicht dasselbe

Die Erwartungen, die etwa Tester, Wartungsprogrammierer, Analytiker und Endbenutzer an das Reverse Engineering stellen, sind sehr unterschiedlich. Die Interessen des Testers liegen naturgemaess im Testdeckungsbericht (Test Coverage Report), in dem die Testueberdeckung des Programms und seiner Daten protokolliert wird. Der Tester wird sein Augenmerk vornehmlich auf den Kontrollfluss im Programm, auf die verwendeten Daten und die Schnittstellen richten.

Dem Wartungsprogrammierer geht es seinerseits darum, Defekte zu lokalisieren oder Auswirkungen der Aenderungen zu identifizieren. Er benoetigt Informationen ueber Querverweise und Aufruf- Hierarchien, intermodulare Verbindungen sowie Datenflusszweige.

Tester und Wartungsprogrammierer bevorzugen gleichermassen eine Programmiersprachen-orientierte Sicht auf die Applikation (wechselnde Namen, Erzeugen von Aggregationen oder Ausblenden von unwichtigen Details). Selbst Diagramme sind fuer diese Zielgruppe in der Regel inakzeptabel, sofern sie nicht die dem Programm zugehoerigen Funktionen und Daten abbilden. Tester und Wartungsprogrammierer werden sich deshalb eher auf den urspruenglichen Code konzentrieren, als in Kauf zu nehmen, dass durch diesen Abstraktionsprozess wertvolle Information verlorengeht.

Die Gruppe der Wartungsprogrammierer und Tester stellt mehrere Anforderungen an ein Reverse-Engineering-Werkzeug.

Sie moechten unter anderem in Erfahrung bringen,

- in welchen Saetzen und Datenstrukturen ein bestimmtes Datenelement vorkommt;

- von welchen Modulen, Transaktionen und Funktionen es verarbeitet wird;

- welche Module einen Satz verarbeiten;

- in welchen Dateien beziehungsweise Datenbanken ein Satz gespeichert ist;

- welche Datenelemente von einer Funktion oder Transaktion verarbeitet werden;

- auf welche Saetze oder Dateien von einem Modul aus zugegriffen wird;

- in welchen Modulen eine bestimmte Funktion vorkommt und

- welche anderen Module ein Modul aufruft.

Ausserdem soll es moeglich sein, durch die Programmdokumentation zu navigieren.

Eine andere Sicht der Dinge haben Analytiker und Endbenutzer. Sie wollen die Details gaenzlich unterdrueckt wissen, um einen Ueberblick der Vorgaenge im Code zu erhalten. Sie sind an der Applikationslogik interessiert und vernachlaessigen technische Details wie Datenbankzugriffe und Masken- oder Fehlerverwaltungsroutinen.

Analytiker wollen einen allgemeinen Ueberblick ueber die Anwendung bekommen. Sie benoetigen eine generelle - semantisch hoehere - Abstraktionsebene, die die Datenobjekte und ihre Beziehungen zueinander sowie Zugriffspfade, Aufrufhierarchien und die Exekutionsfolge der Prozessschritte entfaltet.

Eine solch abstrahierte Uebersicht ueber die Software-Architektur interessiert Mitarbeiter der Fachabteilungen, die Endbenutzer also, weniger. Sie benoetigen detaillierte Informationen auf der Statement-Ebene, das heisst auf der Ebene der atomaren Funktionselemente. Diese soll jedoch nicht die technischen Informationen enthalten, sondern die logischen Funktionen - beispielsweise die Entscheidungslogik fuer die Berechnung von Zinsen. Endbenutzer wollen die sogenannten Geschaeftsregeln (Business Rules) aus dem Programm extrahieren.

Tools richten sich an verschiedene Gruppen

Zusammenfassend laesst sich feststellen, dass Restrukturierung und Re-Engineering in erster Linie dem Programmierer weiterhelfen. Reverse Engineering ist hingegen fuer verschiedene Benutzertypen relevant, wenn es auch den Anspruch, die Anforderungen aller Interessengruppen zu befriedigen, nicht erfuellen kann.

Auf die Wuensche einer bestimmten Gruppe vertiefend einzugehen bringt zunaechst Vorteile. Ein Beispiel dafuer sind die Reverse- Engineering-Werkzeuge Via-Insight von der Viasoft Inc. oder jene von McCabe & Assoc. McCabe-Werkzeuge sollen ausschliesslich Wartungsprogrammierer und Tester zufriedenstellen. Auf deren Beduerfnisse laesst sich im Gegensatz zu den Anforderungen des Endbenutzers oder Analytikers zweifelsohne viel eher eingehen.

Je hoeher das Abstraktionsniveau ist, das man - ausgehend von der Code-Ebene - im Reverse-Engineering-Prozess zu erreichen versucht, desto schwieriger wird es, diesen Prozess durch ein entsprechendes Werkzeug zu unterstuetzen.

Es existieren nur wenige Tools, die einen Ueberblick ueber die Applikationsarchitektur in verstaendlicher Form anbieten. Da es keine automatische Trennung zwischen den technischen Details und der Fachlogik durch die Werkzeuge gibt, werden dem Benutzer dieser Tools stets mehr Detailinformationen geboten, als er eigentlich wuenscht.

Tools genuegen nicht den Analytikeranspruechen

Dieses Auseinanderklaffen von Wuenschen und Leistungsfaehigkeit der gaengigen Werkzeuge ist verantwortlich fuer die generelle Enttaeuschung der Kunden ueber Reverse Engineering. Die Aussage, dass sich eine Programmspezifikation aus der Anwendung selbst extrahieren laesst, hat zur Konsequenz, dass sich der Analytiker oder Endbenutzer ein Spezifikationsdokument vorstellt, das die fuer das Verstehen des Programms notwendigen Informationen bereitstellt, ohne auf technische Details naeher einzugehen.

Tatsaechlich aber erzeugt Reverse Engineering entsprechend dem Stand der Technik Tabellen und Diagramme, die einzig der Programmierer versteht, weil sie nichts als technische Details beinhalten. Der Grund liegt darin, dass die Ergebnisse des Reverse Engineering stets auf das Niveau der Implementierungsebene beschraenkt sind. Wenn beispielsweise das Programm nicht wiederzuerkennende Namen fuer Funktionen und Daten, keine Dokumentation sowie spezielle Datenkommunikationsroutinen enthaelt, fliessen diese direkt in die rueckuebersetzte Spezifikation ein.

Was ein Reverse-Engineering-Werkzeug bislang nicht liefern kann, ist die Applikationssemantik, die der Endbenutzer eigentlich erwartet. Es waere falsch, anzunehmen, dass sich Reverse Engineering aufgrund des werkzeugbedingten Problemkreises im Rahmen einer Nachdokumentation von Applikationen nicht sinnvoll anwenden laesst. Die Technik ist fuer den Wartungsprogrammierer im Nachvollziehen der Querverweise und fuer den Tester im Definieren der Testfaelle erfolgreich. Bislang versagte sie jedoch, wenn es darum ging, die Fragen der Analytiker und Endbenutzer zu beantworten.

Folgende Thesen moechte ich hinsichtlich der Werkzeuge aufstellen:

1. Mit den heute verfuegbaren Werkzeugen ist es unmoeglich, die fachliche Bedeutung eines Systems automatisch aus dem Programmcode abzuleiten. Die Information ueber Zweck und Bedeutung von Datenfeldern oder -strukturen laesst sich aus dem Programmcode allein nicht ableiten. Ohne zusaetzliche Informationen lassen sich auch keine zuverlaessigen Aussagen ueber die Nebenwirkungen von Aenderungen im Programm treffen. Die Dokumentation aus dem Reverse- Engineering-Prozess heraus hat stets die Sicht der Implementierung.

Ein Werkzeug kann entweder nur die im Programmcode vorhandene explizite oder implizite Information nutzen oder im Werkzeug selbst gespeicherte Regeln und Daten verwenden. Aus keiner der beiden Quellen lassen sich jedoch Informationen ueber die fachlichen Zusammenhaenge automatisch und ohne Zusatzwissen ableiten.

Benutzer sind auf Grafik angewiesen

Der Reverse-Engineering-Analytiker ist nur durch Gespraeche mit der Fachabteilung in der Lage, sich Hintergrundwissen anzueignen und dadurch neue Informationsquellen ueber die Applikation zu erschliessen. In einem naechsten Schritt kann er ueber Vermutungen und Annahmen Hypothesen aufstellen, die ihn in seinem Prozess des Programm-Verstehens weiterfuehren.

Die wichtigste Aufgabe der Werkzeuge ist es, die im Programm vorhandenen Informationen sichtbar darzustellen: so zum Beispiel die Aufrufhierarchie, der Datenfluss, die Benutzung von Datenelementen oder die zeitlichen Zusammenhaenge. Es ist seitens des Benutzers praktisch ummoeglich, die Zusammenhaenge in einem System ohne geeignete grafische Darstellungen rasch zu ueberblicken. Reverse-Engineering-Werkzeuge sollten vor allem zur Erstellung von Grafiken eingesetzt werden.

Die Aussagen ueber Zweck und Bedeutung der im System relevanten fachlichen Hintergruende lassen sich also kaum aus dem Programmcode allein herleiten. Gerade in kommerziellen Applikationen sind die Daten, die im System verarbeitet werden, wesentlich fuer eine Analyse. Soll deren Bedeutung und Inhalt erschlossen werden, ist meist der Benutzer hinzuzuziehen.

2. Die Datenelemente sind der Angelpunkt, an dem die fachliche Anforderung und die DV-technische Realisierung zusammenhaengen. Datenelemente tragen daher am meisten zum Verstehen kommerzieller Anwendungen bei. Wo eine naehere Beschreibung der Datenelemente fehlt, erschliesst zunaechst der Bezeichner den Zugang zum Inhalt. Sprechende Namen helfen, die richtigen Assoziationen zu wecken. Als weiteres Indiz dient die Herkunft des Datenelements. Weniger Informationen ergeben sich daraus, wie Datenfelder im Programm verwendet werden, aus der Analyse von Operationen also, an denen Datenelemente beteiligt sind.

Die Betrachtung von Operationen, die das Datenelement fuellen, liefern mehr Hinweise als Abfrageoperationen. Oft bleibt jedoch der Zweck eines Datenelements ungewiss. Es ist daher ausserordentlich wichtig, eine ausreichende Dokumentation der Datenelemente fuer die Durchfuehrung eines erfolgreichen Reverse Engineering zu besitzen.

Datenelemente nur im Kontext verstaendlich

Ein Datenelement ist nur im Kontext seines jeweiligen Einzugsbereichs verstaendlich:

- Programminterne Felder sind im Kontext des aktuellen Programms (zum Beispiel Fehler-Switch, Zaehler etc.) definiert.

- Fachliche Datenelemente lassen sich nur aus dem Kontext des Applikationsgebiets verstehen (etwa Niederlassungsnummer, Kontosaldo etc.).

- Datenelemente, deren Einzugsbereich ein System ist: Sie dienen zur Steuerung mehrerer Programme, haben aber keine direkte fachliche Bedeutung.

Die Bedeutung eines fachlichen Datenelements laesst sich nur dann mit Sicherheit festlegen, wenn sein ganzer Einzugsbereich betrachtet wird. Ist nur ein Teil davon bekannt, bleibt man auf Vermutungen angewiesen. Die Abgrenzung der Systeme und die Betrachtung der Schnittstellen-Daten bieten Informationen ueber die Systemkonstruktion. Hier ist die Betrachtung von sogenannten Musterdaten (Input-, Output-Daten) nuetzlich.

Aus Benutzersicht lassen sich folgende Thesen aufstellen:

1. Reverse Engineering auf Programmebene ist nicht gleich Reverse Engineering auf Systemebene. Das gilt in bezug auf das gewaehlte Vorgehen, die bevorzugte Methode und die verwendeten Werkzeuge (je nachdem, an welche Benutzergruppe sich die Werkzeuge und Methoden richten).

Datenflussanalyse ist fuer Benutzer wichtig

Auf Systemebene spielen fuer den Analytiker und Endbenutzer oder Fachabteilungsexperten vor allem die generelle Architektur, das Unternehmens-Datenmodell und die Datenflussanalyse eine wichtige Rolle. Auf Anwendungsebene kommt es fuer den Wartungsprogrammierer und Tester vor allem auf gute Kenntnisse der verwendeten Programmiersprache (und ihrer Eigenheiten) sowie auf das Verstehen der Datenelemente an.

2. Reverse Engineering ist gepraegt vom Wechselspiel zwischen Hypothesenbildung und -pruefung. Thesen ueber Zweck und Wirkung von Systemteilen werden aufgestellt und anhand der verfuegbaren Informationen geprueft. Die Frage nach dem Warum eines Code- Abschnitts fuehrt zu Hypothesen ueber den groesseren Zusammenhang.

Bei der Hypothesenpruefung sollte man alle Programmkommentare als falsch ansehen, bis man sich selbst davon ueberzeugt hat, dass sie exakt richtig sind (das heisst, sie sagen nicht mehr und nicht weniger aus, als im Code auch tatsaechlich vorhanden ist).

3. Verstehen und Beschreiben sind zwei verschiedene Dinge. Die Beduerfnisse des Analytikers sind unterschiedlich, wenn er versucht, ein Programm oder System zu verstehen oder zu beschreiben. Ersteres erfordert das Erkennen grosser Zusammenhaenge. Nach der gewuenschten Information kann entweder im Groben (zum Beispiel High-Level-Datenflussdiagramme der Modul-Objekt-Beziehung) oder im Detail (zum Beispiel Low-Level-Datenflussdiagramme der Funktion-Daten-Beziehung) gesucht werden. Das Beschreiben erfordert, einen moeglichst gleichmaessigen Detaillierungs- beziehungsweise Abstraktionsgrad der aus der Applikation rekonstruierten Information zu finden.

4. Die Kenntnis der Systemumgebung spielt eine zentrale Rolle beim Reverse Engineering. Ein Grossteil der Systemteile wird durch die speziellen Anforderungen der Umgebung eines Systems bestimmt und ist nicht durch das System selbst erklaerbar. Zu den relevanten Punkten der Umgebung gehoeren:

- die verwendete Basissoftware (Betriebssystem, TP-Monitor, Datenbanksystem, Netzwerk etc.);

- unternehmensinterne Standards (Handbuecher, Programmrahmen, Programmierrichtlinien, Namenskonventionen etc. sowie uebliche Programmiertricks, Programmierkultur im Unternehmen, Programmierstil etc.);

- Schnittstellen zu anderen Systemen oder Systemteilen;

- Entwicklungsmethoden und

-werkzeuge, Eigenheiten der verwendeten Generatoren, Compiler etc.;

- Anforderungen an Performance, Restriktionen beim Verbrauch von Ressourcen, die bei der Entwicklung einzuhalten waren;

- Datenschutz-, Datensicherheits- und Controlling-Bestimmungen sowie die

- Projektsituation bei der Entwicklung der Software (zeitliche Restriktionen und Sachzwaenge).

5. Es gibt kein allgemeingueltiges Vorgehensmodell fuer Reverse Engineering. Der Grund liegt in dessen Abhaengigkeit vom jeweiligen Ziel des einzelnen Benutzers, von der Systemumgebung, den zur Verfuegung stehenden Werkzeugen und vom notwendigen Zusatzwissen der Experten.

Es ist anzunehmen, dass fuer jedes Unternehmen, eventuell sogar fuer jedes Projekt, eine andere Vorgehensweise zweckmaessig erscheint. Wesentliche Faktoren fuer den Erfolg von Reverse Engineering sind vor allem Erfahrung, Kreativitaet und Faehigkeiten der Analytiker sowie einsatzgepruefte Werkzeuge.

6. Es gibt eine geringe Anzahl von Elementen, deren Kenntnis fuer das Reverse Engineering wesentlich ist. In jedem System und jeder Systemumgebung gibt es gewisse Tricks, Vorschriften und Traditionen, die man unbedingt kennen muss, um das Ganze ueberhaupt zu verstehen.

7. Die Pflege der sogenannten Informatikkultur wird vernachlaessigt. "Kultur" ist nicht nur als das Einhalten von Vorschriften zu verstehen, sie ist in den DV-Abteilungen meist mit den Jahren gewachsen und sollte etwa an den neu eingetretenen Wartungsprogrammierer unbedingt weitergegeben werden. Somit wird das Reverse Engineering von Applikationen, die beispielsweise unterschiedliche Programmierweisen mehrerer Autoren beinhalten, erschwert.

Abschliessend noch ein Wort zum Verstehen von Programmen. Es umfasst die Taetigkeit, fachliche Zusammenhaenge im Code erkennen zu koennen. Grundsaetzlich laesst sich zwischen einer syntaktischen, semantischen und einer konzeptorientierten Analyse von Programmen unterscheiden.

Erstere untersucht das Programm auf der Ebene des abstrakten Syntaxbaums (Code-Modell-Niveau) wie beispielsweise die herkoemmliche Mustererkennung. Die semantische Analyse bezieht sich darueber hinaus auf die Daten- und Kontrollflusssemantik, etwa um Algorithmen, Funktionen etc. in Loop-Schleifen zu erkennen.

Aufgabe der konzeptorientierten Analyse ist schliesslich, das Programm nach bestimmten abstrakten Konzepten zu untersuchen - sie ist beispielsweise dazu geeignet, eine Lagerbestandsberechnung oder ein Sortierkonzept im Code wiederzufinden.

Reverse Engineering unterstuetzt das Program Understanding entweder mit Werkzeugen oder, indem eine aussagekraeftige Nachdokumentation aus dem Programm mit Hilfe von Tools rekonstruiert wird (auf denen dann ein Program Understanding aufsetzen kann). Bis dieses Verfahren so reibungslos funktioniert, wie es uns Tool-Anbieter schon heute glauben machen wollen, vergeht wohl noch einige Zeit.