In the case where the Transition is triggered by a Signal with attributes, the 'effect' or 'entry' Behavior should have 'in' parameters matching those Signal attributes.

What happens if you have both an 'effect' Behavior and an 'entry' Behavior? What happens if you have neither? What happens when the 'effect' or 'entry' Behavior parameters don't exactly match the Signal attributes? Some cases are explored here.

Click on the image to view it full size

Watch simulation

Watch a high resolution version of the video on Vimeo.

Note that an 'effect' or 'entry' Behavior must be owned by its Transition or State, so you can't directly use a Behavior owned by the owner of the StateMachine; for such cases use wrapper Activities, which are indicated here related to their wrapped Activities using a custom Stereotype «wraps».

In the actual example shown, one doesn't really need the wrappers, because the wrapped Activities don't access the owning context EffectVsEntry of the StateMachine, they are just OpaqueBehaviors that print the value 'v'. But in general 'effect' or 'entry' Behaviors might need to access the owning context.

The tool MOSTLY looks after this "wrapping" for you:

MagicDraw/Cameo: If you drag a Behavior from the model browser onto the SYMBOL of a State (that does not already own the Behavior) and set it as an 'entry', 'doActivity', or 'exit' Behavior a "wrapper" Behavior owned by the State will be created.

But some tool actions "steal ownership" of such Behaviors!

MagicDraw/Cameo: GOTCHA: ‘entry’, ‘exit’, ‘doActivity’ are all subsets of ‘ownedElement’; to use an existing Activity without changing its owner you need to create a “wrapper” Activity. Beware the tool does not simply move your Activity!

MagicDraw SysML/Cameo 19SP3: GOTCHA: If you drag a Behavior from the model browser onto the 'entry', 'doActivity', or 'exit' field in a specification dialog of a State it WILL BECOME OWNED by the State (which "steals ownership")!

The example also shows some "pathological" cases. In Magic Model Analyst^® (Cameo Simulation Toolkit^®) one can in fact feed some inconsistent arguments into an 'effect' or 'entry' Behavior. The OpaqueBehavior StringArg with argument s:String accepts the v:Real without complaint! If you instead use an OpaqueBehavior BlockArg with argument b:FAILME - where FAILME is a Block - you at least get a warning like this:

WARN: Illegal value, '[6]' is not FAILME in Call Behavior Action.

But then it still prints the correct value anyway:

blockArg: b=6

There are also cases where the Signal TrigEffectOrEntry is not consumed at all. There is no Transition with trigger TrigEffectOrEntry from State HadEffectBlockArg. A warning is correctly issued to the simulation console:

WARN: the signal TrigEffectOrEntry has not been consumed and removed from the EffectVsEntry@493e7f2c pool

Learn SysML for MBSE with the Webel IT Australia Live Online web seminar or On-Site course!

Please email or phone Webel IT Australia on +61 405 029 008 to arrange On-Site, Off-Site, or Live Online remote web training seminars and workshops.

Course: Model-Based Systems Engineering with OMG Systems Modeling Language® (v1) and the MagicDraw/Cameo (CATIA Magic™) tools for SysML

Webel IT Australia is an OMG-Accredited Training Provider for SysML!