Finite State Machine

or shortly FSM, is a control object, that:

• has an enumerable set of control states, named State for simplicity
• stores local Context for every State and can modify it when transitioning to another State
• reacts to dispatched Actions, transitioning to another State, based on current Context and dispatched Payload. The transition is
  • atomic
  • transactional
  • synchronous
• can reactively observe Events, translating them into Actions
• can emit Events when transitioning to certain States

Essentially, Yantrix generates a code module in any of Supported Languages, containing a Mealy Machine implementation, which behaviour is described by slightly extended Mermaid diagrams.

More academical info on the subject:

• State diagram
• Automata bases programming
• Algorithmic state machine

States

State is enumerable constant, specific for a particular business process. That process is then modeled as a graph of transitions between States and can declare rules of data transformation applied to each of them.

The purpose of State to describe minimum variety of values that significantly impact the behavious of the modeled system. Modeling with States takes some practice, but in the end it grants a lot of benefits, some of them being:

• Atomicity of logic and clear responsibility patterns
• As much synchronous code as possible
• Transactional updates with pre-defined behaviour for each transition
• Similar representation for various data sources, allowing for reproducible primitives and complex behaviours built from them

Every State can have an attached Payload, which is a plain data object that stores quantifiable attributes which describe a given State.

Actions

Actions are plain object that are dispatched ("fed") to FSM via:

• an API,
• using Integrations
• from Event Bus using Event Adapter and mappings, declared in the diagram

An Action might also carry a Payload, which are plain data objects. The States are switching as in response to Actions, one at a time, and they can use Payload properties to define behavior and processing rules. In the diagram Actions are declared as names of transitions. If not specified, Action name is assigned automatically based on its traversal path.

Note that by default declared Actions can only be dispatched when the FSM is in relevant State, otherwise the Action is ignored. If an Action is declared as transition from [*], it can be invoked from any State and performs the corresponding transition.

Forks

Nodes that are declared using Mermaid's <<choice>> directive are not translated into States, but rather represent a conditional transition, that can resolve into different States and attached transition rules. To define a fork:

• create a <<choice>> node
• define an Action in the transition incoming to that node
• label the outgoing transitions from that node with a Predicate that can draw properties both from current Context and the incoming Payload.

Notice: Predicates are being validated in order of appearance, so mind the sequence.

How to use it?

A simple FSM can be represented with Mermaid diagram like this:

However, this is also a valid Yantrix code which can be built into a readymade code, providing abstractions in required language for operating named States, Actions, possibly storing data in FSM Context and defining complex to incoming Events.