Home   :   Other Stuff   :   xUML in Second Life   :   Ping Sending State

The Ping Sending State Actions

The generated event is placed in the receiving Ping instance's “newPing” (strictly speaking this handle is out of scope here) Event Pool.   It lies ready in the pool to be consumed by the State Machine when free, which is, in this case, immediately.

The absorption of the event causes the State Machine to "move" from the “Activate” state to the Sending state.  Notice that there is another "go" transition in this State Machine.  This has no bearing on the current situation since we are only interested in transitions coming out of the current state which is "Activate".

Once in the new "Sending" state it progresses though the state actions.  The first state action statement is:

this.count = this.count + 1

This reads the newPing's fact called “count”, increments it by one then writes it back to the fact “count”.  This allows us to keep a record of the number of times the model has progressed through the "Sending" state. 

Next, we find which instance of Pong is related to this (newPing) instance:

myPong = this -> R1

This statement navigates the association to establish the value of the handle called myPong.  The link between the two instances was formed earlier in the Initialisation Segment.

A test to see if the handle returned from the navigation is valid is next:

if myPong != UNDEFINED then

Which is superfluous in this situation as the Association is actually 1:1 and not conditional in any way.  We then test to see if the demonstration has gone on for long enough:

if this.count > 3 then

On this first iteration, count has the value of one at this point causing the:

else

Part of the if statement to execute.  Here the actions are to generate a "go" signal to the associated Pong instance called myPong:

generate POG1:go() to myPong

This signal appears momentarily in the myPong instance's Event Pool.  The second action is to generate a self directed “wait” signal.  Self directed signals take priority over signals from other State Machines and so are never placed in the Event Pool:

generate PIG2:wait() to this

The reason for the above statement is to make the State Machine "move" to the "Waiting" state after the "Sending" state completes and goes dormant.

The final action is to display a message via a Domain Operation indicating we have successfully sent the signal to myPong:

[] = PP1::outputString["PING_PINGED"]

Once invoked, the Domain Operation appears, displays the message to the user and then disappears.

Finally for this state, both if statements are terminated:

    endif

endif

After the ”Sending” state has completed for the first time, the self directed signal produced earlier has primed the transition to the “Waiting” state.  This is now acted upon and the State Machine changes state.

Notice that there is an event waiting in the Event Pool that has already being sent by the instance in the Pong class.  Now having arrived in the “Waiting” state the State Machine is ready to consume it.

This causes the “Sending” state to be re-entered.  This cycle of sending an event to the Pong instance and receiving one back is repeated a number of times.

When entered for the fourth time the result of the test:

if this.count > 3 then

Becomes true and the “then” part of the if statement is executed.  Here the actions are to generate a “die” signal to self and another to the myPong instance:

generate POG3:die() to myPong

generate PIG3:die() to this

The self directed “die” signal causes a transition to the “Terminated” state where a completion message is displayed.  The state then becomes dormant and the State Machine becomes exhausted.