The Ping Pong model demonstrates how events are sent and received by active entities, or more precisely by two objects from different entities having state machines. The model has no Real World significance. Another version of the Ping Pong model is described here.
The function of the model is for one object to send an event to another and then wait for an event in return. The first object then sends the event again. This is repeated 5 times. As the model progresses through states status messages are displayed.
The Domain Bridge Diagram (DBD) below has the standard single domain drawn on it. We do this for all models at this time.
The Entity Relationship Diagram (ERD) shows two entities Ping and Pong, two attributes that belong to Ping, and two unary relationships, Ping:Signals:Pong & Pong:Replies:Ping, that form a binary association.
Ping's attribute names are prefixed by a type name called Index.
Below is the State Transition Diagram (STD) for the Ping entity. We can see that an object of Ping is created synchronously (via a CreateActive action process or at initialisation) since there is no transition into the creation state. In this case the object is created at initialisation by specifying the instance in an Object statement.
On receiving the Go event (triggered by an ObjectEvent statement), Ping's only object's state machine transitions into the Sending state. In this state two events are sent. One is a self directed event that causes the Ping object to transition into the Waiting state. The other event goes to the Pong object which sends back the Go event and this causes the transition to the Sending state.
The cycle is repeated 5 times after which a Die event is sent to both objects. The Die event causes entry into the deletion state called Terminated after which the object ceases to exist.
Below is the Process Flow Diagram (PFD) for the Sending state. The PFDs for the Activate and Waiting states are not shown since they have no actions.
Click on the picture below to get a clearer view of the diagram.
The transition event enters the diagram from the top and executes the Assignment action process first. The control and data flow carries the Ping object signifier which makes the object's attributes available to the process. By examining the Matrix code we can see that Ping.Count is incremented by one. The result is written to the Ping data store that corresponds to the collection of objects that belong to Ping.
The flow of control proceeds to the Traverse process which reads Pong's data store and makes all Pong's objects (in this case just one) that are related to the Ping object available to the CaseSelection process and eventually to the GenerateEvent processes.
If the number of events to be sent by Ping has not yet been reached, a message is displayed and Ping:Wait & Pong:Go events are sent. Otherwise, the Ping:Die & Pong:Die are sent.
The PFD of the Terminated state displays a message and unrelates the relationship to the Pong object before the Ping object is automatically deleted.
The Pong's STD is very similar to Ping STD.
Pong's PFDs are than simpler Ping's and there are no further insights to be gained here.
Click on the Code Map diagram below to get a view of the code.
When the Matrix model is executed under the Simulator with all tracing turned off the following display output is produced in the command prompt window:
Matrix Model Simulator - Learning Edition - Version 1.0.0
Development on THU-02-JAN-2014 @ 12:24:18
Copyright (C) 2014, Dark Matter Systems Ltd. All rights reserved.
Connection established: MATRIX*CORE - Version 0.5.2
$ | Ping_Pong Scenario
$ trace all off
$ trace display on
$ trace events on
$ trace states on
$ initialise all
Ping Pinged (1)
Pong Pinged (1)
Ping Pinged (2)
Pong Pinged (2)
Ping Pinged (3)
Pong Pinged (3)
Ping Pinged (4)
Pong Pinged (4)
Ping Pinged (5)
Pong Pinged (5)
$ display all
$ host pause
Press any key to continue . . .
Model Simulation Elapsed Time: 00:00:01
Disconnected from MATRIX*CORE on THU-02-JAN-2014 @ 12:24:19