What is a statechart?
A statechart can be explained in many ways, and we'll get to those explanations, but essentially, a statechart is a drawing. Here's a simple statechart:
However, this drawing might not be so useful for software engineers who want to reap the benefits outlined elsewhere on this site, so let's dive into some other ways of describing what a statechart is. The original paper that defines statecharts bills them as "A visual formalism for complex systems" (Harel, 1987). With that out of the way, let's try to explain statecharts.
Put simply, a statechart is a beefed up state machine. The beefing up solves a lot of the problems that state machines have, especially state explosion. One of the goals of this site is to help explain what statecharts are and how they are useful.
Statecharts offer a surprising array of benefits
- It's easier to understand a statechart than many other forms of code.
- The behaviour is decoupled from the component in question.
- This makes it easier to make changes to the behaviour.
- It also makes it easier to reason about the code.
- And the behaviour can be tested independently of the component.
- The process of building a statechart causes all the states to be explored.
- Studies have shown that statechart based code has lower bug counts than traditional code.
- Statecharts lends itself to dealing with exceptional situations that might otherwise be overlooked.
- As complexity grows, statecharts scale well.
- A statechart is a great communicator: Non-developers can understand the statecharts, while QA can use a statecharts as an exploratory tool.
There are a few downsides to using statecharts that you should be aware of.
- Programmers typically need to learn something new, although the underpinnings (state machines) would be something that most programmers are familiar with.
- It's usually a very foreign way of coding, so teams might experience pushback based on how very different it is.
- There is an overhead to extracting the behaviour in that the number of lines of code might increase with smaller statecharts.
There are a few common arguments against statecharts.
- It's simply not needed.
- It goes against the grain of [insert name of technology].
- It increases the number of libraries, for web applications this means increased load time.
- It increases the number of hand coded lines.
The benefits outlines above should make it clear that the introduction of statecharts is generally a net positive.
First of all, know that a W3C committee spent 10+ years (2005 to 2015) standardizing something called SCXML (yes, Statechart XML), and that it defines a lot of the semantics and specifies how to deal with certain edge cases. There are tools to read, author and even execute statecharts written in SCXML, in various languages. There are also some derivatives that support the same model as SCXML, but using a different syntax.
Additionally, there are statechart libaries for a variety of platforms, that in varying degrees support the semantics described by SCXML. You should consider using these libraries just to get those edge cases taken care of. The libraries generally perform entry and exit actions in the right order and so on.
With that out of the way, read on!
In addition to just using statecharts to model the behaviour in documents separte from the actual running code, it's possible to use one of various machine formats, both to design the behaviour, and at run-time to actually be the behaviour. The idea is to have a single source of truth that describes the behaviour of a component, and that this single source drives both the actual run-time code, but that it can also be used to generate a precise diagram that visualises the statechart.
This carries along some different pros and cons:
- No need to translate diagrams into code
- No bugs introduced by hand translation of diagrams
- The diagrams are always in sync
- The diagrams are more precise
- The format and tools for executable statecharts is limited
- Type safety between statechart and the component is hard to enforce
In essence, if you have any definition of a statechart in your code, all you need to do is to take that representation and automate the generation of the visual statechart. This is of course simpler when the definition is in a separate file, e.g. in a JSON or XML file.
If you feel like chatting to someone about statecharts, you should go to spectrum.chat/statecharts, where you'll find a community of like minded developers that can help you understand and reap the benefits of using Statecharts.
Quite a few people have written books or held presentations that deal with statecharts in various ways, and they're included in our resources page.
There are some pages that haven't found any place in the web of documents, so they're honourably mentioned here: