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:
On completion of each assigmnet students should submit a report, in the form
of a Microsoft Word document, supported by appropriate Java source files
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.
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.
Class summaries should be presented in a tabular format exactly the same as those found on Sun's Java WWW pages ( http://java.sun.com/j2se/1.5.0/docs/api/).
For each programmer defined class (i.e. not one taken from the Java API) there should be a set of tables describing the fields, constructors (except default constructors) and methods associated with that class. Clearly if a particular class has (say) no fields then there is no need to include a field summary table!
The detailed design should be expressed in terms of Nassi-Shneiderman charts and, where appropriate, activity diagrams.
Students should include Nassi-Shneiderman charts for each of their methods.
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.
When using the UNIX/LINUX operating system, to cut and paste results of running a Java programme, proceed as follows:
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:
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".
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.
8. ELECTRONIC SUBMISSION
The documnetation associated with a paractical (see Section 7 above) will typically comprise three files: a word document and two java source files (i.e. .java files, not .class files). These must be submitted electronically using the Computer Science department's electronic submission system located at http://cgi.csc.liv.ac.uk/cgi-bin/practical.pl. This URL will take you to a screen of the form given in Figure 2.
Figure 2: CS Department electronic submission system "login" window
Use your CS user name and password to login and this will take you to a second window of the form given in Figure 3.
Figure 3: CS Department electronic submission system "select practical" window
From the presented menu select a practical and click "Select", this will take you to yet another window of the form given in Figure 4.
Figure 4: CS Department electronic submission system "upload file" window
To now upload a file proceed as follows:
Warning Once a file has been uploaded you cannot delete it, upu can however overwrite the file!
Created and maintained by Frans Coenen. Last updated 14 November 2005