Software Workshop Team Java 2004/5

What's new

A list of provisional marks may appear here after the last exams have been sat.

The deadline for all coding is 9:00am, 21 March. No code should be committed to CVS after that. The file for the final report and any electronic appendices may be submitted until 14:00 Thursday, 24 March.

See the demonstration schedule for your team. You may have to miss a lecture because of the demonstration (it is the same with final year project demonstrations).

See the team list for your team and demonstrator. (Updated on 26.1.)

The module

Slides for the first lecture

See also the Syllabus page for this module for prerequisites and Learning Outcomes.

Students will be randomly assigned to teams at the beginning of semester 2. Even before you have been assigned to a team, you could start working on the module by doing some essential and background reading (see books below).

Since this module does not have an exam (and hence does not require any revision), all the work takes place in the semester. It is therefore important to work on it steadily each week. If you do not begin work early enough, it may be impossible to catch up later in the semester.

You should also be aware that the final report is as important for the final mark as the demonstration, so that it is advisable to begin writing drafts fairly early.

Email and questions about the module

All routine mail about this module should be sent to teamjava@cs.bham.ac.uk. Please quote you team number, e.g. A1, in the subject line. Mail about Team Java not addressed to this address is not guaranteed to be answered. Mail sent to this address can be seen by the lecturer and demonstrators, but not by other students. In case of confidential issues that you do not wish demonstrators to see, the module lecturer can be mailed directly.

We will maintain a FAQ. Check it before you mail.

Weekly progress

All teams are required to make a brief progress report each week, and discuss it with their demonstrator. This is limited to one page of A4, must be word-processed, and should address the following:

What team meetings have taken place since the last report, and who attended them? There should be at least one planning meeting with the whole team attending.
What has been done since the last meeting? Have any milestones been reached?
What decisions have been taken on targets for next week?
Are there any problems that the team has to address, or that the demonstrator or the module lecturer should look at?

You can also show your demonstrator any other evidence that you are making steady progress and are managing yourselves well, such as minutes of team meetings, design sketches, drafts of sections of the final report, etc. You should also see these meetings with the demonstrator as a valuable opportunity to gain "feedback".

Inspections

The inspections are less formal than the final demonstration. You show and explain your prototype in a meeting with your demonstrator. It is recommended that you follow the same structure as that of the demonstration, so as to give you some practice. However, it is less important that everything works (it is only a prototype); rather, the main point is to gain feedback from your demonstrator.

Demonstration

The demonstration is part of the assessment of the module by the module examiner (and demonstrators). It is structured as follows:

The team must be prepared to check their code out of the CVS and build it at the start of the demonstration, so that we can be sure that what is demonstrated is identical to what has been submitted to the CVS.
The team gives a brief presentation of the software they have built.
All team members should participate in the presentation, concentrating on their responsibilities.
It may be useful to have additional visual aids, such as slides on a different computer, but this is optional.
Start with the features that work best (and are most robust) before covering more experimental things.
The examiner may then do some testing of your system.
The team should be ready to answer questions; all team members should have a working knowledge of the whole system, and detailed understanding of the parts they worked on.

Teamwork

Virtually all teams contain members of different programming and report writing ability. It is an essential part of team management that all members are given the opportunity to make a productive contribution to the best of their abilities. Teams need to document what they have done to assure this.

Nonetheless, there are usually some students in the module whose contribution to their team is problematic; if they refuse to contribute, the other team members will not be held responsible.

If there are problem members in your team, you should discuss the problems with your demonstrator. If a team member does not attend meetings or does no work on the allocated tasks, keep copies of email reminders and CC emails to teamjava@cs.bham.ac.uk as evidence. All students are required to read email sent to their departmental accounts, so that emailing is enough as a reminder, and you are not obliged to chase them up in other ways. On the other hand, if you believe that your team is making it difficult for you to contribute or is trying to exclude you, you should discuss this with your demonstrator or contact the module lecturer directly.

The project

The aim of this project is to develop a software engineering tool that helps the user in understanding large Java programs. It combines elements of syntax tree browsers and, more ambitiously, some program analysis. You will be given a Java parser that constructs the abstract syntax tree, which is an internal representation of a Java program suitable for manipulation by the computer. Your code will have to navigate this complex data structure (syntax tree walking), compute useful information about the program, and interactively display this information to the user. (More details are in the first lecture; see the slides).

You have considerable freedom in coming up with your own user requirements, as long as they are useful for the task described above. However, it is essential that you get a prototype with basic functionality working before you attempt anything more ambitious or experimental. You can gain higher marks if you achieve some original or advanced functionality, and showing initiative is generally good, but if you are planning anything unusual, you should first discuss it with your demonstrator.

Software process

The Software Process Model we are going to use in this module is Evolutionary Development (for more details, see Software Engineering texts, for instance Sommerville, Section 3.1.2, page 46ff). This means that you will first implement a prototype with basic functionality. The prototype should be ready for the inspection by the demonstrator; this is an opportunity to gain "feedback" (formative assessment). There is no mark for the prototype shown in the inspection. Thus the point is not to produce something that looks superficially impressive, but to learn as much as you can to make the final product as good as possible for the demonstration, which will determine part of the final mark.

The requirements and feasability for the second system will then be based on the experience with developing the first prototype. When you first start on this project, your idea of the requirements may well be quite imprecise (that is arguably closer to a real world situation than the Waterfall model). Ideally, your requirements should evolve as the project progresses, for two reasons:

Designing and implementing prototypes gives you a better idea of the problem, and of possible solutions;

you are faced with a situation that is quite similar to the intended application: there is a (relatively) large system, not just code you have written yourself. So you could aim for functionality that you would find useful for understanding large amounts of Java code.

ANTLR

The Java code will be parsed by a parser generated by ANTLR. See the ANTLR web site. You will not need to know how ANTLR does the parsing, but you will have to make sense of the resulting syntax tree.

See local documentation for ANTLR: setup notes and reference manual.

For more information on getting started with ANTLR, see what Chris has prepared.

CVS

CVS is a tool that allows a group of people to work on a software project whilst at the same time maintaining a master source code tree. CVS handles the versioning of code which allows developers to "roll back" to a previous known working tree, locate where and when bugs were introduced and keep track on who is working on what and when.

The CVS repository will be used as evidence in the assessment. If something is not in the repository, it is assumed not to exist. If you want to claim credit for some code, you should make sure you are the one who submits it to the repository. If you do not, your contribution will be more difficult to ascertain, and this may affect your mark.

CVS is an open-source implementation of an approach to team-based software engineering (two commercial software products are BitKeeper and Visual Sourcesafe) which is used extensively in the big wide world. This is all done using the simple command line tool cvs. CVS stands for Concurrent Versions System and can be found at http://www.cvshome.org/.

Assessment

The final report submission deadline is the final day of semester 2, Thursday 24 March. Two copies of the report should be handed in to the School Office, the procedure for handing in being the same as for final-year projects.

See the guidelines on the final report and details of the assessment criteria. Final marks will not be discussed.

Books

The first four chapters of this book are essential reading.
Kevin Lano, Jose Luiz Fiadeiro, and Luis Andrade:
Software Design using Java 2
Palgrave Macmillan, 2002
A standard reference for Software Engineering methodology is Ian Sommerville, Software Engineering (6th edition). The same book is widely used in other modules in the School.
For some background reading, Fred Brooks, The Mythical Man Month, is recommended. It is rather dated, not very technical, but very readable and full of insights. The tar pit has become a canonical metaphor.