Homework #3 Errors

90-754 Homework #3: Criteria and Comments
15 February 1999

Sample:
A sample solution to Problems #1-3 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 1: Adding domains to E2.1

Criteria for grading:

Score Description

3 Mostly correct; grasp of the core concepts demonstrated

2 Attempted, but the given model lacked adequate detail

0 No attempt made

Comments:

Number Description

1.1 The purpose of domains is to make explicit the type of the data being stored in the given attribute. To that end, domains should be chosen that are more specific than the normal primitives (int, string, float, etc.). For example, many of you used double to represent currency, but this is not the best choice: currency has only small, fixed precision, not floating precision (i.e. no one wants to keep track of one millionth of a cent) and also cannot be negative. When choosing domains, even if the data seems simple, try to choose a representation that encapsulates as many of the preconditions on the data type as possible.

1.2 Some of you didn't specify the actual contents of your structured domains. It is important to include this information so that your reader can tell what you mean by "Address" etc.

1.3 Some of you chose not to use domains to represent Address and Currency, but these were prime candidates for domain conversion, and we home that you'll consider using them in future work.

Back to top

Problem 2: Showing catalog aggregation for the lawn mower assembly

Criteria for grading:

Score Description

3 Mostly correct; grasp of the core concepts demonstrated

2 Attempted, but lacked significant correct use of the notations being demonstrated

1 Attempted, but mostly irrelevant information

0 Not attempted

Comments:

Number Description

2.1 Aggregation symbols (the diamond arrow) are for showing ownership and multiple cardinality on class diagrams. We asked you to construct an instance diagram for this assignment, so the aggregation symbols were not appropriate.

2.2 Some of you showed cardinality symbols (0...*) on your diagrams, but again, these are only appropriate for class diagrams, not instance diagrams.

2.3 The question asks for catalog aggregation using the class diagram 3.17. Since this diagram only shows two classes, and one of them is for physical aggregation (not relevant to this problem), all of your objects should have had the same type: CatalogPart. However, a number of you constructed a class diagram nearly identical to the one given in the book in Figure 3.18. To be honest, it isn't clear to me what the authors were trying to show with this diagram, because it is thrown in without explanation and has no bearing on their discussion up to that point. Worse, it is confounding to the previous page, where types of things (models of parts) are treated as objects, not classes. On the whole, this part of the book is constructed very poorly and I apologize for it. If you copied diagram 3.18 you received full credit, but you should look at the sample solution to see what was expected.

2.4 These objects had natural names that you could have included, for example Engine: CatalogPart.

2.5 The problem asked for catalog aggregation, not physical aggregation. So, all of your objects should have been of type CatalogPart, and PhysicalPart objects should not have appeared in your solution.

2.6 Your diagram does not seem to comply with either OMT or UML, which are the diagramming standards we are interested in for this course. Please make sure that you are conforming to a diagramatic standard so that your reader will understand your work.

2.7 The quantity tag is associated with the link between a part and its parent assembly, not the object itself.

2.8 Your diagram was difficult to read. When a diagram gets very complicated like this, you should (a) consider breaking it up into several diagrams, or (b) create a rough draft and then reorganize it.

Back to top

Problem 3: Adding matrix management

All of your answers were reasonable and received the full credit for this problem (1/1).

Number Description

3.1 When your diagram contains two unlabelled associations between a pair of classes, that association can usually be replaced by a single association.

3.2 There must be an association either between managers and people or from managers to each of (a) IndividualContributors and (b) Managers. Otherwise, there would be no way to represent managers who both are managed by other managers and who manage people themselves.

3.3 You must have had multiple cardinalities on your links so that each person can be managed by multiple people and each manager can potentially manage multiple people.

3.4 It is more expressive to create the Manager and IndividualContributor subclasses because it makes to roles of the people (objects) involved more explicit. However, your solution is not technically incorrect.

3.5 Whenever a diagram has several associations per class, they should be labelled to clarify their nature.

Score	Description
3	Mostly correct; grasp of the core concepts demonstrated
2	Attempted, but the given model lacked adequate detail
0	No attempt made

Number	Description
1.1	The purpose of domains is to make explicit the type of the data being stored in the given attribute. To that end, domains should be chosen that are more specific than the normal primitives (int, string, float, etc.). For example, many of you used double to represent currency, but this is not the best choice: currency has only small, fixed precision, not floating precision (i.e. no one wants to keep track of one millionth of a cent) and also cannot be negative. When choosing domains, even if the data seems simple, try to choose a representation that encapsulates as many of the preconditions on the data type as possible.
1.2	Some of you didn't specify the actual contents of your structured domains. It is important to include this information so that your reader can tell what you mean by "Address" etc.
1.3	Some of you chose not to use domains to represent Address and Currency, but these were prime candidates for domain conversion, and we home that you'll consider using them in future work.

Number	Description
2.1	Aggregation symbols (the diamond arrow) are for showing ownership and multiple cardinality on class diagrams. We asked you to construct an instance diagram for this assignment, so the aggregation symbols were not appropriate.
2.2	Some of you showed cardinality symbols (0...*) on your diagrams, but again, these are only appropriate for class diagrams, not instance diagrams.
2.3	The question asks for catalog aggregation using the class diagram 3.17. Since this diagram only shows two classes, and one of them is for physical aggregation (not relevant to this problem), all of your objects should have had the same type: CatalogPart. However, a number of you constructed a class diagram nearly identical to the one given in the book in Figure 3.18. To be honest, it isn't clear to me what the authors were trying to show with this diagram, because it is thrown in without explanation and has no bearing on their discussion up to that point. Worse, it is confounding to the previous page, where types of things (models of parts) are treated as objects, not classes. On the whole, this part of the book is constructed very poorly and I apologize for it. If you copied diagram 3.18 you received full credit, but you should look at the sample solution to see what was expected.
2.4	These objects had natural names that you could have included, for example Engine: CatalogPart.
2.5	The problem asked for catalog aggregation, not physical aggregation. So, all of your objects should have been of type CatalogPart, and PhysicalPart objects should not have appeared in your solution.
2.6	Your diagram does not seem to comply with either OMT or UML, which are the diagramming standards we are interested in for this course. Please make sure that you are conforming to a diagramatic standard so that your reader will understand your work.
2.7	The quantity tag is associated with the link between a part and its parent assembly, not the object itself.
2.8	Your diagram was difficult to read. When a diagram gets very complicated like this, you should (a) consider breaking it up into several diagrams, or (b) create a rough draft and then reorganize it.

Number	Description
3.1	When your diagram contains two unlabelled associations between a pair of classes, that association can usually be replaced by a single association.
3.2	There must be an association either between managers and people or from managers to each of (a) IndividualContributors and (b) Managers. Otherwise, there would be no way to represent managers who both are managed by other managers and who manage people themselves.
3.3	You must have had multiple cardinalities on your links so that each person can be managed by multiple people and each manager can potentially manage multiple people.
3.4	It is more expressive to create the Manager and IndividualContributor subclasses because it makes to roles of the people (objects) involved more explicit. However, your solution is not technically incorrect.
3.5	Whenever a diagram has several associations per class, they should be labelled to clarify their nature.