Re: [papyrus-rt-dev] Opaque Behavior and isReentrant

[Bran Selic <selic@xxxxxxx>]

The only case where it might make sense to have re-entrancy in UML-RT state machines would be in local utility operations that a transition/entry/exit/do behavior might need to invoke. However, these behaviors themselves should not be made re-entrant because of the RTC semantics, as Peter points out.

Cheers... Bran

On Tue, Mar 7, 2017 at 7:43 AM, Peter Cigéhn <peter.cigehn@xxxxxxxxx> wrote:

Hi,

When providing feedback for the new code snippet view I bumped into the question which properties that the code snippet view shall set when creating Opaque Behaviors for entry and exit for states and effect for transitions, e.g. setting a name.

When checking the legacy tooling, the Opaque Behaviors created have isReentrant=false. Not sure if that is intentional or not, since the default value for isReentrant is false in the Eclipse UML2 version being used in the legacy tooling. But for the version used in Papyrus-RT the default value of isReentrant has changed to true. This can also be noted if a legacy model is imported into Papyrus-RT then an explicit value of isReentrant=false is now persistently stored in the model file (this is probably handled by the migration from one UML version to another).

Anyway, the question is if we shall ensure to explicitly set isReentrant=false for Opaque Behaviors created by the code snippet view. We already have a constraint in the UML-RT profile that state-machines should have isReentrant=false due to the run-to-completion semantics of state-machines. And since we have this run-to-completion semantics, then I assume that also the Opaque Behaviors for entry/exit/effect also should have isReentrant=false.

Bran, any comments?

/Peter Cigéhn

_______________________________________________
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