Hi, Team,
In looking into the impact of inheritance support in the state machines on model validation, something has come up that I hadn’t thought about before. It’s a question of whether the state machine of a capsule specializes or redefines the state machine of the capsule’s superclass.
The thing is, that for most of the RedefinableElements that we’ve dealt with so far in UML-RT's inheritance scenarios (ports, parts, connectors, protocol-messages, regions, states, transitions), those elements are not classifiers. But, state machines are classifiers — in fact, they are classes, which are behaviored classifiers (!) — so they also support the concept of generalization. The UML-RT specification shows an example of incremental inheritance in state machines in §3.1.2 Fig. 3. This object diagram shows explicitly that the state machines of capsules in a generalization hierarchy are related by redefinition, via the StateMachine::extendedStateMachine property, which is a subset (indirectly and by redefinition) of RedefinableElement::redefinedElement. This intention to use redefinition is reinforced by the application of the «RTRedefinedElement» stereotype to the state machines.
However, according to UML, a redefining state machine requires its context class (a capsule in our case) to be a redefinition, not (only) a subclass, of the context class of the redefined state machine:
isRedefinitionContextValid(redefined : StateMachine) : Boolean
-- The query isRedefinitionContextValid() specifies whether the redefinition context of a StateMachine
-- is properly related to the redefinition contexts of the specified StateMachine to allow this element
-- to redefine the other. The context Classifier of a redefining StateMachine must redefine the context
-- Classifier of the redefined StateMachine.
body: self._'context'().oclAsType(BehavioredClassifier).redefinedClassifier- >includes(redefined.oclAsType(Behavior)._'context'())
I don’t understand the reason for this: if a state machine’s own redefinition depends on its context classifier (capsule) being a redefinition, then what is the redefinition context of that capsule?
In any case, the UML specification’s discussion of redefinition in state machines fairly consistently refers to specialization of state machines, not redefinition. So, it seems that it is expected that state machines are extended by generalization/specialization rather than by redefinition. This also avoids the problem of the valid redefinition context: when state machines have generalization relationships instead of redefinition, then their redefinition context doesn’t enter the picture.
So far, in our UML-RT implementation, all RedefinableElements have been treated in the same way, using redefinition to express the extension or overriding of inherited elements in a capsule that is a subclass of another capsule. But, for the capsule’s state machine, this runs afoul of the redefinition context constraint.
So, what should we do in Papyrus-RT to resolve this problem?
- Make the state machine of a capsule specialize the state machine of the superclass capsule via generalization, as in the capsules themselves, instead of redefining the state machine of the superclass capsule? Or,
- Override the StateMachine::isRedefinitionContextValid(…) operation in our UML-RT implementation to require a generalization relationship between the context capsules of the redefining and redefined state machines instead of a redefinition relationship?
For myself, I think I would prefer option 2 because it makes more sense to me, but I’m not nearly as comfortable with the UML semantics of redefinition as our UML-RT experts, so I am happy to be educated on the subject.
