Department of Computer Science and Software Engineering
433-254 Software Design
(Semester 2, 2003)
The objective of this project is to give students a chance to practice OOP and assess their understanding of the OO concepts and techniques.
Markers will be provided with:
· One or more bundles of submitted projects. Each submission consists of:
o a class diagram
o the printed source codes and the result of execution for a test case.
· Marking sheets.
· A marking guide (this document).
· A test case and the corresponding expected output.
Please follow the following guidelines when you are marking the projects. For each marked project, you must complete a marking sheet. You should also write brief but clear comments and explanations (especially when marks are deducted) both on the printouts and the corresponding marking sheet as feedback to students and for my future reference (when I will have to deal with complaints).
For the purpose of this project, students were only asked to provide a very basic class diagram. In fact, they were not asked to follow any specific notation or to provide details of their classes. Thus, only the following aspects of the class diagrams are marked:
· Header Documentation (2 marks):
o Class header documentation: Each class should have a header document that provides a brief description of the class and its purpose (1 mark).
o Methods header documentation: Each method should have a header document that explains its purpose and functionality briefly and provides descriptions for its input parameters (if any) and/or expected output (if any)(1 mark).
· Readability (1 mark):
o Consistent indentation (0.5 marks)
o Reasonable and meaningful names for classes, methods and variables (0.5 marks)
Students should have demonstrated reasonable levels of understanding of the OOP concepts and their implementation by:
· Having meaningful inheritance relations between classes that are consistent with their class diagram. (1 mark)
· Utilizing standard data structures and class libraries, such as Hashtable and Vector classes, instead of making their own data structures (0.5 marks)
· Reasonable level of abstraction by having at least one abstract class (e.g. abstract class Product). (0.5 marks)
· Reasonable level of information hiding by using visibility modifiers (e.g. public, private and protected). (0.5 marks)
· Reasonable level of encapsulation by good choice of methods and variables for each class. (0.5 marks)
Award the full two marks for an exact match between the actual and expected results as reported by ‘sdiff’ (the UNIX utility) at the end of each printout. If there is any difference:
· No penalties for:
o Having “PRODUCT_REPORT” instead of “PRODUCTS_REPORT”.
o Or “25.0” instead of “25.00”
· For small differences deduct 0.25 of a mark for each case.
· For more significant differences, such as wrong requirements reference in the error messages, deduct 0.5 of a mark for each case.
· For the runtime errors or infinite loop after mostly acceptable results deduct one mark.
· For the runtime errors or infinite loop without many acceptable results deduct the full two marks.