Example: How to Create a Block Contract

Creating an activity block means creating its activity diagram, providing Java code for operations and creating a block contract. Here is an example how a block contract is developed from the activity steps defined by the activity diagram.

Let us create a contract for the block Simple Server with the guideline described here. The activity diagram of this block is depicted in the following figure.


Informal Behavior Description

Intuitively, the Simple Server block needs to be started first via pin start. Thereafter, it reports every request it receives via pin request until it is stopped via pin stop.


Identification of Activity Steps

The block above has four activity steps as depicted in the next four figures.

  • A token enters parameter start and flows through operation startServer and rests in reception SERVER_STARTED. This means that now the block is ready to receive signal SERVER_STARTED.

  • The token flows from reception SERVER_STARTED (the block now receives the expected signal) through the fork node where it is duplicated. One token flows to operation getServerAddress and output parameter started. The other token flows to reception REQ_RECEIVED, activates the reception and waits there.

  • The token flows from reception REQ_RECEIVED to output parameter request. Note the * symbol on the left side of the event reception. This means that the token stays in the event reception REQ_RECEIVED* and accepts new events repeatedly.

  • A token enters parameter stop and flows through operation stopServer and output parameter stopped. The token does not rest inside the block.


Activity steps and parameter nodes

  • Activity step 1 includes a starting pin. This is a candidate for an initial transition.
  • Activity step 2 includes streaming output started.
  • Activity step 3 includes streaming output request.
  • Activity step 4 includes streaming input stop and terminating node stopped. This is a candidate for a transition to a final state.

Creating the Block Contract

  • From activity step 1, we create a transition from the initial state to a certain state (let us call this state starting) since the token rests in a stable position. This transition involves input parameter start. Since this parameter is a starting input, therefore the transition is from the initial state. In the transition dialog, fill in the information like the figure below.

  • From activity step 2, we create a transition from state starting to a state named active. This transition includes parameter started. Note that a token also rests in another stable position and hence the new state.
  • From activity step 3, we create a self transition of state active. This transition involves output parameter request. It is a self-transition since after the activity step number 3 the token rests in the same stable position just like when the activity step begins.
  • From activity step 4, we create a transition from state active to a final state. This transition includes parameters stop and stopped. Note that the order of the parameters is important, i.e., stop must be placed before stopped. Moreover, since a terminating pin is used here, then the target state must be a final state. In the transition window, fill in the information like the following figure. Use the Move Up or Move Down buttons to make the correct sequence.


The Result

The block contract of block Simple Server should look like the following figure. The upper part shows the tabular form, the bottom part depicts the diagram.

The Reactive Blocks SDK provide Analysis tool to check whether a block and its block contract are consistent. You can use this by choosing action Analyze from the context menu of the block in the Building Block view. Moreover, you can also animate the block in order to determine if it behaves as you intended.

Internal Activity Steps

Let us do a small modification to the Simple Server example above. We add a timer between reception SERVER_STARTED and the fork node as depicted in the following figure.

For this activity diagram, there is an activity step from reception SERVER_STARTED to the timer node and another one involving the timer node, the fork node, operation getServerAddress, parameter started, and reception REQ_RECEIVED. The former step is an internal (with respect to the block) activity step. Therefore, the block contract of this modified activity diagram is exactly the same as the block contract for the Simple Server above.

Composed Blocks

Creating a contract in the presence of inner blocks is described here.