Community
Participate
Working Groups
It must be easy to change a simple state into a composite state. This can be achieved by combining the act of navigating to the state machine diagram of a composite states, to also change a simple state into a composite state. When double clicking on a state in a state machine diagram, then for the case of a composite state, the state machine diagram of that composite state should be opened automatically. If the state is still a simple state (or no state machine diagram could be found), then a dialog should popup ask for confirmation of creating a state machine diagram, and turning the state into a composite state, i.e. adding a region to it. If the user confirm the creation of the state machine diagram and turning the state into a composite state, then a Region with the RTRegion stereotype applied shall be created nested under the state. A state machine diagram shall be created with the state as its owner and root element. The diagram shall be setup to be canonical and fully synchronized with its owner state. The diagram shall be left unnamed, and its name label shall instead be derived from its grand-parent capsule/class and the its parent state like this '<Name of grand-parent capsule/passive class>..<Name of parent state>'. If the diagram is given an explicit name, then that name shall be shown instead (to make it possible for the user to override the default derived name). When changing from a simple to a composite state, and the simple state had transitions terminating at or originating from it, then the following should also be done: For each transition that terminates on the simple state, the transition is changed so that it terminates at a entry point pseudostate of the composite state For each transition that originates on the simple state, the transition is changed so that it originates from a exit point pseudostate of the composite state. The created pseudostates should have the RTPseudostate stereotype applied.
Created attachment 261972 [details] Example of composite state annotation in legacy tooling One more aspect: When making a simple state into a composite state, the composite state should have a small annotation in the lower right corner that indicates that it is a composite state, so that the user knows that it is a composite state and that you can "navigate into" it by double clicking on the composite state.
(In reply to Peter Cigehn from comment #1) > Created attachment 261972 [details] > Example of composite state annotation in legacy tooling > > One more aspect: When making a simple state into a composite state, the > composite state should have a small annotation in the lower right corner > that indicates that it is a composite state, so that the user knows that it > is a composite state and that you can "navigate into" it by double clicking > on the composite state. It shall be noted that the ruling when this adornment is shown is not as simple as isComposite=true, which is derived from the existence of (at least one) region in UML. In UML-RT the region is actually not of interest so additional ruling when the adornment is shown and not is needed. One example of when the adornment is *not* shown, even though the state has a region is when you have a state with only internal transitions (see Bug 494287 related to the creation of internal transitions). Since the internal transitions is owned by the state's region, the derived isComposite is true, but the adornment is not shown. It can also be questioned whether such a state should have it's nested state machine diagram, even though it has a region. In the legacy tooling, the state machine diagram is not created as a consequence of creating a region, e.g. when adding an internal transition, but as a consequence of the double-click action (which asks if the diagram shall be created). The adornment should be used to guide the user into knowing that there are something of interest to see "inside" the state. I am not fully sure about the exact ruling for when the adornment is shown in the legacy tooling so this I guess we need to elaborate on a bit further. Initially it probably is okay to strictly follow the derived UML property isComposite. But it must be prepared that additional ruling can be added/updated later.
(In reply to Peter Cigehn from comment #2) > One example of when the adornment is *not* shown, even though the state has > a region is when you have a state with only internal transitions (see Bug > 494287 related to the creation of internal transitions). Since the internal > transitions is owned by the state's region, the derived isComposite is true, > but the adornment is not shown. It can also be questioned whether such a > state should have it's nested state machine diagram, even though it has a > region. In the legacy tooling, the state machine diagram is not created as a > consequence of creating a region, e.g. when adding an internal transition, > but as a consequence of the double-click action (which asks if the diagram > shall be created). Personally I would propose simplicity and consistency and thereby solely relying on the isComposite UML property for the adornment, but also to create the regions diagram when the region is created. This eliminates the need for extra UI to query the user wether to create said diagram or not when the user navigates into the composite state and no such diagram exists. Also I believe the "exceptions" will be more than internal self transitions and we risk a feeling of inconsistency. Later on, when functionality exist to show internal self transitions as a compartment on the regions diagram, it would make sense for the diagram to exist and to show that there is something on the inside. This would also eliminate the need to have an adornment for the existence of "internal self transitions". One caveat with this is that a composite state in which the region only contains exit and entry pseudo states would be considered a composite state from the outside which might not be desirable. I think one could live with it though if the diagram already existed so there would be no UI overhead of a dialog asking for creation of non existing diagram when navigating into this "empty" composite state.
(In reply to Andreas Henriksson from comment #3) > (In reply to Peter Cigehn from comment #2) > > One example of when the adornment is *not* shown, even though the state has > > a region is when you have a state with only internal transitions (see Bug > > 494287 related to the creation of internal transitions). Since the internal > > transitions is owned by the state's region, the derived isComposite is true, > > but the adornment is not shown. It can also be questioned whether such a > > state should have it's nested state machine diagram, even though it has a > > region. In the legacy tooling, the state machine diagram is not created as a > > consequence of creating a region, e.g. when adding an internal transition, > > but as a consequence of the double-click action (which asks if the diagram > > shall be created). > > Personally I would propose simplicity and consistency and thereby solely > relying on the isComposite UML property for the adornment, but also to > create the regions diagram when the region is created. This eliminates the > need for extra UI to query the user wether to create said diagram or not > when the user navigates into the composite state and no such diagram exists. > Also I believe the "exceptions" will be more than internal self transitions > and we risk a feeling of inconsistency. > > Later on, when functionality exist to show internal self transitions as a > compartment on the regions diagram, it would make sense for the diagram to > exist and to show that there is something on the inside. This would also > eliminate the need to have an adornment for the existence of "internal self > transitions". Yes, if internal transitions is *always* shown "on the inside", in a separate compartment, then it makes sense to always have the diagram when the region has been created, even though it empty for the rest of the diagram. And then it also makes sense to indicate to the user that there is something to "see inside" as well, i.e. since it has a region and thus according to the derived property isComposiste is composite state, i.e. the compartment with internal transitions (even though they will also be visible on the outside) it there to see. > One caveat with this is that a composite state in which the region only > contains exit and entry pseudo states would be considered a composite state > from the outside which might not be desirable. I think one could live with > it though if the diagram already existed so there would be no UI overhead of > a dialog asking for creation of non existing diagram when navigating into > this "empty" composite state. Well, since entry and exit points are owned directly by the state, you can have a simple state with entry and exit points, without it being a composite state, i.e. it still have no region, e.g. if the user explicitly adds entry and exit points directly to a simple state. So the double-click action (possibly at a later stage) would then create the region, and the diagram for that composite state, and the adornment for a composite state would appear at that time.
To conclude the latest discussions. We start with "simplicity and consistency" and: 1) Always create the nested state machine diagram whenever the region is created, i.e. both for the double-click as well as for the case of adding the first internal transition (see Bug 494287) 2) The composite state adornment should follow the standard UML definition of composite state, i.e. when the state has a region. 3) The double-click should have a confirmation dialog if the state is about to be turned into a composite state, i.e. the addition of the region, nested state machine diagram and adding entry/exit points on all incoming/outgoing transitions, asking "Change the simple state into a composite state?" or something like that.
New Gerrit change created: https://git.eclipse.org/r/74442
(In reply to Eclipse Genie from comment #6) > New Gerrit change created: https://git.eclipse.org/r/74442 The gerrit patch is merged to master (Eclipse Genie will comment soonish).
Gerrit change https://git.eclipse.org/r/74442 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus-rt/org.eclipse.papyrus-rt.git/commit/?id=e89bad80bbc300775881709593d877675f20f9b0
I've tested this in the latest Papyrus-RT build and it works as expected. When double clicking on a simple state, the confirmation dialog pops up, the regions and the state machine diagram is created, all incoming/outgoing transitions gets an entry/exit point. There are however a few things to be noted: 1) The diagram label of the diagram in the composite state uses the "::" as separator which is a bit confusing. As stated in Commen 0 the separator to be used between the gran-parent capsule and composite state name should be "..". This is how it is named in the legacy tooling and I assume that this is due to that the composite state actully can be nested several levels below the capsule. So the diagram label be derived as '<Name of grand-parent capsule/passive class>..<Name of parent state>' at all levels of nesting of the state. 2) If you make a state into a composite state and then undo it there are a few things to be noted. One thing is that the double-click navigation seem to be reset to some default. So if you now try to make the state into a composite state again by double-clicking on it, then the standard Papyrus Manage Hyperlinks dialog pops up. If you close the model editor and re-open it again, the double clicking works again. 3) Another aspect when you undo, is that since the diagram you just navigated to now is removed, it is expected that the diagram you originally were located in, i.e. the context in where you did the double-click, is re-opened again. Instead it seem like the welcome page is shown instead. Kind of confusing when you loose your navigation history. Not sure if we shall reopen this one and track these remaining aspects within the scope of this Bugzilla or not. At least 1) probably should be in the scope of this one, since the naming was specified in Comment 0. The undo aspects 2) probably should be in the scope of this since the double-click stops working as expected. Aspect 3) probably can be made into its own Bugzilla. Since I don't have the access rights I cannot reopen (in case we decide to track at least issue 1) and 2) in the scope of this Bugzilla).
(In reply to Peter Cigehn from comment #9) > 3) Another aspect when you undo, is that since the diagram you just > navigated to now is removed, it is expected that the diagram you originally > were located in, i.e. the context in where you did the double-click, is > re-opened again. Instead it seem like the welcome page is shown instead. > Kind of confusing when you loose your navigation history. This is a general problem in Papyrus, which it is too late to fix for Neon. I am not sure that an attempt to work around it in Papyrus-RT would be worth the effort. Please do raise a new bug for this.
New Gerrit change created: https://git.eclipse.org/r/75086
Gerrit change https://git.eclipse.org/r/75086 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus-rt/org.eclipse.papyrus-rt.git/commit/?id=55c5ba00447d9cfefe9da5215d7578786e7b74c7
(In reply to Eclipse Genie from comment #12) > Gerrit change https://git.eclipse.org/r/75086 was merged to [master]. This fixes problems (1) and (2) in comment 9, plus an additional problem that undo would leave a zombie state machine diagram in the Model Explorer.
I've checked this in the latest Papyrus-RT build. The naming of the diagram is now correct and after an undo it is still possible to double-click the state again. I put this one into verified, and any remaining issues will be tracked in separate Bugzillas.
New Gerrit change created: https://git.eclipse.org/r/77606
Gerrit change https://git.eclipse.org/r/77606 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus-rt/org.eclipse.papyrus-rt.git/commit/?id=ceedf5dd926de1908cf32424c468d19f4278d82f
Closing as verified fixed.
