Exercise Solutions (Restricted)
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.
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.
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).
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]
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.)