Site Map  Search

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

Exercise Solutions (Unrestricted)

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

Chapter 7

Question 7.3
In the context of financial accounting what might Customer, Investment, Cruise Ship and Tanker have in common?

Two are ocean-going vessels and all are assets.

Question 7.4
In the context of a mathematics package, what might Circle and Ellipse have in common?

They are both conic sections.

[This was mentioned in the text as a question that is perpetually circulating in the object world. "Is circle a kind of ellipse or is an ellipse a kind of circle?" And the answer is, "Tell me what they both do and then I'll figure it out. (And I already suspect that neither is a subtype of the other; rather that they are both subtypes of some third supertype.)" JD]

In the context of CAM axle-grinding, what might Circle and Ellipse have in common?

Very little.

Question 7.5
In the context of a fighter-pilot training simulator, what might Bird Flock, Detonation and Cannon Round have in common?

They might all be threats.

Question 7.6
(Moderately difficult) Write a short essay comparing and contrasting the generalization relationships that one might find and model in subject matters (“the real world”) with the inheritance mechanism in the programming language you know best.

Most modeler's use of the generalization relationship is for taxonomy. Blackmail and robbery are both crimes. Electrons and muons are both leptons. Gilts and bunds are both kinds of bonds, and bonds and shares are both kinds of investments. Some kind of abstraction is being performed: if I ignore this, this and this, then I see that these things have something in common.

The inheritance relationship found in object-oriented programming languages often involves the acquisition of something. This is particularly true in languages like Java and C# where there is a way of acquiring extra types without using inheritance. And this quality of acquisition accords with the natural use of the word inheritance, of course.

When we ask the question, "How does similarity in subject matter entities manifest itself?", we usually find nothing more than, "They have subsets of properties in common." So the word inheritance, in its natural sense, could also be used. However, subject matter modelers usually feel able to portray generalization relationships without actually haven fastened upon the properties to be modeled, so perhaps "generalization" is the more appropriate term for the subject matter relationship.

Does the term "generalization" have an obvious corresponding term in programming languages? Not really. In Java, the term used is probably closest in semantics -- "extends" -- whereas the C++ term, "derived from", is probably closer to the semantics of "inheritance". But it's neither clear nor obvious.

Are we merely worrying that the terms are different when the semantics are actually the same? No, because the inheritance mechanism in languages like C++ and Java can do two quite distinct things. The inheritance relationship can give an object extra types, which is an externally manifest quality, an interface quality; and the inheritance mechanism can give a class extra instance variables (data members), which are not manifest externally provided one follows the ubiquitous advice to keep them private, and extra methods (member functions), which are not manifested externally in languages like C++ and Java. (Method signatures might be manifested externally, that though is what we deem type; methods, that is to say the code, are not manifested. One can call a function but one cannot ever call a member function or method, one messages the object whose method it is.) This separation of interface from implementation, of "is a kind of" from "works like", is one of the most powerful features of object technology, whereas such a separation is almost never found in subject matters.

Java and C# handle this stuff quite differently to C++. In Java the inheritance mechanism must always at least include an "is a kind of" relationship, i.e. type inheritance, whereas in C++ the programmer can (although in object-oriented C++ is not encouraged to) elect to only inherit implementation, i.e. only the "works like" relationship, using non-public inheritance. (Java only has the equivalent of public inheritance.) This reflect the common perception, today, that type is the strategically important thing, that there are alternatives to implementation inheritance (i.e. composition and delegation)

Do the generalization relationships in subject matter models tend to indicate type relationships to designers or implementation relationships to designers? Given that implementation is not manifest and is more arbitrary, or one could say more technical, one would have to suspect that the generalization relationship of subject matter models does not suggest inheritance of implementation as well as it suggests inheritance of interface (type).

One must also point out a big difference even between generalization and inheritance of type: type in subject matter models is typically determined by attributes and relationships and perhaps state-transition patterns, whereas type in object-oriented programming is usually determined solely by message signatures.


Question 7.8
Briefly describe all the reasons why we might need to be more careful with generalization relationships than with associations and aggregations.

  • Generalization relationships couple entire sets of things together, whereas characterizing relationships (and use relationships) potentially couple only individual instances together.
  • The coupling of generalization relationships is stronger for another reason. Three things traverse a generalization relationship: sharing of attributes, sharing of relationships and sharing of state-transition patterns. (Or you could say more than three things because there is more than one kind of relationship being shared.) In a characterizing relationship only identity traverses the link.
  • Because generalization's differences as to meaning and functioning are greater between the analysis and design than are the differences for association and aggregation, the difficulties of getting good predictions are greater and even more care in getting correct relationships is required.
  • Some developers' education channels might have over-emphasized the importance of generalization, over-emphasized the usefulness of generalization, encouraged "top-down suspicions" rather than "bottom-up determination", anticipated too great a similarity with inheritance and anticipated an unrealistic payoff from inheritance. For several cultural reasons, then, we have to be very careful. (It's a judgement as to whether said care is greater than the care required over other traditional misdirections, such as association directionality.)

Question 7.9
Here is a simple exercise to get the hang of state machines. Recall the state machine that recognized certain binary number representations (Figure 7.23, on page 195). Create a state machine that recognizes when an odd number of 0 digits and an even number of 1 digits have been seen. (By “recognize”, we mean that being in certain states indicate that the pattern has been seen, whereas being in all the other states indicate that it has not.)

Assuming, as the majority of mathematicians seem to, that zero is an even integer:

[I find this an interesting example. Even though is "simple", it seems to me to illustrate that one cannot read a state machine's correctness; one must somehow run it or come up with an insight that helps verify it's correctness. Now it may be because I'm not terribly bright, but my first effort looked correct and wasn't; a couple of test cases soon established that.

The above solution passed all my test cases. I was nervous though. (For a moment I had wondered if I had set a problem that a state machine couldn't solve. But it is a partitioning problem, and not a counting problem, so a state machine can do it.) There was no-one around for a walkthough, so I did a "cardboard cut-out review". The above solution passed. I was still nervous, however. Then I found the right way to look at it. The state machine above oscillates up and down on 1s, and left and right on 0s. With that picture I was finally happy. But what if I'd drawn it in a different orientation? Would I have found the right way of looking at it? Can I ever expect to find the right way of looking at a state machine with more than nine states? JD]


Question 7.11
Here is a simple exercise to get the hang of activity diagrams. Recall the algorithm described in Exercise 6.1, on page 163. Present it in the form of an activity diagram.