| Re: [papyrus-rt-dev] State machine inheritance |
I’ve been using: http://download.eclipse.org/papyrus-rt/updates/nightl for the nightly builds - others will correct me if wrong…y/neon/ /Charles
On 2017-02-26, at 16:20 , Bran Selic <selic@xxxxxxx> wrote:Hi Peter,Sorry for the late reply, but I was on a business trip all of last week. Also, I didn't notice that my preious responses to you did not get to the papyrus-rt discussion list, since I don't have the right privileges (will register for it later). So, I have explicitly copied Ernesto, Charles, and Christian on this reply, since they were interested in the discussion.On Thu, Feb 23, 2017 at 7:08 AM, Peter Cigéhn <peter.cigehn@xxxxxxxxx> wrote:Hi Bran,Okay, if you haven't seen the video, then start with that. Christian have published three videos so far:[bvs] I have no seen the videos (thanks for pointing me to them). I have two comments:(1) I still think that it should not be required of the modeler to explicitly create a new state machine on a capsule that is a subclass of a capsule that already has a state machine. Instead, this should be done automatically when the modeler decides to make a change to the inherited state machine. (I realize that there are some practical issues with how this is to be done, but I will leave that discussion for later, if we decide to have it.)
I just realized, that one aspect that needs to be considered (since Ernesto want the semantic to be clear), and that is when classifierBehavior of the subclass capsule is assigned. As can be seen from my screen shot below, the classifierBehavior is not set for Capsule2, in the situation when it only have inherited the state-machine (via inheritedMember). But to be able to assign classifierBehavior the capsule needs an ownedBehavior (since classifierBehavior is a subset of ownedBehavior), i.e. it is not until you actually have created the redefining state-machine in the subclass capsule that you can assign its classiferBehavior.
So if we are going to be "strict" with the definition of classifierBehavior, you always need to create the redefining state-machine in the subclass, to semantically state that it has a classifierBehavior.
(2) it is stated in one of the videos that pseudostates are not redefinable/excludable, which is not true for UML-RT models (by the way, there is an issue before the OMG requiring that all state machine Vertices be made kinds of redefinable elements). I wrote a section on this point in the UML-RT profile document (section 3.1.3). Is there some reason why this capability is not supported in current Papyrus RT?
Thanks, Peter. I no longer recall, but my guess is that I added pseudostates in that list based on an assumption, as opposed to a concrete use case. On first thought, I cannot think of a use case for excluding psuedostates. And, considering that the capability was not missed by Ericsson, it is probably best to avoid it.
Apart from that I also suggest to test the latest nightly build of Papyrus-RT. What is demonstrated in those videos (including improvements already made based on feedback to these videos) is merged and now part of the latest nightly build of Papyrus-RT.[bvs] I thought I had the nightly build of Papyrus RT in my list of update sites, but it does not seem to be picking up any - so I must have the wrong URL. What is the right one?I am not fully sure how I shall interpret your feedback, i.e. whether it is a concern of what has been implemented so far,[bvs] This is my concern, as I wrote above. As for the rest, it is just a generic diatribe on some principles, independently of the current implementation. Since it seems to be well understood and supported, you can ignore it.Cheers... Branor if it is "misunderstandings" of what has been discussed (very briefly) in this mail thread, or if they are of more general concern. The concern about modifying the superclass in the context of the subclass, I would say is exactly what we already try to achieve, e.g. this about double-clicking on a composite state and either navigating to the superclass, i.e. ensure that the user performs any edit in the context of the superclass, or explicitly making the choice of redefining the composite state in the context of the subclass. Check the last of the three videos for this aspect. But maybe not even this takes care of this concern./Peter CigéhnOn 23 February 2017 at 11:40, Bran Selic <selic@xxxxxxx> wrote:Fair enough, Peter. I have not seen Christian's video, but I was assuming that the modeler had to take the initiative - which is the main part I did not like. However, even if all it takes is to make a simple selection in a dialog, I am still worried about placing an unnecessary burden, even a small one, on the modeler. Surely, the software can make the call, based on the fact that the modeler has chosen to make a modification to the inherited state machine.Related to this:In general, I do not think that modelers should be allowed to modify the namespace/features of a superclass in the context of a subclass of that superclass, since this gives a very limited view of the potential impact of such a change. If you need to modify a superclass, you should navigate to that superclass and then do the modifications there. This means that, if I find something that I need to change in my inherited state machine while in the context of the subclass, I should not even be given the option to change the superclass' state machine. Instead, I should be forced to explicitly go to the superclass and make the change there before navigating back to the subclass. This decreases the likelihood of unintentional global design corruption due to focus on strictly localized concerns - I have seen this problem happen often.Cheers... BranOn Thu, Feb 23, 2017 at 10:21 AM Peter Cigéhn <peter.cigehn@xxxxxxxxx> wrote:Hi Bran,Just a quick check: Have you seen Christians vide that Ernesto refers to? I have feeling that we might have some misunderstanding related to this about when and how the redefining state machine is introduced and how much "manual" work it currently is.
I think the core question here is related to "when the modeler decides to modify the inherited state machine". In Christian's video this can be seen at the point when the user right clicks on the capsule and selects "New UML-RT Child > StateMachine" in the subclass, which then automatically creates the redefining statemachines, automatically establishes the redefinition relations, including applying the RTRedefinedElement stereotype and applicable elements.As I indicated this in my response, we have had actually exactly the same discussion about when the user navigates into an inherited composite state by double-clicking on it, and either the user selects to navigate to the inherited diagram in the context of the superclass, or the user has the intention of modifying the "inside" of the composite state, and thus we redefine the composite state and create a "redefined" nested state-machine diagram for that composite state.
I think that we have something very similar here, i.e. either the user is happy with looking around in the inherited state-machine (in the context of the superclass), or the user has the intention as you say, to start modifying the inherited state-machine. The question is just how and when we are going to ask that question? For the composite state case, we have the double-click action on the a composite state. For the top level state-machine itself, we don't have anything similar.So the question is if it is "good enough" to do exactly as Christian already have done and what is showed in the video, i.e. the user explicitly selects to create a state-machine in the subclass using "New UML-RT Child > StateMachine".Or if we need to find some other "gesture" for the user to indicate that the intention is to start modifying the state-machine, similar to the case for inherited composite states./Peter CigéhnOn 23 February 2017 at 11:01, Bran Selic <selic@xxxxxxx> wrote:I think that, from the modeler's perspective, state machine inheritance should be treated exactly as inheritance of any other feature. Hence, it should not be affected by the fact that state machine inheritance is realized through an idiosyncratic redefinition mechanism, which was only necessary because of the poor design of inheritance in UML (i.e., it only allows inheritance at one level of namespaces, overlooking the fact that some names in namespaces can be namespaces in their own right).Therefore, I cannot say that I like the option whereby the modeler has to explicitly define a redefining state machine. Perhaps the most important advantage of inheritance is that it occurs automatically. Requiring manual intervenion in that process contravenes that and only burdens on the modeler with no added value to him/her. (I don't see Peter's corner case as being any different than the case for inheriting the usual features from a class defined in another model; the inheritance mechanism knows nothing about where classes are defined and should not have to know anything about it.)So, my preferred solution is to automatically introduce a redefining state machine when the modeler decides to modify the inherited state machine. Note that this will means the need to show the inherited state machine (diagram) for a capsule class even when no changes are made to it (but, I would expect this to be a rare and rather peculiar use case). This is because, unlike regular features (attributes, operations), we must show the fully collapsed inheritance view of state machines, since any added features only make sense when shown in their inherited context). I do not think that the RSA approach of always adding a redefining state machine in a subclass is suitable, since it needlessly bulks up the model and, possibly, the generated code.Cheers.. BranOn Thu, Feb 23, 2017 at 8:42 AM Peter Cigéhn <peter.cigehn@xxxxxxxxx> wrote:Hi,Good question! I actually already provided some input regarding this in bug 510315 comment 2. Since the fact that the state-machine (and the state-machine profile) now is optional is not something that have had to be considered before in legacy models. In the earlier generations of UML-RT, the state-machine have been mandatory, and creating a capsule have always created the state-machine at the same time (you cannot even create a capsule without a state-machine in the legacy tooling, and trying to remove it casues a live validation kicking in that blocks the removal of the state-machine). So comparing with our legacy, this has been non-issue, and the redefinition relation of the state-machine ins the subclass have been established as soon as the generalization for the capsule have been established.But with the introduction of an optional state-machine profile, and thus an optional state-machine, e.g. to make it possible to have pure structure capsules without behavior, we have quite a few "corner cases" and different combinations to consider, i.e. superclass/subclass with/without state-machine at the time the generalization is established, and adding/removing a state-machine in the superclass/subclass *after* the generalization already have been established.Regarding the specific example that Christian showed his video, i.e. the state-machine did not exist in the subclass capsule at the time when the generalization was established, is a good example to discuss around.I am not fully sure what you mean when you say "It looks like the capsule state machines are not automatically inherited". How could we conclude that from the video? What happened was that no redefinition of the state-machine was established automatically. That happened when the state-machine was explicitly created at a later point in time. The semantic could still be that the state-machine is inherited "as-is". But to be able to start-redefining the state-machine, we need to establish the redefinition. This is kind of the same discussion that Christian brought up regarding the nested state-machine diagram for composite states, i.e. to be able to redefine the "inside" of a composite state, it first have to be redefined so that the redefined diagram have a place-holder.So yes, one alternative is that the state-machine is considered to be inherited by default, even if the subclass does not have a state-machine itself. But to be able to redefine it in the context of the subclass the state-machine needs to be added explicitly (and a redefinition is established automatically as shown in Christians demo). Another alternative is to explicitly create a state-machine in subclass (if it does not have one yet) at the time the generalization is established, and establish the redefinition. But this would make us bump into another "corner case" if the subclass capsule is in another model that the superclass, and the optional state-machine profile is not applied on that model. So maybe the former alternative is better, and the user have to explicitly add the state-machine in the subclass to be able to start redefining it.Regarding the last question, when the capsule owns other behavior such as interactions and activities, I am not sure what you mean "should they be inherited too"? If you by "inherited" mean that they should have the same kind of redefinition relation established and graphical layout inheritance, then the answer is "no". That is only applicable to the state-machine./Peter CigéhnOn 22 February 2017 at 18:10, Ernesto Posse <eposse@xxxxxxxxxxxxx> wrote:Hello. While going through Christian's excellent demo videos, I found something that seemed to be a bit odd to me. It looks like capsule state machines are not automatically inherited.More precisely, in the demo, there is a capsule Capsule1 with a state machine as its classifierBehavior, and a capsule Capsule2 with a Generalization to Capsule1. But Capsule2 does not get to inherit the state machine automatically. The user must explicitly add a state machine to Capsule2, which will then be (automatically) the redefinition of Capsule1's state machine.This prompted a discussion with Christian on this issue, and we are not quite certain about the semantics here. In UML-RT, are state machines supposed to be inherited by default (if the user doesn't explicitly add a state machine) or not?Furthermore, if we eventually support other classifier or owned behaviours such as interactions or activity diagrams, should they be inherited too?--Ernesto PosseZeligsoft--Ernesto PosseZeligsoft_______________________________________________
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