Sequential Function Charts Modeling Tool (aka. Snot)

Pflichtenheft

Die folgende Liste enthält das Pflichtenheft. Der erste Eintrag ist jeweils der aktuelle.

5.	Version 5	1. Juli 2001	kleinere Fehler ausgebessert,
4.	Version 4	28. Mai 2001	Listen der abstr. Syntax reimplementiert. Vereinbarungen von letzter Woche eingetragen
3.	Version 3	17. Mai 2001	kleinere Änderungen, Teams eingetragen
2.	Version 2	5. Mai 2001	kleinere Änderungen an der Abstrakten Syntax, SMV-Teil ein wenig ausführlicher
1.	Version 1	2. Mai 2001	Originalversion zu Beginn

Zeitplan

Die Dauer des Projektes ist festgelegt durch die Dauer des Sommersemesters 2001: Beginn ist der 23. April, Ende der 27. Juli. Das sind rechnerisch 13. Wochen. Tabelle 1 stellt die geplanten Termine und Ziele für das Projekt zusammen.

Woche Datum Ziel

1. 23. April erste Grobspezifikation; erste Besprechung; cvs-Repositorium fertig

2. 30. April Modul- u. Gruppeneinteilung, technische Rahmenbedingungen klar (accounts, Zugriff, java etc.), Handouts durchgearbeitet, abstrakte Syntax funktionsfähig

3. 7. Mai klar(ere) Vorstellungen der gewählten Aufgabe, Gemeinschaftsbesprechung der Schnittstellen, eventl. Vorstellungen über Java-Spezifika der Library

4. 14. Mai erster (nicht funktionsfähiger) Integrations/Kompilationstest (``stubs'')

5. 22. Mai konkrete Schnittstellen (Java!) vorhanden, Integrations/Kompilationstest in dieser Woche

6. 29. Mai konkrete Schnittstellen (Java!!!) vorhanden, inklusive Exceptions!

7. 5. Juni Gruppenweises Vorstellen des Erreichten + Plan (siehe interne email)

14. 23. Juli Abschluß, Review-Treffen, Schlußdemo

Table 1: Semesterübersicht

Der wirklich feste Termin ist das Semesterende. Wichtiger noch als das sklavische Einhalten der sich vorgenommenen Termine und Ziele ist gegebenenfalls, rechtzeitig zu erkennen, daß ein Ziel sich als unrealistisch herausstellt und dies auch in den Besprechungen offen, begründet und realistisch¹ zur Sprache zu bringen, so daß man geeignet und rechtzeitig darauf reagieren kann, z.B., durch Redefinition der Ziele, Umlagern der Last oder ähnlichem. Wichtiger und am Ende des Projektes befriedigender, als viele Features ein bischen und wackelig realisiert zu haben ist es, eine sinnvolle, geringere Auswahl vollständig und sicher implementiert zu haben.

Arbeitsgruppen

Jedes der Teams bearbeitet i.d.R. ein Java-Paket. Die Beschreibung der Aufgabenstellung findet sich im Pflichtenheft.

Paket      Gruppe

Gui/Integration      Hans Theman, Ingo Schiller

Editor      Natalia Freudenberg, Andreas Lukosch

Checks      Tobias Pugatschov, Dimitri Schultheis

SMV-Backend      Tobias Kloss, Kevin Koeser

Simulator      Carsten Heine, Jörn Fiebelkorn

Table 2: Gruppeneinteilung

Die Mailadressen der Teilnehmner finden sich (intern) unter

      $WORKDIR/Snot/org/gruppen.txt

Baselines

Die Baselines sind hier zur schnelleren Referenz als Javaarchiv snot_v[x].jar festgehalten, wobei [x] die Nummber des Schnappschusses ist. Als Entwickler mit Zugriff auf das Quellcoderepositorium kann man die Entwicklungsschritte sie natürlich mittels cvs wieder zurückholen. Zum Ausführen der Archivs speichere man die Datei snot_v[x].jar an einen geeigneten Platz, und rufe

  java -classpath [geeigneter_platz]/snot_v[x].jar gui.Gui

auf; alternativ kann man auch fest

 export CLASSPATH=[geeigneter_platz]/snot_v[x].jar

setzen, dann kann man sich die option -classpath schenken.

3.	Baseline 3	Parser an Bord	1. Juli 2001
2.	Baseline 2	Simulator an Bord	13. Juni 2001
1.	Baseline 1	erste Gesamtkompilation	5. Juni 2001

HTML-Dokumentation

Zur schnelleren Orientierung wird die mit javadoc dokumentierte Implementierung im Netz bereitgestellt. Die Seiten werden bei größeren Entwicklungsschritten aufgefrischt.

Dokumentation Snot: momentan (April 15, 2002): teilfunktionsfähig, integriert. Parser hinzugefügt

Konventionen und Spielregeln

Neben den gesondert ausgeteilten und diskutierten CVS-Spielregeln sollen folgenden Dinge beachtet werden.

Makefile: jedes Paket, d.h. die Wurzel des entsprechenden Unterverzeichnisses soll ein Makefile enhalten. Als erstes Target muß make all unterstützt werden, welche für das Paket den Java Bytecode erzeugt. Daneben soll ein make clean unterstüzt werden, welches den byte-code und temporäre Dateien wieder entfernt. Ein einfaches Beispiel für ein passendes Makefile findet sich im Unterverzeichnis src/templates/.
Dokumentation: Der Java-Code soll sinnvoll kommentiert und dokumentiert werden. Für Information über die Implementierung, die für die Mit-Entwickler von Interesse ist, soll dies mittels javadoc geschehen. Dies betrifft insbesondere die Methoden, die zur Schnittstelle mit anderen Paketen gehören. Zur öffentlichen (aber projekt-interne) Dokumentation gehört auch der Name der Entwickler und die Version. Weitere sinnvolle Information kann den Status der Methode, Klasse, oder sonstigen Programmteils betreffen. Beispielsweise, ob die Implementierung noch virtuell ist (als stub), ob nur Teile der vereinbarten Funktionalität bereitstehen, ob die Funktionalität noch ungetested ist, ob Fehler bekannt sind eind.

Die javadoc-Kommentare dienen unter anderem zur internen Koordination, d.h. den anderen Gruppen Schnittstelle und Status des eigenen Paketes mitzuteilen. Die generierten Seiten werden in regelmäßigen Abständen in unserer Projektseite aktualisiert.

1: Ein oft gehörtes Symptom einer unrealistischen Lageeinschätzung geht ungefähr so: ``Wir sind die letzten drei Wochen nicht viel weiter gekommen, aber das ist kein Problem, denn von nun an werden wir dreimal so schnell arbeiten.''

Pages last (re-)generated April 15, 2002

This document was translated from L^AT_EX by H^EV^EA.