| Re: [papyrus-rt-dev] State machine inheritance |
Superclass | Subclass | |
Case 1 | No state-machine | No state-machine |
Case 2 | State-machine | No state-machine |
Case 3 | No state-machine | State-machine |
Case 4 | State-machine | State-machine |
Case 1 | Case 2 | Case 3 | Case 4 | |
Establish generalization | Allowed | Allowed Create empty redefining state-machine and set classifierBehavior =>Case 4 | Not allowed | Not allowed |
Create state-machine in super-class | Not allowed (if it can be detected) | Not applicable | Not applicable and not allowed (if it can be detected) | Not applicable |
Create state-machine in sub-class | Not allowed | Not applicable | Not applicable | Not applicable |
Delete state-machine in super-class | Not applicable | Not allowed and not applicable (if it can be detected) | Not applicable | Not allowed (if it can be detected) |
Delete state-machine in sub-class | Not applicable | Not applicable | Not applicable | Not allowed |
Remove generalization | Allowed | Not applicable | Not applicable | Allowed Remove redefining state machine and unset classifierBehavior => Case 2 |
Hi, Peter,It appears to me that the inheritance of the classifierBehavior state machine is analogous to the transition guard. Our UML-RT implementation provides for transitions to inherit their ownedRule constraints, including its guard, trigger guards, and whatever other constraints may be serving an information/documentary purpose. The one that is singled out as the guard is inherited as the guard, also. Similarly, we can let a class inherit all of the ownedBehavior state machines and also inherit the classifierBehavior subset. (I say "ownedBehavior state machines" specifically because we don’t have incremental inheritance of the details of other kinds of behaviours, apart from the OpaqueBehavior).This is all at the level of the model implementation, without reference to how it should be presented in the UI.In the tooling UI we have, as you say, to make a decision. I can propose at least two alternatives that I think would be workable. First, and probably simplest to fit into the way Papyrus works, is to ensure that the subclass actually manifests the redefining state machine in the model, but initially with its region and all that it contains inherited. So that we have a “real” state machine that is a stub. This, then, can have a diagram that presents the inherited contents of this state machine to let the user start editing it. It also ensures that the user will see the subclass’s state machine regardless of whether the Model Explorer is configured with the facet that shows inherited elements.The alternative would be to update the Model Explorer’s default facet configuration to present the inherited classifierBehavior state machine always, even if it is not redefined. In this case, it could not have a diagram for the same reason that an inherited composite state cannot have a nested diagram until it is redefined (that reason being the Viewpoint framework). But, of course, the tooling would automatically redefine the state machine when the user creates a diagram, which then essentially puts the model in the first case as described in the previous paragraph.I would further propose that I can prototype one or both of these solutions for us to get a better idea of how they feel.On the subject of exclusion of pseudostates, I think it may be worth noting that the exceptional exclusion mechanism (the false constraint) as implemented in Papyrus-RT already works for pseudostates and anything else owned by a Namespace. It’s just that we have trained the UI not to let pseudostates be excluded. This is easily changed if we got it wrong.
Cheers,Christian
On Feb 27, 2017, 03:08 -0500, Peter Cigéhn <peter.cigehn@xxxxxxxxx>, wrote:
Hi,Some comments inline below./Peter Cigéhn
On 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/
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.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.(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). 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).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: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.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.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éhn
On 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... Bran
On 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éhn
On 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.. Bran
On 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éhn
On 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 Posse
Zeligsoft_______________________________________________
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