Reverse Engineering

Reverse Engineering – vom Produkt zur Konstruktionszeichnung, vom Quellcode zur Anforderung

Der Begriff Reverse Engineering hat seinen Ursprung im Maschinenbau bzw. in der Hardwareanalyse, wo zum Zwecke der Konkurrenzanalyse oder zur Verbesserung eigener Produkte das Entschlüsseln von Entwürfen aus fertigen Produkten weit verbreitet ist. Heutzutage wird Reverse Engineering auch in der Softwareentwicklung genutzt, wobei vielfach Lizenzbedingungen ein solches Vorgehen durch Externe untersagen¹.

Eine allgemeine Definition von Reverse Engineering – manchmal auch als RE abgekürzt² – liefern Elliot J. Chikofsky und James H. Cross II in „Reverse Engineering and Design Recovery: A Taxonomy“³:

„Reverse engineering ist the process of analyzing a subject system to identify the system’s components and their interrelationships and create representations oft he system in another form or at a higher level of abstraction“.

Auf Deutsch:

„Reverse Engineering ist der Prozess der Analyse eines Systems mit dem Ziel, die Komponenten des Systems und ihre Beziehungen untereinander zu identifizieren und Repräsentationen des Systems in anderer Form oder auf einer höheren Abstraktionsebene zu erstellen“.

Reverse Engineering und artverwandte Begriffe

Immer wieder gibt es Diskussionen über Reverse Engineering und artverwandte Begriffe. Aus diesem Grund liefern Elliot J. Chikofsky und James H. Cross II nicht nur eine Definition des Begriffs Reverse Engineering, sondern erläutern auch die Begriffe Redokumentation, Design Recovery, Forward Engineering, Restrukturierung und Reengineering. Das Ziel ist nicht die Schaffung neuer Begriffe, sondern die Rationalisierung bereits verwendeter Begriffe.

• Reverse Engineering ist der Prozess, bei dem man ein ausreichendes Verständnis für ein Produkt auf Designebene erlangt, um dessen Wartung, Verbesserung oder Ersatz zu unterstützen. In der Softwareentwicklung handelt es sich um einen Teil des Prozesses zur Softwarewartung, der dabei hilft, das System ausreichend zu verstehen, um Entscheidungen darüber zu treffen. Bei diesem Prozess wird das System in keiner Weise verändert.
• Redokumentation ist ein Teilbereich des Reverse Engineering, bei dem es darum geht, verlorene oder nicht vorhandene Dokumentation über das System wiederherzustellen.
• Design Recovery ist ein zweiter Teilbereich des Reverse Engineering, bei dem das Ziel darin besteht, alle Informationen zu reproduzieren, die eine Person benötigt, um vollständig zu verstehen, was ein Programm tut, wie es und warum es dies tut.
• Forward Engineering bezeichnet den Prozess, der von den Anforderungen über den Entwurf bis zur Implementierung eines Produkts führt. Während also das bestehende System der Ausgangspunkt für ein Reverse Engineering ist, ist es der Endpunkt beim Forward Engineering.
• Restrukturierung – oder Refactoring, wie es inzwischen meist genannt wird, ist der Prozess der Änderung der zugrundeliegenden Struktur eines Systems, ohne sein äußeres Verhalten zu beeinflussen.
• Reengineering bezeichnet die Neugestaltung und Implementierung eines Systems in einer neuen Form. Unterschieden werden zwei Formen: beim „reinen“ Reengineering soll das System lediglich rekonstruiert werden, ohne das Funktionalität hinzukommt, beim „erweiternden“ Reengineering wird das System rekonstruiert, um vorhandene Funktionalität zu verändern oder neue hinzuzufügen.

Darüber hinaus wird auch ab und an von einer Architekturrekonstruktion gesprochen. Eine Architekturrekonstruktion ist ein Reverse Engineering mit dem Ziel, eine Beschreibung der Architektur eines Systems zu erstellen.

Ziele beim Reverse Engineering

Es gibt eine Reihe von Zielen, die beim Reverse Engineering adressiert (und entsprechend von Elliot J. Chikofsky und James H. Cross II genannt) werden:

• Die Bewältigung von Komplexität,
• die Generierung alternativer Ansichten,
• die Wiedererlangung verlorener Informationen,
• das Erkennen von Nebeneffekten,
• die Synthese von höheren Abstraktionen und
• die Erleichterung der Wiederverwendung.

Interessanterweise decken sich viele dieser Ziele mit den Ansätzen einer Clean Code Softwareentwicklung. Clean Code fordert die klare, verständliche, nachvollziehbare, logische und disziplinierte Implementierung von Code. Ziel ist es, Software effizient und effektiv zu produzieren, und dabei den Code so zu gestalten, dass er leicht lesbar, änderbar, erweiterbar und wartbar ist. In anderen Worten: Reverse Engineering und Clean Code ergänzen sich großartig.

Reverse Engineering in der Softwareentwicklung

Heutzutage stehen viele Organisationen nicht nur vor dem Problem, ihre Informationssysteme durch neue zu ersetzen, gleichzeitig müssen sie auch die Kontrolle über ihre Altanwendungen bzw. ihren Legacy Code behalten. Reverse Engineering bietet zu diesem Zweck die Möglichkeit,

• verlorene Informationen wiederzuerlangen,
• vorhandene Softwarearchitekturen mit ihren Komponenten und entsprechenden Zusammenhängen und Funtkionsweisen zu verstehen,
• komplexe Systeme umzustrukturieren,
• alte Systeme in eine neue und besser wartbare Architektur zu überführen oder
• Software zu portieren.

Und damit wird Reverse Engineering gemeinsam mit Forward Engineering zum Reengineering.

Wenn Ihnen der Beitrag gefällt, teilen Sie ihn gerne in Ihrem Netzwerk. Und falls Sie sich für Tipps aus der Praxis interessieren, dann testen Sie unseren beliebten Newsletter mit neuen Beiträgen, Downloads, Empfehlungen und aktuellem Wissen. Vielleicht wird er auch Ihr Lieblings-Newsletter.

[1] „Es ist Ihnen nicht gestattet, den Source Code oder die Datenstrukturen der Software manuell oder maschinell zurück zu entwickeln.“ – so oder so ähnlich lauten Formulierungen in Lizenzbedingungen von Softwareherstellern, die ein Reverse Engineering explizit untersagen. Ob solche Regelungen aber in allen Ländern und unter allen Umständen gelten, sollte man bei Bedarf im Einzelfall prüfen.

In der Europäischen Union untersagt die Directive 2009/24/EC of the European Parliament and of the Council of 23 April 2009 on the legal protection of computer programs  explizit das Dekompilieren von Software, sofern er nicht zur Anpassung von Schnittstellen erfolgt.

[2] Die Abkürzung RE hat zahlreiche unterschiedliche Bedeutungen. Hier finden Sie eine Übersicht.

[3] Reverse Engineering and Design Recovery: A Taxonomy