Site Map  Search

OOA Home OOD content UML Corrections book Code object Exercise Solutions oriented Resources tutorial Miscellany textbook

Exercise Solutions (Restricted)

Chapters 1 2 3 4 5 6 7 8 9 11 12

Change log (ISO date format -- yyyy-mm-dd)

2005-09-06:
  The GIF files of question 10 were corrupt. They have been replaced.
  Question 12 hadn't been answered. Now done and uploaded.

 

Chapter 7

Question 7.1
You are reviewing a model from the POLLY hotel system development last mentioned in Exercise 5.7. The modeler has UML generalization relationships (hollow, triangle arrowhead) pointing from:

  • Hotel Room to Property, and Conference Room to Property
  • En-suite Bathroom to Hotel Room
  • Bed to Mattress
  • Furniture to Asset, and Fitting (like a trouser press) to Asset

Say which of those you agree are generalization and which are not, and why. Note any assumptions you have made.

[The first printing of the first edition had an incorrectly duplicated entry. JD]

It was mentioned on page 20 that hotel software subsystems concern themselves with repair. If it is assumed that the meaning of "Property" here is "something that requires upkeep, maintenance and repair", in other words "Property" is almost being used as a synonym for "Asset", then the Hotel Room and the Conference Room would probably have enough in common that a generalization relationships would be correct. If, on the other hand, one assumes that "Property" means something that a realtor or estate agent would sell, then it is probably incorrect.

An "En-suite Bathroom" might be part of a "Hotel Room", but it isn't a kind of hotel room. This clearly fails the LSP (Liskov Substitutability Principle) and is incorrect.

The same thing applies to "Bed" and "Mattress" a bed might be associated with a mattress (although this is likely to fail another test -- what I called "Butler's Test" -- in that it is unlikely to be relevant). Certainly a bed isn't a kind of mattress.

"Furniture" and "Fitting" would both seem clearly to be kinds of "Asset" and the last one is surely correct.

Question 7.2
You are working on a part of the model for the STREPT student record system mentioned last in Exercise 6.11. Assuming you chose entities that included Student, Staff Member, Message, Address, Department, Faculty, Course, Module and Presentation, what, if any, are the possibilities for generalization relationships?

Hardly any! "Student" and "Staff" can probably be generalized. The first name I wrote down for the general type was "Person" but that is hopelessly overused and vague. After some time with a thesaurus I came up with "Scholar". However, to generalize between "Department" and "Faculty", for example, or between "Course", "Module" and "Presentation", would be a mistake because they are not in subtype/supertype relationships, again the LSP test is failed.

 

Question 7.7
(Difficult) Why do we insist that generalization relationships respect the principle of substitutability? I can think of at least two reasons.

We want to avoid making anything out of coincidental similarity. If we see common attributes or common relationships among entity sets (one might also use the term "entity class" or "class" here), it would be a mistake to create a supertype, to generalize, if it was mere coincidence. A future version of the model might change attributes or associations and the coincidental similarity disappear, leaving the model with a meaningless supertype. (OK, analysis models tend not to get many new versions as much as design models might, but then the same thing applies to design models as well.)

Also, thinking about design, there is even less chance that a generalization relationship in the analysis' subject matter model will predict something useful about the design model if it is not backed by real, semantic similarity.

Finally, and again thinking about maximizing the likelihood that the analysis model will actually be useful to the designers, we note that between the class system of the design and type system of the design, it it the type system that the strategically more important. In our current languages it is the coupling that cannot be avoided. One of the unique benefits of object technology is that complicated trickery in C++, or interfaces in Java and C# can give us pure, abstract types; and thus the inevitable coupling of a variable holder to the variable's type is as loose as we can manage with today's know-how. In a famework, like EJB for example, the types (the interfaces) are published to, and used by, the framework users, whereas via careful design and the use of factory methods, abstract classes and concrete classes are not.

If we just wish to avail ourselves of some existing capabilities and mechanisms, experience has overwhelmingly demonstrated that the best way to do that, if at all possible, is with component object instances. If we are going to couple entire classes together via inheritance, there must be some powerful extra reason to do that. So when we insist on respecting the principle of substitutability (Liskov's Substitutability Principle) we are saying, "If we are picking up type via some route, and if it makes sense to pick up default implementation over that same route, well OK. If we are primarily interested in implementation, then there are better ways to get it than via inheritance. So by insisting from the beginning that the PoS (or LSV) be respected, we ensure that type sharing is behind these more highly coupling relationships (more highly coupling that association and aggregation, which are inter-instance rather than inter-type relationships).

 

Question 7.10
Create a state machine to model the state of a normal room in a part of the POLLY hotel system that helps the front desk find rooms for new guests, helps room cleaning staff know what cleaning has to be done each day and also helps direct maintenance staff.

This uses concurrent partitions to indicate that minor repairs can occur independently of whatever else is happening to the room. An alternative that exercises a couple of other UML state machine features, might be:

[Both solutions use time events. "Midnight" is an absolute time event, whereas the word "after" indicates that the other time even is an elapsed duration. JD]

[Be careful with transitions to and from group (composite) states. Personally I don't usually give entry and exit actions to group states but if one does then they will fire. (As you will know from reading the book, I tend to avoid actions altogether and stick to protocol state machines. JD]

[I've shown group states along with their content. Make sure your CASE tool allows you to suppress the detail of group states, and that it allows you easily to "push" into the detail of a group state (e.g. double-click) and "pop" back up again (e.g. ESC). JD]

 

Question 7.12
You are planning the workflow for checking a guest out of the POLLY hotel system we have been considering in some of these exercises (Exercise 7.1 for example). You have investigated what happens at several of your example hotels. The activities on your list so far are:

  • Ensure the guest has returned the keycard.
  • Find the room account.
  • Check the phone record and add any calls that are not on the account.
  • Check for any breakfast tab that morning and amend account accordingly.
  • Ask about any mini-bar consumption last night and update room record accordingly.
  • Print out bill for guest to check and confirm.
  • Ask the guest if they enjoyed their stay.
  • Record any complaints and book any maintenance required.
  • Record the method of payment.
  • If a card has been used to pay, swipe the card for authorization.
  • If the card used for payment isn’t a chip and PIN card, get the voucher signed.
  • Print off the final copy of the bill for the guest.
  • Wish them away nicely.
  • Update the status of the room to “dirty”.

Draw an activity diagram for the workflow, paying particular attention to activities that are in dependent sequences versus activities that are independent and potentially concurrent. There are at least two styles for depicting decisions in UML activity diagrams; try more than one. Note any assumptions or amendments you have made.

(Click in the image for a higher-resolution version.)

Exercise 7.12 Activity Diagram