| Re: [papyrus-rt-dev] State Machines: Redefinition or Generalization? |
I hope this email makes it to the list (I believe that I am now registered), but, just in case, I've cc'd Peter and Christian explicitly.On Tue, Feb 28, 2017 at 3:15 AM, Peter Cigéhn <peter.cigehn@xxxxxxxxx> wrote: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;}[bvs] That's very strange. I cannot find either of these in the current version of the OMG standard. (http://www.omg.org/spec/UML/2.5/PDF/ or the corresponding XMI file (http://www.omg.org/spec/UML/20131001/UML.xmi) ), so I have no idea where they come from, or why they differ. In fact, the second version is not even valid OCL (should be "instanceOf(StateMachine)" and not "instanceOf StateMachine").
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éhnOn 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::redefinedE lement. 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).redefinedC lassifier- >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?[bvs] I too was mystified by this and did some archeological analysis. The best I could come up with is that this is, unfortunately, a consequence of some clumsy metamodeling of state machine redefinition. If you look at Figure 9.1 in the 2.5 spec you will see that a classifier can have zero or more redefined classifiers. This was intended to support the possibility of redefining nested classifiers, but, it seems that it was misunderstood when state machine redefinition was done (see the final paragraph of section 9.2.3.3). Hence, it seems that whoever wrote the operation cited above by Christian, incorrectly assumed that there had to be a redefinition of the context Class.
[bvs] For the record, state machine redefinition for UML 2.0 was done in a desperate rush to beat the submission deadline. Hence, it was never checked and, since not many tools implemented state machine redefinition, this particular operation seems to have gone unchecked.[bvs] Unfortunately, this does not explain why RSA did not run into this problem or where the strange OCL functions that Peter listed come from. So, I cannot claim to have solved the mystery, but I think the above is on the right track.
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.[bvs] Unfortunately, sensible as it might sound, the above conclusion is wrong. Classifier behavior state machines are quite intentionally specialized via redefinition.This is because of the limitatition of the UML generalization mechanism, as I explained in the UML-RT profile document: the inability to specialize members of nested namespaces. (However, how the redefinition mechanism solves this, was never really identified in the UML 2 spec. One way of doing it is specified in the UML-RT profile document and it is based on how RSA did it.)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::isRedefinitionCo
ntextValid(…) 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.[bvs] Option 2 is definitely the right way to go.You could still get by without overriding the operation, by adding the (unneccessary) redefinition of the context capsule class (this may be how RSA got around the problem?).
[bvs] Apologies for taking so long to respond, but I was really swamped this past week.Cheers... Bran
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
_______________________________________________
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