Wer kennt es nicht, das Gefühl vor einem Stück Software zu sitzen, daran etwas anpassen zu müssen und dabei so gut wie nichts über die Software und deren Entstehung zu wissen. Gerade im Themengebiet Modernization und Application LifeCycle Management sind solche Erlebnisse oft unumgänglich und werden uns wohl vermehrt begegnen.
Beim Wühlen im verstaubten, Jahre alten Code liegt die Assoziation zur Archäologie natürlich auf der Hand. Damit sind leider nicht die spannenden Abenteuer von Indiana Jones oder Lara Croft gemeint.
Im Gegensatz zur realen Archäologie, in welcher bei Ausgrabungsarbeiten bewährte Tools wie Schäufelchen, Spatel und Pinsel eingesetzt werden, herrscht zum Thema Softwarearchäologie zuweilen grosse Begriffsverwirrung.
Im vorliegenden Beitrag wird versucht diese etwas zu entwirren.
Der Begriff Software-Archäologie wird in unterschiedlicher Ausprägung seit 2001 mehr oder weniger intensiv verwendet. Grady Booch, ein Pionier auf dem Gebiet des modularen und objektorientierten Softwareentwurfs, hat den Begriff Softwarearchäologie folgendermassen definiert:
„Software Archeologie: The recovery of essential details about an existing system sufficient to reason about, fix, adapt, modify, harvest, and use that system itself or its parts”
Insbesondere der Begriff des "Erntens" springt dabei ins Auge. Gemeint ist damit die Identifikation von Design und Development Patterns welche „geerntet“ und in verschiedener Ausprägung wiederverwendet werden können.
Doch nun zu konkurrierenden Begriffen, welche gerne im Zusammenhang mit der Software-Archäologie auftreten:
• Refactoring
• Reverse Engineering
• Reengineering
Refactoring bezeichnet (gemäss Wikipedia) in der Software-Entwicklung die manuelle oder automatisierte Strukturverbesserung von Programm-Quelltexten unter Beibehaltung des beobachtbaren Programm-Verhaltens. Dabei sollen die Lesbarkeit, Verständlichkeit, Wartbarkeit und Erweiterbarkeit verbessert werden, mit dem Ziel, den jeweiligen Aufwand für Fehleranalyse und funktionale Erweiterungen deutlich zu senken.
Reverse Engineering bezeichnet (gemäss Wikipedia) den Vorgang, aus einem bestehenden, fertigen System durch Untersuchung der Strukturen, Zustände und Verhaltensweisen, die Konstruktionselemente zu extrahieren und zu beschreiben. Das beinhaltet in der Regel folgende 3 Bereiche:
• Die Rückgewinnung des Quellcodes oder einer vergleichbaren Beschreibung aus dem Binärcode. Zum Beispiel von einem ausführbaren Programm oder einer Programmbibliothek, etwa mit einem Disassembler (kann Teil eines Debuggers sein) oder einem Decompiler.
• Die Erschließung der Regeln eines Kommunikationsprotokolls aus der Beobachtung der Kommunikation.
• Die nachträgliche Erstellung eines Modells, ausgehend von bereits vorliegendem Quellcode.
Reverse Engineering impliziert dabei nicht, dass keine Dokumentation vorhanden ist sondern lediglich das diese nicht ausreichend ist.
Reengineering bezeichnet gemäss (] Chikofsky E.J. and Cross, J.H., "Reverse Engineering and Design Recover; A Taxonomy") die Untersuchung und Änderung eines bestehenden Systems, um es zu rekonstruieren sowie neu zu implementieren. Reengineering setzt dabei in den vielen Fällen Reverse Engineering voraus.
Software-Archäologie ist eng mit Reverese- und Reengineering verbunden und es werden in der Regel dieselben Tools und Methoden eingesetzt. Der grösste Unterschied besteht jedoch darin, welche Zielsetzungen damit verfolgt werden.
Reverse Engineering folgt im Allgemeinen einem unmittelbaren Bedarf oder Problem, während die Software-Archäologie längerfristig angesetzt ist. Software-Archäologie verfolgt eher das Ziel etwas über das System bzw. deren Entwicklungsgeschichte zu erfahren und daraus zu lernen als aktuell konkrete Probleme zu lösen. Ein Ergebnis von Software-Archäologie kann durchaus auch sein, Erkenntnis darüber zu gewinnen wieso in der Vergangenheit gewisse Entscheidungen und Muster gewählt wurden und welchen Einfluss dies auf die zukünftige Entwicklung haben kann und sollte.
Das ist ganz analog zur realen Archäologie, die hat auch nicht zum Ziel aktuelle Probleme zu lösen sondern Verständnis darüber zu erlangen, wie die Mechanismen und Rahmenbedingungen früher waren und was daraus entstanden ist.