Studienarbeit "Animation vergangener Codeänderungen von Java-Methoden"
Auf dieser Seite werden die Anforderungen an die in dieser Studienarbeit zu erstellende Software genauer beschrieben.
Einleitung
Ziel dieser Arbeit ist es, ein Werkzeug zu Visualisierung der Mikroevolution zu beginnen. Die Aufzeichnung des Mikroprozesses (siehe
http://www.electrocodeogram.org und
ThesisEclipsemonitor) liefert unter anderem Codeänderungen in feinen Schritten in einer XML-Repräsentation. Diese sind pro Klasse aufgeschlüsselt nach Methoden in einer Art Video animiert darzustellen, so dass man die Evolution einer Methode über die Zeit leicht erkennen kann.
Anforderungen
Diese Animation sollte die Zeit stauchen, aber auch Lücken überbrücken können. Ferner sollte erkennbar sein, welche Codeteile wie lange nicht mehr geändert wurden. Die Visualisierung ist (voraussichtlich) in der Eclipse-Entwicklungsumgebung zu realisieren.
Folgende Anforderungen sind möglichst zu erfüllen.
- Als Darstellungsrahmen sollte Eclipse benutzt werden, insbesondere die Darstellung von Bäumen zur Auflistung der animierbaren Methoden und ein read-only Editorfenster zur Anzeige der Animation selbst.
- Es soll - in Form eines Baums von animierbaren Methoden, gruppiert nach Klassen - die interessierende Methode ausgewählt werden können.
- Nach der Auswahl der Methode soll in einem Fenster das "Video" der Mikroevolution abgespielt, wobei
- der aktuelle Zeitpunkt sichtbar ist
- eine Handsteuerung (ähnlich wie bei Video- oder Audioplayern) möglich ist
- zur Auswahl eine zeitproportionale Abfolge (also proportional gleiche Geschwindigkeit wie im Original) oder eine einfache Aneinanderkettung der Änderungen
- bei ersterem wäre schön:
- der Geschwindigkeitsfaktor zum Original schon einstellbar sein (von 1/10 bis 10 mal so schnell)
- größere Pausen (die sich auch über Tage erstrecken können) sollen ab einen Schwellwert überbrückt werden
- bei zweiterem wäre schön:
- Einstellen der Geschwindigkeit, d.h. der kurzen Pausen zwischen jedem Ereignis (unabhängig von den Originalabständen) von 0 bis 5 Sekunden.
- Es sollte erkennbar sein, welche Zeilen sich seit dem letzten Codezustand geändert haben.
Ausgangsbasis
- Die Darstellung basiert auf den Ereignis des "CodeChange" aus dem ECG-Projekt. Diese Daten liegen in einem XML-Format vor, das auch gerne selbst definiert werden kann.
- Es ist zu überlegen, ob diese CodeChanges, die immer komplette Dateien abbildet, besser in CodeDeltas pro Methode umgewandelt werden sollten. Diese Umwandlung kann im ECG-Server erfolgen. Der Einfachheit halber macht es aber auch Sinn, solche CodeDeltas direkt vom Eclipse-Sensor liefern zu lassen (denn Eclipse "kann" sowas). Es ist zu beachten, dass man einen robusten Parser benötigt, der auch systaktisch nicht korrekten Code möglichst weitgehend zumindest bis zur Methodendefinition parsen kann.
- Mit welchen kodierten Ereignissen auch immer: Das Werkzeug liest eine XML-Datei ein. Es ist zu beachten, dass diese sehr groß sein kann.
Zukünftige Erweiterungen
Die resultierende Software soll die Basis für einige Erweiterungen legen. Um einen ausreichend allgemeinen Entwurf zu unterstützen, sind folgend die geplanten Erweiterungen aufgelistet, die aber wohlgemerkt nicht mehr Teil dieser Arbeit sind:
- Auf Wunsch sollte am Farb-/Grauton einer Codezeile erkennbar sein, wie "alt" sie ist, also wie lange sie nicht mehr geändert wurde.
- Verallgemeinerung von Methoden auf ganze Klassen oder auf Teile von Methoden
- Verallgemeinerung von Java auf andere Programmiersprachen
- Verallgemeinerung in Richtung der gleichzeitigen Anzeige anderer Mikroprozessereignisse oder -phasen, z.B. Defektentfernungsphasen oder Unterbrechungsereignisse. Diese würden z.B. auch in Farben kodiert.
Da diese Arbeit also nur der Anfang ist, wird auf eine gute Dokumentation sowohl des Codes als auch des Entwurfs viel Wert gelegt. Die notwendigen Schritte zur Implementierung der zukünftigen Erweiterungen sollten dadurch klar werden.