You are here: Wiki>SE Web>ThesesHome>ThesisEclipsemonitor>ThesisEclipsemonitorRequirements (26 Oct 2005, jekutschPCPOOL.MI.FU-BERLIN.DE)Edit

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
  • Programm ausprobieren
  • Änderungen am Code an einer Stelle vornehmen
  • Pause machen
  • Suchen im Code oder in JavaDoc
  • Debugging
und so weiter. Aus diesen elementaren Ereignissen des Programmierprozesses - genannt "Mikroprozess" - lassen sich typische Fehlersituationen - "Episoden" - entdecken, wie etwa
  • Mehrfaches Kopieren von Programmzeilen mit nachträglichen Änderungen
  • Abgelenkt werden mitten im Kodierprozess
  • Umfangreiche Trial-and-Error-Zyklen
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:
  • Aufzeichnen des Mikroprozesses aus mehreren Sensoren mit nachträglicher Offline-Analyse durch andere Werkzeuge, z.B. R (Statistik)
  • Abspielen eines Mikroprozesses synchron mit einer Videoaufzeichnung und gleichzeitiger manueller Hinzufügung neuer Ereignisse
  • Erkennen des Mikroprozesses mit just-in-time Senden von erkannten Episoden nach Hackystat oder direkt zurück in die Eclipse-Entwicklungsumgebung (letzteres ist aber nicht Teil dieser Arbeit). Einige der Ideen findet man unter MicroprocessHome.
  • Entwickeln eines Episodenerkenners (s.u.), wobei das Entwickeln möglichst praktisch vonstatten gehen soll, z.B. durch leichte Wiederholbarkeit eines Durchlaufs
  • Leichtes Extrahieren eines Zeitabschnittes. Idealerweise (nicht Teil dieser Arbeit) die Möglichkeit, eine deklarative Anfragesprache dafür einzusetzen.
  • Einsatz des Werkzeuges bei einer größeren Entwicklungsmanschaft und Sammeln all dieser Daten, wobei jeder Entwickler natürlich einen anderen Rechner hat. Die entstehende Datenmenge kann sehr groß werden. In diesem Rahmen wäre ein praktischer Upgrade-Mechanismus gut, um neue Versionen von ECG leicht zu distributieren.
  • Andererseits will ein einzelner Programmierer lediglich in Eclipse arbeiten und dort aufgrund einer erkannten Episode eine Rückmeldung auf Eclipse-typische Weise bekommen ("Problem"). Idealerweise braucht er dazu außer Eclipse kein anderes Programm starten.

Ereignisse allgemein

Ein Ereignis hat im allgemeinen folgende Parameter:
  • Zeitpunkt oder Zeitraum
  • Projekt, an dem gearbeitet wurde. Dies kann in einem ersten Schritt das aktuelle Eclipse-Projekt sein. Für andere Sensoren oder für bestimmte Ereignisse muss dieser Parameter frei bleiben.
  • Entwickler, der das Ereignis erzeugt hat. Es genügt, den am Betriebssystem angemeldeten Benutzer zu nehmen
  • Evtl. ist es wichtig zwecks Rückwärtskompatibilität eine Versionsnummer zu führen. Diese ändert sich, wenn sich die Definition der Ereignisart erweitert oder verändert hat.
  • Art des Ereignisses mit artspezifischen weiteren Parametern
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:
  • Codeänderung. Nur diese ist im ersten Schritt deutlich detaillierterer zu betrachten, siehe nächster Abschnitt.
  • Ausführen des Programms
    • mit und
    • ohne Debugger
  • Browsen/Navigieren = Auswahl einer neuen Edcitoransicht, insbesondere einer anderen Datei, aber auch Scrollen innerhalb einer Datei oder Nutzen des Outline-Views in Eclipse. (Dieser Bereich wird in Zukunft gewiss detailliert.)
  • Abspeichern einer Datei
  • Einchecken und Auschecken einer Datei aus der Versionsverwaltung
  • Einsatz eines der anderen Werkzeuge, z.B. JUnit, Ant, etc.
  • Sonstige Ereignisse innerhalb von Eclipse, die nicht weiter differenziert werden, aber wissen lassen, dass der Programmierer was tut, also nicht lediglich nachdenkt, sich anderen Programmen zuwendet, diskutiert oder telefoniert, also Eclipse-externe Ereignisse stattfinden oder nur eine Pause entsteht.

Weniger wichtig (und nicht im Rahmen dieser Arbeit zu realisieren) sind die folgenden:
  • Eclipse-Automatismen: Eclipse macht gelegentlich was im Hintergrund, z.B. Unterkringeln eines syntaktischen Fehlers. Diese Ereignisse sind evtl. interessant als Ursachen für Unterbrechungen und Ablenkungen.
  • Eclipse-Konfigurationszustand und -änderungen: Es ist ebenfalls interessant, ob es z.B. überhaupt Unterkringelungen gibt

Es ist notwendig, jedes Ereignis genau zu beschreiben.

Eine besondere Ereignisklasse sind Editieraktionen in einer bestimmten Quelldatei. Zentral sind dabei zwei Dinge:
  • Die Grenze einer Detailänderung. Eine Detailänderung ist eine wirklich kleine Änderung innerhalb eines zeitlichen (ein Ereignis) und Code-örtlichen (eine Stelle) Rahmens.
  • Das Änderungsdelta im Code, angegeben durch die Differenz im abstrakten Syntaxbaum oder im Code als String

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
  • per Hand bedienbare Ereignishinzufüger (für nur durch Menschen erkennbare Episoden oder Ereignisse)
  • Ereignisherausschreiber, z.B. in die Hackystat-Datenbasis. Dies werden nur wenige Ereignisse sein, z.B. die erkannten Episoden.

Nicht-funktionale und allgemeine Anforderungen

Hier einige lose zusammenhängende Punkte zu sonstigen Anforderungen:
  • Es ist eine Freigabemitteilung (Systemvoraussetzungen) zu schreiben. Mindestanforderung ist Windows XP/2000 mit Eclipse 3.0. Ein zusammenarbeiten mit Eclipse 2.x ist nicht nötig, schön wäre aber eine Liste mit erkannten und vermuteten Inkompotibilitäten mit älteren Versionen.
  • Wichtig ist eine hohe Qualität des Ergebnisses, das schließt ein:
    • Systematische Tests inklusive Testautomatisierungen (Vorbild wieder Hackystat)
    • Dokumentation des Codes insbesondere in Hinblick auf Erweiterungen bis hin zu Tutorials
  • Die Software wird Open-Source sein. Eine frühe Veröffentlichung wäre sinnvoll.
  • Der Entwicklungsprozess ist nicht vorgeschrieben, es sollte aber bedacht werden, dass es ein Forschungsprojekt ist und es somit eine Tendenz zu spontanen Anforderungserweiterungen gibt, insbesondere, weil das Werkzeug für explorative Arbeiten gedacht ist. Frühe Versionen mit eingeschräkter Funktionalität sind nötig für möglichst frühe Konkretisierungen. Dabei muss evtl. an eine Aufwärtskompatibilität der Aufzeichnungen geachtet werden bzw. eine Migration der Daten ermöglicht werden.
  • Eine Lauf des Sensors darf sich die Geschwindigkeit von Eclipse für den Entwickler nicht fühlbar verringern. Eine qualtitative Formulierung steht noch aus.
  • Pro Entwickler muss eine Mindestereignisrate von 1 Sekunde erreicht werden können.
  • Die Kodierstilvorgaben (Coding Conventions) sollten entweder Hackystat entsprechen oder sich an http://java.sun.com/docs/codeconv/ orientieren.

Kommentare

 
Topic revision: r10 - 26 Oct 2005, jekutschPCPOOL.MI.FU-BERLIN.DE
 
  • Printable version of this topic (p) Printable version of this topic (p)