THE COMP101 OO DEVELOPMENT METHODOLOGY

The OO methodology described here is a fairly standard approach to creating small to medium sized OO applications. The prescribed techniques have been borrowed from an number of sorces and include:

1. Class diagrams founded on a simplified notation to that described by UML
2. Field, constructor and method summary tables identical to those used to describe the Java API by Sun on their Java WWW pages.
3. UML Activity Diagrams to describe the flow of control through a system.
4. Nassi-shneiderman charts to describe the procedural aspects of individual methods.

These will be presented to students in the form of a "requirements statement".

Students should analyse thne requirements to identify the classes that will be required to produce a solution. As a guide line students should consider developing at least two classes: (i) an "operational" class and (ii) an application class. A particular problem may require several operational classes, but can only have one application class.

Once the classes have been identified students should identify the fields, constructors and methods required by each class.

The result of the analysis should be presented in the form of a class diagrm and a set of summary tables.

3.1. Details to include in class diagrams

Class diagrams can be produced at many levels of granularity. With respect to COMP101 the class diagram should include all classes that an application uses including those taken from the Java API with the exception of the System class. The latter is used so regularly that its presence can be assumed (it will also be compiled in automayically).

The diagrams should include all fields, methods and constructors that will be designed and implemented by the student (with the exception of default constructors). The diagram should also include any fields, constructors (again with the exception of default constructors) and methods taken from the Java API that might be used in the solution. There is no need for students to list all the members in every Java API class used --- only those that are actually used in the solution.

Occaisionally it is necessary the create an anonymous instance as part of the input to some method or constructor. For example:

public static BufferedReader keyboardInput = 
               new BufferedReader(new InputStreamReader(System.in));

which includes a reference to an anonymous isntance of the InputStreamReader class. It is not necessary to include such classes in class diagrams.

3.1. Field, Constructor and Method Summary Tables

The detailed design should be expressed in terms of Nassi-Shneiderman charts and, where appropriate, activity diagrams.

4.1. Nassi-Shneiderman Charts

Students should include Nassi-Shneiderman charts for each of their methods.

4.2. Activity Diagrams

In the context of COMP101 Activity Diagrams are to be included to indicate the "paths" through a systems. This requirement should therefore govern the level of detail to be included in such diagrams. In many cases a very "high level" view will normally suffice.

Note: For the first few practicals there will be no requirement to include activity diagrams.