Community
Participate
Working Groups
Created attachment 265124 [details] snapshot Changing kind to internal from self transition of substate inside of composite state diagram causes transition being lost from model explorer. See attached snapshot. If you change onPong transition to internal, then the transition onPong disappears from the model explorer. Note that this problem does not happen in Papyrus UML model so it must be UML-RT problem.
Keep in mind that internal transition shall be created completely different compared to external and local transitions. Please see Bug 494287 for how internal transitions shall be created in Papyrus-RT.
(In reply to Peter Cigehn from comment #1) > Keep in mind that internal transition shall be created completely different > compared to external and local transitions. Please see Bug 494287 for how > internal transitions shall be created in Papyrus-RT. Just to be clear. From your comment and looking at Bug 494287 one could conclude that the it should not be possible to change an external self transition into an internal transition (as it appears to be a finite list not discussing the "creation" appraoch listed in this bug). Is that what you expect the behavior to be?
(In reply to Charles Rivet from comment #2) > (In reply to Peter Cigehn from comment #1) > > Keep in mind that internal transition shall be created completely different > > compared to external and local transitions. Please see Bug 494287 for how > > internal transitions shall be created in Papyrus-RT. > > Just to be clear. > > From your comment and looking at Bug 494287 one could conclude that the it > should not be possible to change an external self transition into an > internal transition (as it appears to be a finite list not discussing the > "creation" appraoch listed in this bug). Is that what you expect the > behavior to be? Well, that was not my intention with this comment. Since I felt that it was some confusion regarding the current state of implementation, i.e. that we neither have started with the tooling for creating transitions using the transition tool on the paletter, nor creating internal transitions, I just wanted to clarify this. When it comes to this specific case, i.e. changing the kind to/from external (or local) to internal, that is a case that definitively should be supported. The legacy tooling allows an external self-transition to be changed both to a local self-transition as well as an internal transition. So this shall be supported. There are a few things to keep in mind though, e.g. when it comes to the ownership of the transition (changing from external self-transition to local or internal should change the ownership of the transition from the region of the parent state(-machine) to the region of the (composite) state, and automatically creating entry/exit points (as discussed in Bug 494284). When testing this a bit in the legacy tooling I can see a few inconsistencies which I guess we should get right in Papyrus-RT. Not sure though if we shall make this Bugzilla into "feature" Bugzilla and list all the different "refactoring" scenarios when changing the kind of transition, or if it should be limited to its original scope. I have feeling that the different refactoring scenarios is something that could come later, once we are finished with having the basic functionality in place, and probably should be tracked with a separate Bugzilla.
Rémi, could you please look at this, comment, and assign?
Set as assigned, while working on state machines.
(In reply to Peter Cigehn from comment #3) > When it comes to this specific case, i.e. changing the kind to/from external > (or local) to internal, that is a case that definitively should be supported. > > The legacy tooling allows an external self-transition to be changed both to > a local self-transition as well as an internal transition. So this shall be > supported. > > There are a few things to keep in mind though, e.g. when it comes to the > ownership of the transition (changing from external self-transition to local > or internal should change the ownership of the transition from the region of > the parent state(-machine) to the region of the (composite) state, and > automatically creating entry/exit points (as discussed in Bug 494284). When > testing this a bit in the legacy tooling I can see a few inconsistencies > which I guess we should get right in Papyrus-RT. > > Not sure though if we shall make this Bugzilla into "feature" Bugzilla and > list all the different "refactoring" scenarios when changing the kind of > transition, or if it should be limited to its original scope. > > I have feeling that the different refactoring scenarios is something that > could come later, once we are finished with having the basic functionality > in place, and probably should be tracked with a separate Bugzilla. I wrote a separate, more general bug tracking all the different toggling scenarios that needs to be supported. So this bug is only one special case of all the ones covered by Bug 508754.
