90-754 Homework #2: Criteria and Comments
8 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 #4
 


Problem 1: Extending the Hotel model

Criteria for grading:
Score Description
3 Mostly correct; grasp of the core concepts demonstrated
2 Attempted, but the given model cannot store some needed data
0 No attempt made

 

Comments:
Number Description
1.1 Class names should be singular, i.e. "Amenity" instead of "Amenities" because when an object of this type is instantiated, we want to refer to it as an Amenity, not as an Amenities.
1.2 Your choice of dealing with Amenities and Seasons is fine, but there is another way to implement multiple types (with subclasses.)  Refer to the sample solution for details.
1.3 Your model contains the same data in several places.  This can become a problem when the data needs to be updated, and can potentially cause nasty concurrency faults.
1.4 When naming attributes, it is usually not necessary to include the class name in the attribute name.  For example, in the Season class, use "name" instead of "seasonName" as the name of the attribute.  The reason for this is that the class of an object is always prevalent and known anyway, so duplicating the class name is just redundant and inconvenient.
1.5 Your design seems to indicate that each hotel has its own amenities that belong to no other hotel.  However, the wording of the problem indicates that Amenity objects represent types of amenities, and that a given Amenity will be related to multiple hotels (because the question "Which hotels have this type of Amenity" must be answered.)
1.6 Your diagram contains some detail or data that was not actually called for in the problem or in the original model.  Please refer to my original comment about why making up detail is a bad idea.  (Homework #1, comment 1.10).
1.7 Your diagram contains elements that are neither part of UML nor OMT (which is the standard your book uses).
1.8 In order to represent pricing with a separate class, each Hotel must be able to have several Pricing objects, but your diagram did not seem to reflect that.
1.9 If you used more than one class to represent the pricing extension, you should probably justify your design; I would contend that one additional class is enough.
1.10 Your diagram did not contain enough attributes to store the correct pricing information, and so could not have solved the problem.
Back to top
 


Problem 2: Instance Diagrams for the User Authorization system

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 contained a lot of irrelevant information or symbols
0 Not attempted

 

Comments:
Number Description
2.1 Your rendering of the instance diagram with association classes was not correct.  Please refer to the sample solution for details.
2.2 The links that appear in your instance diagram should all be instances of one of the associations defined in the given class diagram.  That means that you need to use the same names for your links as the associations had (grantor, grantee, owner) and not make up your own (access, modify, attach)
2.3 The class diagram given in the book makes it impossible for a given Authorization object to link with more than one User and Table, respectively.  However, some of you indicated that the same Authorization object served both User B and User C.
2.4 It is really important that you pay close attention to the information that is denoted in the class diagrams.  In particular, if there is no association between two classes, then any instance diagram containing those classes may not be linked in any way.  Many of you installed links between Users and other Users, which is not allowed according to the class diagram definition.
2.5 When an association object such as Authorization mitigates a link via the dotted-line notation, only one such link can be mitigated by each object.  Some of your diagrams had multiple dotted lines going to the same association object, which is not correct.
2.6 The dashed-line notation is meant to indicate a relationship between association objects and links, not association objects and other objects.
2.7 The wording of the problem indicates that User A is the only user that owns the table, so it would be incorrect to draw an "owns" link between any other user and the table.
2.8 It is important for diagrams to be clearly and unambiguously labelled, which means that link labels should be near or over just one link, not several.
2.9 In these diagrams, each object may appear in a given diagram only once.
Back to top
 


Problem 3: Comparison of Association class notation

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


Problem 4: Class diagram of Church system

Note: Since the purpose of this course is to learn how to analyze requirements and design a system based on that analysis, we will not be evaluating you on the quality or plausibility of your design. Instead, you will be evaluated on the readability and clarity of your documents which present that design.

Criteria for grading:
Score Description
3 Understandable and clear; gives a good impression of the proposed model
1-2 Minimal effort made
0 Not attempted.

 

Comments: No comments were made.  Good job, everyone!
Back to top