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.¹

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 do²

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:

current status, especially wrt. one's one time plan
encountered or forseen problems
potential delays
(justified) requests for additions/changes ...to other groups
to comment on errors reported in one's own package, how they will be dealt with/have been dealt with, ...

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

Makefile: each package, i.e., the root of the respective sub-directory must containt a Makefile. Its first target must be make all, which generates for the packges the Java byte code (whatever it takes in intermediate steps). Additionally, a target make clean must be supported, which removes the byte-code and all temporary files again. An example for a workable Makefile is contained in the absynt-package which covers the (very simple) needs just described.
Documentation: the Java-code should be meaningfully commented and documented. Information about the implementations which are relevant for the co-developers, are done in javadoc. This especially applies to the intended meaning and usage of the public interfaces between the packages. Part of the documentation should be the name of the developer(s) and the version of the file. Further useful information could be the status of the method, class, ..., e.g., whether the implementation currently is only available as stub, whether the functionality is finished, but not yet tested, which are the known bugs/features ....

The javadoc-comments may serve the internal communication to state what the package offers (and what it assumes). The generated web-pages are available via the project page, they are refreshed from time to time, and kept here.

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 L^AT_EX by H^EV^EA.

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