Exercise Solutions (Unrestricted)
Two are ocean-going vessels and all are assets.
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?
They might all be threats.
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.
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]