Oli's Blog

Do you know that? You have to maintain some old programs and you are wondering what the hell is that piece of code doing. Why does it work? And where is the architecture of that damn software system you should adapt for the future?

Welcome to the world of software archaeology, also known as legacy code. The first law of software archaeology from Mitch Rosenberg (see Wikipedia) gives you good feeling about the trouble in digging in old rotten code:

Everything that is there is there for a reason, and there are 3 possible reasons:

1. It used to need to be there but no longer does
2. It never needed to be there and the person that wrote the code had no clue
3. It still needs to be there and YOU have no clue

The corollary to this "law" is that, until you know which was the reason, you should not modify the code (or data).

And if you would like to learn some ancient language of the beginning of the computer stone age watch this video:

Edward Snowdon:

"Zu sagen, man kümmere sich nicht um Datenschutz, weil man nichts zu verbergen habe, ist genauso, wie zu sagen, man kümmere sich nicht um das Recht auf freie Meinungsäußerung, weil man nichts zu sagen hat."

Nach Version 1.0 im letzten Jahr wurde dieses Wochenende die Version 1.1 ausgeliefert. Die Änderungen sind eher interner Natur (kleinere Refactorings bzw. Umbauten) und Rückmeldungen aus einigen Tests. So fehlten in der XML-Beschreibung einige Felder, die mit 1.1.0 über die Resouce "fehlendeFelder.xml" mitgeliefert werden (s.a. TeildatensatzXml).

PatternTesting 1.6 no longer supports Java 5 - you now need at least Java 6 if you want to use PatternTesting. On the other side the classloader of Tomcat 8 is now directy supported by the ClasspathMonitor.

Some deprecated classes and methods were removed now. And some tester were extended: the FileTester prints now the filename for files which differs (see feature request 47) and allows you to add a StringConverter as argument. This allows you e.g. to ignore white spaces or upper case letters.

The ClassTester checks now also static initializers to find dependency problems to other classes during the startup phase of a class.

“Es gibt bereits alle guten Vorsätze, wir brauchen sie nur noch anzuwenden.”
(Blaise Pascal)

Die Adventszeit ist eine Zeit, in der man Zeit hat, darüber nachzudenken, wofür es sich lohnt, sich Zeit zu nehmen.

(Gudrun Kropp)

Bereits 2012 hatten wir bei der Java User Group Stuttgart uns einen Rückblick auf 20 Jahre Java gegönnt - reichen doch die Ursprünge von Java bis 1992 zurück. Inzwischen ist Java Mainstream geworden und entwickelt sich immer mehr zum COBOL der Neuzeit.

Von Entwicklung kann derzeit eigentlich kaum noch die Rede sein - man orakelt, dass hinter den Kulissen viele aktive Entwickler abgezogen wurden und viele Bereiche in der JDK- und JEE-Entwicklung jetzt brach liegen. Die spannenden Themen wie Mobile und IoT finden zunehmend woanders statt.

Aber auch wenn es in der Java-Szene kräftig rumort und einstige Zugpferde wie James Gosling oder Erich Gamma fehlen, so ist es an den meisten Universitäten die erste Wahl für objekt-orientierte Programmiersprachen. Und dies lässt hoffen für die Zukunft, dass sich Java trotz der derzeitigen Durststrecke weiterentwickeln und weiterhin für eine offen Welt stehen wird.

Es ist soweit - die Artikel-Serie über Software Archäologie, die auch Thema auf dem Java Forum Stuttgart 2015 war, ist jetzt im aktuellen Heft von Java aktuell zu lesen.

Wer meint, dass Altlasten (neudeutsch: Legacy) langweilig und nur etwas für zurückgebliebenen Entwickler ist, der irrt: zum einen ist Code spätestens nach 3 Monaten bereits Legacy Code (oftmals schon früher), zum anderen kann alter Code eine jede Menge erzählen: verschiedenen Firmen-Fusionen und Umbenennungen können an der Package-Struktur abgelesen werden, die Outsourcing- oder indische Area hat tiefe Spuren im Code hinterlassen, oder man entdeckt immer wieder neue Anti-Pattern, die man vorher nicht kannte. Guter Code ist langweiliger Code! Dies gilt auch für Legacy-Systeme. Ich kann Ihnen versichern, dass jede Menge interessanten Code in Altsystemen steckt ;-)

Die Zukunft war früher auch besser.
(Karl Valentin)

3. Unterstützung durch AOP

4. Ausblick

Don't patch bad code - rewrite it.
The Elements of Programming Style

Der Aufwand, sich in unbekanntem Code einzuarbeiten, wird häufig unterschätzt. Langfristig ist es meist wirtschaftlicher, vorhandenen Code komplett neu zu entwickeln, wenn die Dokumentation veraltet ist, der Code an vielen Stellen ausgewuchert ist und auch die Testfälle nicht vorhanden oder von zweifelhafter Qualität sind.

Oftmals hat man aber keine andere Wahl, als auf den bestehenden Code aufzusetzen, weil er die einzig gültige Quelle der Dokumentation darstellt. Und hier bietet die Aspektorientierung eine Vielzahl von Möglichkeiten, um

• zusätzliche Log-Möglichkeiten einzubauen,
• Sequenz-Diagramme zu generieren,
• Schnittstellen zu überwachen,
• Objekt-Recorder zu implementieren und
implantieren,
• die aufgenommenen Objekte wieder einzuspielen,
• u.v.m.

Daraus lassen sich weitere Testfälle schreiben und neue Erkenntnisse gewinnen, um Refactoring-Maßnahmen einzuleiten oder sich für eine Neuentwicklung zu entschließen. Allerdings entbindet auch AOP nicht von der Aufgabe, bestehenden und neuen Code so zu gestalten und umzuformen, dass künftige Generationen damit glücklich werden.

2. Abstecher in die Welt von AOP

3. Unterstützung durch AOP

Nach diesem Ausflug in die wunderbare Welt der Aspekte, die uns einen kleinen Einblick in die Denkweise ermöglichte, wenden wir uns wieder unserem Fundstück aus der Steinzeit des Java-Zeitalters zu. Der größte Manko bei Altanwendungen (und nicht nur dort) sind die Testfälle. Meistens fehlen sie oder sind genauso veraltet wie die Dokumentation. Ist die Anwendung noch in Betrieb, kann man versuchen, daraus Testfälle für die weitere Entwicklung abzuleiten. Und genau hier kann AOP helfen, fehlende Log-Informationen zu ergänzen oder die Kommunikation mit der Umgebung aufzuzeichnen.

3.1. Schnittstellen beobachten

Die interessanten Stellen sind vor allem die Schnittstellen zur Außenwelt. Bei J2EE-Applikationen sind dies meist andere Systeme wie Legacy-Anwendungen oder Datenbanken, die über das Netzwerk angebunden werden. Hier reicht es oft aus, die Anwendung ohne Netzwerkverbindung zu starten und zu beobachten, wo überall Exceptions auftreten:

java.net.SocketException: java.net.ConnectException: Connection refused
    at com.mysql.jdbc.StandardSocketFactory.connect(StandardSocketFactory.java:156)
    at com.mysql.jdbc.MysqlIO.(MysqlIO.java:283)
    at com.mysql.jdbc.Connection.createNewIO(Connection.java:2541)
    at com.mysql.jdbc.Connection.(Connection.java:1474)
    at com.mysql.jdbc.NonRegisteringDriver.connect(NonRegisteringDriver.java:264)
    at java.sql.DriverManager.getConnection(DriverManager.java:525)
    at java.sql.DriverManager.getConnection(DriverManager.java:193)
    at bank.Archiv.init(Archiv.java:25)
    …

Aus dieser Exception kann man erkennen, dass die Anwendung auf eine MySQL-Datenbank zugreift, aber kein Connection-Objekt vom DriverManager bekam. Mit diesem Wissen kann man sich alle Connection-Aufrufe genauer unter die Lupe nehmen:

after() returning(Object ret) : 
         call(* java.sql.Connection.*(..)) {
    log.debug(getAsString(thisJoinPoint) + " = " + ret);
}

Mit dieser Anweisung wird am Ende jedes Connection-Aufrufs der Aufruf selbst mitsamt seinen Parametern (z.B. SELECT-Statements) und Rückgabewert ausgegeben (über die getAsString()-Methode, hier nicht abgebildet). Ähnlich kann man bei Netz- bzw. Socket-Verbindungen verfahren: man erweitert die Stellen (im AOP-Jargon „Joinpoints“ genannt), über die Daten ausgetauscht werden.

Handelt es sich um eine interne Bibliothek oder Framework, das es zu betrachten gilt, sind vor allem die öffentlichen Schnittstellen von Interesse. Hier kann man mit Aspektorientierten Sprachmitteln all die Methodenaufrufe ermitteln, die tatsächlich von außerhalb aufgerufen werden – denn oft sind nicht alle Methoden, die als „public'“ deklariert sind, für den Aufruf von außen vorgesehen.

public pointcut executePublic() :
    (execution(public * bank..*.*(..))
        || execution(public bank..*.new(..)))
    && !within(EnvironmentAspect);

public pointcut executeFramework() :
    execution(* bank..*.*(..)) || execution(bank..*.new(..));

public pointcut calledFromOutside() :
    executePublic() && !cflowbelow(executeFramework());

before() : calledFromOutside() {
    Signature sig = thisJoinPoint.getSignature();
    String caller = 
        getCaller(Thread.currentThread().getStackTrace(), sig);
    log.info(caller + " calls " + sig);
}

Hier werden alle Methoden eines Bank-Frameworks (bank-Package) überwacht. Nur wenn der Aufruf nicht von innerhalb kam (!cflowbelow), wird vor der Ausführung der Methode oder Konstruktor der Aufrufer anhand des Stacktraces ermittelt (Methode getCaller(), hier nicht aufgelistet).

...
jsp.index_jsp._jspService(index_jsp.java:54) calls bank.Konto(int)
jsp.index_jsp._jspService(index_jsp.java:58) calls void bank.Konto.einzahlen(double)
jsp.index_jsp._jspService(index_jsp.java:60) calls double bank.Konto.abfragen()
...

Dies ist die Ausgabe, die den Aufruf aus einer JSP zeigt. Lässt man die Anwendung lang genug laufen, erhält man so alle Methoden, die von außerhalb aufgerufen werden.

3.1.1 Daten aufnehmen

Mit Java ist es relativ einfach möglich, Objekte abzuspeichern und wieder einzulesen. Damit lässt sich ein einfacher Objekt-Recorder bauen, um damit die Schnittstellen-Daten aufzunehmen:

after() returning(Object ret) : sqlCall() {
    objLogger.log(thisJoinPoint);
    objLogger.log(ret);
}

Hinter thisJoinPoint verbirgt sich der Kontext der Aufrufstelle, die der AspectJ-Compiler (eine AO-Sprache, die auf Java aufbaut, s.a. [1]) als Objekt bereitstellt.

3.1.2 Aufnahmedaten einspielen

Wenn man die notwendigen Schnittstellen-Daten gesammelt hat, kann man anhand dieser Daten einen (einfachen) Simulator bauen. Man kennt die Punkte, über die diese Daten hereingekommen sind, man muss jetzt lediglich an diesen Punkte die aufgezeichneten Daten wieder einspielen:

Object around() : sqlCall() {
    Object logged = logAnalyzer.getReturnValue(thisJoinPoint);
    return logged;
}

Hat man so die Anwendung von der Aussenwelt isoliert und durch Daten aus früheren Läufen simuliert, kann man das dynamische Verhalten der Anwendung genauer untersuchen. So kann man weitere Aspekte hinzufügen, die automatisch Sequenz-Diagramme erzeugen oder wichtige Programmzweige visualisieren (z.B. mit Hilfe der UMLGraph-Bibliothek). Damit erhält man neben der statischen Sicht durch Klassen-Diagrammen (die sich notfalls mittels Reverse-Engineering wiedergewinnen lassen) auch eine Visualisierung des dynamischen Verhaltens.

3.2. Code-Änderungen

Nach diesen Vorbereitungen kann mit den ersten Code-Änderungen (Refactorings) begonnen werden. Soll der Original-Code (noch) unverändert bleiben (was bei unbekannter Abdeckungen von vorhandenen Testfällen sinnvoll sein kann), liefert die Aspektorientierung die Möglichkeit, den Code getrennt vom Original abzulegen. Man kann sogar verschiedene Varianten einer Komponente vorhalten und diese während der Laufzeit austauschen. Auf diese Weise kann man experimentell verschiedene Varianten und Code-Manipulationen ausprobieren, um deren Verhalten auf die Gesamt-Anwendung studieren zu können.

4. Ausblick

1. Die klassische Herangehensweise

2. Abstecher in die Welt von AOP

Um in die Begriffs- und Gedankenwelt von AOP (Aspekt-Orientierte Programmierung) einzutauchen, betrachten wir ein Beispiel aus dem Bank-Bereich:

public class Konto {

    private double kontostand = 0.0;

    public double abfragen() {
        return kontostand;
    }
    
    public void einzahlen(double betrag) {
        kontostand = kontostand + betrag;
    }

    public void abheben(double betrag) {
        kontostand = kontostand - betrag;
    }

    public void ueberweisen(double betrag, Konto anderesKonto) {
        abheben(betrag);
        anderesKonto.einzahlen(betrag);
    }

}

Listing 1: Einfache Konto-Klasse

Dies ist ein sehr einfaches Modell einer Konto-Klasse, bei dem die Businesslogik (Einzahlung, Auszahlung, Überweisung) noch sehr gut erkennbar ist. Eine Warnung vorneweg: für Real-World-Implementierung bitte nie double als Datentyp verwenden, sonst kann es böse Überraschungen wegen Rundungsfehlern kommen (s. Ich bin reich!)

2.1. Code-Verschmutzung

„Alle Kontobewegungen müssen protokolliert werden.“

Diese gesetzliche Anforderung sollen jetzt umgesetzt werden. Dazu wird die Konto-Klasse wie folgt erweitert:

public class Konto {

    private static Logger log = Logger.getLogger(Konto.class);
    private double kontostand = 0.0;

    public double abfragen() {
        return kontostand;
    }
    
    public void einzahlen(double betrag) {
        kontostand = kontostand + betrag;
        log.info("neuer Kontostand: " + kontostand);
    }

    public void abheben(double betrag) {
        kontostand = kontostand - betrag;
    }

    public void ueberweisen(double betrag, Konto anderesKonto) {
        abheben(betrag);
        anderesKonto.einzahlen(betrag);
        log.info("neuer Kontostand: " + kontostand);
    }

}

Listing 2: Konto-Klasse mit Logging

So langsam tritt damit die eigentliche Businesslogik immer mehr in den Hintergrund. Und es warten noch jede Menge weitere Anforderungen (oft auch als „Concerns“ bezeichnet), die technischer Natur sind und mit der eigentlichen Fachlichkeit nichts zu tun haben: Authorisierung, Sicherheit, GUI, Transaktionen, …).

Separations of Concerns?

Während des Information-Studiums bekommt man mit Dijkstras „Separations of Concerns“ die Empfehlung mit auf den Weg, jeden „Concern“ in einer eigenem Modul oder Klasse zu kapseln, aber bereits dieses einfache Logging-Beispiel zeigt, dass das mit den Mitteln der Objekt-Orientierung gar nicht so einfach ist.

2.2. Separation of Concerns

Ein Ausweg aus diesem Dilemma bietet die Aspekt-Orientierung. Sie bietet Konzepte an, um solche meist technischen Anforderungen (im AOP-Jargon als „Crosscutting-Conerns“ bezeichnet), in eigene „Aspekte“ kapseln zu können:

Separations of Concerns!

AspectJ als Aspekt-orientierte Erweiterung von Java bietet dazu Sprachmittel, um

Ein Vertreter aspekt-orientierter Sprachen ist AspectJ, die Java um einige Sprachmittel erweitert und damit das Herauslösen der Logging-Funktionalität aus der Konto-Klasse ermöglicht:

public aspect LogAspect {
	
    private static Logger log = Logger.getLogger(LogAspect.class);

    pointcut setKontostand() :
        set(double bank.Konto.kontostand);

    after(double neu) : setKontostand() && args(neu) {
        log.info("neuer Kontostand: " + neu);
    }
   
}

Listing 3: LogAspect

Um den Code besser zu verstehen, muss man erst einige Begrifflichkeiten verinnerlichen, die im nächsten Abschnitt vorgestellt werden. Übersetzt bedeutet dieser Code: Wenn sich der Kontostand ändert, gib eine Log-Meldung aus.

2.3. Do You Speak AOP?

Genauso wie SQL mit eigenen Begriffen wie Relationen und Normalform daherkommt, grenzt sich die Aspekt-Orientierung mit Ihrer eigenen Begriffswelt von anderen Techniken ab. Die wichtigsten davon sind:

• Aspekt
• Joinpoints
• Pointcuts
• Advice

Der Aspekt ist für AOP das, was für OOP die Klasse bedeutet: es ist der Container für die neuen Sprachmittel:

public aspect LogAspect {

    // ...
   
}

Listing 4: Leerer LogAspect

2.3.1 Joinpoints und Pointcuts

Als Joinpoints werden im AOP-Jargon all die Punkte im Programm bezeichnet, auf die Einfluss genommen werden kann. Im Falle von AspectJ (und den meisten anderen AOP-Sprachen) sind dies:

Aufruf (call) oder Ausführung (execution) einer Methode oder eines Konstruktors
Initialisierung einer Klasse oder eines Objekts (initialization, preinitialization, staticinitialization)
Zugriff auf eine Instanz-Variable (set, get)
Exception-Handling (handler)

Über Pointcuts lassen sich diese Joinpoints dann adressieren:

    pointcut setKontostand() :
        set(double bank.Konto.kontostand);
    pointcut callBankMethods() : 
        call(* bank.*Konto.*(..));

Listing 5: Definition zweier Pointcuts

Den ersten Pointcut (setKontostand) kennen wir schon aus dem obigen Beispiel des LogAspects (Listing 3:) - er addressiert den schreibenden Zugriff auf das kontostand-Attribut. Interessanter ist der zweite Pointcut (callBankMethods): er adressiert alle Methoden der verschiedenen Konto-Klassen (genauer: die mit „...Konto“ im Namen aufhören und im bank-Paket liegen) und beliebige viele Argumente haben. Möglich wird dies durch die Unterstützung verschiedener Wildcards, die der Schlüssel für das Herausziehen der Crosscutting Concerns sind.

Das Ganze lässt sich auch mit boolschen Operatoren verknüpfen und mit weiteren Bedingungen kombinieren, sodass sich damit (fast) alle erdenklichen Szenarien realisieren lässt. Seit AspectJ 5 können auch noch Annotations zur Selektion herangezogen werden, was nicht nur für die Lesbarkeit und Wartbarkeit große Vorteile bietet.

2.3.2 Advices

Advices sind die Methoden der Aspekt-Orientierung: mit Ihnen kann ich die Punkte im Programm, die ich über die Pointcuts adressiert haben, um zusätzliche Funktionalität anreichern (oder einfacher: manipulieren). Dabei habe ich die Wahl, ob der Advice

vor (Before-Advice),
nach (After-Advice) oder
anstatt (Around-Advice)

des Pointcuts ausgeführt wird.

    after(double neu) : setKontostand() && args(neu) {
        log.info("neuer Kontostand: " + neu);
    }

Listing 6: After-Advice

Hier wird nach dem Pointcut „setKontostand“ die entsprechende Log-Meldung ausgegeben. Die Verknüpfung mit dem args-Schlüsselwort von AspectJ dient in diesem Beispiel nur dazu, um auf das Argument (sprich: dem Attribut) des Pointcuts zugreifen zu können. Alternativ erlaubt AspectJ auch den Zugriff auf den Kontext des Joinpoints.

2.3.3 Der Webe-Vorgang

Wie kommen die Aspekte in das fertige Programm? Dazu gibt es Techniken wie:

• Compile-Time Weaving (CTW)
• Load-Time Weaving (LTW)

Bei Compile-Time Weaving (CTW) werden die Aspekte nach Java übersetzt und mit Hilfe des bestehenden Java-Compilers in den bestehenden Java-Code „eingewebt“. Dabei muss der Java-Code nicht unbedingt als Source-Code vorliegen, sondern der AspectJ-Compiler schluckt auch Byte-Code bzw. Jar-Dateien als Input.

Beim Load-Time Weaving (LTW) werden die Aspekte während des Ladens der Java-Klassen „eingewebt“. Dies Technik wird z.B. vom Spring-AOP-Framework verwendet, das intern auf AspectJ aufsetzt. Vorteil hierbei ist, dass man mit den Aspekten eine größere Reichweite hat (prinzipiell jede Klasse, die geladen wird). Als Nachteil erkauft man sich hier Syntax-Fehler, die erst zur Laufzeit bemerkt werden.

AspectJ beherrscht beides und das AJDT-Plugin für Eclipse3 unterstützt neben der inkrementellen Kompilierung die Visualisierung von Pointcuts und das Debuggen von Advices.

3. Unterstützung durch AOP

Motivation

1. Die klassische Herangehensweise

Meist ist die Dokumentation oft die erste Anlaufstelle, um sich mit einer Alt-Anwendung vertraut zu machen. Auch wenn sie oftmals von der Realität abweicht, gibt sie doch einen wertvollen Einblick und wichtige Informationen, die den Einstieg in die Thematik erleichtern.

1.1. Der Ideal-Fall

Im Ideal-Fall ist eine aktuelle Dokumentation vorhanden, die diesen Namen auch verdient und verschiedene Sichten auf die Anwendung erlaubt. Vor allem Übersichts-Dokumente über die Architektur, Infrastruktur und Randbedingen sind hier für die Einarbeitung, aber auch als Nachschlagewerk sehr hilfreich.

Um festzustellen, inwieweit der Code tatsächlich mit der Dokumentation übereinstimmt, sind Testfälle (sofern vorhanden) von eminenter Bedeutung. Sie bilden den Ausgangspunkt, um verschiedene Programmteile zu erkunden und deren Verhalten zu studieren. Die meisten Schwierigkeiten bestehen meist darin, die Testfälle zum Laufen zu bringen.

Hat man die Tests am Laufen, kann man sich an Refactoring-Maßnahmen wagen mit dem Ziel, die Businesslogik stärker zum Vorschein zu bringen und die Lesbarkeit und Wartbarkeit zu erhöhen. Vor allem JEE-Anwendungen sind oftmals over-designed, was eine Einarbeitung meist erschwert.

Mit den neuen Erkenntnisse sollte nochmals die Dokumentation begutachtet werden: welche Dokumente müssen überarbeitet, welche Dokumente können aussortiert oder/und in Form von neuen Testfällen ausgedrückt werden.

1.2. Der Normal-Fall

Die Realität sieht oft ganz anders aus: Die Dokumentation ist oft Teil des Problems und nicht der Lösung. Ehemalige Entwickler sind samt KnowHow im Bermuda-Dreieck des Outsourcings verschwunden und als Test-Umgebung dient das Produktiv-System. Da heißt es dann im Code graben und die Mosaikstücke der ursprünglichen Architektur richtig zu deuten. Alles, was mir dabei hilft, den Source-Code zu verstehen, hilft mir bei der Rekonstruktion des Gesamt-Systems.

Auch die wenigen Test-Ruinen, die man dabei oft noch findet, sind von unschätzbarem Wert, geben Sie doch einen Einblick auf die dynamischen Zusammenhänge. Zusammen mit Aspektorientierten Code-Injektionen kann man darauf aufbauend neue Erkenntnisse über den Zusammenhalt der Code-Bereich gewinnen.

2. Abstecher in die Welt von AOP

Motivation

Neue Projekte auf der grünen Wiese sind selten. Viel öfters wird man mit Altlasten konfrontiert und steht vor der undankbaren Aufgabe, vergangene Architekturen wieder freizulegen und unbekannten Code zu deuten, um das Projekt zu vergangenen Hochkulturen wieder zurückzuführen.

Dabei gibt es verschiedenen Möglichkeiten, dem Code seine Geheimnisse zu entreißen. Ein vielversprechender Ansatz ist dabei der Einsatz von Aspekt-Orientierung und AspectJ, um unbekannte Codestellen zu erschließen und das Programmverhalten zu ergründen. Damit lassen sich:

• Schnittstellen überwachen
• Schnittstellen simulieren
• Events aufzeichen
• Sequenz-Diagramme für ausgesuchte Bereiche generieren
• …

Alles Dinge, die helfen, das Verhalten unbekannter Code-Bereich zu analysieren und Tests für weitere Belastungsproben aufzustellen. Dies kann auch aktuellen Projekten helfen, SW-Erosionen vorzubeugen.

Die klassische Herangehensweise

Am 9. Juli ist es soweit - das Java Forum Stuttgart 2015 und damit auch mein Talk zu SW-Archäologie mit AspectJ steht vor der Tür. Zeit, um einige Begriffe zu klären:

Archäologie ist eine Wissenschaft, die die kulturelle Entwicklung der Menschheit erforscht. SW-Archäologie dagegen ist kein "offizieller" Begriff, steht hier aber für die mühsame Erforschung gewachsener SW-Systeme ("Altlasten"), die Ähnlichkeiten mit Ausgrabungen versunkener Ruinen, der Suche nach weiteren Puzzle-Teilen oder der Deutung unbekannter Code-Stücke ähnelt.

Wer mehr dazu wissen will (und vor allem, wie man mit AspectJ - einer Aspekt-Orientierten Erweiterung von Java - das Graben im Code unterstützen kann), sollte zum Vortrag kommen oder diesen Blog hier verfolgen - für die nächsten Tage sind als Vorbereitung auf das JFS einige begleitende Artikel zu diesem Thema geplant.

Teil 0: Motivation