
Statecharts: A visual formalism for complex systems [pdf] - sktrdie
https://pdf.sciencedirectassets.com/271600/1-s2.0-S0167642300X00603/1-s2.0-0167642387900359/main.pdf?X-Amz-Security-Token=IQoJb3JpZ2luX2VjEFMaCXVzLWVhc3QtMSJHMEUCIHucfbZrX7uhXZ6g7sPgeMz%2FaNK8vVrrniEMDHpdj8oNAiEA6MndWhkJGxvkmaBiFCeBzAK8i6Cp3TYJ7CUjTsn8%2BZAqvQMI2%2F%2F%2F%2F%2F%2F%2F%2F%2F%2F%2FARACGgwwNTkwMDM1NDY4NjUiDHtJBwUuEOSOkHMD3SqRA96cbj%2B8pFDILB37hoRQqXwXlDLo8cHbqg0DGazBqN3JluH39kLyJ1W2RJQoGYpX56pTvygrv4YsmAXA1XCZTAuUirLwKenI%2BIsuSvZGZhSsxj4nXfoxMdAN0QR9of4WPEUXcvHVlDAcA9w6PhSwE7JDmlnXjC1uHQv6PaTKtvDjTCN7GN2%2F5XUz6UCLJys6Eh3QS7WVur%2BsbY7j5lmSeYVu9%2B%2Bvv1OUaiNvZtDnwowqdMg8MWvmHPgaH1Jw6cnAMJ1twKOJ8pqzN1CB5oUXnca80zNXC8Ll3APvzG6f7FI2YLgaZxY%2FHlS7EMlsg460PYvobzODr7a3vRypr66OmazUfN0QjM%2BPQbx1DT4UbXX6aNwidCuDcVCnGO93PoZI52P5Xm0ayR1Utss69TsbyCIE5ASfHuSo0bhfJ69rmf2Ym5JyoFZLNVsHiM%2F0EENB53XjBVN5NTtRhwFD%2FxDym2YahTATsI6xRuCNJ67i0UMy2Aq42t8dBPXLiqIrmSircIutZu1A49SZ0l4lrKqB7VtBMNq0kvEFOusBDAkKvoIobf3FXFYCuGor2dslmz5yLUJOTxwb1331nvlXFbHzlvOUSJIWiDG5lM17hzUSHLl%2FIAM1iiWxq0nVqv4uljwXAAVeEoe787L%2BEZ8mTCdbu6aefx4r0keotVqaBRfbd7XZVKsve9eKtM9aXLBOUzxCdkhuRniZo7qsCL83oN%2FUTGSDpp4p6%2BYwNvTTWWL%2BxwV55vZ8eAKvGmmEQKwXDGORuDFjI9pNxBdLUbC%2FyquaoznQS8iKExy7wXK8Fk7lSlX7%2FJmy7ln06LKznS67jqjP8HhRDwkNT9U1PXBvirn2VuDq56TIPA%3D%3D&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Date=20200119T190111Z&X-Amz-SignedHeaders=host&X-Amz-Expires=300&X-Amz-Credential=ASIAQ3PHCVTY6PFD5VUW%2F20200119%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Signature=738a6e6dbcba7354b3d02a0a79babfc6e9ce15f1af6820d23723ec7d54af3d25&hash=e57859694f003430965ce27a8e30172bba2e37086eb1109895ff6d2b1994196d&host=68042c943591013ac2b2430a89b270f6af2c76d8dfd086a07176afe7c76c2c61&pii=0167642387900359&tid=spdf-faed9d06-b6a0-45ae-80df-50bb31c923d9&sid=383795ee78944049719af099d4b4b2255614gxrqb&type=client
======
davidkpiano
This is the paper (by David Harel) that initially inspired me to create XState
a few years ago. Here is a direct PDF link:
[http://www.inf.ed.ac.uk/teaching/courses/seoc/2005_2006/reso...](http://www.inf.ed.ac.uk/teaching/courses/seoc/2005_2006/resources/statecharts.pdf)

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](https://statecharts.github.io) Community:
[https://spectrum.chat/statecharts](https://spectrum.chat/statecharts)
Documentation for XState:
[https://xstate.js.org/docs/](https://xstate.js.org/docs/)

------
clumsysmurf
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.

"Constructing the User Interface with Statecharts"
[https://www.amazon.com/Constructing-User-Interface-
Statechar...](https://www.amazon.com/Constructing-User-Interface-Statecharts-
Horrocks/dp/0201342782)

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?

~~~
dukoid
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).

~~~
emmanueloga_
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].

1:
[https://stackoverflow.com/a/40679958/855105](https://stackoverflow.com/a/40679958/855105)

~~~
dukoid
What's their expressiveness? I always thought the nesting could be
"flattened", so it wouldn't really make a difference?

~~~
emmanueloga_
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._

1: [https://statecharts.github.io/state-machine-state-
explosion....](https://statecharts.github.io/state-machine-state-
explosion.html)

2:
[http://www.dcs.ed.ac.uk/home/kxt/on_visual_formalisms.pdf](http://www.dcs.ed.ac.uk/home/kxt/on_visual_formalisms.pdf)

------
sktrdie
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.

~~~
streetcat1
So Harel did form a company - iLogix
([https://en.wikipedia.org/wiki/I-Logix](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](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.

~~~
brucou
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](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.

------
neilv
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.

------
brucou
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](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.

