Community
Participate
Working Groups
Transitions should have a customized properties view showing only the relevant properties for UML-RT. The most relevant properties are name, kind (external, internal, local) and triggers. The kind property should preferably be shown as radio buttons. Each of the radio buttons (external, internal and local) should only be enabled and possible to select only when relevant, e.g. it does not make sense to change a self-transition (ether external or internal) into a local transition. It can also be questioned whether an external (non-self) transition should be possible to make into an internal transition. The effect and guard code is best shown in the separate code snippet view, see Bug 494288. The table with triggers should be improved to have more details for each trigger. One proposal is to make it into a table, one row for each trigger, with columns for ports, protocol message, and guard. Compare with the table added in the scope of Bug 476984. When selecting a specific trigger in this table, the code snippet view (see Bug 494288) should be updated to show the guard code for that specific trigger. Triggers should be possible to be created directly from this table, bringing up the trigger creation dialog as described in Bug 477811. Editing a trigger via this table should bring an edit version of the same dialog as in Bug 477811.
Properties observed in Papyrus-RT version 0.7.2.201608261452 seem to address this. Please verify and determine if this can/should be closed or enhanced.
(In reply to Charles Rivet from comment #1) > Please verify and determine if this can/should be closed or enhanced. The enhancements proposed here has not been considered. The proposed table for triggers (comparable to how it looks like in the legacy tooling) I still see. The current list of triggers only shows the name of the trigger, not any details about its ports, protocol message or guard. So personally I would still like to see a customized UML-RT tab, with the proposed improvements, i.e. changing kind into radio buttons, changing the simple list of trigger into a propert table (similar to the parameter table for protocol messages) and the "removal" of guard and effect (or actually "move" of this information into the code snippet view according to Bug 494288 for easier viewing and editing). So I see this Bugzilla equally applicable as when it originally was written.
(In reply to Peter Cigehn from comment #2) > (In reply to Charles Rivet from comment #1) > > Please verify and determine if this can/should be closed or enhanced. > > The enhancements proposed here has not been considered. The proposed table > for triggers (comparable to how it looks like in the legacy tooling) I still > see. The current list of triggers only shows the name of the trigger, not > any details about its ports, protocol message or guard. > > So personally I would still like to see a customized UML-RT tab, with the > proposed improvements, i.e. changing kind into radio buttons, changing the > simple list of trigger into a propert table (similar to the parameter table > for protocol messages) and the "removal" of guard and effect (or actually > "move" of this information into the code snippet view according to Bug > 494288 for easier viewing and editing). > > So I see this Bugzilla equally applicable as when it originally was written. Thanks Peter, So there here is a significant UX point of view for anyone moving from legacy tooling - an important factor, as well as a usability issue. I'm marking it as new. This is part of 0.0/MVP2 (a feature-boxed release tentatively scheduled for end of November).
New Gerrit change created: https://git.eclipse.org/r/84365
Gerrit change https://git.eclipse.org/r/84365 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus-rt/org.eclipse.papyrus-rt.git/commit/?id=098795121e6d9162b7921d3be2c827a586dd791d
Fix merged but tests to be added
New Gerrit change created: https://git.eclipse.org/r/85433
Gerrit change https://git.eclipse.org/r/85433 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus-rt/org.eclipse.papyrus-rt.git/commit/?id=4ce2ad112fd0e0e230d84b667445a7bb9932c614
I have tested this a bit in the latest Papyrus-RT build. The relevant properties, name, kind and the table trigger (with a ports, protocol message and guard column) are now included on the UML-RT tab. There are a few issues though: 1) The enabling/disabling of the kind radio buttons is not working as expected. When creating a transition from a state inside a composite state to an exit point on the composite state, then this is an external transition. But the external radio button is disabled and the local is enabled, making it possbible to change to a local transition which does not make sense. Unfortunately there is a cut-and-paste fault in Bug 494284 Comment 0 which is clarified in Bug 494284 Comment 2 for this specific case. 2) In general it maybe should be possible to change transitions to internal transitions in several more situations (the legacy tooling supports this). Not sure how useful it is, but it should be considered. 3) Related to both issue 1) and 2). How shall we handle the enable/disable of the kind radio buttons, before we actually support that refactoring correctly? When are planning on supporting changing an external self transition into a local self transition (or an internal transition)? The radio button is enabled, but these cases does not really work as expected. I have a feeling that it might be better to disable the toggling of the kind radio buttons, until we actually have tested and implemented the toggling in a correct way. This about which refactoring cases to support was also brought up in Bug 506808. 4) As already discussed in the Gerrit change, we should not have the guard and effect fields on the UML-RT tab (at least not in its current form). When we have the code snippet view in place, Bug 494288, I expect the effect and guard code for the transition to be edited using the code snippet view. We need to track the removal of these fields when we have a the code snippet view in place. I suggest that we write a separate bug for this. Before putting this one into verified, or reopening it, I would like to understand what strategy we should have regarding the enabling/disabling of kind radio buttons. If we do not intend to fix all the different toggling scenarios, then I suggest that we simply disable them in the scope of this bug and track the introduction of toggling/refactoring in separate bug(s).
See comments inline. (In reply to Peter Cigehn from comment #10) > I have tested this a bit in the latest Papyrus-RT build. The relevant > properties, name, kind and the table trigger (with a ports, protocol message > and guard column) are now included on the UML-RT tab. > > There are a few issues though: > > 1) The enabling/disabling of the kind radio buttons is not working as > expected. When creating a transition from a state inside a composite state > to an exit point on the composite state, then this is an external > transition. But the external radio button is disabled and the local is > enabled, making it possbible to change to a local transition which does not > make sense. Unfortunately there is a cut-and-paste fault in Bug 494284 > Comment 0 which is clarified in Bug 494284 Comment 2 for this specific case. This is bug and will put new gerrit once https://git.eclipse.org/r/#/c/85519/ is merged. Then we should not have inconsistency between core and tooling. > > 2) In general it maybe should be possible to change transitions to internal > transitions in several more situations (the legacy tooling supports this). > Not sure how useful it is, but it should be considered. > Agree to disable switch to internal transition until this is supported. > 3) Related to both issue 1) and 2). How shall we handle the enable/disable > of the kind radio buttons, before we actually support that refactoring > correctly? When are planning on supporting changing an external self > transition into a local self transition (or an internal transition)? The > radio button is enabled, but these cases does not really work as expected. I > have a feeling that it might be better to disable the toggling of the kind > radio buttons, until we actually have tested and implemented the toggling in > a correct way. This about which refactoring cases to support was also > brought up in Bug 506808. > Once internal transition is disabled then switching to other kind should not be possible after update. > 4) As already discussed in the Gerrit change, we should not have the guard > and effect fields on the UML-RT tab (at least not in its current form). When > we have the code snippet view in place, Bug 494288, I expect the effect and > guard code for the transition to be edited using the code snippet view. We > need to track the removal of these fields when we have a the code snippet > view in place. I suggest that we write a separate bug for this. > Sure. > Before putting this one into verified, or reopening it, I would like to > understand what strategy we should have regarding the enabling/disabling of > kind radio buttons. If we do not intend to fix all the different toggling > scenarios, then I suggest that we simply disable them in the scope of this > bug and track the introduction of toggling/refactoring in separate bug(s).
(In reply to Peter Cigehn from comment #10) > 4) As already discussed in the Gerrit change, we should not have the guard > and effect fields on the UML-RT tab (at least not in its current form). When > we have the code snippet view in place, Bug 494288, I expect the effect and > guard code for the transition to be edited using the code snippet view. We > need to track the removal of these fields when we have a the code snippet > view in place. I suggest that we write a separate bug for this. I wrote Bug 507965 to track this aspect.
New Gerrit change created: https://git.eclipse.org/r/85593
Gerrit change https://git.eclipse.org/r/85593 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus-rt/org.eclipse.papyrus-rt.git/commit/?id=a098dc826c1b8791dfbd3ee0f22a3b368ac18a91
I have tested this in the latest Papyrus-RT build and the updated behavior of the kind radio button, where only the selected radio button is enabled (and the others are disabled), is in the short term the most reasonable. Still there are some issues that the wrong kind is created from the beginning, but that should hopefully be covered by Bug 494284 (since there still are some issues left even when Bug 506810 was resolved, see Bug 506810 Comment 10). So I assume that whenever Bug 494284 have been resolved for all the cases of transitions are covered, then the correct kind will also be assigned already at creation, which leaves the behavior in the properties with not allowing to change the kind good for now. I will write a separate bug for the "refactoring" support to toggle the kind of transition, e.g. changing a local self-transition to an external and vice versa among. The aspect with the effect and guard fields are already tracked by Bug 507965. With that, the reduced scope of this bug can be considered verified. I put this one into verified fixed.
Closing as verified fixed.
(In reply to Peter Cigehn from comment #15) > I will write a separate > bug for the "refactoring" support to toggle the kind of transition, e.g. > changing a local self-transition to an external and vice versa among. > I wrote Bug 508754 regarding the support for toggling transition kind.
