Many of the ideas carried over to UML, and statecharts are used in many areas of software and hardware engineering today. They're useful in many different aspects of modern development (especially in user interfaces) because they strongly encourage the developer to explicitly model the "finite states" of an application, instead of writing ad-hoc logic everywhere in a haphazard way.
Like any technology choice, statecharts shouldn't be used for everything, and should be used when modeling complex application logic with (potentially hierarchical/orthogonal) finite states is appropriate.
A few times I've seen someone on HN bring up the idea of using statecharts for UI implementation. Many years ago there was a book around this idea, but I wasn't able to get a copy before it became very rare.
I've always wondered if statcharts were a powerful enough abstraction to handle everything I needed, and would like to read more about its specific application to implementing UIs. Does anyone have any other references, books, etc?
I have been looking for that too and could not find much, at least not much that is available for free. That said, I give a series of example of miscellaneous complexity in Kingly documentation site (https://brucou.github.io/documentation/). Kingly is a state machine library that replicates pretty much the formalism of statechart, without its concurrency model (i.e. no parallel states). Interestingly the amazon book you quote is also recommending to make spare use of parallel states (if I remember well, it recommends to use it only at the top-level of the chart, and when possible not at all).
Anyways, on the Kingly site, you will find the following examples:
- a counter (yeah there is always a counter or hello world somewhere)
- a keypad app (with Svelte)
- a password meter (tells you if yuor password is strong enough)
- a two-player chess game (with React)
- an interface to an online movie database (with 7 different UI libraries, including Vue, React, Svelte, Ivi)
- a wizard form (with cycle.js)
- an implementation of suspense functionality (with Svelte)
- an implementation of Conduit, a clone of Medium. Conduit is considered to be, like TodoMVC a benchmark of miscellaneous approaches to UI implementation, but for a real world complex application.
All of that may be useful to you, with the benefits that you won't have to make the examples, as I had to, to evaluate the applicability of the technique to UI implementation.
If there is anythign you do not understand let me know.
They are not powerful enough to model complex UIs. In terms of expressiveness, state machines are equivalent to regular expressions. That's why I find the title quite misleading. They may be useful to some extent for very simple UIs (for instance, Siemens Mobile has used them to model mobile phone (app) UIs).
Statecharts _builds upon_ state machines, but is a more powerful language to model a system's state than FSMs or regular expressions. There's a good explanation here [1].
Flattening the nested states would produce an explosion of states. This page describes how Statecharts avoids that [1].
In regard to expressivity, specially compared with FSM, a thorough description can be find in the paper "On Visual Formalisms" [2]. I copy some points here for convenience:
...people working on the design of really complex systems have all but given up on the use of conventional FSMs and their state diagrams for several reasons
(1) State diagrams are “flat.” They provide no natural notion of depth, hierarchy, or modularity + orthogonality + broadcast communication.
(2) State diagrams are uneconomical when it comes to transitions [...] resulting in an unnecessary multitude of arrows.
(3) State diagrams are [...] infeasible: as the system under description grows linearly, the number of states grows exponentially.
(4) State diagrams are inherently sequential in nature and do not cater for concurrency in a natural way.
State charts have parallel states, which require an exponential number of states with a finite state machine. And it supports history—returning to a container state can return to the last entered state in that container, whichever it was—I’m not sure if finite state machines can support that or not. Maybe they can, but again, it would vastly explode the state space.
State machines are a generic term. You will find here the different kinds of state machines, with varying expressive power that are used in computer science and actuak programming: https://github.com/achou11/state-machines
In any case, keep in mind that Turing machines are (extended) state machines (albeit with infinite memory) so the expressive power of state machine is at least anything computable (sequentially - turing machine is a model of sequential computation).
This article is from 1987 and feels way ahead of its time. One of the (sad) conclusions was:
> (4) The future lies in visual languages and methodologies that, with appropriate structuring elements, can exploit all the obvious advantages of graphical man-machine interaction.
> As to thesis (4), we believe that before long scientists and engineers will be sitting in front of graphical workstations with large (blackboard size?) displays of fantastic resolution, carrying out their everyday technical and scientific chores.
> The ‘real’ description of the object is usually given in some textual, algebraic form, and the picture is there only to help see things better, and to assist in comprehending the complexity involved. Here we are suggesting that visual formalism should be the name of the game;
> Textual representations of these visual objects can be given, but they are the aids (e.g., for users lacking graphical equipment, or for applications requiring textual reports), and not the other way around.
Yet, 33 years later we are nowhere close to the man-machine interaction the authors were suggesting.
So Harel did form a company - iLogix (https://en.wikipedia.org/wiki/I-Logix), which developed "no code" visual tools using statecharts, mainly for embedded systems.
Also, in early 2000, there was a movement for "executable UML", (https://en.wikipedia.org/wiki/Executable_UML).
Which was based on state charts, and tried to be the first version of what is today known as "no code".
However, then agile came alone, and we went back to "code is the design", so those methods did not find commercial success.
I find your thesis interesting (that agile ended the top-down design approach resulting from statecharts modeling). Do you have any references/links I can review to support it? It is true that agile seems antithetic to Big Design Up Front (http://www.agilemodeling.com/essays/bmuf.htm). However the methods did seem to have found commercial success (in safety-critical software) albeit not in front-end programming.
I believe instead that the drivers of adoption/rejection are specific to the success factors in specific industries. That or maybe front-end programming is driven more by trial and error (+ hype?) than by engineering.
Wrote my master thesis of chemical engineering in the ninetees about an attempt to model a chemical plant in state charts to assist safety analysis.
State charts allow for formal verification of a model which can be beneficial for embedded, safety critical software like central locling of cars or airbags. VSDL can be generated from Statemate.
We managed to model a significant part of the demo plant, the vessels and valves and such, not any software, but failed with an attempt of verification of properties with temporal logic and theorem provers.
In '97, I defined an (awful) Java-ish syntax DSL for expressing Harel Statecharts textually (including concurrency, substates, etc. semantics), and wrote a compiler from it to Java.
The language was intended as an intermediate representation for a visual front-end for a full-cycle CASE system that would support multiple "views" of related abstractions (e.g., how analysis-level models related to production code-level models, and maintaining consistency among changes to any of them). I never built that CASE system, because I got even more interested in another area.
At the time, I had already worked heavily on production cross-platform multithreading in C++, but Java was so much easier and safer. (Also, the Java was very hot at the time, and with good reason.)
Today, I know Scheme well, and a separately-compiled DSL, for what could instead be a much more elegant and powerful mix of normal Scheme and syntax extension, seems silly.
That is one of the early papers by David Harel which divulgated statecharts among the scientific community. Note that since then, there has been a number of criticisms made about the original statecharts (namely the absence of precise semantics, and the concurrency model) and a number of variants have since seen the day. What seems to have remained in all variants is the concept of hierarchy. In the Kingly state machine library (https://github.com/brucou/kingly), I only use hierarchy and discard broadcast and concurrency. The latter two can be added at will according to the problem at hand.
Many of the ideas carried over to UML, and statecharts are used in many areas of software and hardware engineering today. They're useful in many different aspects of modern development (especially in user interfaces) because they strongly encourage the developer to explicitly model the "finite states" of an application, instead of writing ad-hoc logic everywhere in a haphazard way.
Like any technology choice, statecharts shouldn't be used for everything, and should be used when modeling complex application logic with (potentially hierarchical/orthogonal) finite states is appropriate.
Excellent guide to statecharts: https://statecharts.github.io Community: https://spectrum.chat/statecharts Documentation for XState: https://xstate.js.org/docs/