| Re: [papyrus-rt-dev] State machine inheritance |
On Mon, Feb 27, 2017 at 3:07 AM, Peter Cigéhn <peter.cigehn@xxxxxxxxx> wrote:Hi,Some comments inline below./Peter CigéhnOn 27 February 2017 at 04:03, charles+zeligsoft.com <charles@xxxxxxxxxxxxx> wrote:I’ve been using: http://download.eclipse.org/papyrus-rt/updates/nightl for the nightly builds - others will correct me if wrong…y/neon/ /CharlesRegarding the latest nightly, I suggest to base it on the tester setup, i.e. follow the instructions on the Tester wiki page regarding installing with the Oomph papyrus-rt-tester.setup file. Then all needed update sites will be ensured automatically. But yes, that .setup-file uses the http://download.eclipse.org/papyrus-rt/updates/nightly/n repo for the nightly builds (along with a bunch of other repos).eon/ [bvs] I did my best to follow the process described therein. It turned out to be anything but simple, and I am still unsure whether I got the right image. For one, it required a new Java VM (release 8), and I had to remind myself how to get a copy of that. Once I got that done, (I think) I followed the instructions carefully (although some of the screen shots did not match what I was getting), and, somehow, ended up with a Mars version of Papyrus RT. After some more fumbling around, I think I managed to get a proper Neon version, but I am not sure. For example, the version I am using does not allow me to create transitions using the drag handles (or whateer they are called) nor could I create parts using elements form the palette. Also, system SAPs could only be created by dragging appropriate protocols from the model explorer (as opposed to using the port tool from the tool palette). So, I have the uneasy feeling that what I have is not what you folks have.[bvs] Once again, I must rail against the complexity of getting a valid copy of Papyrus RT. It is never simple and I am never sure of the results. This has got to be fixed.
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 think it is rather crucial that we understand this about "automatically when the modeler decides to make a change to the inherited state machine". Yes, there are practical issues around this (depending on what you mean with it). I feel that we *first* need to understand what this means, before deciding if we shall have it. Not the other way around. Too me this statement is far too abstract and I cannot spin my head around what it would mean in practice.[bvs] Fair enough. Let me be clearer: Let's say I create a subclass of a capsule class. At that point, it inherits all the members of the namespace of the parent capsule, including its classifier behavior state machine. If I now I decide to view the state machine that I inherited, the following should happen: A redefining state machine should be created, automatically, and a new state machine diagam should appear for this state machine with the inherited bitsshown according to the standard convention for inherited bits. One tool-specific issue is: how do I open up the new state machine if one does not yet exist? I can think of at least two different ways that this could be done, but I will leave that for a separate discussion.
But, I woudl say that in the vast majority of cases, when you subclass a capsule class that has a classifier behavior state machine, in practically all cases, you will want to modify the inherited state machine. So, one option is to automatically create a redefining state machine when the generalization to the parent is created.
I also feel that this is vert much related to one of my later follow ups: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.I am not sure about how strict we shall be about classifierBehavior being assigned in the subclass or not, but if I understand all this correctly, then we *must* create on owned redefining state machine in the subclass to be able to assign its classifierBehavior. Then I would assume that we should automatically create the redefining state-machine already when the generalization is established, i.e. the user should not have to explicitly create a state-machine as a next step (as shown in Christian's video), and then also assign classifierBehavior for the subclass, directly when the generalization is established.[bvs] That is one possibility (see my response above).(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?I think that we have some confusion here. A long time ago we had lots of discussion around this how we should handle redefinition/exclusion and how to handle this about pseudostate not being redefinable in UML. My understanding of the conclusions from those discussions was that, yes, and issue should be raised with OMG (which you have done). We also discussed whether a new redefinition/exlucision mechanism should be introduced (you proposed a completely new profile with a very generic redefinition/exclusion mechanism, replacing the use of the RTRedefinedElement stereotype).[bvs] I may be "mis-remembering", but the mechanism I introduced was copied from the mechanism used in RSA RTE. So, it was not new.
But in the end we decided that Papyrus-RT should not introduce any any new redefinition/exclusion mechanism, but instead do how the legacy tooling were doing for non-redefinable elements, e.g. the constraint with a literal-false specificaton for handling exclusion of triggers. But keep in mind that the constraint with literal-false is *only* used for triggers (it actually fits in exactly with how trigger guards work, the only difference is that a trigger guard with a false-literal can be "evaluated" during code-generation and thus be seen as an exclusion, whereas a trigger guard specified by an opaque _expression_ needs to be "deferred" to run-time to be evaluated).[bvs] You may be right about the compatibility of the mechanism with how guards work, but this is mereserendipitious coincidence. It does not change the fact that this is a kludge to work around a UML limitation.
The constraint with literal-false specification is not being used for pseudostates in the legacy tooling. Yes, the UML-RT profile document mentions pseudo-states in this paragraph, but for me this is an oversight. If I would have paid closer attention when reviewing I would have commented on that this special construct is only used for excluding triggers. I and Christian had some discussions about this bug 511060 and we then actually asked you for a clarification of this about a month ago. And then you did agree on that we should not introduce exclusion for pseudostate:[bvs] I am not sure what I agreed with (apologies), but it may have been driven by practical considerations as opposed to theoretical ones. This is why we decided to fix UML so that the redefinable elements are all vertices and not just Regions, States, and Transitions.
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.So I really think that we should stick to this, i.e. we do not introduce a new mechanism for excluding pseudostates and align with legacy.[bvs] I see that as an implementation-specific decision. Remember that, in the future editions of UML, pseudostates will be redefinable.
What the legacy tooling do support however is the implicit exclusion of pseudostates, i.e. if all incoming/outgoing transitions of a pseudostate is excluded, leaving a "dangling" pseudostate, then the pseudostate itself is graphically hidden from the subclass diagram, i.e. from an end-user perspective you achieve the "exclusion" anyway (at least from a graphical point of view and reducing "clutter" in the subclass diagram). I think that this is "good enough" when it comes to excluding pseudostates.Cheers... Bran