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