Bachelorarbeit ThesisEpisodeRecognizerFramework

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)

• Handlungen:

Entwerfen einiger Beispielautomaten

Überlegungen über Eingabemöglichkeit bei späterer Nutzung

Erste Überlegungen zur Architektur

• Erkenntnisse:

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)

• Handlungen:

Überlegungen zur Architektur der Software und dem Eingabeformat für Automaten.

Überprüfung und -arbeitung der Entwürfe mit Hilfe von weiteren Beispielautomaten.

Problemanalysen

• Erkenntnisse:

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)

• Handlungen:

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

• Erkenntnisse/Produkte:

- 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:

• Handlungen:

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)

• Erkenntnisse/Produkte:

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:

• Handlung:

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)

• Erkenntnisse/Produkte:

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:

• Handlung:

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

• Erkenntnisse/Produkte:

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:

• Handlung:

Regelerläuterung der neuen Schreibweise durch Abbildung der Regeln auf das Automatenmodell

Anpassung der bisherigen schriftlichen Ausarbeitung

• Erkenntnisse/Produkte:

erweiterte und überarbeitete schriftliche Ausarbeitung inkl. Regelerläuterung der eigenen Schreibweise

6 Formalisierung des Beschreibungsmechanismus:

• Handlung:

Formalisierung des neuen Beschreibungsmechanismus nach dem Beispiel anderer Programmiersprachen (teil 1)

Korrektur und Erweiterung der Ausarbeitung (teil 1)

• Erkenntnisse/Produkte:

-/- (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:

• Handlung:

Ü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

• Erkenntnisse/Produkte:

erweiterte Spezifikation von ALED

8 Dokumentation und Feinschliff:

• Handlung:

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

• Erkenntnisse/Produkte:

fertige Ausarbeitung

9 Abgabe der Arbeit: (teilweise p) (AKTUELL)

• Handlung:

Vollendung der Rechtschreib-, Grammatik- und Ausdruckskorrekturen

Abgabe der schriftlichen Ausarbeitung

Überarbeitung der TWiki-Seiten

Beginn der Arbeiten am Verteidigungsvortrag

• Erkenntnisse/Produkte:

erste Version des Verteidigungsvortrags

überarbeitete TWiki-Seiten

finale Version der schriftlichen Ausarbeitung

0 Ausarbeitung des Vortrags: (p)

• Handlung:

Überarbeiten und Anpassen des Verteidigungsvortrags

Vortrag und Verteidigung

• Erkenntnisse/Produkte:

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:

• Einarbeitung:

-/-

• Konzeptarbeit/Entwurf:

-/-

• Entwicklung:

Vollendung der Rechtschreib-, Grammatik- und Ausdruckskorrekturen

Abgabe der schriftlichen Ausarbeitung

Überarbeitung der TWiki-Seiten

Beginn der Arbeiten am Verteidigungsvortrag

kommende Woche:

• Einarbeitung:

-/-

• Konzeptarbeit/Entwurf:

-/-

• Entwicklung:

Ü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

Commenting is disabled while not logged inPlease Login first, before submitting content.