5 ms·

Statecharts: A visual formalism for complex systems [pdf]

121 points by sktrdie 7y ago

clumsysmurf 7y ago
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-Statecharts-Horrocks/dp/0201342782 https://www.amazon.com/Constructing-User-Interface-Statechar... 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?
- enturn 7y ago
  I came across a javascript implementation [1] and HN discussion from a year ago [2]. [1] https://github.com/davidkpiano/xstate https://github.com/davidkpiano/xstate [2] https://news.ycombinator.com/item?id=17805950 https://news.ycombinator.com/item?id=17805950
- rojoca 7y ago
  For js there are various implementations including this one: https://xstate.js.org/docs/ https://xstate.js.org/docs/ Here is an article by the author of this library with some justification for the appropriateness of statecharts in UI construction: https://dev.to/davidkpiano/no-disabling-a-button-is-not-app-logic-598i https://dev.to/davidkpiano/no-disabling-a-button-is-not-app-...
- dukoid 7y ago
  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).
  - TFortunato 7y ago
    Statecharts are not the same as simple Finite State Machines.
  - emmanueloga_ 7y ago
    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 7y ago
      What's their expressiveness? I always thought the nesting could be "flattened", so it wouldn't really make a difference?
sktrdie 7y ago
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.
- ahasani 7y ago
  It is ahead of its time and we are getting closer, one example, please check out UE4 Blueprint visualizing animation states at https://docs.unrealengine.com/en-US/Engine/Animation/StateMachines/index.html https://docs.unrealengine.com/en-US/Engine/Animation/StateMa...
- streetcat1 7y ago
  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 7y ago
    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.
davidkpiano 7y ago
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/resources/statecharts.pdf http://www.inf.ed.ac.uk/teaching/courses/seoc/2005_2006/reso... 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/
neilv 7y ago
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 7y ago
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.
deleted 7y ago
[deleted]

121 points by sktrdie 7y ago

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-Statecharts-Horrocks/dp/0201342782 https://www.amazon.com/Constructing-User-Interface-Statechar... 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?

enturn 7y ago
I came across a javascript implementation [1] and HN discussion from a year ago [2]. [1] https://github.com/davidkpiano/xstate https://github.com/davidkpiano/xstate [2] https://news.ycombinator.com/item?id=17805950 https://news.ycombinator.com/item?id=17805950
rojoca 7y ago
For js there are various implementations including this one: https://xstate.js.org/docs/ https://xstate.js.org/docs/ Here is an article by the author of this library with some justification for the appropriateness of statecharts in UI construction: https://dev.to/davidkpiano/no-disabling-a-button-is-not-app-logic-598i https://dev.to/davidkpiano/no-disabling-a-button-is-not-app-...
dukoid 7y ago
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).
- TFortunato 7y ago
  Statecharts are not the same as simple Finite State Machines.
- emmanueloga_ 7y ago
  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 7y ago
    What's their expressiveness? I always thought the nesting could be "flattened", so it wouldn't really make a difference?

sktrdie 7y ago

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.

ahasani 7y ago
It is ahead of its time and we are getting closer, one example, please check out UE4 Blueprint visualizing animation states at https://docs.unrealengine.com/en-US/Engine/Animation/StateMachines/index.html https://docs.unrealengine.com/en-US/Engine/Animation/StateMa...
streetcat1 7y ago
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 7y ago
  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.

davidkpiano 7y ago

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/resources/statecharts.pdf http://www.inf.ed.ac.uk/teaching/courses/seoc/2005_2006/reso... 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/

neilv 7y ago

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 7y ago

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.

deleted 7y ago

[deleted]