[Technical Faculty]


Sequential Function Charts Modeling Environment (aka. Slime)



Review

Date of the final review, demo, and debriefing is fixed to

18.07.2002, 17:00


Karsten Stahl, Martin Steffen overview
Andreas Niemann editor
Marco Wendel parser
Immo Grabe simulator
Karsten Stahl, Martin Steffen checks

Table 1: Presentations


Java-doc

For convenient lookup for those who like javadoc, the public documentation and comments are avaiable here. The pages are refreshed from time to time, especially after larger development steps.

documentation Slime: currently (July 19, 2002): last-minute ``integrated'' tool

Snapshots

The baselines or snapshots are archived here for quick reference as slime_v[x].jar, where [x] is the number or the tag of the snapshot. Developers with access to the source repository can retrieve those snapshots of course with cvs.1

To execute one of the archived snapshots, save it at some convenient place, set the CLASSPATH (or use the -classpath option) of java) to include the saved jar-file + the required versions of JLex and java_cup, and do2

java <slimeversion>.jar slime.Main

The required version is jdk1.4, earlier version may cause trouble, later ones are not tested.

 
  archive/date explanation command
6. 19. July 2002 last-minute ``integration'', end-of-semester, a bit cleaned up java -jar slime_v5.jar
4., 5. 18. July 2002 obsolete,  
3. 10. July 2002 snapshot 3: compiles, but not integrated java -jar slime_v3.jar
2. 9. July 2002 second compilation (separately) java slime.editor.EditorInFrame
1. 3. July 2002 first compilation (separately), all packages on board java slime.editor.EditorInFrame

The last version is slime_v5.jar. It could be that the ``last-minute-integration'' version was a file slime_v6.jar, which seems no longer available, but it's unclear. It can also be that version 5 has been ``reused'' for the latest one (replacing the obsolete version 5 from the day before).

Requirement specification

The following list contains the requirement specification (``Pflichtenheft''). The top-most entry is the current one

4.    Version 4      10. July 2002      sync' spec with the decisions/implementation
3.    Version 3      14. Juni 2002      small repairs in the spec
2.    version 2      26. April 2002      formal semantics added
1.    Version 1      22. April 2002      original proposal


Weekly meetings

This section contains the results of the weekly meetings as communicated via email to the group members. There are kept here for quick reference.

0.    9. April      no meeting this week, only email
1.    16. April      task assignment, change of meeting time
2.    24. April      no real decisions, preparation for next meeting
3.    1. May      holiday
4.    8. May      task presentation, status of editor group unclear, check group said ciao, restructuring planned
5.    15. May      no email?
6.    22. May      no email?
7.    29. May      no email
8.    5. June      makeshift parser under utilites added; first integration set to 12. June
9.    12. June      restructuring now (freeze)!, makeshift checks will be implemented (as visitor or otherwise), no integration (since code missing)
10.    19. June      no integration yet
11.    26. June      everyone on board; plan of final review; plan for last 3 weeks
12.    3. July      removal of additional checked in stuff + removal of class files.
13.    10. July      decisions about interface inconsistencies, making it compilable, preparing the integration
14.    17. July      no meeting

Organisatorial/procedural things discussed during the meeting at 3.7.02 included arguments mentioned here.

Time line

The project's duration is determined by the length of the summer term 2002. Start is April, 10th, the end is July, 17th. This gives nominally 14 weeks. Table 2 shows a overview over the planned milestones of the project.


week date goal
1. 16. April presentation of sfc's, potential task and packages, discussion of assignments, handouts, cvs-repos ready, presentation of cvs + development stratety
2. 23. April fixed task assignmens, proposal for interfaces, abstract syntax finished; technical nonsense solved (account, access, additional java packages ...). During the 2. and the 3. week: separate meetings or extra subgroup meetings to clarify tasks and goals (e.g. also for decision finding)
3. 30. April presentation of the packages by the developers (written plan with milestones expected problems, overlap/interaction with other packages ...)
  12. June first common compilation
  18. Juli final review, demo, debriefing

Table 2: Semester




The work in the course consists not only in producing code! Required is also active participation in the project, especially a weekly progress report of each groups, explicitely addressing the following points: A fixed date is the end of semester. It is important to realize in time if a goal turns out to be unrealistically ambitious or if other problems interfere with the goal. Furthermore it is important to addresse any of those problems or delays in the working meetings in an open manner, to asses the situation realistically and explain real or expected problems.3 Only in this way it is possible to react in time, for instance by redefinition of the goal, re-assignment of a task, cutting down the features .... Problems of this kind don't disappear by delaying counter measures, and trying not to mention problems leads to delay.

In the end, it is more important and satisfying to implement a well-defined, small set of features in a solid way than to incoporate tons of things which probably would work with additional one more month of time, or two.

Furthermore it is important, not to feel responsible for one's one package in isolation, but also for the group project, i.e., it's not a shame report on other packages' errors and, conversely, to react upon errors or purported errors reported by others. The error reports are kept in a separte file. For importantant announcements, error reports, or coordination messages, we have set up an email-list. It's address is
swprakt+slime@informatik.uni-kiel.de

Groups

Each developer or team is responsible (in general) for one Java-package. The requirements are described in the specification document. findet sich


package      responsible
gui/integration      Norbert Boeck
editor      Andreas Niemann
checks      Karsten Stahl, Martin Steffen
simulator      Immo Grabe
parser      Marco Wendel,
(layout)      Andreas Niemann
abstract syntax      all
utils      Karsten Stahl, Martin Steffen

Table 3:


The email adresses of the developers are available (internally) at
      $WORKDIR/Slime/org/packages.txt
For messages to the whole project, use swprakt+slime@informatik.uni-kiel.de.

Conventions and rules of the game

Besides the CVS-strategies which have been handed out and discussed, we should take care of the following:


1
The command is cvs update -r [tag]. Be careful with this command, don't generate development branches without knowing.
2
Since the archive is not stand-alone in that it requires additionally at run-time the lexer and the parser generator, the archive is not executable with the -jar option.
3
An often heard symptom of an unrealistic assessment of the situation goes like this: ``last 3 weeks, there was no progress, but that's not a problem, since I'm able to work 3 times as fast from now on.''

Pages last (re-)generated July 19, 2002
This document was translated from LATEX by HEVEA.