--- In executableuml@yahoogroups.com, Ashley at Metamaxim <ashley.mcneile@...>
wrote:
>
> The uncertainty about behavioural conformance stems from uncertainty
> about the semantic relationship between the child and the parent. It
> could be that:
>
> 1. The child is a sub-type and should be substitutable. This means
> that the child must support at least every behaviour of the parent.
> 2. The child is a specialization of the parent and may, as a result,
> have set of behaviours that is not as wide (general) as the parent.
> 3. The child is a something that re-uses (by inheritance) behavioural
> definitions in the parent but is not required to have any
> particular formal behavioural conformance with its parent.
>
Executable UML doesn't have this uncertainty at the model level. Inheritance is
an implementation mechanism. (See the gray text in section 6.5.1.) This renders
the terms, child and parent, specious in an Executable UML discussion.
The following definitions from the book might help clarify things:

superclass - is a class that generalizes classes in a
generalization-specialization hierarchy.

subclass - is a class that specializes classes in a
generalization-specialization hierarchy.

leaf subclass - is a subclass that is not the superclass of any other class.

object - an instance of a class, or an instance of several classes in a
generalization-specialization hierarchy.

When we refer to behavior, we are referring to the behavior of objects. The
recommendation in the book is to put state machines only in the subclasses when
behavior is specialized. I'm not sure what the full basis is for this
recommendation. My experience suggests that it is due to lack of tool support
for a state model split across multiple classes in a
generalization-specialization hierarchy, and a lesser incidence of need.