Introduction
Kingly lets you declaratively describe the behavior of reactive applications with state machines. We introduce separately here each of these concepts. In the next section, we show how Kingly integrates them to implement applications with state machines and decouples behavior from appearance.
Reactive applications
Reactive applications are reactive systems that operate rarely in isolation, communicating and receiving communication from external systems. Those external systems are often accessed through interfaces (e.g. APIs). We will call them interfaced systems.
Reactive systems have several definitions that are often scoped to a specific field. We use the one that is often used in academia: reactive systems are systems which continuously react to inputs from the environment by generating corresponding outputs. David Harel, the creator of the statecharts visual formalism, explained the distinction between transformational systems and reactive systems as follows:
A transformational system accepts inputs, perform transformations on them and produces outputs. […] Reactive systems, on the other hand, are repeatedly prompted by the outside world and their role is to continuously respond to external inputs. Common to all [reactive systems] is the notion of the system responding or reacting to external stimuli, whether normal user-generated or environment-generated ones […] or abnormal ones.
Reactive application behavior
The vast majority of the software applications that we write are thus reactive in nature. They continuously react to user or environment inputs. The task of specifying such applications thus consists of specifying the reaction(s) of the application to inputs across its lifetime. Harel further explains:
The problem [of specifying reactive systems] is rooted in the difficulty of describing reactive behavior in ways that are clear and realistic, and at the same time formal and rigorous, sufficiently so to be amenable to detailed computerized simulation. The behavior of a reactive system is really the set of allowed sequences of input and output events, conditions, and actions […]
State machines
State machines are one way by which the behavior of reactive application can be accurately specified or modeled. There are many kinds of state machines, depending on the capabilities that we give to the machine (e.g., memory, hierarchy, communication mechanism).
- Finite automata accept inputs but do not produce outputs.
- Kingly relies on hierarchical state machines with memory (encapsulated internal state) that compute outputs from received inputs. That type of machines is called hierarchical (because it admits sub-machines as control states) state transducer (because it computes outputs).
- Harel’s statecharts are based on communicating hierarchical state transducers. That means statecharts computes outputs, admits sub-machines as control states, but can also be comprised of several isolated machines that are not in a hierarchical relationship and communicate together through some mechanism (e.g., broadcasting).
Unless otherwise mentioned, when we will talk about state machines, we will talk about the kind of state machines leveraged by Kingly, i.e. hierarchical state transducers with memory. Let’s see how all of this is useful to specify the behavior of reactive applications.