| Re: [papyrus-rt-dev] Question about Trigger Guards |
Hi,Yes, the tooling should apply the RTGuard stereotype, including also the import tool, which currently does not do this either, which is tracked by bug 511060.Since the intention with the RTGuard stereotype is to uniquely identify the constraints that are used for the trigger guards (since base UML does not support trigger guards, and only transition guards), I would say that I disagree with Ansgar. The intention with the introduction of the RTGuard steretype in the UML-RT profile for Papyrus-RT, was to make it clear that these constraints indeed are the "extension" of base UML to support trigger guards. The constraint used for the transition guard shall *not* have the RTGuard stereotype (since it is clear from base UML that the constraint is used as a transition guard).So don't be "forgiving" when the RTGuard is missing, because it was introduced due to exactly the reason of making the model precise.
We must ensure that the tooling, and the import tool, applies the RTGuard stereotype correctly.One "problem" with the tooling is that the current support for editing the trigger guard is not what we want as the final solution. I see this just as a "work around" (in the corresponding way as we had a "work around" for a long time when it comes to the trigger creation dialog which we finally have gotten in place). The final way to create/edit a trigger should be via the code snippet view tracked by bug 494288 (and not "inline" in the trigger table as it is done now). Unfortunately the code snippet view will not make its way into 0.9, but is currently planned for 1.0.So we need to fix the current "work around" with the inline editing in the trigger table, to ensure that the created constraint have the RTGuard stereotype applied. This was an oversight during the testing when this was introduced in the tooling. Due to the lack of support for the code snippet view, the creation of the transition guard on the other hand is made "completely by hand" so we currently provide a rather strange user experience regarding the editing of the transition guard vs. the trigger guard./Peter CigéhnOn 7 February 2017 at 17:31, Ansgar Radermacher <ansgar.radermacher@xxxxxx> wrote:Hi Christian,
in my opinion, a missing RTGuard stereotype should not imply to ignore a constraint (by the facade), since it is still a valid UML constraint and it might not be evident for a user why it is not taken into account. Yet, the tooling should systematically apply the stereotype for created guards. Thus, the problem becomes only an issue for broken or legacy models.
Best regards
Ansgar
On 07/02/2017 17:13, Christian Damus wrote:
Hi, Team,
I am now working on support for state machine inheritance in the state machine diagram. Along the way, I have updated a few of the utilities that support presentation of decorations in the diagram (and the explorer) to use the façade API to simplify access to the details of potentially inherited elements.
However, I have a test failure in the State Machine Diagram Tests in the validation of the decorations for transitions: a transition that is supposed to show the shield decoration for a trigger guard and a gear decoration for a transition effect is now not showing the guard decoration.
It turns out that the reason for this is that the trigger guard constraint in the test model does not have the «RTGuard» stereotype applied. It is my understanding from the UML-RT Profile Specification that this stereotype is required to designate a constraint as a trigger guard, so the façade API will not report a guard for a trigger when this stereotype is missing. The reason being that, otherwise, the constraint is merely informative (I suppose).
My questions are: should the façade API and the tooling not ignore constraints for triggers that omit this stereotype? Should the tooling not apply this stereotype to the constraint that it creates for a trigger guard?
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/mailma n/listinfo/papyrus-rt-dev
-- Ansgar Radermacher CEA/DRT/DILS/LISE http://www-list.cea.fr/index.htm phone: +33 16908 3812 mailto: ansgar.radermacher@xxxxxx
_______________________________________________
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