I-PROJVP-HOME

  1. Einleitung

  2. Vorgänge

  3. ToDos


I-PROJVP - Projekt Visuelle Programmierung am Beispiel des PlanetEarthsimulators
Zusammenfassung KW22

    Achtung : Skript gibt den mündlichen Vortrag nur teilweise wieder !!!
AUTHOR: Gerd Döben-Henisch
DATE OF FIRST GENERATION: March-19, 2004
DATE OF LAST CHANGE: May-31, 2004
EMAIL: doeben_at_fb2.fh-frankfurt.de



1. Einleitung

Dieses Dokument gibt nur einen summarischen Überblick über Materialien und Aktivitäten.


START



2. Vorgänge

Aus KW21 resultierte die Aufgabe eine möglichst einfache erste experimentelle Struktur für die gewünschten Editoreigenschaften zu finden.

Ferner sollte Florian St. ein spezielles Tutorial zu cvs am Beispiel unseres Projektes geben.

Das spezielle cvs-Tutorial musste aus organisatorischen Gründen nochmals um 1 Woche verschoben werden. Es findet jetzt am Do, 3.Juni statt.

Als Kandidaten für eine experimentelle Struktur konnte in der Teamsitzung ein erster Vorschlag auf der Basis einer Ausarbeitung von Axel B. (in Zusammenarbeit mit Fabian K. und Christian H.) ermittelt werden.

Über den Plugin-Mechanismus von eclipse kann man eine Klsse Manager aktivieren. Über diese wird eine Klasse data-engine und eine Klasse viewer gestartet. Die Klasse data-engine enthält die Datenstruktur für die zu bearbeitenden visuellen Objekte in Einklang mit der FSL-Spezifikation. In der Klasse viewer können vorhandene Objekte aufgerufen und modifiziert werden. Ein Manager könnte im Prinzip mehrere data-emgines und mehrere Viewer bedienen.



I-visprog-basisklassen

Klassendiagramm für minimalen visuellen Editor

Im Sequenzdiagramm wird eine erste einfache Variante der notwendigen Interaktion zwischen den Klassen Manager, data-engine und viewer dargestellt.

  1. run(): Über das Plugin kann eine Aktion gestartet werden, die den Manager aktiviert.


  2. start_data(), start_viewer(): Der Manager startet die data_engine und den viewer (oder später auch weitere Klassen).


  3. get_structure(): dann fordert der Manager von der data_engine die aktuell gültige Struktur an.


  4. reply_structure(): die data_engine antwortet mit der aktuell gueltigen Struktur (u.U. beschraenkt auf einen bestimmten Ausschnitt, sofern der Manager dies andeutet)


  5. get_input(): dann fragt der Managr den viewer ab, ob er einen Input von einem Benutzer hat (eventuell über Ereignisse).


  6. do_input(): Der viewer verarbeitet Benutzereingaben


  7. input_proposal(): die Benutzereingaben werden als Anforderung an die data_engine an den Mansager übermittelt


  8. process_input(): die data_engine übergibt den Änderungsvorschlag an die data_engine zur Überprüfung; ist die Änderung entsprechend den regeln des Datenmodells aktuell überhaupt möglich?


  9. feedback_input(status): die data_engine liefert mit 'status' einen boolschen Wett zurück.


  10. confirm_input(status): die Reaktion der data_engine wird über den Manager an den viewer weiter gereicht; entweder #true' oder 'false'; im Falle von true würde die Änderung sichtbar.


I-visprog-basismodell-sequenz

Sequenzdiagramm für minimalen visuellen Editor

Über den Befehl get_input() könnte der manager in eine Schleife eintreten.


START



3. ToDos

Für KW23 wurde beschlossen:

Das verschobene spezielles Tutorial von Florian St. zu cvs am Beispiel unseres Projektes nachholen.

Versuch einer ersten Implementierung der minimalen Editor-Sruktur (siehe oben). Es gab folgende Schwerpunktbildung:

  1. PlugIn-Rahmen: Axel B.


  2. data_engine: Fabian K.


  3. Benutzeroperationen im Viewer (root_system anzeigen; beliebig oft neue Systeme in bestehende Systeme einfügen): Team 1+2



START