Hierarchische State Machines

For stateful development with asynchronous messages we offer hierarchical state machines (HSM). These follow the UML State Diagram standards and are very well suited to model complex processes.

Essentially, we assume that each non-trivial message traffic is accompanied by the states of its objects involved. The HSMs represent the state of the object. The core idea is that an object cannot process all the messages it supports at a certain point in time.

Examples:

  • Object A can only handle the request of object B once the previous request has been completed.
  • For a request, an object must first send some messages to a third and fourth object before it knows the answer.
  • Since an object A is already in the state Z, it makes no sense to accept messages that put it in the state already reached.

The hierarchy of states in an HSM makes it possible to inherit message handling from their parent states. This allows for efficient coding by passing messages up the hierarchy of states if they are not handled. Existing implementations in parent states are thus reused.

When entering or leaving a state (during a transition), the system also generates entry, start and exit messages. This ensures that no initialization or cleanup work is forgotten.

Simple Example:

When the refrigerator is opened, the light is switched on, when leaving the open state, the light is switched off.

State machines are particularly useful when encapsulating resources that can only be processed by one transaction at a time. For transactions that can run in parallel, it is usually easier to start an extra target for processing.

HSM are a common pattern for message-based development, and devel.one supports it.