Hi, Ernesto,
Yes and no. The transition’s own guard is specifically called out by being in the Transition::guard subset of the Namespace::ownedRule collection of the transition.
But, indeed, the spec does indicate that the stereotype signals the intention that the constraint is a guard for a trigger and not some other kind of constraint. But, then again, the fact of the trigger being in the Constraint::constrainedElement would also indicate this intention, so the stereotype seems perhaps to be redundant. But I suppose that users are free to model constraints for their own purposes, even referencing triggers as constrained, so it is important to use this stereotype, right?
And, yes, the RSA-RTE conversion paragraph in the spec does require that the importer apply the stereotype to all constraints that happen to constrain triggers, because there’s just no other way to infer the intent from a tool that didn’t have this stereotype.
So, who makes the call on whether a constraint without this stereotype that happens to constrain a trigger shall or shall not be treated as the trigger’s guard?
On Feb 7, 2017, 11:34 -0500, Ernesto Posse <eposse@xxxxxxxxxxxxx>, wrote:
The constraint is not owned by the trigger but by the transition. It's the stereotype that distinguishes a trigger guard from the transition's guard. So if you have a constraint that doesn't have the stereotype, you don't know if it's a trigger guard or a transition guard.
BTW import is not yet adding the RTGuard stereotypes, but there is a bug for it.
--
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?
_______________________________________________
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
--
_______________________________________________
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
