Re: [papyrus-rt-dev] State Machines: Redefinition or Generalization?

[Peter Cigéhn <peter.cigehn@xxxxxxxxx>]

Hi,

I guess Bran is the only one that really can give a recommendation and explanation here. 

Anyway, I just wanted to understand how this is handled in the legacy tooling. When I checked earlier what had been overridden in the UML-RT specific implementation of the UML meta-model in the legacy tooling, I did not see that isRedefinitionContextValid had been overridden (there were a few isConsistentWith that had been overridden, which in its turn calls isRedefinitionContextValid).

But on the other hand, the legacy tooling is based on an earlier version of the UML specification (version 3.2.100 of org.eclipse.uml2.uml). So I checked how isRedefinitionContextValid looked like "back then". Here is what I could see:

public static boolean isRedefinitionContextValid(StateMachine stateMachine,

StateMachine redefined) {

if (redefined != null) {

BehavioredClassifier context = stateMachine.getContext();

return context != null

&& context.allParents().contains(redefined.getContext());

}

return false;

}

So, "back then", the isRedefinitionContextValid uses generalization to check for valid redefinition context for a state-machine.

Just for comparison, the current implementation looks like this (in 5.3.0 of org.eclipse.uml2.uml):

public static boolean isRedefinitionContextValid(StateMachine stateMachine,

RedefinableElement redefinedElement) {

if (redefinedElement instanceof StateMachine) {

BehavioredClassifier context = stateMachine.getContext();

return context != null && context.getRedefinedClassifiers()

.contains(((StateMachine) redefinedElement).getContext());

}

return false;

}

So yes, something has changed compared to how this is handled in the the legacy tooling. So it feels like your proposal to override the implementation of isRedefinitionContextValid seem to be the most appropriate way forward (if we want to align with legacy). But I guess Bran is the one that needs to give his view on this.

/Peter Cigéhn

On 27 February 2017 at 21:45, Christian Damus <give.a.damus@xxxxxxxxx> wrote:

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?

1. 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,
2. 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.

Thanks,

Christian

_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev