Specifying Item Flow with Object Flows

Activities, and the Actions they are composed of, typically do work by processing items that arrive on Input nodes and, when the work is complete, placing the resultant items onto Output nodes. As was discussed earlier, Activity modeling in the SysML is based on a branch of mathematics called Petri Nets, which is concerned with discrete State Event systems. The items that arrive at the input structures must pass through the graph of Activities and their contained Actions in an orderly and systematic way. The passage is created by Object Flows that act as conduits to carry tokens from one node to another. The tokens represent a number of different types of 'thing' including information, structures or physical items such as solids, liquids and gases. There are thus two important parts to the way that items pass through the Activity - the nodes that act as origins and destination of tokens, and the connectors (conduits) that transmit the items.

Enterprise Architect has full support for modeling these flows, and when a diagram is created or opened for editing, the Toolbox contains the Object Nodes as shown:

It also contains a section that lists the Object Flow relationships that can be used to connect the nodes, creating the conduit for the tokens to flow from one node to another.

Orchestrating the Flow of Tokens

When modeling complex systems there is often the need to create more elaborate paths (conduits) for the token flow, such as forking and joining paths to allow tokens to be sent to a number of object nodes so that work can be done simultaneously, or to allow tokens to be routed down a particular path based on some condition. These Control Nodes control flow and are grouped together on a page of the Diagram Toolbox.

Enterprise Architect allows the connectors to be manipulated to create any path that is required. This can be done by utilizing the line styles from a connector's context menu; the most flexible of these is the Custom Line Style, but there are several other styles that are very useful. A modeler can also fix the connector ends to a specific part of the Source or Target element.

Storage for Tokens in Transit

During the execution of an Activity it is sometimes necessary to store tokens for a longer period of time than is possible with Activity Parameters and Action Pins, which act simply as temporary storage devices. A common circumstance is when a number of Actions require access to a stream of tokens - the tokens can be stored in a Central Buffer and made available to the nodes that require them. The Central Buffer accepts all tokens on its incoming flows, then makes the tokens available to downstream nodes; once accepted, the tokens are then removed from the buffer.

The Central Buffer can be created by dragging the 'Central Buffer' icon from the Toolbox onto an open Activity diagram; it can then be connected to other object nodes using Object Flows.

Thus the Central Buffer can, during the execution of the Activity, be replete with tokens or empty depending on the consumption of tokens. Another type of node is the Data Store, a specialization of the Central Buffer where, as tokens are consumed by downstream actions, a copy is made and stored back in the buffer. This has the effect of the Data Store having the appearance of a permanent store - but only for the lifetime of the Activity's execution.

The Data Store can be created by dragging the 'Data Store' icon from the Toolbox onto an open Activity diagram; it can then be connected to other object nodes using Object Flows.