| Re: [papyrus-rt-dev] Inheritance in State Machine Diagrams |
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: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
