Project: Documentation¶

The target audience for the class project documentation is the team itself and the course personnel grading the project.

Each project needs to have a directory containing an up to date documentation of the project. This directory is named as Documentation.

As a whole, the documentation graded should contain:

A PDF-document under the Documentation directory.
The log information in teams’s remote repository.
Comments in the code created by the team. The Javadoc comments must be used to comment the classes and interfaces created by the team and all public features (methods and attributes) in those classes and interfaces. For the consistency of the style, it is advisable to use the Javadoc comments also with the private members in team’s code. The difficult to understand parts of the methods are commented with the common line and block comments, as usual.

The two latter are in the remote repository as they are and are not separately included into the PDF document.

The PDF-document decribes:

The structure of the part of the software implemented by the course team. A clear hand drawn diagram is perfectly fine. An UML class diagram is best created with a tool that is capable to reverse-engineering the diagram from the code. For example, the free UMLet tool is able to create a class diagram from the Java code. Please, note that automatically created diagrams need to be worked further, because they often omit most of the relations between the classes. Unfortunately, there are no established free UML plugin for NetBeans that is both free and able to reverse-engineer.
Reponsibilities of the key classes.
Project functionality, including each extra feature clearly described.
Those classes implemented by the team containing pre and post conditions.
The agreed and actual division of work.
A short user manual.
Known bugs or missing features.

The document can be written what ever the team chooses, but it must be turned in as a PDF file. The PDF-document should not exceed five (5) pages.