Activity Semantics

Activities are a type of behavioral diagram used in software development. Activities use data flows and are also known as flow charts. Activity semantics can describe the behavior of an application in detail so that code can be generated from it. Reactive Blocks combines traditional programming (algorithms) with code generated from activity diagrams describing the data flow.

Activity Steps

The behavior of an application is executed in activity steps. These are steps that are executed in isolation. An application waits until an event happens. Once this event happened, the application executes all actions that can be executed, and then waits again for the next event.

Activities can be understood with the flow of tokens. Think of tokens as a coin that you can move along the edges and nodes of the activity diagram. A token movement is started by a triggering event (see below) and the activity step is finished once all tokens have found their new stable positions.

Triggering Events

An activity step is always triggered by one of the following events:

  • Startup via initial nodes, when the application or system is activated. Each initial node holds one token whan starting an application and all of this tokens (one or many) are one triggering event.
  • Timeouts, once timers expire.
  • Event receptions, once an event is dispatched by one of the building block’s operations.
  • Spontaneous transitions (which are triggered from inside a building block, effectively by an event perception or timeout within a building block.)

Stable Positions

An activity step is finished once all moving tokens found a stable resting position. Such stable positions are the following:

Position   Description
     
  A token enters a timer. This means that the timer is activated, and the token entering the timer stops. The token will leave the timer (and trigger a new activity step) once the timer expires.
     
  A token enters an event perception. This means that the event perception is activated, and the token entering the event perception stops. The token will leave the event perception (and trigger a new run-to-completion step) once the event occurs.
     
  A token stops once it enters a flow final node. In this case, the token is just removed.
     
  A token also stops when it enters an activity final node. In contrast to a flow final node, this means that the entire application is terminated after all tokens in this activity step have arrived in their final position.
     
  A token stops when it enters an incomplete join node. This means that the join node still needs tokens to arrive on the other incoming edges to fire through.
     
  A token stops when it enters an operation which has many parameters and is incomplete. This means that the operation still needs tokens to arrive on the other pins for parameters to fire through.
     

In the following cases, tokens do NOT stop:

  • Set and get variable actions
  • Decision node
  • Join node in which all other incoming edges already provide a token. Then the join node fires immediately, without waiting.
  • Operation which has zero or only one parameter. This is because we assume operations do not block, but execute quickly. If an operation should nevertheless perform a long-running operation, there exists a special pattern to handle this case, using a thread and an event reception.
  • Operations with several parameters work similar to joins. Tokens do not stop if all parameters are available.

Activity Steps Passing Through Blocks

An activity step corresponds in an activity diagram to a subgraph of the activity, consisting of all nodes and edges that are traversed within one single step. Each edge that is a part of an activity step is passed by exactly one token. Therefore, activity steps can be visualized through highlighting parts the activity diagram, which is done in the animation modus of the tool.

An activity step may also pass through blocks. Each block of an activity contributes in one of three ways to an activity step:

  • The block is passed by tokens, and contributes with exactly one transition to the activity step.
  • The block is not involved in the activity step at all. No tokens are moved through it, and the block stays in its state.
  • The block is blocked, since tokens arrive in a way that harm its block contract. Then token arriving at the pins are simply stopped.

Example

  • Let’s have a look at the Speech and Buffer application from the Speech Buffer Tutorial, which you can import from blocks.

  • Start the animation to explore possible activity steps within this system:

  • In the beginning each initial node carries one token. These tokens are the triggering event causing the next activity step to happen. In this system, there are two executable activity steps possible as either initialization of block Speech fails:

  • …or initialization of block Speech succeeds:

  • Both executable activity steps are possible after having starting this application and both activity steps are triggered by the same triggering event, namely the tokens sitting at the initial nodes.
  • What precisely is happening in the case of successful initialization of block Speech? To understand what is going on it helps to open the contracts of involved building blocks:

  • Block transitions involved in the current activity step are marked in yellow.
  • The token from the left initial node moves to the first fork node, which consumes the incoming token and forwards one token to each of the two outgoing edges. One token moves to the first timer, where it stops as this is a stable position. The other token moves from the fork node to operation getFirstSentence and further via two merge nodes to pin add of block Buffer Eager Simple, which participates in this activity step with transition add/ going from state intial to state firstItemAdded.
  • The token from the right initial node moves to pin init of block Speech, which participates in this activity step with transition init/ready going form state initial to state active. The token emitted via pin ready is ignored within this application, so there is no moving token anymore to take into account.
  • Once this activity step is executed, the timer to the very left carries one token. The animation shows again two possible activity steps from there, one triggered by this token the other one triggered by Buffer Eager Simple emitting a token via pin out (this is a so called spontaneous transition).