Der Funktionsumfang des Prototyps ist so weit implementiert. Wir versuchen nun die Benutzerführung noch zu verbessern und die Exception, welche sporadisch von Eclipse geworfen werden zu analysieren und den Fehler zu beheben.
Die merkwürdigsten Exception sind wohl diejenigen, welche nur indirekt mit unserem Plugin zu tun haben und wir möchten daher an dieser Stelle all jene Exceptions auflisten, die wir noch genauer Analysieren werden:

- PerGen Exception
- Nullpointer auf diverse Objekte
- Resource is locked for modifications (bzw. auch resource tree is locked for modifications)

- Unitetests- Benutzerführung (Nur im Kontextmenu anzeigen was wichtig ist)- Import von Dateien (Refresh?)

Artefakte:

Abstract Deutsch
Abstract English
Plakat

Testing
Benutzerdokumentation
BA Dokumentation

Dies war der grösste Erfolg: Das bekannte “Out-of-sync”-Problem wurde heute gelöst und sollte in Zukunft keinen Ärger mehr machen.
Dies ist der wichtigste Beschluss: Es kann nur immer eine Add, Change, oder eine Remove Aktion auf das gleiche Element gemacht werden, die gleiche Aktion darf aber nochmals ausgeführt werden. Beispiel: Add Code und nach ein Change Code ist nicht möglich. Mann darf aber das Add Code nochmals ausführen, wenn man einen Fehler gemacht hat beim Eintippen.
Dies braucht noch ein paar “Hirnoperationen” mehr: Rename auf Field.
Dies muss bis nach Ostern imlementiert sein: Alle Commands ink. Review des alten BA-Codes (aber kein Rename auf Field). Auslagern von XML-Objekt-Search Methoden in PA-Code.
Projektstand: Aufgabenstellung der BA wurde bereits erfüllt, das vereinbarte Ziel verläuft nach Zeitplan, persönliche Ziele und Ideen können nicht implementiert werden.

Die Grundfunktionalität des Adaptlet-Visualizers ist nun implementiert. Einzig die Funktionalität des Adds scheint uns einige Schwierigkeiten zu bereiten. Wir müssen unseren Java-Parser umstellen, damit die “Add-Elemente” sofort geparst parsen werden und nicht erst mühsam in die interne Objekt-Struktur (XML-Baum) abgefüllt und dann geparst werden. In diesem Zusammenhang fehlt auch noch das Selektieren des betreffenden Elementes im Adaptlet Java Editor. Zum jetzigen Zeitpunkt wird beim Ausführung einer Aktion via Adaptlet Explorer, das selektierte Element nicht in den Adaptlet Java Editor übernommen.
Zusätzliche Features wie Diff der originalen Source und der Adaptieren, oder Filter auf den Adaptlet Explorer sind ebenfalls schon implementiert. Nun müssen wir den aktuellen Stand des Visualizers anschauen und allfällige Änderungen am Design und Funktionalität mit unserem BA-Betreuer besprechen. Bis zur Besprechung arbeiten wir an der BA-Dokumentation. Der Code wird momentan eingefroren.

In den letzten Tagen haben wir (besonders Marco) einen lauffähigen vertikalen Prototypen hergestellt, der es ermöglicht den Methodencode zu ändern. Heute haben wir es geschafft, dass wir Änderungen im XML auch wieder im Source sehen und umgekehrt. Sehr beeindruckend wenn mal etwas so tolles läuft. Beim beenden der Eclipse instanz über die erzeugende Instanz erhalten wir ein “OutOfSync” (Ich hoffe das hat so geheissen.) Müssen wir dran denken und später noch beheben. Zudem haben wir den BusinessObjekten (A…), die im AdaptletProjectExplorer angezeigt werden Decorators verpasst. Das sind in Eclipse kleine Überblend-Icons die einen bestimmten Status anzeigen können. Wir möchten diese Verwenden um anzuzeigen, das Elemente noch unverändert, verändert, inkludiert oder exkludiert vom Projekt sind. Funktioniert auch schon sehr gut über das AElement. Das AElement bildet ein Kernstück des gesamten Ablaufs.

Nach der Sitzung am Freitag habe ich die aktuelle Situation und den heutigen Erfahrungsstand für die BA-Dokumentation festgehalten (Dokumentation befindet sich auf GoogleDocs). Die Story-Cards habe ich ebenfalls so angepasst, dass sie die Besprechung am Freitag reflektieren. Daher besitzen nun die StoryCards auch noch ein Prio-Feld mit den, im Beitrag vom Freitag, genannten Werten. Wir sind nun ideal gewappnet um den Adpatlet-Visualizer zu implementieren.

Wir hatten heute eine Sitzung betreffend der Priorität von den Storycards. An erster Stelle stehen die Karten mit direkter Manipulation. Sprich alles was nötig ist, damit der Entwickler nicht mehr sieht das es eine Spezifikation ist. Weitere Stufen sind Managment-Tool nützliches, und Nice-To-Have Karten.

Der Startschuss zur Implementation des Adaptlet-Visualizers ist heute gefallen und bereits gab es einen ersten Implementation / Design-Entscheid.
Wir werden alle Eclipse spezifischen Klassen, welche normalerweise ein “I” -Interface haben, nicht einfach implementieren, sondern wir bauen einen Wrapper um die Implementations-Klasse des “I”-Interfaces. So ersparen wir uns viel Zeit und können trotzdem zusätzliche Funktionalität einer bestehenden Eclipse-Klasse hinzufügen.

Heute haben wir zuerst besprochen, was wir gemacht hatten. Insbesondere die Storycards, die Marco feinsäuberlich zusammengetragen hat. Eine gute Übersicht über Bevorstehendes. Es gibt viel zu tun und es kann nicht schaden bereits früh genug zu evaluieren, was nun Priorität hat und was nicht. Wir werden im Meeting morgen, dies noch genauer abklären. Zudem haben wir konzipiert, neue bisher weniger bedachte Gebiete diskutiert und über eine Realisierung gesprochen. Insbesondere der gesamte Kommunikationsfluss des Plugins. Dabei sind wir auf eine gute Lösung gestossen, die Kernkomponente möglichst umfangreich zu benutzen und dafür andere Tasks streichen zu können. Wenn es so funktioniert, definitiv eine Erleichterung. Es ist gut Verantwortung vom Framework zu nehmen, dessen genaue Machbarkeit nicht klar ist.