Diplomarbeit "Protokollierung von Programmiertätigkeiten in der Eclipse-Umgebung" - Anforderungsbeschreibung

Auf dieser Seite werden die Anforderungen an die in der Diplomarbeit zu erstellende Software genauer beschrieben.

Einleitung

In dem Projekt Mikroprozessanalyse zur frühen Erkennung von Programmierfehlern wird die Hypothese geprüft, ob anhand der Tätigkeiten eines Programmierers Indizien auf entstehende Fehler (= Fehlverhalten) automatisch entdeckt und somit Defekte vermieden werden können. Die Tätigkeiten eines Programmierers sind etwa und so weiter. Aus diesen elementaren Ereignissen des Programmierprozesses - genannt "Mikroprozess" - lassen sich typische Fehlersituationen - "Episoden" - entdecken, wie etwa oder ähnliches. Derzeit sind weder alle diese Fehlersituationen bekannt noch der Nachweis geführt, dass sie auch signifikant häufig zu Defekten im entstehenden Programm führen. Dies soll unter anderem mit Hilfe umfangreicher Datensammlungen geschehen.

Im ersten Schritt zur Realisierung eines Werkzeugs zur Aufzeichnung des Mikroprozesses soll die integrierte Entwicklungsumgebung Eclipse herangezogen werden, um oben genannte Prozessdaten zu sammeln. Eclipse eignet sich durch seine offene Architektur besonders gut für eine solche Tätigkeitsprotokollierung. Gleichzeitig soll untersucht werden, ob sich Hackystat eignet, als Backend und auch als Frontend zu fungieren. Hackystat ist eine ähnliche Umgebung zur Aufzeichnung einer Art Milliprozesses, also lediglich dateiweite Änderungen, Testdurchläufe, Entwicklungszeiten, etc.

Das Projekt trägt den Codenamen ECG "ElektroCodeoGram" (wie EKG oder EEG aus der Medizin), also etwa "Aufzeichner des Kodierens mit elektronischen Mitteln".

Es folgen die Anforderungen, die sich aus dem Forschungsprojekt ergeben. Es ist wichtig zu bedenken, dass gerade im Forschungsbereich Anforderungen häufig ändern.

Funktionale Anforderungen

Der Grundgedanke ist klar: Der Mikroprozess des Programmierens, der sich in Eclipse zeigt, soll kontinuierlich aufgezeichnet werden, so dass eine nachträgliche Analyse (nicht Teil dieser Anforderungen) möglich wird. Ein Prozess ist dabei zu sehen als eine Folge von Ereignissen. Im Folgenden werden daher vor allem diese Ereignisse beschrieben. Ihre Beschreibung muss wegen des Forschungscharakters zunächst noch unvollständig und unklar bleiben. Es ist zu erwarten, dass sich eine endgültige Klärung erst mit den ersten Prototypen des ECG ergeben kann. Das betrifft insbesondere die Unterscheidung zwischen Ereignis und Episode, die Zusammenfassung und die Ordnung von Ereignissen.

Die Ereignisse des Mikroprozesses werden im Allgemeinen nicht nur an einer einzigen Quelle abgenommen, sondern an vielen. Zwar beschränkt sich diese Arbeit nur auf Eclipse, es ist aber die erste Arbeit dieser Art, d.h. der Entwurf muss es möglich machen, andere Quellen zu nutzen und dabei gemeinsame Teile (z.B. Episodenerkennung, Ereignisfilterung, Abspeicherung/Hackystat-Kommunikation) wiederzuverwenden. Eclipse beinhaltet als eine integrierte Entwicklungsumgebung zudem selbst viele potentielle Quellen. Man kann davon ausgehen, dass der Entwickler diese auch in Eclipse optimal nutzt, d.h. Editor, Debugger, Programmausführung, Ant, JUnit.

Bezüglich einer Ereignisquelle wird also ein "Sensor" realisiert. Die Installation ist mit dem Eclipse-Plug-in-Mechanismus zu erledigen, inklusive des Upgrade-Mechanismus, d.h. es muss einfach möglich sein, eine neue Version (z.B. zur Erhebung neuer Ereignisse) zu installieren. Auch die Konfiguration sollte mit Eclipse-typischen Mitteln erfolgen.

Es ist zu bedenken, dass in einer späten Ausbaustufe Hackystat als Server/Backend/Datensenke eingesetzt werden soll. Der ECG ist trotzdem möglichst Hackystat-unabhängig zu halten, basiert aber zumindest auf dort gesetzte Standards wie z.B. die Sensor Data Types und deren Repräsentation. Im Unterschied zu Hackystat soll die Speicherung in einem ersten (und stets als Alternative bleibenden) Weg in eine lokale Datei laufen. Der Speicherort der Datei ist möglichst in den privaten Bereich des Entwicklers zu legen. Grund sind Datenschutz und Privatheitsaspekte dieser "Arbeitskontrollsoftware".

Es wird viellerlei Episodenerkenner geben, die unabhängig voneinander realisiert werden sollten und auch nachträglich leicht (in einer Art Plug-in-Mechanismus) in das ECG eingeführt werden sollen. Genaueres ist unten zu lesen.

Ebenfalls soll der Entwurf der ECG-Aufzeichnung ein nachträgliches Abspielen des Mikroprozesses erlauben, z.B. um nachträglich Episoden zu erkennen oder um manuell neue (nur von Menschen erkennbare) Ereignisse in den Mikroprozess einzufügen. Es gibt also einen Live- und einen Replay-Modus. Letzterer kann in Echtzeit (zwecks Synchronisation mit z.B. einem Video) oder in Schnellzeit ablaufen.

Typische Einsatzszenarien für das ECG sind also:

Ereignisse allgemein

Ein Ereignis hat im allgemeinen folgende Parameter: Es gibt vermutlich eine Sensor-Initialisierungs-Datenbasis: Viele der Ereignisse sind Deltas zu einem vorherigen Zustand des Programms, von Eclipse und des Entwicklungsprozesses. Dazu braucht man aber die Basis, wo man angefangen hat, z.B. die bzgl. des Quellcodes erste Version nach Start des Sensors. Ein großes Problem wird auch die Absicherung sein, dass trotz diverser möglicher Probleme (z.B. Zeitverzögerungen) der Mikroprozess weiter aufgezeichnet wird, so dass möglichst keine Lücken entstehen. Entstehen sie dennoch, sollten sie gekennzeichnet werden.

Ereignissklassen

Folgende Hauptereignisse gibt es in Eclipse, nach Wichtigkeit für die Forschung geordnet:

Weniger wichtig (und nicht im Rahmen dieser Arbeit zu realisieren) sind die folgenden:

Es ist notwendig, jedes Ereignis genau zu beschreiben.

Eine besondere Ereignisklasse sind Editieraktionen in einer bestimmten Quelldatei. Zentral sind dabei zwei Dinge:

Eine Codeänderung hat neben den üblichen Ereigniss-Eigenschaften noch den Parameter der Stelle, also wo die Änderung statt findet. Die genaue Definition des Begriffs Stelle ist noch zu klären. Vorläufig genügt es, eine Javaklasse oder eine Methode/einem Feld in einer Klasse als Stelle anzusehen.

Welche Codeänderungen unterschieden werden und wann eine solche identifiziert ist, ist ebenfalls noch zu klären.

Als Programmiersprache ist Java anzunehmen. Eine Beschreibung, wie auf andere Programmiersprachen gewechselt werden kann, ist jedoch zu erstellen.

Episoden

Teil des ECG ist ein Episodenerkenner-Rahmenwerk. Es gibt eine Reihe von Episodentypen (siehe Beispiele in der Einleitung) und dementsprechend eine Reihe von Episodenerkennern. Ein solcher Erkenner muss unabhängig entworfen und in das ECG-Werkzeug leicht einbaubar sein, am besten zur Laufzeit.

Episoden werden erkannt, indem die zeitliche Folge von Ereignissen linear analysiert wird und nach einer passenden Folge von Ereignissen eine erkannte Episode ebenfalls als Ereignis geliefert wird. Die Episode ist also auch ähnlich einem Ereignis (bloß mit einer Zeitdauer statt einem Zeitpunkt) mit bestimmten Parametern.

Ein Episodenerkenner könnte abstrakt als Zustandsautomat beschrieben werden, der auf Ereignisse reagiert (und dabei vielleicht die Zustände wechselt) und bei Erreichen eines Endzustands selbst ein neu generiertes Ereignis ausgibt. Ein Rahmen zur Erstellung von Episodenerkennern könnte diese Sichtweise unterstützen. Es ist allerdings nicht klar, ob der Erkenner tatsächlich wie ein Zustandsautomat spezifizierbar ist oder einfach beliebiger Code sein sollte. Erst die Praxis wird dies klären können. (Diese notwendige theoretische Fundierung ist nicht Teil dieser Arbeit und bei fehlender Fundierung folglich auch deren Realisierung nicht.)

Es ist wichtig, dass eine neue Episode allen anderen Episodenerkennern präsentiert wird, so dass sie darauf reagieren können. Insbesondere bedeutet dies, dass Episoden sowohl auf Ereignisse, als auch auf andere Episoden reagieren können.

Erkenner können den vorhandenen Ereignissen auch lediglich neue Attribute hinzufügen. Genauso kann es "Erkenner" geben, die Ereignisse herausfiltern. Weitere Spezialfälle von Episodenerkennern sind

Nicht-funktionale und allgemeine Anforderungen

Hier einige lose zusammenhängende Punkte zu sonstigen Anforderungen:

Kommentare