Applications are constructed from reactive building blocks. A reactive building block is a combination of tightly connected diagrams and Java code.
The behaviour of builidng blocks is normally defined using activity diagrams. It is also possible to define the behaviour using state machines, either using a so called shallow block that has no internal behaviour, only a block contract, or using a so-called state machine block where the internal behaviour is defined using a state machine in stead of an activity diagram. In order to control the instantiation of blocks they are be classified as either normal, single session, multisession or singleton blocks. Application blocks are top level activity blocks needed to define an executable system.
An activity block describes behavior that is executed locally on a single component. However, operations may invoke code that interact with code on other machines via an API. The behavior is specified in an activity diagram. This type of block has input ( ) and output ( ) pins. It does not have initial nodes nor activity final nodes.
The Send Email block below is an example. The upper left part shows the block seen from outside, the bottom part shows activity diagram detailing the block behavior, the upper right part shows the block contract.
An application block specifies an application at the highest decomposition level. It is an activity diagram that does not have any input or output pins, but initial nodes () for start and activity final nodes () for termination. To build applications, you need this type of block as top-level element.
The figure below shows an example of an application block.
A shallow block is used to coordinate flows in an activity diagram using only block contract and no internal activity. Formally they behave like state machines. From the outside they look like ordinary blocks, but internally there is no activity.
The Toggle block below is an example. The upper left part shows the block seen from outside, the contract is shown on the right handside, and the bottom left lists the pins of the block.
Sometimes blocks have a state machine kind of behaviour that is better described using state machines than activities. State machine blocks enable you to describe the internal behavior of a block as state machine. This kind of block does not have an activity diagram, but a table defining transitions of the state machine. Therefore, they cannot have inner blocks. State machine blocks also have a block contract. The contract is, however, derived automatically from the state machine behavior. Java methods implement guards and operations used by the state machine.
The figure below shows an example of a state machine block. The upper left part shows the Buffer Eager Simple block seen from outside, its behavior in state machine table is shown on the bottom part, the generated block contract is shown on the upper left part.
The behavior of the Buffer Eager Simple block can also be viewed in a state machine diagram as depicted below.
Read more about state machine blocks here.
A singleton block is like an activity block, with the exception that all uses of the block refer to one single block. It is typically used to control access to one or more shared resources.
This type of block has two block contracts:
The provider contract needs to take into account possible multiple invocations from many uses, while the client contract only need to consider a single use.
When the block is used in another block, you will see it has a thick grey outer border and its pins have type (a collection of)
The figure below shows an example of a singleton block. The upper left part shows the block seen from outside, the bottom left describes the internal behavior in an activity diagram. The ones on the right-handside shows the client and provider contracts of the block.
Read more about singleton blocks here.
A multi-session block is also like an activity block, with the exception that multiple concurrent instances of the block are created, each maintaining a session (hence the name multi-session). Input and output flows need to carry addressing information to identify the receiving/sending instance.
The figure below shows an example of a multi-session block. The upper left part shows the block seen from outside (note the thick blue lines on its border), the bottom left describes the internal behavior in an activity diagram. The block contract is shown on the right handside.
Read more about multi-session blocks here.