Execution order

Execution order

All sequencing within an activity is determined exclusively by data availability. The vertical order in which the actions are written, for example, is not relevant to action sequencing. To process an activity during runtime, it is necessary to convert an activity into a data flow graph to determine the required sequencing.

The execution of an activity begins immediately, upon either state entry or explicit invocation depending on the activity type, state, method, etc. Any input parameters and any data in the class model is immediately available.

Each action in the activity may execute only when all of its inputs are available. An input to an action is either a data flow, as represented by a variable or a class model access, an input parameter designated in the activity signature, or a sequence token (more about those later).

When an activity first starts, any action whose input consists entirely of input parameters or class model accesses may execute immediately. Any action requiring a sequence token, temporary variable value or output from some other action must wait until these items are made available. On a data flow diagram we can see the order in which inputs will become available and, thus, determine which actions can proceed concurrently and which must be sequenced.

Let’s examine the data flow diagram for the following action from the Searching for new destination state in the R53 // Shaft assigner state model.

// The Cabin in this Shaft is stationary and has no Transfer
cabin in shaft .= /R2/Cabin
destination aslev .= cabin in shaft.Ping both ways()
destination aslev? {
    Execute -> *Transfer &R53 cabin in shaft, destination aslev
    Transfer created -> me
} : No destination -> me

We can view this as the following data flow diagram:

images/control-flow-10.png

On this diagram, classes are shown as rectangles and temporary variables appear between parallel lines. Solid lines with arrow heads represent the flow of data. A write access points into a class or store while a read access points into an action.

Upon invocation, all input parameters are considered available. The class model content is always available. A variable is available once it is initialized with a value. A sequence token is available upon completion of an associated action block.

The data flows with no origin are either input parameters or data supplied or implicitly assumed in the action text. The R2 relationship name is taken from the Hop action’s path name text. The me.Shaft input is implicitly assumed by context (me, in this case, is the partitioning instance for a multiple assigner, which will be some instance of Shaft). The Cabin class is specified in the path name text and we assume all class model data is available. Therefore, the Hop action can execute immediately when the activity starts. Note that all of the faded out actions require data which is not immediately available.

images/control-flow-20.png

The next action to execute will be the Ping both ways method of the Cabin instance selected by the Hop action. This method takes no input parameters, but it does produce an instance of Accessible Shaft Level as its output which is assigned to the destination aslev instance set variable.

images/control-flow-30.png

At this point all remaining downstream actions may execute, though there is a conditional dependency determining which set of actions will execute. If no destination was selected by the previous method action and destination aslev is empty (false), only the signal action on the left sending the No destination signal will execute. Otherwise, the signal action on the right sending the Transfer created signal will execute. In either case, the Create action executes, but it will have no effect if the destination aslev variable contains the empty set.