Generalization and the Third Manifesto

[lwri...@frogooa.com]

I found a couple of items, with regards to the Third Manifesto's (Date
and Darwen) views of inheritance, that probably merit further
discussion in the context of Executable UML.

1) The "NOT" subclass. In the Third Manifesto, the example used often
is CIRCLE is-a ELLIPSE. Reference is made to dividing the set of
ellipses into circles and not-circles, but the Third Manifesto model
doesn't require an explicit NOT_CIRCLE type. Would this be desirable in
Executable UML? Would it be abusable? Would it obscure the "only one"
instance view of generalization hierarchies?

2) The diamond inheritance model. An example in the Third Manifesto
shows a SQUARE is-a RECTANGLE, a SQUARE is-a RHOMBUS, a RHOMBUS is-a
PARALLELOGRAM, and a RECTANGLE is-a PARALLELOGRAM. In Executable UML,
this isn't considered legal due to RECTANGLE and RHOMBUS having to be
disjoint. Should Executable UML allow this (obviously) correct type of
hierarchy? In looking at it from a set perspective, there is no
conflict as SQUARE is the intersection of RHOMBUS, RECTANGLE, and
PARALLELOGRAM.