Homework #3 Errors

90-754 Midterm: Criteria and Comments
8 March 1999

Sample:
A sample solution to Problems #1-4 are provided here. No sample is available for Problem #4, since elucidating the requirements of the client is a large part of the learning experience of this course.

Contents:
Problem #1
Problem #2
Problem #3
Problem #4

Problem 1: Use Case Diagram

Criteria for grading:

Score Description

24-25 Answer is complete and represents a design that is both feasible and elegant

23 Answer is complete and represents a sub-optimal but feasible design

20-22 Answer is complete, but design as it stands cannot feasibly implement the stated requirements

0-19 Some parts of the question not attempted

Comments:

Number Description

1.1 Some part of your diagram does not use UML correctly. The most typical error made on the midterm was a misuse of the <<extends>> arrow. If you are interested in using extends, I suggest you look over Rational's UML Notation Guide, or come see me. However, if you are in doubt about how to use a piece of UML syntax, I would suggest that it is better to avoid using it than to use it incorrectly.

1.2 Your top-level diagram contains some use cases that cannot be done in isolation; these include use cases such as "compute costs". Remember that at the top level, only the main capabilities of the system should be shown. See the UML Use Case FAQ for details.

1.3 You might have recognized that the two capabilities of the system (printing reports and adding information) are likely to be done by two different types of users, and so represented them as separate actors rather than just having one "user" actor.

1.4 Use case names should be verbs that indicate actions, or behaviors, that the system can perform. Use case ovals should not correspond to objects or data elements.

1.5 A given system, regardless of its complexity, should have just one top-level use case diagram. So, if you have two top-level behaviors, they should appear on the same diagram.

Back to top

Problem 2: Classes, associations, and attributes

Comments:

Number Description

2.1 Your choice of one or more attributes makes your design infeasible. The most common errors were to associate mileage with Vehicle. This is an error because the system needs to track the mileage of a given vehicle at the time of each repair, so for a given vehicle you will need many places to store mileages, not just one. Another common error was to associate warantee with Vehicle or Task rather than RepairEvent, which is an error for the same reason.

2.2 The repairTask must be associated with the Event in order to be able to discover from the model which tasks were performed during which events.

2.3 Your model included some associations between classes that need not exist. Although not technically illegal, it is usually not a good idea to have a non-tree structure for your associations. (That is, to have a cycle in the graph of associations.) If you do, you may find that you have redundant information embedded in the associations, which can lead more easily to inconsistency.

2.4 Your model either omits or carries an incorrect multiplicity on one or more associations. The most common mistake was for RepairEvent to be associated with many Vehicles or Facilities, even though the problem implies that a given repair can only be performed at a single place, on a single car.

2.5 Your model has an attribute on a class that is itself another class. As we've discussed, when this situation arises, you should represent it by associating the two classes, since classes cannot be attributes of other classes in UML.

2.6 Your model cannot show whether or not a repair is being done as part of routine maintanance or as an emergent repair.

2.7 Facility must be directly associated with event, or else the model cannot show which facility a certain repair occurred at.

Back to top

Problem 3: Preconditions and Postconditions

Comments:

Number Description

3.1 In your preconditions, you might want to consider mentioning the validity of each of your parameters explicitly, such as the date, mileage, etc.

3.2, 3.3 In your contract you mentioned parameters, attributes, methods, or classes that are not defined elsewhere in the description of your design. It is important to define all of the elements that you use so that your reader has something to refer to if they don't understand a word in your contract.

3.4 Your contract was a little too brief or a little too vague. Typically you want to use these textual descriptions of your methods to help your reader understand what your methods do, so it isn't helpful to be cryptic or glib.

3.5, 3.6 Some conditions that you included were somewhat extraneous, or weren't really preconditions or post-conditions of the methods that you were describing.

3.7 You were asked to complete contracts for both the adding repair and printing report use case, but you omitted one. This probably resulted in your score of 15 or so points on this question.

Back to top

Problem 4: Using patterns to define operations

Criteria for grading:

Score	Description
24-25	Answer is complete and represents a design that is both feasible and elegant
23	Answer is complete and represents a sub-optimal but feasible design
20-22	Answer is complete, but design as it stands cannot feasibly implement the stated requirements
0-19	Some parts of the question not attempted

Comments:

Number Description

4.1 Your collaboration diagram(s) show one or more messages that do not correspond to methods defined elsewhere in your model. Remember that collaboration messages are the same as method calls, and so it is impossible for a message to have some name other than a method.

4.2 Your collaboration diagram(s) show objects whose classes are not defined elsewhere in your model. See 3.2.

4.3 The creator pattern stipulates that a class cannot have the responsibility of creating objects of its own type. To see why this is true, imagine the state of the system when it first boots and no objects exist. If Foo objects are the only types of objects whose methods create Foo objects (which is what it means to have that responsibility) then where does the first Foo come from? If no Foo objects exist, then no Foo objects can ever be created! Whoops! So, the responsibility for a creating a class mustn't go on that class.

4.4 We would have liked for you to mention explicitly the patterns that you used and how they led you to your design decisions. However, it wasn't specifically asked for in the problem so for the most part we tried to infer your pattern motivation from the design.

4.5,4.6 Collaboration diagrams, unlike static diagrams, cannot show many unrelated things about a system on one diagram without making it confusing. For this problem, it would probably be more informative to have used two diagrams rather than one.

4.7 Your diagram indicated to us that you may be confusing actors with objects. Actors are people that use the system, but they aren't necessarily data objects that are tracked within the system.

4.8 Your diagram could have been helped by more explanation, comments, or titles to indicate your thoughts. Again, the goal is to be clear and descriptive; just using the syntax correctly is not enough.

Back to top

Number	Description
1.1	Some part of your diagram does not use UML correctly. The most typical error made on the midterm was a misuse of the <<extends>> arrow. If you are interested in using extends, I suggest you look over Rational's UML Notation Guide, or come see me. However, if you are in doubt about how to use a piece of UML syntax, I would suggest that it is better to avoid using it than to use it incorrectly.
1.2	Your top-level diagram contains some use cases that cannot be done in isolation; these include use cases such as "compute costs". Remember that at the top level, only the main capabilities of the system should be shown. See the UML Use Case FAQ for details.
1.3	You might have recognized that the two capabilities of the system (printing reports and adding information) are likely to be done by two different types of users, and so represented them as separate actors rather than just having one "user" actor.
1.4	Use case names should be verbs that indicate actions, or behaviors, that the system can perform. Use case ovals should not correspond to objects or data elements.
1.5	A given system, regardless of its complexity, should have just one top-level use case diagram. So, if you have two top-level behaviors, they should appear on the same diagram.

Number	Description
2.1	Your choice of one or more attributes makes your design infeasible. The most common errors were to associate mileage with Vehicle. This is an error because the system needs to track the mileage of a given vehicle at the time of each repair, so for a given vehicle you will need many places to store mileages, not just one. Another common error was to associate warantee with Vehicle or Task rather than RepairEvent, which is an error for the same reason.
2.2	The repairTask must be associated with the Event in order to be able to discover from the model which tasks were performed during which events.
2.3	Your model included some associations between classes that need not exist. Although not technically illegal, it is usually not a good idea to have a non-tree structure for your associations. (That is, to have a cycle in the graph of associations.) If you do, you may find that you have redundant information embedded in the associations, which can lead more easily to inconsistency.
2.4	Your model either omits or carries an incorrect multiplicity on one or more associations. The most common mistake was for RepairEvent to be associated with many Vehicles or Facilities, even though the problem implies that a given repair can only be performed at a single place, on a single car.
2.5	Your model has an attribute on a class that is itself another class. As we've discussed, when this situation arises, you should represent it by associating the two classes, since classes cannot be attributes of other classes in UML.
2.6	Your model cannot show whether or not a repair is being done as part of routine maintanance or as an emergent repair.
2.7	Facility must be directly associated with event, or else the model cannot show which facility a certain repair occurred at.

Number	Description
3.1	In your preconditions, you might want to consider mentioning the validity of each of your parameters explicitly, such as the date, mileage, etc.
3.2, 3.3	In your contract you mentioned parameters, attributes, methods, or classes that are not defined elsewhere in the description of your design. It is important to define all of the elements that you use so that your reader has something to refer to if they don't understand a word in your contract.
3.4	Your contract was a little too brief or a little too vague. Typically you want to use these textual descriptions of your methods to help your reader understand what your methods do, so it isn't helpful to be cryptic or glib.
3.5, 3.6	Some conditions that you included were somewhat extraneous, or weren't really preconditions or post-conditions of the methods that you were describing.
3.7	You were asked to complete contracts for both the adding repair and printing report use case, but you omitted one. This probably resulted in your score of 15 or so points on this question.

Number	Description
4.1	Your collaboration diagram(s) show one or more messages that do not correspond to methods defined elsewhere in your model. Remember that collaboration messages are the same as method calls, and so it is impossible for a message to have some name other than a method.
4.2	Your collaboration diagram(s) show objects whose classes are not defined elsewhere in your model. See 3.2.
4.3	The creator pattern stipulates that a class cannot have the responsibility of creating objects of its own type. To see why this is true, imagine the state of the system when it first boots and no objects exist. If Foo objects are the only types of objects whose methods create Foo objects (which is what it means to have that responsibility) then where does the first Foo come from? If no Foo objects exist, then no Foo objects can ever be created! Whoops! So, the responsibility for a creating a class mustn't go on that class.
4.4	We would have liked for you to mention explicitly the patterns that you used and how they led you to your design decisions. However, it wasn't specifically asked for in the problem so for the most part we tried to infer your pattern motivation from the design.
4.5,4.6	Collaboration diagrams, unlike static diagrams, cannot show many unrelated things about a system on one diagram without making it confusing. For this problem, it would probably be more informative to have used two diagrams rather than one.
4.7	Your diagram indicated to us that you may be confusing actors with objects. Actors are people that use the system, but they aren't necessarily data objects that are tracked within the system.
4.8	Your diagram could have been helped by more explanation, comments, or titles to indicate your thoughts. Again, the goal is to be clear and descriptive; just using the syntax correctly is not enough.