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 sources and include:

1. Class diagrams founded on a simplified notation to that described by UML (Unified Modelling Language).
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.

On completion of each assigmnet students should submit a report, in the form of a Microsoft Word document, supported by appropriate Java source files (.javafiles).

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

Students should analyse the 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) a "target" class and (ii) an application class (containing a main method). A particular problem may require several target 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 final report in the form of a class diagram and a set of summary tables.

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

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.

Occasionally it is necessary to 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 instance of the InputStreamReader class. It is not necessary to include such classes in class diagrams.

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

Students should follow a "top-down" style of implementation. Starting with the "bones" of a class (i.e. empty methods) and then adding the detail in a step-wise manner (an approach sometimes referred to as stepwise refinement). It is recommended that students compile their code incrementally, as each additional refinement is made, throughout the implementation rather than when the implementation is complete.

(Other than for the first practical) students should design a set of test cases to exercise all aspects of their implementations. These test cases should be presented in tabular form as part of the documnentation (see Section 7 below).

The students should then run these test cases to check the actual result against the expected result.

In the case of the first practical students should simply present the output from their application.

To include the results of running a Java programme (i.e. "evidence of testing") into your Word report it is simplest to cut and paste the resuklt into your document. How to do this will depend on the operating system you are using.

6.1. UNIX/LINUX Cuting and Pasting

When using the UNIX/LINUX operating system, to cut and paste results of running a Java programme, proceed as follows:

1. In the "terminal" window:
   1. Highlight the area of the window that you wish to copy by holding down the left button of your mouse and dragging the mouse cursor across the text you wish to copy.
   2. Press control-c.
2. In your Word document:
   1. Move the mouse cursor to the position in your word document where you want to paste the text.
   2. Press control-v.

6.2. Windows Cuting and Pasting

When using the Windows operating system, to cut and paste results of running a Java programme (i.e. "evidence of testing") into your word document, proceed as follows:

1. In the "command prompt" window:
   1. Highlight the area of the window that you wish to copy by holding down the left button of your mouse and dragging the mouse cursor across the window.
   2. Press return.
2. In your Word document:
   1. Move the mouse cursor to the position in your word document where you want to paste the text.
   2. Press control-v.

All supporting documentation (i.e. excluding source files) should be prepared as a single MicrosClass Diagrams, NS charts and Activity Diagrams. "Box and arrow" type diagrams can easilly be prepared using Powerpoint and cut and pasted into Word. Alternatively Word includes a simple drawing capability which will suffice (see note below).

Evidence of testing (for each test case) should be included in the documentation. The best mechanism for doing this is to simply cut and paste into your word document. Highlight the text your are going to paste, copy it onto the "clipboard" (if you are running your application under windows this is done either by using the copy option from the menu, or by simply hitting the "return" key), and then paste into you Word document using "control-v".

7.1. The Word Drawing Tool

Figure 1: Example Word drawing icons

"Autoshapes" is useful for triangles, circles, squares and diamonds. The arrow icon is OK for class diagrams (the arrow is filled which is not strictly UML, but we will have to live with that!) and activity diagrams. Text can be included as "text boxes". To get rid of the border surrounding a text box highlight the border so that it is dotted (not diagonally dashed) by clicking on the boarder, select format from the menu bar and then Text Box ... and then edit the resulting "Format Text Box" window.