Der Begriff Reverse Engineering ordnet sich in das Themengebiet des Software-Reengineering ein. Er bezieht sich auf die Identifizierung und Dokumentation der einzelnen Bestandteile/Komponenten eines Softwareartefakts eines Anwendungssystems und ihrer Beziehungen. Dazu wird eine methodische Analyse implementierungsnäherer Artefakte des Systems, häufig ausgehend vom Quellcode, durchgeführt.
Der Ansatz des Reverse Engineering
Im Rahmen der Systementwicklung bzw. des Software Engineering werden sukzessiv aus Softwareartefakten auf einer realitätsnäheren, fachlichen Ebene implementierungsnähere Artefakte abgeleitet. Wichtige Artefakte sind z.B. die Anforderungsdefinition, die Modulstruktur bzw. ‑hierarchie und das konzeptionelle Datenschema bzw. das Klassenmodell auf der Entwurfsebene sowie der Quellcode.
Im Rahmen der Software-Wartung wird der Code eines Anwendungssystems häufig geändert, ohne dass alle betroffenen Artefakte des Systems entsprechend aktualisiert werden. Gründe hierfür liegen insbes. darin, dass die Wartungskosten auch ohne diese Aktualisierung bereits hoch sind und außerdem die Durchführung der Wartungsaufträge vielfach einem starken zeitlichen Druck unterliegt.
Die fehlende Aktualisierung der Softwareartefakte führt über die Jahre dazu, dass die Artefakte immer weniger mit der Implementierung übereinstimmen. Bevor größere Änderungen an einem System im Rahmen eines Software-Reengineering-Projekts durchgeführt werden können, müssen deshalb vielfach die Artefakte sukzessiv ausgehend vom Quellcode auf einen aktuellen Stand gebracht werden. Gleiches gilt gerade bei komplexen Systemen, wenn die Systeme durch eine Neuentwicklung oder ein Standardsoftwaresystem ersetzt werden sollen und dazu die Anforderungen identifiziert werden müssen, die das jeweilige Altsystem erfüllt.
Da die Aktualisierung der Artefakte in entgegengesetzter Richtung zum Software Engineering-Prozess erfolgen muss, wurde der Begriff „Reverse Engineering“ geprägt. Damit sollte insbesondere ausgedrückt werden, dass die Aktualisierung der Artefakte – wie die Softwareentwicklung – ingenieurmäßig unter Einsatz entsprechender Vorgehensweisen, Methoden und Werkzeuge erfolgen muss. Inzwischen existiert eine Fülle von methodischen Ansätzen, die zum Teil auch von Werkzeugen unterstützt werden. Entwickelt wurden vor allem sogenannte Cross-Reference-Tools, die den Quellcode analysieren und bestimmte Zusammenhänge und Abhängigkeiten (z.B. die Aufrufe von Funktionen/Prozeduren oder Zugriffe auf Daten) ermitteln sowie diese zum Teil auch visuell darstellen.
Abhängig von der Zielsetzung eines Reverse Engineering und den Rahmenbedingungen in der betreffenden Organisation werden die ermittelten Informationen teilweise auch in einem Repository-System gespeichert.
Ziele und Einsatzgründe des Reverse Engineering
Ziele des Reverse Engineering sind u.a.:
-
die Gewinnung aktueller bzw. nicht mehr verfügbarer Informationen,
-
die Beherrschung der Komplexität von Anwendungssystemen,
-
die Ableitung zusätzlicher Softwareartefakte (z.B. entsprechend neuer Unternehmensrichtlinien),
-
die Identifizierung von Seiteneffekten und von potenziellen Schnittstellen,
-
die Vorbereitung der Wiederverwendung (von Softwarekomponenten und/oder Wissen).
Eingesetzt werden kann das Reverse Engineering zum einen, um Softwareartefakte eines Anwendungssystems zu aktualisieren. Den Ausgangspunkt bildet zumeist die Implementierung; bis auf welche Ebene die Aktualisierung erfolgt, wird unterschiedlich gehandhabt. Zum anderen kann gezielt wiederverwendbares Wissen (z.B. bezüglich zu erfüllender Anforderungen) identifiziert und extrahiert werden, das für „andere“ Zwecke wie z.B. eine Neuentwicklung benötigt wird.
Im Zusammenhang insbesondere mit dem erstgenannten Einsatzgrund wird häufig der Begriff Redokumentation verwendet; er bezieht sich auf die Erzeugung bzw. Revision entweder einer semantisch äquivalenten Beschreibung eines Softwareartefakts als externe Dokumentation oder einer internen Kommentierung des Artefakts. Eine externe Dokumentation ist z.B. das Benutzerhandbuch oder das Programmier- bzw. Systemhandbuch. Die wichtigste interne Dokumentation bilden die Kommentarzeilen im Quelltext. Die Erzeugung bzw. Revision einer internen oder externen Dokumentation ist i.d.R. nicht ohne ein Reverse Engineering möglich, da ein umfassendes Verständnis des betreffenden Softwareartefakts sowie der eventuell aus dem Artefakt abgeleiteten implementierungsnäheren Artefakte erforderlich ist, die sich auf einem aktuelleren bzw. dem aktuellen Stand befinden.
Wenn im Rahmen eines Reverse Engineering das vollständige Design wiedergewonnen werden soll, spricht man auch von Design Recovery. Es erfordert in der Regel den Rückgriff auf Domänen- und Anwenderwissen.
Literatur
Aiken, Peter: Data Reverse Engineering: Slaying the Legacy Dragon. New York : McGraw-Hill, 1995.
Eilam, Eldad: Reversing: Secrets of Reverse Engineering. Indianapolis : Wiley Publishing, 2005.
Raja, Vinesh ; Fernandes, Kiran J.: Reverse Engineering – An Industrial Perspective. Berlin : Springer, 2010.
Tonella, Paolo ; Potrich, Alessandra: Reverse Engineering of Object Oriented Code. Berlin : Springer, 2005.
