Stand der Dinge, Wochenberichte, Planung und Dokumente:
((Darlegung des derzeitigen Standes und der Absolvierten Arbeiten im Rahmen meiner Bachelorarbeit))
Wochenberichte:
0 Erste Einschätzung der Komplexität: (v)
Entwerfen einiger Beispielautomaten
Überlegungen über Eingabemöglichkeit bei späterer Nutzung
Erste Überlegungen zur Architektur
Komplexität möglicher Automaten sind beinahe keine Grenzen gesetzt (Paralellität, etc.)
=> Nötige Eingabemöglichkeiten müssen umfangreich sein.
Skriptsprachen und Ähnliches sind aufgrund der großen Zahl an Ereignissen und Attributen ungeeignet.
Konzeptidee Skriptsprache
noch keine konkreten Erkenntniss über Architektur oder Realisierungsmöglichkeit gefunden
0 Vorbereitungen: (v)
Überlegungen zur Architektur der Software und dem Eingabeformat für Automaten.
Überprüfung und -arbeitung der Entwürfe mit Hilfe von weiteren Beispielautomaten.
Problemanalysen
Erster Entwurf der Architektur,
zum Klassen- und Objektmodell. Eingabe von Automaten über das Erweitern von Klassen und implementieren abstrakter Methoden. Vorgehensweise geklärt: Erster unabhängige Rohimplementierung, dann funktionsreife und letztendlich Einbindung in den Datenfluss und das ECG, dabei schrittweise Erweiterung wünschenswerter Eigenschaften.
1 Erste Schritte: (teilweise v)
erste Rohimplementierung zur verdeutlichung der Überlegungen zur Architektur und den angestrebten Möglichkeiten des Moduls.
Suche nach geeigneten Bibliotheken für die Map-
MatchMap-Datenstrukturen
Einarbeitung und Einrichtung der Entwicklungsumgebung
- erste, grobe Rohimplementierung
- Suche nach Datenstrukturen bisher nicht erfolgreich
- neue Javakenntnisse (
StreamReader und -Writer; synchronizierung von
HashSet; Wann
HashSet, wann Vector, etc)
- erste Erfahrungen mit der ECG-Software
2 Vorstellung:
Weiterentwicklung der ersten Rohimplementierung (onPre~ und onPostTransition-Methoden) und dokumwentieren des Quellcodes;
tiefere Einarbeitung in die Automatentheorie, insbesondere Kellerautomaten und die Mächtigkeit von Automaten
Ausarbeitung des Vorstellungsvortrages
Vorstellungsvortrag und anschließende Diskussion
Überlegungen zum weiteren Vorgehen (go-left/go-right-decision-point)
leicht erweiterte und dokumentierte Rohimplementierung
Erkenntnisse über die Mächtigkeit von (unterschiedlichen) Automatenmodellen und regulären Ausdrücken (siehe auch Vorstellungsvortrag!)
Vorstellungsvortrag (in Form einer
OpenOffice-Präsentation)
bisheriger Entwurf nicht unproblematisch, da möglicher Episodenerkenner aus vielen unterschiedlichen Phasenerkennern bestehen kann -> umständliche Implementierung. (Andere Darstellung empfehlenswert?)
3 Beschreibungsmodelle von Epsioden:
Ausarbeitung einiger Episoden mit Anschließender Analyse ihrer Komplexität (->Anforderungen an die Beschreibungsmodelle)
Formulierung/Moddelierung der Beispiel-Episoden als erweiterter Automat (werden anforderungen abgedeckt?)
Entwurf einer eigenen Beschreibungssprache/Darstellung für Episoden und darauf basierende Formulierung der Beispiel-Episoden
Formulierung/Moddelierung der Beispiel-Episoden als reguläre(r) Ausdru(e)ck(e)
Für die Formulierung der Episoden als reguläre(r) Ausdru(e)ck(e) werden tiefergehende Kenntnisse von regulären Ausdrücken benötigt, die moddellierung gestaltet sich daher schwierig (neuer Aufgabenpunkt: tiefere Einarbeitung in reg. Ausdrücke !?)
Das Automatenmodell mit den gewählten Eweiterungen erfüllt die analysierten Anforderungen
Produkt: eigene Beschreibungs"sprache" für Epsioden
eigene Beschreibungssprache ist leicht verständlich und gut erlernbar (wenig Zeitaufwand)
Schwächen der eigenen Beschreibungssprache: starr, also nicht dynamisch ("in vertikaler Richtung"), Lösungsansatz via Kompositummuster (!?)
in Textform
hier im zweiten Abschnitt
4 Theoretische Ausarbeitung:
tiefere Einarbeitung in reguläre Ausdrücke
Formulierung der Beispiel-Episoden als reguläre(r) Ausdru(e)ck(e)
weitergehende Analyse der drei möglichen Beschreibungsmodelle
Anfertigung einer schriftlichen Ausarbeitung über sämtliche bisher erlangten theoretischen Erkenntnisse
Auswahl einer Darstellungsform für verstärktes Vorgehen
erste Überlegungen zur (programmier-)technischen Umsetzung der drei bisher gewählten Darstellungen
schriftliche Ausarbeitung über bisherige theoretische Erkenntnisse (demnächst im Netz, siehe unten)
Entscheidungen:
1.: weiteres Vorgehen für das Rhmenwerk unter zuhilfenahme des neu entwickelten Beschreibungsmechanismus;
2.: Umsetzung als Codegenerierer
5 Abbildung des neuen Beschreibungsmechanismus auf das Automatenmodell:
Regelerläuterung der neuen Schreibweise durch Abbildung der Regeln auf das Automatenmodell
Anpassung der bisherigen schriftlichen Ausarbeitung
erweiterte und überarbeitete schriftliche Ausarbeitung inkl. Regelerläuterung der eigenen Schreibweise
Formalisierung des neuen Beschreibungsmechanismus nach dem Beispiel anderer Programmiersprachen (teil 1)
Korrektur und Erweiterung der Ausarbeitung (teil 1)
-/- (da in dieser woche nur drei Tage für die Bachelorarbeit zur verfügung stehen ist erst in der folgenden Woche mit ergebnissen zu rechnen, ich werde mich beeilen)
7 Erweiterung des Beschreibungsmechanismus:
Überlegungen zu und Durchführungen von Erweiterung in ALED; Ideen: Alternativen/ODER-Verknüpfung einzelner Anweisungen bzw. Anweisungsblöcke, Sonderbefehle (ABORT, WAIT, NEW, THROW), Kopf- und Fußzeilen
erweiterte Spezifikation von ALED
8 Dokumentation und Feinschliff:
Ausformuliern, Anpassen und Schreiben der Kapitel: Java-ALED, Ausblicke und weiteres Vorgehen, Begriffserklärungen und Literaturverzeichniss
Überarbeiten der Ausarbeitung
Dokumentation des Rahmenwerkvorschlags
Abgabe an Rechtschreib-, Grammatik- und Ausdruckskorrektoren
fertige Ausarbeitung
9 Abgabe der Arbeit: (teilweise p) (AKTUELL)
Vollendung der Rechtschreib-, Grammatik- und Ausdruckskorrekturen
Abgabe der schriftlichen Ausarbeitung
Überarbeitung der TWiki-Seiten
Beginn der Arbeiten am Verteidigungsvortrag
erste Version des Verteidigungsvortrags
überarbeitete TWiki-Seiten
finale Version der schriftlichen Ausarbeitung
0 Ausarbeitung des Vortrags: (p)
Überarbeiten und Anpassen des Verteidigungsvortrags
Vortrag und Verteidigung
finale Version des Verteidigungsvortrags
(n) := Nacharbeitung (Diese Wochen werden nicht in die Arbeitszeit der BSc-Arbeit eingerechnet.)
(v) := Vorarbeitung (Diese Wochen werden nicht in die Arbeitszeit der BSc-Arbeit eingerechnet.)
Planung
diese Woche:
-/-
-/-
Vollendung der Rechtschreib-, Grammatik- und Ausdruckskorrekturen
Abgabe der schriftlichen Ausarbeitung
Überarbeitung der TWiki-Seiten
Beginn der Arbeiten am Verteidigungsvortrag
kommende Woche:
-/-
-/-
Überarbeiten und Anpassen des Verteidigungsvortrags
Vortrag und Verteidigung der Ergebnisse am 28.09.2006 ab 17:00h im Rahmen des
Seminars "Beiträge zum Software Engineering" (Termin-# 60) Raum SR 005 Takustarße 9 Berlin-Dahlem