Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [papyrus-rt-dev] Inheritance in State Machine Diagrams
Hi,

I checked the video regarding redefining transitions. Regarding the placement of the redefinition icon, I think we shall align with the legacy tooling and place it at the target end of the transition, and not centered as shown in the video, in the corresponding was as the icons of guard/effect is placed at the source end of the transition.

Maybe the same principle with a "fixed" position as Rémi did for those icons. I can see in the legacy tooling that the redefinition icon "moves around" and are placed differently depending on the length of the transition, sometimes even placed on top of the arrow itself. We had the same issue initially with the trigger warning/guard/effect icons. I guess Rémi can provide some guidance on how he did the "fixed" placement of those icons, and I suggest we do the same for the redefinition icon.

And since we are talking about the icons for the guard and effect, I can point out that the legacy tooling have the same kind of "washed out" principle also for these icons, i.e. if you have an inherited transition with some effect (and possibly guard) code, then those icons are also washed out. If you now redefine the effect or guard code, then the corresponding icon becomes normal to indicate that the effect/guard have been redefined. This will also be applicable for the code snippet view, where the icons on the tabs for effect and guard code will use the same "washed out" principle when showing the inherited (but not yet redefined) effect or guard code.

When you have a transition with redefined effect or guard code, and you right-click on the transition in the diagram, you have separate "Reinherit"-menu choices for reinheriting the effect and guard code. So you could redefine the transition, e.g. by reorienting it, redefine the effect and/or guard code, but then only reinherit the effect and /or guard code separately. When reinheriting the transition itself, the effect and guard code is implicitly also reinherited.

/Peter Cigéhn

On 18 February 2017 at 01:35, Christian Damus <give.a.damus@xxxxxxxxx> wrote:
Thanks, Peter,

In RSA-RTE it is obvious that the composite state would have to be redefined, as the diagrams are literally owned by their context elements via annotations.  But I think it makes sense also for Papyrus-RT in which the diagrams are not owned, for all of the reasons that I’m glad to see we agree on.

BTW, I did manage today to overcome the difficulty I mentioned in the weekly status call about editing the redefining state machine, in which I was finding that all edits in the subclass were actually being done in the superclass:


It was just more edit-policies that needed to be overridden to account for inheritance and the fact that the semantic element of an edit-part is not always actually the element referenced by the notation view.  The feature branch build is up-to-date with the capabilities demonstrated in the video above, but it does require the latest Papyrus Neon build in which I had to fix a few things.

Thanks,

Christian


On Feb 17, 2017, 03:31 -0500, Peter Cigéhn <peter.cigehn@xxxxxxxxx>, wrote:
Hi,

Looks like a good start! I became a bit curious regarding the case when the state-machine already exist (with the initial elements already created) before you establish the generalization. But I guess that is still work in progress to ensure that the existing elements are removed in the subclass (as I commented on the bug).

Regarding the issue with nested state-machine diagram of an inherited composite state, what you propose (if I understood the details correctly), is perfectly in line with what the legacy tooling does as well.

If you double-click on an inherited composite state the following dialog pops up:

Inline images 1
As you can see from the options presented to the user, it is exactly as you propose. Either the user navigates to the inherited state machine diagram, i.e. it opens the diagram in the context of the superclass, or the user selects to redefine the state and create a local state machine diagram and open it in the context of the subclass.

When the redefinition have been made, the double-click action the naturally always takes you to the local (redefined) state-machine diagram. The dialog only pops up in the case the composite state is not yet redefined.

I suggest that we, as you propose, align with the legacy tooling and introduce a similar dialog with those two options.

/Peter Cigéhn

On 17 February 2017 at 05:20, Christian Damus <give.a.damus@xxxxxxxxx> wrote:
Hi, Team,

I’ve uploaded a short demonstration of the current (as of today) inheritance support in the state machine diagram, on the inheritance feature branch (builds):


Overall, I’m quite happy with the progress so far, despite some instability here and there and a few regrettable regressions that have been found and fixed — the accounting for inheritance is quite a cross-cutting concern with wide impact.  But my work on the diagrams this week has run into a question (I think not quite a snag) that I’d like to raise here.

As in the Capsule Structure Diagrams, a view of an inherited element references that inherited element as it is defined in the context from which it is inherited, even in a diagram for the inheriting context.  However, this poses a problem for the nested state-machine diagrams for composite states.  A composite state that is inherited may already have a nested diagram in the state machine from which it is inherited.  Because of restrictions in the viewpoint definition, a composite state is only permitted to have one diagram, so the same composite state cannot also have a diagram in the context of a state machine that inherits this state.

On the face of it, that seems already perfectly okay because, if the composite state is inherited, no new diagram is needed:  the diagram exactly as defined in the parent context is complete.  If the redefining state machine doesn’t redefine the composite state to change it in some way, then nobody needs a new diagram of that state.  Besides, there is no clear way that I can see by which to expand the viewpoint definition to account for the inheriting state machine context:  the viewpoint understands only that a composite state has a diagram; it cannot distinguish that a diagram is for a composite state but in the context of an inheriting state machine.

So, I’m thinking that the best thing to do is, if the user really wants to create a diagram for an inherited composite state, to force a redefinition of that composite state in the inheriting state machine.  Any changes that user would make in such a diagram would inevitably result in the composite state being redefined anyways in order to accommodate semantic changes in the state machine that inherits it.  This then provides a distinct composite state element in the inheriting state machine that redefines the inherited composite state, so that each may have its own diagram, according to the viewpoint definitions that we already have.

Thoughts?  Concerns?

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

_______________________________________________
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


Back to the top