Community
Participate
Working Groups
This is an extraction of a remaining aspect from Bug 513613. Currently when the redefined composite state is re-inherited back to a simple state, then the incoming/outgoing transitions are left redefined, even if they really don't need to be redefined. An enhancement is that the transitions also should, implicitly, be re-inherited to avoid that the user have to manually go through and re-inherit the transitions one by one. This is also how the legacy tooling supports. One improvement compared to the legacy tooling though is that the transitions *only* shall be re-inherited unless they are redefined in some other way than just redefining the source/target of the transition to reference the entry/exit point of the composite state, e.g. if the effect code of the transition is redefined. The rule should be that the transition should only be implicitly re-inherited is that all its property values are "unset" and thus inherited from the superclass and thus there is no need for any redefinition. If any of the properties are explicitly set (even if they are explicitly set to the same value as in the superclass), then a redefinition is needed. It should be investigated whether some generic support for all redefinable elements can be introduced, or if only this specific case of implicitly re-inheriting transitions when re-inheriting a composite state should be handled.
New Gerrit change created: https://git.eclipse.org/r/95423
Gerrit change https://git.eclipse.org/r/95423 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus-rt/org.eclipse.papyrus-rt.git/commit/?id=2200e7d78afcdc7d0b8d3372b6f81b2aa16bd62a
(In reply to comment #2) > Gerrit change https://git.eclipse.org/r/95423 was merged to [master]. This addresses the problem described in comment 0 as well as scenarios in which the composite state being re-inherited redefines a state that is not simple but composite. In such cases, there may still be locally-defined connection points that will disappear and so have an impact on transitions connecting through them: * a locally-defined transition on a local connection-point is deleted because it cannot be updated to just connect directly to the re-inherited state because that state is still composite and so requires connection-points * an inherited transition that was redefined to connect to the re-inherited state via a locally-defined connection point has the appropriate source/target property re-inherited to re-connect to the vertex from the parent context. And, as per comment 0, if that results in a transition that is indistinguishable from the redefined transition, then it is re-inherited altogether See the test model used by new JUnit tests for examples of these scenarios.
Verified to be fixed in the latest Papyrus-RT build (#583). When re-inheriting a composite state back to a simple state, also re-inherits the incoming/outgoing transitions (unless they still needs to be redefined for some other reason, e.g. if their effect code have been redefined as well). Also verified that the two additional cases mentioned in Comment 3 works as expected. Putting this bug into verified fixed. When we have all these nice features, I wonder how much is actually left to support Bug 512295 for the core feature of converting a composite state back to a simple state, for the non-inheritance case, which currently is planned for future? We actually have much more elaborate handling of the inheritance case, compared to basic feature, which feels a bit strange... :)
Closing as verified fixed.
