![]() |
AC11001 marking criteria |
Please note that not every heading will be appropriate for every lab you do
|
Object oriented design |
You are expected to show evidence that you are adopting an object oriented approach to software development. This is shown through (e.g.) appropriate choice of classes & methods, activity diagrams, pseudocode etc. |
|
Quality of user interface |
Remember that ultimately, software is only any good if users can use it effectively. This means, even in the simplest programs, an attractive, clear interface; input error checking and data validation; helpful messages; good presentation of results. |
|
Quality of Java code produced |
The extent to which the program meets its requirements correctly; good use of the features of the Java language and its libraries; appropriate use of method calls, parameter passing; efficient algorithms. |
|
Structure/ use of methods |
Related to the object orientation but to do with the actual choice of methods and their place within the classes of the program. Also, appropriate data structures should be used for each purpose. |
|
Appropriate modularity/ |
Is the program properly modular – e.g. are classes general purpose and are they independent, i.e. is all the data they need passed in as parameters rather than acting on global variables/ do they have any side effects (such as changing global values)? |
|
Appropriate layout of code |
Is the code laid out according to the guidelines issued. Is there plenty of appropriate white space in the code? Is the code appropriately spaced and are blocks of code clearly identified and indented? |
|
Comments & documenting |
The report which accompanies the code should provide full documentation on how the program works and how to use it. The program listing should be fully commented. In particular, each function should have a header description (as in class example), comments should be used to explain non-obvious code (single lines or routines). Is the program written in such a way that someone else could come read it and easily understand what was going on? |
|
Self documenting code |
As far as possible, your code should be self-documenting. This involves the use of descriptive names for variables and functions, as well as to the overall structure of your program (which is more likely to be good if you have adopted a top-down approach). |
|
Critical self-evaluation |
With most reports you provide a critical self-evaluation which discusses how well you think you did (and suggests a mark) and also discusses where you see the strengths and weaknesses of the report and code. |