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

Auf dieser Seite wird der Stand des Fortschritts der Diplomarbeit vermerkt.

Aktuelles Release

Version 0.6 des ECG

Aktuelle Dokumentation

Dokumentaion des ECG

Wochenberichte

Eintrag 1

1. Erledigte Arbeiten vergangene Woche

Ich habe gelesen:

Azad Bolour: "Notes on the Eclipse Plug-in Architecture", 2003, http://www.eclipse.org/articles/Article-Plug-in-architecture/plugin_architecture.html

2. Planung für nächste Woche (inkl. Widervorlage aus Wochenplan)

a. Bau einfacher Plug-ins gemäß der obigen Anleitung

b. Lese John Arthorne: "How You've Changed!", 2004, http://www.eclipse.org/articles/Article-Resource-deltas/resource-deltas.html

c. Antworten auf die Frage: "Was kann ich messen?" finden.

3. Erkenntnisse (inkl. Irrtümer) und Vermutungen

Eclipse ist ein tolles Framework.

Die Eclispe Plug-in Architektur stellt ein von Eclipse völlig unabhängiges Entwurfsmuster (design pattern) für stark erweiterbare Anwendungen dar.

Ich verstehe die grundlegenden Mechanismen, um Eclipse Plug-ins zu erzeugen und einzubinden.

4. Entstandene Artefakte (Spezifikationen, Entwürfe, Pläne, Code, Dokumentation, Ausarbeitung, Vortrag) mit Versionen

keine

Eintrag 2

1. GELESENES MATERIAL:

John Arthorne: „How You’ve Changed! – Responding to resource changes in Eclipse workspace”, 2004, http://www.eclipse.org/articles/Article-Resource-deltas/resource-deltas.html

Eclipse V3.0 PlugIn-Developer Online-Help

Eclipse V3.0 Platform API-Reference

2. ERKENNTNISSE

Entgegen meinen ersten Befürchtungen gibt es eine ganze Reihe von „Listenern“ aus der Eclipse Platform (Core API) und weiteren PlugIns, welche es uns ermöglichen auf viele Events zu lauschen und zu reagieren. (siehe Anlage „allListeners.txt“, „allJDTListeners.txt“).

Ein erstes Prototyp PlugIn ist erstellt. Es bekommt u.a. das Öffnen und Schließen von Eclipse Fenstern, das Öffnen, Schließen und Auswählen von „Parts“ (Outline, Console, Navigator, …) und das Verändern von Resourcen mit und schreibt diese mittels „java.util.logging.Logger“ an die Console. (siehe Anlage MyEclipseSensor.zip)

Die Reaktionen auf die Ereignisse sind noch sehr unbeholfen, vor allen Dingen was die notwendige Erstanalyse angeht. So bekommen wir momentan nur mit, dass sich Resourcen geändert haben, aber nicht auf welche Weise (obwohl ich das gecodet habe).

Des Weiteren müssen hier noch sehr viel mehr Listener registriert werden, vor allen Dingen welche, die den Quelltext auf Änderungen belauschen. Hier besteht das Problem darin mit Hilfe der API-Doc heraus zu bekommen, wo man die Listener registrieren kann.

3. FRAGESTELLUNGEN

Es ist an der Zeit, dass wir einige grundlegende architekturelle Entscheidungen treffen. Ich denke mittlerweile, dass es prinzipiell kein Problem ist den Prototypen von seinem jetzigen Stand aus weiter zu entwickeln. Man lauscht auf mehr, man logged ins FileSystem, …

Letztendlich hätte man dann ein Eclipse PlugIn, dass seinen Zweck erfüllt, aber auch nicht mehr. Da ja in der Aufgabenstellung explizit nach einem allgemeinen Entwurf gefragt ist, denke ich, dass man den Sensor in einen etwas größeren und von Eclipse unabhängigen Rahmen (um nicht zu sagen „Rahmenwerk“) stellen muss.

Ich habe dazu bereits einige konkrete Vorschläge und Fragen für Donnerstag.

Eintrag 3

1. GELESESENES MATERIAL

Eclipse V3.0 Plug-In-Developer Online-Help

Eclipse V3.0 Platform API-Reference

Quelltexte der „HackyStat“-Packages:

hackyEclipse - Eclipse V3.0 Sensor

hackyEmacs - Emacs Sensor

hackyVisualStudio - Visual Studio Sensor

Mehrere „HackyStat“ Dokumente:

Overview - http://www.hackystat.org/hackyDevSite/hackyBuild/README.html

User Guide: Guided Tour - http://www.hackystat.org/hackyDevSite/guidedtour.jsp

User Guide: License Information - http://www.hackystat.org/hackyDevSite/doc/LicenseInfo.html

Developers Guide: Quick Start - http://www.hackystat.org/hackyDevSite/doc/DevQuickStart.html

Developers Guide: The Elements of Hacky Style - http://www.hackystat.org/hackyDevSite/doc/EHS.html

Developers Guide: Test Framework - http://www.hackystat.org/hackyDevSite/doc/TestFramework.html

Developers Guide: Sensor Shell - http://www.hackystat.org/hackyDevSite/doc/SensorShell.html

Developers Guide: Sensor Data Types - http://www.hackystat.org/hackyDevSite/doc/SensorDataType.html

2. ERKENNTNISSE

Die oben genannten Dokumente habe ich auf der Suche nach Argumenten für ein eigenes Framework gelesen. Einige wesentliche Architekturprinzipien von „HackyStat“ habe ich nun verstanden. Leider gibt es keine eigentliche Beschreibung der Architektur, sondern nur implizite Hinweise und Fragmente in allen Dokumenten.

Die Dokumente zur „Sensor Shell“ und zu „Sensor Data Types“ haben mich über die Extensibilität von „HackyStat“ informiert und mir gezeigt, dass man prinzipiell auch einen sehr feingranularen Eclipse Sensor direkt im „HackyStat“ Framework laufen lassen kann. Die Quellen der Emacs und Visual Studio Pakete habe ich mir angeschaut, um zu sehen wie aus nicht Java Umgebungen (Emacs ist Lisp, Visual Studio ist C#) auf „HackyStat“ zugegriffen wird. Es ist sehr hässlich und nicht generisch! Die Argumente gegen den direkten Einsatz von „HackyStat“ habe ich als Anlage beigefügt. In diesem Dokument findet sich dann auch eine oberflächliche Beschreibung meiner Architektur (als bessere Alternative).

Darüber hinaus habe ich begonnen ein Kommunikationsprotokoll für Sensoren und Datensammlern zu Erstellen. Damit legen wir uns auch auf Ereignisse fest, die für die Analysen interessant sind. Das Dokument dazu findest Du auch im Anhang.

Außerdem ist es mir noch gelungen den eigentlichen Eclipse Sensor weiter voran zu bringen. Resourcenänderungen werden jetzt detailliert bemerkt und gelogged. Aber auch Änderungen an geöffneten Dokumenten bekomme ich jetzt mit. Bisher leider nur zeichenbasiert und mit ungenügend vielen Informationen.

3. FRAGESTELLUNGEN

Wir sollten jetzt möglichst schnell klären, nach welcher Architektur wir vorgehen.

Eintrag 4

Auch der Wochenbericht fällt diesmal (aber auch klausurveorbereitungsbedingt) minimalistisch aus. Im Anhang sind zwei Diagramme (in einem word-file), die den aktuellen Datenfluss der Ereignisse aus dem „HackyStat“ EclipseSensor zum Server und eine mögliche Erweiterung dazu darstellen

Eintrag 5

Nachdem ich nun eine Basissoftware habe, werde ich wöchentlich weiter Inkremente entwickeln und integrieren. Die jeweiligen Versionen finden sich dann bei den Attachments. Weiterhin werde ich den Fortschritt hier Dokumentieren.

Aktuelle Version

Mit dieser Version wurde der Projektname auf "ElectroCodeoGram" (ECG) festgelegt. Die entsprechende domain "electrocodeogram.org" ist gemietet und ein gleichnamiges sourceforge-projekt angelegt.

Die aktuelle Version für das ECG-framework ist ecg_v0.3.0.zip

Kurzanleitung

  1. Zip entpacken
  2. Das Verzeichnis "org.electrocodeogram_0.3.0" in das "eclipse/plugin" Verzeichnis kopieren.
  3. Das Verzeichnis "electrocodeogram" in das Verzeichnis "START_LAUFWERK:\Dokumente und Einstellungen\BENUTZERNAME\" kopieren.
  4. Eclipse starten

Zusammenfassung

Mit dieser Version ist ECG ein modulares framework zum Empfangen, Verarbeiten und Ablegen von Sensordaten, des Typs "HackyStat" SensorDataType, geworden.

Es werden drei Klassen von Modulen unterschieden:

  1. SourceModule sind solche, die Sensordaten engegenehmen können und sie weiteren Modulen weiterleiten können. So ist zum Beispiel das interne SensorSourceModule, welches die Sensordaten von laufenden Sensorinstanzen entgegennimmt, von diesem Typ. Aber auch ein Modul, dass die in einer Textdatei abgelegten Sensordaten einliest, wäre ein SourceModul.

  1. IntermediateModuls sind solche, die Sensordaten entweder von SourceModulen oder anderen IntermediateModulen entgegenehmen und weiterleiten. Diese Module werden nochmals danach unterschieden, ob sie Annotator oder Filter sind. AnnotatorModule schreiben in den SensordatenStrom zusätzliche Sensordaten hinein, die als Vorauswertung oder Kommentar dienen können. FilterModule ersetzen ein oder mehrere Sensodaten durch ein neues Sensordatum. Ein AnntatorModul ist zum Beispiel das simple LineNumberAnnotator Modul, dass den SensordatenStrom mit Zeilennummern versieht. Ein FilterModul könnte Trivialereignisse ausfiltern.

  1. TargetModuls sind solche, die Sensordaten entweder von SourceModulen oder anderen IntermediateModulen entgegenehmen und anschließend schreiben. Der FileEventWriter schreibt die Sensordaten zum Beispiel in eine Textdatei in das Dateisystem. Der LoggerEventWriter schreibt sie an die Konsole. Möglich ist auch ein HackyStatWriter, der die Daten explizit zu einem "HackyStat" Server sendet.

Die Kommunikation zwischen den Modulen erfolgt Ereignisgesteuert mit dem observer-pattern und ist unidirektional. Die Sensordaten werden dabei durch einen Modulbaum, mit einem SourceModul als Wurzel und TargetModulen als Blätter, geleitet. Dadurch ist es sowohl möglich Sensordaten wie durch ein "pipe" zu verarbeiten, aber auch parallel verschiedenartig zu prozessieren.

Durch das Bereitstellen von abstrakten Klassen für die verschiedenen Modultypen, ist es leicht eigene Module zu entwicklen. So ist z.B. für TargetModule nur die write()-Methode und für AnnotatorModule nur die annotate()-Methode zu implementieren.

Nur ein kleiner Teil der Module ist fest in das ECG framework einkompiliert und zur Laufzeit bekannt. Der größte Teil der Module wird zur Laufzeit dynamisch aus dem Dateisystem geladen. Konkret heißt das: Die ensprechdenden Modulklassen werden im Verzeichnis "electrocodeogram/modules/MODUL_NAME" im Heimatverzeichnis des Benutzers abgelegt. Von dort aus werden sie vom ECG framework mittels reflection erkannt und durch den eigenen ModuleClassLoader geladen. Bei Bedarf werden die Module dann instanziiert.

Durch diese Vorgehensweise ist es Möglich, dass Dritte ohne Änderungen an den ECG Quelltexten das framework durch Module erweitern (Ähnlich wie bei Eclipse selbst).

Die Entscheidung darüber, wie der Modulbaum für eine konkrete Messung aussieht, wird vom Experimentator in einer grafischen Oberfläche getroffen. Dort können erkannte Module an vorhandene "angehangen" werden, sowie der Fluss der Sensordaten durch die Module überwacht werden.

Neue Funtkionen und Eigenschaften

  • modulares framework (dynamisches Laden von Klassen zur Laufzeit)
  • Modul-API
  • grafische Oberfläche zur Konfiguration
  • SensorSourceModul - nimmt Sensordaten von laufenden Sensoren entgegen
  • LineNumberAnnotator - schreibt Zeilennummern vor jedes Sensordatum
  • LoggerEventWriter - Schreibt Sensordaten auf die Konsole
  • FileEventWriter - schreibt Sensordaten in eine Textdatei

Ziel der nächsten Woche

  • Implementierung einiger gut Verstandener "Micro"-SensorDataTypen
  • Bau eines entprechenden Sensors für Eclipse
  • Testen

Eintrag 6

Durch Osterfeiertage und Krankheit wurde ich etwas aus der Arbeit gerissen, was sich letzen Endes sogar als positiv heruas stellte. Nachdem ich mich nach einer Woche wieder an das Projekt gesetzt hatte, sind mir grundlegende Schwierigkeiten aufgefallen, die ich vorher nciht wahrgenommen habe. Dies hat nun zu einer grundlegenden architektonischen Neuausrichtung geführt.

Vor allen Dingen zeigte sich, dass das einfache Kapseln einer "HackyStat" Binärkomponente nicht ausreicht, um die Anforderungen zu erfüllen. Gerade der Einsatz mehrerer Sensoren, welcher für die Aufzeichnung des gesammten Mikroprozesses notwendig ist, wird von der "HackyStat" Komponente nicht unterstützt. Aber auch die Erweiterung der vorhandenen SensorDataTypes durch eingene feingranulare Typen, ist sehr unschön nur innerhalb der Binärkomponente zu bewerkstelligen.

Um die Anforderungen zu erfüllen, habe ich mich für eine weitere Emanzipation des ECG von "HackyStat" entschieden, wobei ich jedoch die Kompatibilität mit den "HackyStat" Sensoren und der Serverkomponente anstrebe.

Aktuelle Version

Ein neues Release existiert noch nicht. Die Projektquellen werden nun alllerdings in einem Subversion Repository bei Berlios (ecg.berlios.de) gehostet.

Zusammenfassung

Das ECF-Framework gliedert sich nun in mehrer zunächts unabhängige Teile. Der Hauptteil ist ein eine Java-Application, die via Sockets auf eingehende Sensordaten wartet und diese dann in dem bereits bekannten modularen Framework prozessiert.

Neu ist hier die Eigenständigkeit dieses Programms, dass nun direkt als JAR-Datei gestartet wird. Dadurch ist es möglich Daten von beliebig vielen verschiedenen Sensoren zu sammeln, solange die Sensoren sich an die definierten SensorDataTypes halten, und mit auszuwerten.

Ein weitere wesentlicher Teil des Frameworks sind dann eben die Sensoren, welche meist als Plug-In in anderen Anwendungen arbeiten. Um dem Wunsch nach Weiterverwendung der bereits vorhandenen "HackyStat" Sensoren gerecht zu werden, gibt es nun ein Hilfspaket, das den Sensoren vorgaukelt ein "HackyStat" Bestandteil zu sein, aber deren Kommunikation auf den oben beschriebenen ECG "SensorServer" umleitet.

Neue Funtkionen und Eigenschaften

  • Eigenständiges SensorServer Programmm
  • Betrieb mit mehreren Sensoren
  • Neuer SensorDataType (MicroActivity)
  • Integration neuer Ereignisse in den Eclipse Sensor

Ziel der nächsten Woche

  • Bau eines einfachen sinnvollen Episodenerkenners als Modul
  • Ein neues Release

Eintrag 7

Zuerst einmal habe ich nun ein neues Release (v0.4.0) fertig gestellt, welches sich einfach installieren und benutzen lässt. Siehe "Aktuelle Version"

Die wesentlichtse Entwicklung betrifft abermals die Zusammenarbeit mit "HackyStat". Siehe "Zusammenfassung"

Aktuelle Version

Die aktuelle Version des ECG Frameworks kann unter http://download.berlios.de/ecg/ElectroCodeoGram.zip bezogen werden.

Nach dem Entpacken findet man zwei Verzeichnisse vor. Den Inhalt des Verzeichnisses "plugins" kopiert man in den Eclipse plugins Ordner. Achtung: Der Eclipse Sensor arbeitet leider momentan immer noch nur mit Eclipse 3.0!

Im Ordner Application befindet isch das eigentliche Programm in Form der Datei "ElectroCodeoGram.jar". Diese einfach durch Doppelklick (wenn eingerichtet) oder durch "java -jar ElectroCodeoGram.jar" starten.

Wenn der Eclipse Sensor korrekt läuft, dann sieht man das auch in der GUI des ECG. In diesem Fall muss im oberen Panel ("Active sensors") ein rotes Rechteck auftauchen.

Zusammenfassung

Nachdem bereits vorherige Woche die Architektur umgekrempelt worden war, habe ich mich nochmals grundlegend mit der Zusammenarbeit mit "HackyStat" beschäftigt.

Wie bereits mehrfach erwähnt erfüllt "HackyStat" nicht unsere Anforderungen, auch nicht dann, wenn man die Komponeneten einfach nur Erweitert. Die Entscheidung hin zu einem eigenständigen Programm habe ich bereits in der letzten Woche getroffen und berichtet.

Nun war es mir aber immer noch wichtig "HackyStat" für genau drei Dinge zu benutzen. Zuerst einmal exisitiert die Anforderung möglichst alle vorhandenen HS Sensoren mit dem ECG benutzen zu können. Darüber hinaus soll der HS Server auch als mögliche Datensenke genutzt werden können. Daraus ergibt sich, das das ECG bezgl. der Ein- und Ausgabe "HackyStat" kompatibel sein muss.

Außerdem exisitiert im HS Framework ein sehr gut gelöstes SensorDaten Konzept. Dieses ist über Jahre hin entwicklet worden und arbeitet sehr zuverlässig, so dass es vom ECG benutzt werden sollte.

Das ECG entspricht nun diesen drei Punkten und benutzt dabei einfach eine "HackyStat" Binärkomponente ohne diese zu verändern, so dass man prinzipiell die Möglichkeit hat auch von neueren HS Versionen durch Verwendung einer neuen Komponente zu profitieren.

Vom inhaltlichen her ist noch zu erwähnen, dass mit diesem Release ein erster primitiver Episodenerkenner als Modul mitgeliefert wird. Der TrialAndErrorEpisodeAnnotator erkennt dabei zwei "Run" oder "Debug" sessions innerhalb von 10sec. als Muster und erezugt ein neues Episodenereignis.

Neue Funtkionen und Eigenschaften

  • Verwendung von "HackyStat" als Binärkomponente
  • TrialAndError Episodenerkenner
  • Module lassen sich als Annotator oder Filter betreiben. Dies ist zur Laufzeit konfigurierbar.
  • In der module.properties Datei lassen sich Felder definieren, die das Verhalten des Moduls ändern und zur Laufzeit konfiguriert werden können.
  • So kann man nun z.B. für den FileEventWriter eine Ausgabedatei wählen.
  • Module haben hiezu Kontextmenüs in der GUI.
  • Module lassen sich aktivieren und deaktivieren.
  • diverse GUI Verbesserungen

Ziel der nächsten zwei Wochen

  • Urlaub smile

Eintrag 8

Release 0.5.0 ist fertig und wird noch am Wochenende ins Netz gestellt.

Es sind vor allen Dingen einige "Baustellen" bearbeitet worden und von der Liste der längerfristigen Ziele ist das entfernen von Modulen, sowie die Verwaltung mehrerer Sensorquellen implementiert worden..

Installation s.o.

Zusammenfassung

Mit dieser Version habe ich endlich die Lücke zwischen der großen Funktionalität des ECG und dem, was die GUI davon abbilden kann, kleiner gemacht.

Die Modulverbindungen sind nun auch in der Vielfältigkeit benutzbar, wie die Architektur es ermöglicht. So können nun auch mehrere Module ihre Ausgaben an das selbe Modul senden und sowohl Module, als auch einzelne Verbindungen können wieder entfernt werden.

Außerdem ist eine weitere Ereignisquelle hinzu gekommen. Der "Manuelle Ereigniserzeuger" soll Protoptyp und Superklasse aller eventuellen Module dieser Art werden. Ihre Aufgabe wird es sein dem Experimentator die Möglichkeit zu geben. während der Messung, von Hand, Ereignisse in den Strom zu schreiben.

Ein weiterer Prototyp ist der "Codechange Differ". Diese Modul soll Ereignisse des Typs "Codechange" erkennen und im Ergebnis ein vorher/nachher ausgeben. Dabei ist noch nicht klar, ob die Intelligenz des "diffs" im Sensor oder dem Modul liegen soll.

Neue Funtkionen und Eigenschaften

  • Neue Möglichkeiten bei den Modulverbindungen
  • Verbindungen entfernbar
  • Module entfernbar
  • Mehrere Sensoren werden erkannt
  • Prototyp: "Manueller Ereigniserzeuger"
  • Prototyp: "Codechange Differ"
  • Unterstützung vom Eclipse 3.1

Ziel der nächsten Wochen

Das Projekt geht nach diesem Release in eine Konsolidierungs und Qualitätässicherungsphase.

Eintrag 9

Nachdem ich begonne habe, eine Gliederung für die Diplomarbeit zu erstellen und eine Liste weiterer zu erstellender Dokumente anzulegen, bin ich nun in einer generellen Planungsphase, in der alles was noch zu tun ist ,mit Priorisierung und zeitlicher Schätzung, aufgelistet werden soll.

Durch meine Teilnahme an der Microsoft Student Technology Conference 2005 in Kassel in dieser Woche hatte ich wenig Zeit. Dennoch habe ich auch einige Dokumente, wie die Installationsanleitung, erstellt.

Ziel der nächsten Wochen

Ich werde alle Dokumente anfertigen, die sich auf klare und fertiggestellte Themen beziehen. D.h. eine Bedienungsanleitung werde ich noch nicht schreiben, da sich hier später sicher noch viel ändern wird.

Die Planung für die Restarbeit soll fertiggestellt werden.

Ziel der übernächsten Wochen

Kritische Funktionseinheiten des ECG sollen durch automatisierte Tests evaluiert werden. Dabei sollen nicht nur Funktionstests zu, Auffinden von Defekten, sondern auch Sttresstests zum bewerten nicht funktionaler Eigenschaften der Software einfgesetzt werden.

Eintrag 10

Da ich am Donnerstag meinen BSE Vortrag zum über das ECG halte, habe ich mich fast ausschließlich darum gekümmert.

Neben der Präsentation an sich habe ich eine este Version der Architekturdokumentation und eine Beschreibung der Sensorschnittstelle geschrieben. Die Dokumente werden dann bald auf der Projektseite zu finden sein.

Ziel der nächsten Wochen

Durch den Vortrag werde ich erst eine Woche später zum Testen kommen. Aber dann…

Eintrag 11

Den Vortrag habe ich nun hinter mir und die Folien werden dann u.a. auf www.electrocodeogram.org veröffentlicht.

Das Wochenende über habe ich Unterlagen für eine Office-Schulung erstellt und bin deshalb noch nicht weiter gekommen.

Ziel der nächsten zwei bis drei Wochen

Testen, testen, testen …

Eintrag 12

Auch diese Woche war wieder sehr arbeitsreich, wobei ein großer Anteil der Arbeit leider nichts mit der Diplomarbeit zu tun hatte. Dennoch habe ich eine Testplanung geschrieben. In dieser führe ich aus, welche Funtkionseinheiten ich testen möchte und wie.

Dabei lege ich viel Wert auf die Begründung meiner Auswahl an Testfällen, die dort greifen sollen, wo ich die kritischen Teile des ECG sehe.

Es werden mehrere Testfälle zum Testen auf das Vorhandensein von Defekten vorgestellt, die dann in der nächsten Woche implementiert werden sollen.

Neben diesen funktionalen Tests habe ich auch Testfälle für Stresstests entworfen, die die Kapazitativen Grenzen des Frameworks ausloten sollen. Auch diese sollen möglichst bald implementiert werden.

Neben der Testplanung habe ich noch die Architekturdokumentation überarbeitet und dabei die Anregungen von Sebastian eingebaut. Die rein technische Version dieses Dokuments, dass ich vor allen Dingen an Entwickler richtet, die gerne selbst das ECG erweitern wollen, findet sich in der www.electrocodeogram.org Dokumentenverwaltung.

Ziel der nächsten Woche

Beginn der Implementierung der Testfälle mit ersten Resultaten.

Eintrag 13

Wie bereits in der vorherigen Woche angejündigt habe ich nun die Arbeit an den Tests begonnen. Ich kommme weniger schnell voran als ich dachte und werde daher wohl hier mehr Zeit einplanen müssen. Letzten Endes ist es aber besser mehr Zeit in die Qualität zu stecken, als in weitere Funktionen (Alles Wesentliche ist ja eh bereits da).

Neben der Tatsache, dass ich zum ersten mal automatisierte Tests implementiere und daher auch mit JUnit erst mal warm werden muss, finde ich es nach wie vor schwierig meine Software zu testen. Ich habe mich entschieden beim Testen den Fokus auf den Transport der Ereignisdaten zu legen, da dies für die Arbeit des Benutzers ein sehr kritischer Punkt ist. Hier darf nichts schief gehen!

Allerdings ist der Transport der Ereignisdaten mehrfach asynchron und geschiet zudem noch über die Grenzen referenizierbaren Objekten hinaus. Damit will ich sagen: Ich weiß zwar ziemlich genau, was ich testen will, aber ich komme schlecht an die Informationen aus meiner Software ran. Ich will ja durch das Einführen der Tests nicht meinen eigentlichen Code zu sehr verändern.

Auch dadurch, dass ich wärend ich Klassen teste, diese mit JavaDoc versehe und natürlich nochmals inspiziere und ggf. auch Ändere komme ich langsamer voran als geplant.

Ich denke aber, dass ich bis zur kommenden Woche bereits Teilresultate erbringen kann.

Neben den Tests habe ich auch die Planaung auf www.electrocodeogram.org → Tasks überarbeitet und vor allen an die Ergebnisse der Lagaebesprechung der letzten Woche angepasst.

Ziel der nächsten Woche

Weiter testen …

Eintrag 14

Nach zwei sehr frustrierenden und lehrreichen Tagen zum Thema Testautomatisierung habe ich mit Hilfe guter Lektüre einige Testfälle implementiert, die den Transport der Mikroprozessdaten auf der Klientseite des ECG abdecken sollen.

Mit Hilfe eines eigenen Testsensors, der in der Lage ist auf Kommande syntaktisch valide und invalide Ereignisse zu melden, wurden Testfälle implementiert, die untersuchen sollen, ob valide Ereignisse korrekt vom Testsensor bis zum absendenden Thread durchgereicht werden. Syntaktisch invalide Ereignisse sollen bereits auf der Klientseite, noch vor der Übertragung zum ECG Server, ausgefiltert werden. Auch dies wird durch Testfälle untersucht.

Wie erwartet hat die Ausführung der Testfälle dabei geholfen die Qualität der Implementierung zu erhöhen. Dies habe ich zusätzlich auch dadurch erreicht, dass ich sämtliche an einem Testfall beteiligten Klassen einem Review unterzogen, diese komplett mit ausführlicher Quelltextdokumentation versehen und auf Java 1.5 gehoben habe.

Die Tests auf der Klientseite sind also bzgl. der Qualität des ECG sehr fruchtbar gewesen. Einige Schwierigkeiten habe ich nun bei dem Übergang von Klient auf Server. Es handelt sich hier aber um rein technische Detailfragen der Art, wie ich programmatisch meinen Server gestartet und wieder gestoppt bekomme, usw.

Ziel der nächsten Woche

Tests auf der Empfängerseite (ECG Server) …

Eintrag 15

Wie geplant habe ich in dieser Woche autmomatisierte Tests auf dem ECG Server durchgeführt. Auch hier ging es hauptsächlich darum, zu prüfen, ob valide Ereignisse korrekt empfangen und in die Module weitergeleitet werden und, ob invalide Ereignisse ausgefiltert werden.

Auch zur Verbindung zwischen ECG SensorShell (Klient) und ECG Server habe ich einige Testfälle implementiert, die zumindest prüfen, ob, nachdem eine Verbindung hergestellt wurde, der Sendepuffer auf der Klientseite geleert wird.

Wie bereits in der vorherigen Woche habe ich dabei die beteiligten Klassen bzgl. der Codequalität und Dokumentation überarbeitet.

Als Nebenprodukt für die Testfälle auf dem ECG Server hat dieser nun eine eigene Konsole bekommen, auf der Statusinfomrationen ausgegeben werden und auch Befehle, z.B. "quit" eineglesen werden.

Aus den bekannten HackyStat SensorDataTypes habe ich Testereignisse erzeugt und diese sowohl der Klientseite als auch der Serverseite in Testfällen übergeben. Dabei habe ich noochmals die Dokumentation der HackyStat SensorDataTypes studiert und mit vergewissert, dass der "Activity" SDT für die Aufzeichnung von Mikroprozessereignissen am besten geeignet ist.

Neben dem Testen habe ich noch einen Tag in ANT investiert, um den mittlerweile etwas aufwändigen Buildprozess zu automatisieren. Nun esxistieren sowohl für die Klient- als auch für die Serverseite ANT build.xml Dateien, die alle benötigten JARs erstellen und die ECG Lab Anwendung erzeugen.

Ziel der nächsten Woche

Tests zum Transport von Ereignissen zwischen den Modulen

Eintrag 16

Mit den Tests zum Transport von Mikroprozessereignissen zwischen verbundenen Modulen habe ich nun auch die letzte Ebene der funktionalen Tests zum MPE Transport abgeschlossen. Auch in diesem Bereich des Frameworks ist die Implementierungsqualität und Dokumentation verbessert worden.

Für die Modultests wurden exemplarisch zwei verschiedene Modulgeflechte erzeugt. Eine 100 elementige Modulliste und ein binärer Modulbaum vierten Grades. In den Tests werden Ereignisse an die Kopf- bzw. Wurzelelemente übergeben und geprüft, ob das selbe Ereignis am letzen Element der Modulliste bzw. an allen Blattelementen des Baumes empfangen wird.

Die bereits vorhandenen Tests auf der Klient- und Serverseite, welche randomisierte Testereignisse verwenden wurden modifiziert, so dass nun pseudo-randomisierte Testereignisse verwendet werden.

Es wird nun eine Datei erzeugt, in der vor dem Test randomisierte Zeichenketten abgelegt werden. Diese Datei liefert für die Testläufe die Testdaten zeilenweise. So kann das Scheitern eines Testlaufs direkt auf die entsprechenden Testdaten zurückgeführt werden.

Des Weiteren habe ich nun auch mit den sogenannten Stresstests begonnen. Das Ziel dieser Tests ist es, ein Profil des von mir gewählten Übertragungsverfahrens (serialiserte Objekte über Sockets) zu ermitteln. Die Idee ist, Testereignisse unterschiedlicher Größe, von einem Testsensor zu einem Mock-ECG-Server gesendet und die Übertragungszeit zu messen. Bei ersten Messungen zeigte sich allerdings eine unerwartete Konstanz und Unabhängigkeit der gemessenen Zeiten gegenüber den Größen der übertragenen Daten.

Ziel der nächsten Woche

  • Stresstest durchdenken und überarbeiten
  • Ordentliche Sensorimplementierung

Eintrag 17

kurz vor dem Urlaubsantritt habe ich nun noch ein neues Release (v0.6) auf den berlios server (www.electrocodeogram.org) gestellt.

Da die Zeit gerade knapp ist folgen nun die wesentlichen Änderungen/Neuerungen in Stichpunkten

  • Neue konsistente Ordnerstruktur
  • Neue ANT Skripte mit single-click build des ganzen ECG (incl. Sensoren, Server, Module) im Projekt ECG Build
  • Komplettes JavaDoc bis auf protected level runter.
  • Sourcen sind nun (nearly) "findBugs" appproaved
  • Es existiert nun eine sehr saubere HackyStat EclipseSensor Erweiterung zum ECG EclipseSensor
  • Das MicroSensorDataType Managment ist im Kopf fertig smile und die Implementierung wurde begonnen. (Wird ganz toll…)
  • Die Tests für die wesentlichen Komponenten sind mit im Release.
  • Tests zur Verbindung sind fast fertig implementiert.

Ziel der nächsten zwei Woche

  • Urlaub

Eintrag 18

In meiner ersten Woche nach dem Urlaub habe ich nun das Mikroprozessereignis-Management entworfen und implementiert. Zuerst einmal habe ich einen anderen Namen für diesen Bestandteil des ECG gefunden: MicroSensorDataTypes. Wie die SensorDataTypes in HackyStat die Typen der Makroereignisse sind, so sind die MicroSensorDataTypes die Typen der Mikroereignisse des ECG.

Das ECG benutzt bekanntermaßen viele Teile des HackyStat Frameworks als Unterbau, so sind auch die MicroSensorDataTypes eine Unterklasse der SensorDataTypes. Genauer: Alle ECG MicroSensorDataType Ereignisse sind HackyStat "Activity" Ereignisse.

Ein HackyStat "Activity" Ereignis repräsentiert irgend eine aufgezeichnete Aktivität und besitzt einen "Activity-Type-String" zur Klassifizierung der Aktivität und einen "data-String", der noch zusätzliche Details der Aktivität angeben kann.

Bei einem Ereignis, dass einem ECG MicroSensorDataType entpricht ist der "Activity-Type" auf den Wert "MicroActivity" gesetzt. Der "data-String" enthält eine Zeichenkette, die die eigentliche "MicroActivity" beschreibt. Diese Zeichenkette ist ein XML String, der einem der definierten XML Schemata, den MicroSensorDataTypes, entspricht.

Es gibt dabei im ECG integrierte MicroSensorDataType XML Schemata, wie Codechange, Resource, Window oder Rundebug. Außerdem können die Module, die in das ECG hineingeladen werden können noch eigene MicroSensorDataType XML Schemata definieren, die dann z.B. die Ausgabeereignisse des jeweiligen Moduls definieren.

Die Validierung eines eingehenden Ereignisses erfolgt dann zuerst über die HackyStat Mittel und, falls es sich um eine "MicroActivity" handelt, wird die XML Zeichenkette der "MicroActivity" gegen alle bekannten MicroSensorDataType XML Schemata validiert.

Nur, wenn es sich bei dem Ereignis um ein gültiges HackyStat "Activity" Ereignis mit dem "Activity-Type" "MicroActivity" handelt und der XML String nicht nur "well-formed" sondern auch "valid" ist, wird das Ereignis vom ECG akzeptiert.

Für die MicroSensorDataTypes sind auch automatisierte Tests implementiert. Außerdem ist der ECG EclipseSensor auf die Benutzung der MicroSensorDataTypes hin aktualisiert worden.

Ziel der nächsten Woche

  • Bau einiger Module und Verbesserungen im ModulFramework.

Eintrag 19

Durch den exemplarischen Bau einiger Module habe ich die Mdoule-API des ECG esentlich verbessert. Zum einen wurde die Benutzbarkeit und Klarheit gesteigert und zum Anderen wurden Möglichkeiten zur Fehlbenutzung eliminiert.

Zu den implementierten Modulen gehören der bereits bekannte FileWriter, der Ereignisse in Textdateien schreibt, ein FileReader, der Ereignisse aus Textdateien wieder einliest. Ein FilterModul, dass in der Lage ist, Ereignisse anhand ihres MicroSensorDataType zu filtern und in ansätzen ein CodechangeDiffer, der einen eigenen neuen MicroSensorDataType mitbringt.

Auch das Laden der Module mittels des ECG ModuleClassLoader wurde von einigen Fehlern befreit und ist durch ein Dutzend Testfälle abgeklopft worden.

Ziel der nächsten Woche

  • Durch eine Schulung werde ich in der nächsten oche kaum Zeit für das ECG finden. Danach aber umso mehr !

Aktuelle Zeitplanung

Zeitplanung

Kommentare