| Score | Description |
| 7 | Mostly correct; grasp of the core concepts demonstrated |
| 6 | Attempted, but some aspects of the solution were incomplete or did not represent an object model that fulfilled the requirements stated in the problem. |
| 0 | No attempt made |
Note that these assignments are (and have been) graded mostly on effort,
with only small focus on mastery...
...so receiving 7/7 on your
homework does not indicate that you have complete mastery of the material.
Most students will probably benefit from a review of this assignment,
particularly those that received comments on any of their work.
Comments:
| Number | Description |
| 1.1 | Depending on your final design, this noun might be considered a method rather than a class or attribute because it is information derived from other attributes and associations in the system. |
| 1.2 | These nouns might be considered values of a particular attribute, rather than attributes or classes themselves. |
| 1.3 | Actually, this noun might really turn out to be a class (or at least it did for me.) |
Comments:
| Number | Description |
| 2.1 | In order to represent type information (such as payment method, deduction type, or income type) you need to either use the language's built-in type system (inheritance) or create your own (with a type variable). But you should not do both. |
| 2.2 | Since the totals and net pay for an employee are derived data from the employee's paychecks, income items, and deductions, storing them as attributes would create dangerous redundancy in your system. Probably better to leave them as methods. |
| 2.3 | Your system needs to be able to represent deductions and income items within each paycheck. Some of you had just one itemization facility for paychecks, and represented deductions as negative income. This was fine but you should explicitly say that the system works that way. |
| 2.4 | You have some redundant associations in your model. These can often cause problems for cleaning up deleted objects, and in general redundant associations create all of the same non-normalization problems that redundant attributes create. |
| Number | Description |
| 3.1 | The data dictionary needs to be fairly descriptive, because other developers and designers will use it to try to understand your design. If you are too brief or glib, your readers won't be able to construe much else besides what they have already learned by staring at your diagrams. |
| 3.2 | Your data dictionary should include entries for as many of the key terms and entities as possible, not just a few of them. |
All of your answers were reasonable and received the full credit for
this problem (3/3).
| Number | Description |
| 1 | I had hoped for some explanatory text here. What do you think was the purpose of this assignment, and how did you do it? |
| 2 | Did you find nothing unexpected during this entire process? Did you find this assignment useful or learn anything from it? |