Consume a SignalEvent message in a StateMachine Transition 'effect' or State 'entry' or 'exit' Activity

Click on the image to view it full size

This one is subtle (there are a few "gotchas" to watch in implementing it) but it's easy once you've got the hang of it.

We are going to send a Signal(Event) that carries multiple values (attribute Properties) to a StateMachine, where it will be consumed by one of:

  • A Transition with an 'effect' Behavior.
  • A State with an 'entry' Behavior.
  • A State with an 'exit' Behavior.
As we'll see when we run it in Magic Model Analyst® (Cameo Simulation Toolkit®) , if there is a Transition with an 'effect' to a State with an 'entry' the same SignalEvent can in fact be consumed twice!

The SignalEvent available to the 'exit' Behavior of a State is for an outgoing Transition.

We have a class Sender with an owned part target:Consumer. Note that it is of aggregation kind 'composite', otherwise when you run from the Sender it won't start the StateMachine of Consumer.

We have a Signal named SigWithValues that carries an i:Integer and a r:Real value. (You can have course use more complex types with sub-structure, but then you have to do additional unpacking, we'll keep it simple for now.)

The StateMachine ConsumerSTM has a Transition with a SignalEvent trigger for SigWithValues and an 'effect' Activity called EffectConsumer, which simply prints each of the received i:Integer and a r:Real with the prefix "effect:".

Note how there is exactly one ActivityParameterNode for each attribute carried by the Signal

That happens to be an implementation choice for Magic Model Analyst® (Cameo Simulation Toolkit®) , it is not clearly specified in the UML spec. It's a common sense pattern and easy to follow.

The State Behave has a similar 'entry' Activity called EntryConsumer, and an 'exit' Activity called ExitConsumer, which will be invoked when another SignalEvent for SigWithValues triggers the outgoing Transition.

Note that each SignalEvent may carry different underyling values!

The implementation of the driving activity Sender is a little tricky, but only because this example combines all three cases; in a typical application you would probably not have the same signal type driving each of an 'effect', 'entry', or 'exit' this way. The Next AcceptEventAction and the End AcceptEventAction are required to make the Sender wait while the ConsumerSTM does its processing.

This is the console output from Magic Model Analyst® (Cameo Simulation Toolkit®) :

00:00:00,000 : **** Class Sender is initialized. **** 
00:00:00,000 : **** Class Sender behavior is started! **** 
effect: i=1 
effect: r=2.2 
entry: i=1 
entry: r=2.2 
exit: i=3 
exit: r=4.4 
00:00:59,058 : **** Activity Sender execution is terminated. **** 
00:00:59,059 : **** Class Sender execution is terminated. **** 
Visit also this video showing the simulation in Magic Model Analyst® (Cameo Simulation Toolkit®) :

You may wish to visit one of these tutorials next:

Visit more Systems Modeling Language (SysML®) tutorial trails here.
Visit also these screencast tutorial videos

Please email or phone Webel IT Australia on +61 405 029 008 or +61 (2) 9386 0090 to arrange on-site, off-site, or live remote web training seminars and workshops
Watch full video
Up next
Snippets (quotes/extracts)
Visit also
Visit also (backlinks)
Related slides (includes other tutorials)
Related slides (backlinks, includes other tutorials)