| Course web page: Introduction to Computer Science for non-majors II James Tam | Return to the course web page |
| Programming style (credit may be awarded independent of functionality) | Student grade | Max grade/penalty |
| Follows good programming conventions common to all programs (e.g., Appropriate source code white space, self documenting names, clear/simple expressions, methods implementing one task/max 30 lines of code, appropriate used of named constants): Never (0), Sometimes (2), Often (6), Mostly (8), Always (10) | 10 | |
| Information hiding: Never (0), Sometimes (1), often (2), Mostly (3), Always (4) | 4 | |
| Class attributes are logical to the definition (e.g., not variables that are just local to a method but belong to each instance): Never (0), Sometimes (2), Often (4), Mostly (6), Always (8) | 8 | |
| Each class (save the "Driver" and the Debugging class(es) used) consists of at least 3 methods | 3 | |
| Static variables employed (debugging flags excepted), -4 marks each instance with a max of 12 marks lost | -12 | |
| The code for the classes are not included in its own file, -3 marks for each instance | -27 | |
| Other stylistic programming issues | -5 | |
| Sub-total: Style | 0 | 25 |
| Documentation (credit may be awarded independent of functionality) | Student grade | Max grade |
| Header documentation includes full name and tutorial section | 2 | |
| Some form of versioning system is demonstrated in the header documentation | 2 | |
| Program limitations documented | 1 | |
| Program features documented (cut and paste out of the assignment specifications acceptable but it MUST be detailed, clear and specific...the marker must be able to know exactly what features in this marking key were actually working) | 20 | |
| Each function/method is documented (similar to documentation for the entire program but applies only to that function/method) | 10 | |
| Sub-total: Documentation | 0 | 35 |
| Program functionality (program must run to be awarded credit) | Student grade | Max grade |
| Classes listed in assignment description submitted (the class methods can be largely empty) | 5 | |
| Each track is properly initialized and displayed at appropriate time | 2 | |
| Displays clear and sufficiently detailed instructions in the introduction | 2 | |
| Game proceeds on a turn-by-turn basis | 1 | |
| Order of the turns is correct (1 mark per sub-turn in correct order) | 6 | |
| Displays an appropriate status message when the program ends (quit, win/lose, tie) | 4 | |
| SUV and sports car movement menu | ||
| Displays menus | 2 | |
| Gets user input for the SUV and sports car menu and repeats prompts until valid input is entered. | 2 | |
| Player can quit/program runs indefinitely until end game condition met | 2 | |
| Cheat menu can be invoked from either car menu. | 2 | |
| Cheat menu can be invoked from either car menu. | ||
| Gets user input for the cheat menu and repeats prompts until valid input is entered. | 2 | |
| Can toggle debug mode | 2 | |
| Can change fuel of sports car | 2 | |
| Can change fuel of SUV | 2 | |
| Can change location of sports car | 4 | |
| Can change location of SUV | 4 | |
| Can invoke a heat wave from the arctic track during the arctic track sub-turn in the current turn | 4 | |
| Can invoke a blizzard from the desert track during the desert sub-turn in the next turn (current sub-turn has already passed) | 4 | |
| Debug mode implemented | 4 | |
| SUV can move and consume fuel as specified in the class description (non-AWD mode) | 4 | |
| Sports car can move and consume fuel as specified in the class description | 4 | |
| Program checks and properly handles when cars run out of fuel | 4 | |
| SUV can move and consume fuel as specified in the class description (AWD mode) | 4 | |
| Arctic track can randomly generate and properly handle the effects of a blizzard on the SUV (regular mode) | 8 | |
| AWD mode working properly during a blizzard | 4 | |
| Desert track can randomly generate and properly handle the effects of a heat wave on the sports car | 8 | |
| Program can determine when one or both cars have reached the end | 4 | |
| Graphical display of output (input may still be console-based) | 6 | |
| Program plays appropriate sound effects | 4 | |
| Subtotal | 0 | 106 |
| UML class diagram (credit may be awarded independent of functionality) | ||
| Class Track attributes (3) and methods (3) properly specified and matches actual code | 6 | |
| Class ArcticTrack attributes (3) and methods (3) properly specified and matches actual code | 6 | |
| Class DesertTrack attributes (3) and methods (3) properly specified and matches actual code | 6 | |
| Class SUV attributes (3) and methods (3) properly specified and matches actual code | 6 | |
| Relationship properly specified (multiplicity not needed) | 0 | 3 |
| Sub-total: UML | 0 | 27 |
| Design requirements (may modfiy the functionality score) | ||
| Implements static methods other than 'main()': halve marks | ||
| Program consists of only one class (style marks will also be lost): halve marks | ||
| Functionality not assigned to the appropriate class as specified in the assignment description (e.g., the attacker implements a task that belongs to the defender): max 10 marks lost | ||
| Sub-total: Design requirements modifiers | ||
| Assignment: total raw score | 0 | 193 |
| Assignment: grade point | 0 | 4.3 |
1 These two penalties are cumulative so if a program was written using only one class and was full of static methods then the student's program functionality mark would quartered.
| Raw score min | Grade point |
| 0 | 0 |
| 50 | 0.7 |
| 60 | 1 |
| 65 | 1.1 |
| 70 | 1.2 |
| 75 | 1.3 |
| 80 | 1.4 |
| 85 | 1.5 |
| 90 | 1.6 |
| 95 | 1.7 |
| 100 | 1.8 |
| 105 | 1.9 |
| 110 | 2 |
| 115 | 2.1 |
| 120 | 2.2 |
| 125 | 2.3 |
| 130 | 2.4 |
| 135 | 2.5 |
| 138 | 2.6 |
| 140 | 2.7 |
| 142 | 2.8 |
| 144 | 2.9 |
| 146 | 3 |
| 148 | 3.1 |
| 150 | 3.2 |
| 152 | 3.3 |
| 154 | 3.4 |
| 156 | 3.5 |
| 158 | 3.6 |
| 160 | 3.7 |
| 162 | 3.8 |
| 164 | 3.9 |
| 166 | 4 |
| 168 | 4.1 |
| 170 | 4.2 |
| 173 | 4.3 |