Page ThesisTrialErrorStatus
Dieses ist meine persönliche Seite zum Thema Trial&Error; mein Blog.Hier lassen sich meine täglichen/wöchentlichen Berichte und erzielten Fortschritte begutachten.
Zusätzlich werde ich wichtige Links und Erkenntnisse in diesem Bereich abspeichern.
Hier eine Erklärung meiner Vorgehensweise.
Wer ich bin? → Hannes Restel
aktuelle Arbeiten
Letzte Woche:
- Arbeit abschließen
Diese Woche:
- "Systemtest" meiner Arbeit
- Abgabe der Arbeit
Blog
Hier finden sich meine wöchentlichen Berichte und Fortschritte
24.08.2006
Die Arbeit endlich ist eingereicht.Vielen Dank an meine Rechtschreibkorrektoren!
16.08.2006
Die Bachelorarbeit ist (so gut wie) fertig! Ich hoffe, sie noch diese Woche abgeben zu können.Es fehlen noch einige Durchsichten insbesondere im Hinblick auf die Rächtschreibungk.
Der Eventviewer ist so angepasst, dass es nun zwei Fenster gibt: Eines für das Video und eines als Kontrollfenster.
04.08.2006
Die letzen 1 1/2 Wochen habe ich mich dem Kern der Arbeit gewidmet, der Formalisierung der Episoden.Dazu musste ich mir viele Gedanken darüber machen, wie ich die mir zur Verfügung stehenden Instrumente - ALED, ECG und den Stellen-Erkenner - kombinieren und einsetzen kann:
- Mit der Hilfe von Sebastians Stellen-Erkenner (ich habe immer noch keinen vernünftigen Namen für dieses Modul..) habe ich so genannte Hierarchien von Codestellen sowie der Verwandtschaft von Codestellen definiert. Ob eine Stelle für eine T&E-Episode noch relevant ist wird nun anhand des "Verwandtschaftsgrades" erkannt.
Dieses Konzept ist sehr allgemein, so dass es für das Erkennen vieler Episoden eingesetzt werden kann, nicht nur für das Erkennen von Trial&Error-Episoden. - Ich habe die ALED-Syntax um einige Konstrukte erweitert, so dass niedergeschriebende Formalisierungen nun weniger schreibintensiv und weniger fehleranfällig sind. Ausserdem werden nun die Nichtindikatoren und Abbruchindikatoren sowie das Ende einer Episode beinahe "magisch" erkannt.. Anhand der Parameter des Startindikators werden alle folgenden Ereignisse auf bestimmte Art und Weise gefiltert, so dass bereits vor Eintreten eines Ereignisses in den Erkenner entschieden wird, ob dieses Ereignis für den Erkenner relevant ist oder nicht.
- Ich musste das von mir beschriebene theoretische Konzept der Pufferung der letzten x Ereignisse fallen lassen, da es in ALED nicht vorgesehen ist. Daraus folgte, dass es keine Startindikatoren mehr gibt, sondern jeder Erkenner bei jedem Auftreten eines codechange-Ereignisses gestartet wird.
- Erkenner können selbst hierarchisch aufgebaut sein. Auf die Praxis bezogen bedeutet dies, dass ein Erkenner Ereignisse voraussetzt, welche erst von einem vorherigen Episodenerkenner generiert werden müssen.
21.07.2006
Heute habe ich zwei weitere Beobachtungen durchgeführt - eine davon mit Videomitschnitt: Eine Beobachtung war sehr erfolgreiche und die andere nicht. Frei nach Murphy's Law war es selbstverständlich die wenig erfolgreiche Beobachtung, bei welcher ich das ScreenCapturing-Tool installieren konnte! Das ist insofern schade, als dass ich so zwei wesentliche Arten von Trial-Error-Episoden zwar beobachten, nicht jedoch archivieren konnte! 
Zudem fand am Freitag eine weitere Besprechung mit Sebastian statt.
19.07.2006
In der letzen Woche war kein übermäßiger Fortschritt zu verzeichnen, da ich für die letzte Klausur meines Bachelor-Lebens gelernt und diese auch geschrieben habe.Ansonsten habe ich endlich die erste Iteration abgegeben und Anmerkungen von Sebastian bekommen. Diese werde ich in den nächsten Tagen berücksichtigen und die Fassung überarbeiten.
Gleichzeitig werde ich die Ausformulierung des zweiten Abschnitts - des Praxisteils - fortführen. Formal ausformulierte Episoden habe ich immer noch nicht..
Durch eine intensive Auseinandersetzung mit der "ALED"-Syntax (vormals "TUMAS") von Christian habe ich genaue Vorstellungen davon gewonnen, wie T&E-Episoden zu formulieren sind. Momentan sieht ALED jedoch beispielsweise keinen Puffer vor, welcher die letzten x Ereignisse speichert. Nach meinem momentanen Erkenntnisstand bin ich jedoch auf diesen Puffer angewiesen; Ich werde ALED also erweitern (bzw. personalisieren) müssen.
Ausserdem ist es in ALED sehr viel günstiger (wenn nicht sogar Voraussetzung), dass ich das theoretische Konzept der Startindikatoren (also ein run/debug-Ereignis) verwerfen muss und bei jedem Auftreten eines Codechanges einen Episodenerkenner starten lassen werde. Dies ist notwendig, damit ich mehrere Erkenner gleichzeitig laufen lassen kann (bzw. mehrere Wege des Ereignisbaumes verfolgen kann). Um das Problem der kleineren Folgeepisoden einer sehr langen T&E-Episode lösen zu können (diese sollen nämlich nicht erkannt werden), werde ich mich wahrscheinlich gezwungen sehen, hinter meine erkannten Episoden noch einen weiteren Episodenerkenner zu schalten, welcher diese Episoden zu einer großen Episode zusammenfassen.
Sebastian hat mich darauf hingewiesen, dass Episoden ein Anfang und vor allem ein Ende besitzen. Momentan lasse ich jedoch nur den Beginn einer Episode erkennen und nicht das Ende. In diesem Punkt muss ich nachbessern.
Auch das Auftreten von false positives (fälschlicherweise als T&E erkannte Episoden) muss ich noch berücksichtigen.
Herr Prof. Schulte hat sich prinzipiell bereit erklärt, die Zweitkorrektur für meine und Christian Kopfs Arbeiten zu übernehmen. Als wahrscheinliche Termine für die Vorstellung der Arbeiten gelten der 21.09. oder der 28.09. während des BSE-Seminars.
Die Abgabe der Bachelorarbeit ist aufgrund meiner Krankheit vor ein paar Wochen offiziell um zwei Wochen auf Mitte August verschoben worden.
08.07.2006
Die erste Ausformulierung der Arbeit macht gute Fortschritte, ich bin zuversichtlich, Seba am Dienstag die Version zukommen lassen zu können.Die Theorie der Episoden ist leider noch komplexer geworden: Bisher ging ich davon aus, dass eine T&E-Episode erst mit Ausführen des Programms - also mit Auftreten eines Startindikator - beginnen kann. Diese harte Grenze musste ich jedoch erweitern, da es in einigen (oder sogar in den meisten Fällen??) sehr wichtig ist zu wissen, welche Tätigkeiten der Entwickler bereits vor Eintreten eines Startindikators vollführt hat. Ansonsten liegen einem Episodenerkenner zu wenig Informationen vor, um Episoden sicher erkennen zu können.
Ich habe mir die erste Version von Christians Arbeit zum Episoden-Erkenner-Framework durchgelesen und die von Christian vorgeschlagene Syntax einigermaßen verstanden. Ich kann jedoch noch nicht einschätzen, inwieweit sie mir dienlich sein kann: Christians Syntax - noch TUMAS genannt - ist zwar "turing-mächtig" aber er erscheint mit zunächst einmal so, als sei eine Formulierung von komplexeren Episoden sehr umfangreich und durchaus schwierig realisierbar.
In einem der früheren Wochenberichte habe ich von einem Modul gesprochen, welches Seba momentan entwickelt. Dieses Modul hat er mir nun kurz gezeigt: Es handelt sich um einen Algorithmus, der zusammengehörige Blöcke von Programmcode erkennt und die Evolution dieser Blöcke über die Zeit hinweg verfolgt. Ich benötige zwar Zeilenniveau - also noch eine Stufe genauer als es Sebas Block-Algorithmus vermag - aber diese Stufe der Granularität ist sehr viel exakter, als alles, was mir vorher zur Verfügung stand.
Allerdings wird es wieder sehr komplex sein, Christians Syntax mit Sebas Blockerkenner mit meinen Episodenregeln zu verweben… Wie genau das aussehen kann, vermag ich noch nicht zu sagen.
Um nicht in Zeitnot zu geraten, werde ich eine Verlängerung der Bachelorarbeit um eine Woche beantragen und somit meine Erkrankung ausgleichen.
28.06.2006
Seit dem letzten Eintrag sind mehr als zwei Wochen vergangen. Dies ist darin begründet, dass ich die letzen eineinhalb Wochen mit einer schweren Magen-Darm-Infektion krank im Bett verbracht habe und mich nicht in der Lage gesehen habe, irgendetwas für die Universität zu tun.Bereits vor meinem Krankwerden habe ich begonnen, eine erste Fassung (ich nenne sie Iteration) der schriftlichen Ausarbeitung zu verfassen. Dies nimmt viel Zeit in Anspruch, da ich bereits entsprechende Screenshots erstelle sowie die Entwicklervideos auf die relevanten Ausschnitte zusammenschneide.
Des Weiteren habe ich eine Website vom Eventviewer erzeugt (hier einsehbar).
Der Eventviewer hat einige Weiterentwicklung erfahren. Zudem konnte ich Probleme mit dem JavaMediaFramework (JME) identifiizieren, was dazu geführt hat, dass sich viele Videos - insbedondere DivX und Xvid - nicht abspielen ließen. Der Grund dafür ist, dass das JME ausschließlich FourCC-Code des Typs "DIVX" akzeptiert. Sämtliche Videos müssen also auf diesen Code eingestellt werden, möchte man sie mit dem EventViewer nutzen.
Bereits am 16.06. habe ich eine Beobachtung durchgeführt, welche zwar nur eine Stunde dauerte aber einige sehr wertvolle Informationen lieferte. Da ich dieses mal einen ScreenCaputerer laufen lassen konnte, werden Ausschnitte aus dem Mitschnitt definitiv ihren Platz in der schriftlichen Ausarbeitung meiner Arbeit finden.
07.06.2006
Nach einer weiteren Besprechung mit Sebastian Jektusch ende letzter Woche hat sich folgende Vorgehensweise ergeben: Ich werde die vorläufige Anforderungsbeschreibung verfassen sowie eine erste Ausformulierung der bisher von mir gewonnenen Erkenntnisse.Bei der Besprechung wurde noch einmal die Komplexität der Implementierung eines Trial&Error-Phasenerkenners festgestellt, welche sich insbesondere aus der Schwierigkeit heraus ergibt, dass eine Granularität auf Zeichenniveau zur optimalen Bestimmung von T&E-Episoden notwendig ist. Die bisher durch das ECG und die Eclipse-Ereignisse gelieferten Ereignisse sind zeilen- bzw. blockbasiert und deshalb zu ungenau. Sebastian ist jedoch momentan dabei, ein Programm zu entwickeln, welches einiges vereinfacht. Dennoch wird sich mein Erkenner auf einige Episoden beschränken müssen, welche der groben Granularität Rechnung tragen und folglich sehr viel ungenauer sein werden, als die Theorie es zu ließe.
Wahrscheinlich jedoch werde ich keine genaue Implementierung in Form eines ausformulierten Java-Programms abgeben können, sondern nur eine sehr genaue Spezifkation von T&E-Episoden - beispielsweise in der Syntax des von ChristianKopf formulierten Schemas.
Eine weitere Beobachtung am Montag von LuisQuintela hat leider wenig Neues ergeben, da er sich in einer Phase seines Projekts befindet, in welcher er eine neue API kennen lernen und verstehen muss (nämlich Qt unter C++ und KDE) und deshalb ausschließlich nicht-semantische Episoden zu beobachten waren. Abgesehen davon habe ich bei der Beobachtung sehr viel über C, C++, Qt und gelernt!
Ich habe begonnen, ein Programm in Java zu entwickeln, welches ich den EventViewer nenne. Es soll aufgezeichnete Episoden und das dazugehörige Video derart verbinden, dass durch Anklicken einer belibiegen Episode zur korrespondierenden Position im Video gesprungen wird. Ein einfaches und effizientes Navigieren zwischen den einzelnen Episoden steht dabei im Vordergrund. Ein Sreenshot des bisher Programmierten lässt sich unten finden.
Da dies mein erstes Projekt mit dem Swing-Framework in Java ist (ja mein erstes Grafikprojekt in Java überhaupt) und ich ausserdem das JavaMediaFramework (JMF) zum Abspielen der Videos verwenden muss, ist die Einarbeitung recht mühsam.
Ich habe es bisher geschafft, eine zwar wohlüberlegte aber leider nicht sehr ansprechend aussehende Oberfläche zu gestalten, Videos beinahe aller beliebigen Codecs abspielen zu können und einige der Videosteuerungsfunktionen zu implementieren. Nun fehlt noch die Kombinationen von Episoden und Video…
29.05.2006
Ein erstes Interview plus Beobachtung eines Berufsprogrammierers (Christoph Kunze) am vergangenen Dienstag hat leider die Erwartungen nicht erfüllt. Die Beobachtung währte einen gesamten Arbeitstag, also etwa acht Stunden und das Gebiet war die Programmierung von Webseiten unter Verwendung von DatenbankManagementsystemen. Während des Zeitraums konnte ich nur einen einzigen Fall einer der von mir selbst aufgestellten semantischen T&E-Episoden erkennen, wenngleich - nach Aussage von Christoph - die anderen formulierten Episoden ebenfalls durchaus schlüssig und anwendungsnah erscheinen.
Häufiger ließen sich dagegen sehr triviale semantische T&E-Episoden in der Form Ausführen→Korrigieren→Ausführen-Korrigieren→Ausführen finden, deren Implementierung in einem Episodenerkenner wohl relativ simpel wäre. Auch hier ist die Unterscheidung in Trial&Error und systematischem Programmieren nur schwer zu erkennen. In jedem Fall jedoch war es Christoph bewusst, dass er gerade etwas probierte, also T&E verwendet. Nach eigenen Worten verwendet Christoph ohnehin sehr wenig semantisches T&E, und wenn doch dann geplant (z.B. als neuen Branch des Programms, welcher vor Wiedereingliederung erst getestet wird). Meist programmierte er etwas, führte das Programm aus, welches sofort das gewünschte Verhalten erzielte. Ich nenne diesen Vorgang Trial&Success (bzw. Versuch&Erfolg).
Auffällig waren auch die sehr langen Testphasen, welche Christoph seinen programmierten Webseiten unterwarf. Die Idee, einen "Timeout" zwischen den einzelnen Schritten einer T&E-Episode zu setzen, ab dem die Episode wegen des zu großen Zeitabstands verworfen wird, ist deshalb fragwürdig. Der Zeitabshnitt zwischen einem Ausführen des Programms und seiner Korrektur betrug bei Christoph wenige Sekunden bis etwa 12 Minuten.
Wie erwartet traten nicht-semantische T&E-Episoden auch bei einem Berufsprogrammierer oft auf (insbesondere das Schliessen mehrerer Klammern sowie eine falsch verwendete Syntax (beispielsweise length() anstatt size()).
Auch ließen sich einige sehr ausgeprägte und interessante - wenn auch für mich irrelevante Episoden - bei der Benutzung einer dem Probanden kaum bekannten GUI beobachten. Eine weitere nur für Sofoklis interessante Beobachtung ist das beinahe handwerkliche und äußerst ausgiebige Arbeiten mit Copy&Paste-Episoden.
Da Christoph mir erklärte, dass der von ihm während meiner Beobachtung programmierte Code "Routine" ist, werde ich erneut in seinem Unternehmen vorbeischauen, wenn er etwas komplexeres programmiert.
Bei weiteren Überlegungen zu mögliche T&E-Episoden bin auf einige beunruhigende (d.h. schwer implementierbare, zeitintensive) Szenarien gekommen.Hier ein Beispiel mit anschließender Erläuterung:
_rundebug→change A→rundebug→change A→rundebug→change B→rundebug→ Erfolg!_
Der Programmierer glaubt also, dass sich der Fehler im Codeabschnitt A befindet, wenngleich der Fehler im Abschnitt B liegt. Nach einigen Versuchen erkennt er dies, und ändert B einmalig.
Problem: Die Änderungen an A sind keine T&E-Episode, da sie den Fehler nicht erfolgreich behoben haben und die Änderung in B lässt sich für sich allein gestellt nicht als T&E identifizieren.
Es müssen also Codeabhängigkeiten zwischen zwei oder mehreren Codeabschnitten zur Identifizierung herangezogen werden. Ich stelle mir vor, dass eine Implementierung mit diesem "semantisches Erkennen" sehr schwierig und komplex ist. Andererseit könnte die plötzliche Einsicht, dass der Fehler in B liegt darin begründet sein, dass der Programmierer dem Code mit Hilfe seiner Entwicklungsumgebung einer Sichtung unterworfen hat, also bewusst nach Fehlern suchte und damit kein T&E mehr durchführt. Auch hier ist die Entscheidungsfindung, ob T&E vorliegt alles andere als trivial.
22.05.2006
Meine Präsentation hat einige Ergebnisse zu Tage gefördert. Nicht nur, dass meine Folien zu lila waren :-), sondern auc h einige andere Schwierigkeiten sind hervor getreten: Es ist sehr viel schwieriger, gefundene semantische T&E-Episoden (sollte ich diese in Zukunft mit "sTEE" abkürzen?) in einen Episodenerkenner zu implementieren, als ich dachte. Die Schwierigkeit liegt darin, dass die sehr begrenzten zur Verfügung stehenden Daten nicht ausreichend sind um zu erkennen, ob ein Benutzer tatsächlich gerade eine T&E-Episode vollführt hat, oder ob es sich um einen wohlüberlegten, geplanten (und deshalb bewussten) Vorgang gehandelt hat. Ein Mensch könnte dies vielleicht erkannt haben, da er sich in die Lage des Programmierers hineinzuversetzen vermag und die der Codierung hinterstehende Semantik erkennt, einem Computer ist dies jedoch verwehrt.. Man müsste also ein Programm schreiben, welches Semantik erkennt. Dies ist natürlich nicht möglich, und wahrscheinlich sehe ich alles momentan auch viel zu pessimistisch. Da ich noch keine genauen Vorstellungen konkreter semantischer T&E-Episoden habe, kann ich deshalb keine genaueren Aussagen treffen. Am Montag nachmittag setze ich mich mit Christian zusammen und wir werden gemeinsam einige simplere Episoden erdenken, also auch nicht-T&E-Episoden. Hoffentlich kann ich so ein Gespür für die Spezifikation von Episoden entwickeln.
Am Dienstag werde ich eine erste Beobachtung durchführen. Davon erhoffe ich mir erste Erkenntnisse, wie sich T&E-Episoden und "normale" Programmiervorgänge differenzieren lassen. Auch wenn in meiner B.Sc.Arbeit keinen Wert auf nicht-semantische Episoden gelegt wird, so werde ich diese trotzdem mit protokollieren, was keinen wirklichen Mehraufwand bedeutet. Möglicherweise ergeben sich auch daraus schöne Rückschlüsse. Diesen Dienstag werde ich deshalb keine Zeit finden, den Leuten beim Programmierwettbewerb zuschauen zu können, aber vielleicht nächste Woche… Eine Rücksprache mit Christopher wäre in diesem Punkt angebracht.
17.05.2006
Diese Woche habe ich die Präsentation meiner Bachelorarbeit vorbereitet und werde sie am Donnerstag halten.
Letzten Freitag fand ein Treffen mit Sebastian statt, in welchem wir den Rahmen der Bachelorarbeit genauer definierten.
Der Schwerpunkt ist nun die Ausarbeitung und Spezifikation von semantischen Trial&Error Episoden. Dieses sind Episoden, welche erst ab dem Zeitpunkt eintreten, zu dem das Programm kompilierbar wird, also keine "syntaktischen" Fehler mehr enthält.
Eine Semantische T&E-Episode ist eine Phase des Programmierens, in welcher der Programmierer die inhaltlichen Fehler seines Programms entfernt/versucht zu entfernen, wobei er aber keine wohlüberlegten Codeänderungen tätigt, sondern den Code wild abändert und so lange probiert und rätselt, bis alle Fehler beseitigt zu sein scheinen.
Als Artefakte der letzten Wochen habe ich ausserdem zwei Dokumente veröffentlicht, welche mehr oder weniger sortiert meine ersten Gedanken darlegen.
25.04.2006
Erstellen dieser Website.
Glossar
Das Glossar befindet sich hier.Links
wichtige Links
- Homepage der Arbeit und Archiv der Artefakte
- Das Glossar befindet sich hier
- Seite des EventViewers
- Seite der Videomaterialien
