Modeling system states: It starts with a Turing machine

In computer science, there are a few fundamental papers that, without exaggeration, changed everything.

There was A Proposal for the Dartmouth Summer Research Project on Artificial Intelligence in 1955, The Mythical Man-Month in 1975, even the Agile Manifesto in 2001. Few, however, compare to an even earlier one: Alan Turing’s On Computable Numbers, with an Application to the Entscheidungsproblem in 1935.

Despite the movie, despite the prominence of “Turing complete” (no matter how misused) in AI conversations, despite the popularity of Turing in computer science classrooms and lesson plans, the influence of Turing remains hard to overstate.

Here at Mermaid Chart, his most distinct influence is on a diagram I think is similarly underrated: system state diagrams. These diagrams, which model the transitions between different states, look a little like flow charts but are useful in many different circumstances.

Understanding that usefulness means tracing system state diagrams all the way back to the state machines originally proposed by Alan Turing. By retracing that history, we can track how our ability to diagram state changes has evolved and see how a nearly century-old concept is still relevant for modern development and documentation.

From Turing and state machines to UML and system state diagrams #

Alan Turing’s influence is deep, broad, and diffuse, which makes it hard to notice every instance of his impact. When you start measuring the ripples of his work, the secondary and tertiary consequences and influences… it all quickly becomes uncountable.

The more you learn, the more the tragedy of his death deepens. And the more offensive to know how long the British government downplayed its involvement.

Turing and state machines #

Alan Turing was born in England in 1912 and from all reports, appeared to be an early prodigy in mathematics. He went to King’s College in Cambridge, where he studied mathematics and theoretical physics. He graduated in 1934 and became a fellow of King’s College, where he worked on his doctoral thesis.

In 1936, Turing published “On Computable Numbers, with an Application to the Entscheidungsproblem.” In this landmark paper, he introduced the idea of a universal computing machine (now known as a “Turing machine”).

When World War II broke out, Turing started working for the British Government Code and Cypher School at Bletchley Park. There, he helped break the Enigma code that the German military was using and shortened the war by years (this is what the movie The Imitation Game focused on).

After – as if this weren’t enough! – Turing published “Computing Machinery and Intelligence” in 1950. This is where the Turing Test came from.

In 1952, the British government prosecuted him for homosexuality, which was a crime in the UK, and sentenced him to chemical castration. In 1954, he died by suicide.

Since then, however, Turing’s legacy has become more well-known, and the UK has made amends. Turing was officially pardoned by the Queen in 2013, and that year, England passed the “Alan Turing law,” which pardoned all people in England and Wales convicted of homosexuality. A similar law followed in Scotland in 2019. And since 2021, Alan Turing has been on £50 note in England and Wales.

State machines: A deeper look #

Turing’s concept of a state machine is what’s most relevant to our discussion here.

Prior to Turing’s game-changing contribution, mathematicians were deep in debate about whether a single machine could solve all computable problems. At the time, numerous mathematicians were designing and proposing complex models but Turing cut through the issue with a deceptively simple machine.

The device he proposed in “On Computable Numbers, with an Application to the Entscheidungsproblem” became known as a Turing machine, and it comprises three components:

• The tape, which is divided into separate cells, with each cell containing a symbol from a finite alphabet.
• The head, which can read and write symbols on the tape and can move left or right along the tape.
• The state table, which is a set of instructions that tell the head what to do based on the symbol it is currently reading and the state it is in.

The tape is divided into separate boxes and each box contains a blank space or a symbol from a finite alphabet. The state table takes two inputs – either the current symbol on the tape or the current state of the machine. And it produces three outputs – the symbol the head will write on the tape, the direction the head will move, and the machine’s next state.

As the machine runs, it reads a symbol on the tape and follows the instructions to change the symbol or move on to another symbol. The instructions, which we now recognize as a program, depend on the current state of the machine. René Peralta, a computer scientist at NIST, explains:

If the machine needs to decide whether the tape contains the text string “TC” it can scan the tape in the forward direction while switching among the states “previous letter was T” and “previous letter was not C.” If while in state “previous letter was T” it reads a “C,” it goes to a state “found it” and halts. If it encounters the blank symbol at the end of the input, it goes to the state “did not find it” and halts.

With the state table, we have what the mathematicians of the age were looking for: A way to simulate the behavior of this hypothetical machine and compute any output given any input. After, with some testing, computer scientists learned that some problems truly are not computable and that no amount of additions to this simple, hypothetical machine could extend its computational powers.

The state machine had a broad impact on computer science but a direct impact on how we write documentation. Thanks to the state machine concept first articulated by Turing, developers in the following years worked out ways to capture the state of a program or feature in a diagram that could facilitate mutual understanding and collaboration. Eventually, this became formalized as a system state diagram, which became an essential part of UML.

UML turned state machines into diagrams #

UML, or Unified Modeling Language, has fallen out of popular use in recent years, but the body behind UML, OMG, is what instantiated and spread the system state diagram format we know today.

UML came out in 1997. Martin Fowler, who wrote the book on UML, UML Distilled, later wrote that UML’s original purpose was to “eliminate the bedlam that had overtaken graphical modeling languages in the object-oriented world.” It’s a problem and attempted solution we’re all familiar with: Growing chaos and an attempt to standardize.

By 2004, some were calling the rise in popularity a “UML fever.” More than a decade later, a range of experts involved in UML diagnosed it with two fatal flaws: Non-technical people were using UML to control software development and UML itself had become so complex that it felt too unwieldy for most to use.

Despite these obituaries, UML has had a life after death. In 2014, a study found that most of the sketches and diagrams developers and software architects were making still used UML elements. Back in June 2023, we argued sequence diagrams were one of the only good things that came out of UML. Though most of UML deserves to stay forgotten, system state diagrams deserve reevaluation, too.

How system state diagrams are used today #

It’s not clear to the uninitiated, at a glance, why state diagrams are so useful. Let’s walk through the basics of how they work today, why people use them, and in which contexts they can help the most.

What is a system state diagram? #

A system state diagram is a diagram that models how system stages change over time by showing each state at each point.

The below example, from UML, illustrates the water cycle. At first glance, it looks like a flow chart.

The key difference is the idea of a state machine. A state machine, calling back to Turing, contains the current status of a given object. Unlike a flowchart, which models a process, a system stage diagram models the behavior of an object across a lifetime of responses to possible events.

Think about an elevator, for example. An elevator user can only be performing one of three events: entering, waiting inside, or leaving. The elevator can only ever be in one of three states: Open, closed, or running. The elevator can only transition from one state to the next depending on the inputted events (in this case, the actions of the elevator user).

Reg Braithwaite, author of JavaScript Allongé and user experience developer at PagerDuty, shares three rules that both govern system state diagrams and clarify how they work:

1. There are a finite number of states a state machine can be in. If we’re modeling a bank account, for example, it has to either be open or closed. “Its balance certainly is stateful,” Braithwaite writes, “but its ‘state’ from the perspective of a state machine is either open or closed.”
2. The only elements allowed into the model are possible states and allowable transitions between states. Typically, there is a starting point. In the bank account example, the account starts in an open state. From there, he writes, “It can transition from open to closed, and from time to time, from closed back to open.”
3. Transitions between states happen only as a result of events. Working from the same example, Braithwaite writes, “When open, a bank account responds to a close event by transitioning to the closed state. When closed, a bank account responds to the reopen event by transitioning to the open state.”

These guardrails provide clarity as well as structure: A system state diagram models – and only models – how a finite number of states transition from one state to another as a result of particular events.

The goal of a system state diagram, then, is to visualize the different states an object can take and model how an object shifts from one state to the next. This is why, in UML terms, system state diagrams are part of the behavioral family of diagrams and not the structural family.

What are the common elements of system state diagrams? #

System state diagrams can have many elements but the three most important are states, represented by labeled rectangles with rounded corners, transitions, represented by arrows flowing from one state to the next, and events, represented by labels alongside the arrows.

In real world contexts, these relatively simple elements can get complex. As a result, UML provided the concept of hierarchically nested states, which allow for multiple layers of events and transitions so that the diagram doesn’t become needlessly messy.

What are some use case for system state diagrams? #

In programming contexts, states most often represent systems. As Braithwaite writes, from a programming perspective, “When we program with objects, we build little machines. They have internal state and respond to messages or events from the rest of the program via the mechanism of their methods.”

This framework is most applicable when developers are working with event-driven systems or when developers are modeling how an interface or class behaves. An ATM, for example, has finite states (waiting, dispensing money, etc.), reacts to events (such as a user inserting a debit card), and transitions (from waiting to dispensing).

System state diagrams come in most handy when the behavior of a system is complex or non-linear, systems where it can be hard to tell at a glance how particular states respond to particular events. The more complex the workflow – often exemplified by the amounts of conditional code, such as if then else, switch statements, and loops – the more useful these diagrams will be.

That said, system state diagrams aren’t only useful at the outset of development. As Braithwaite emphasizes, system state diagrams allows developers to “separate responsibilities and decompose methods into smaller pieces, each of which is focused on implementing the correct behaviour for a single state.” If you’re trying to better understand a system – potentially to refactor it or otherwise change it – system state diagrams can help you see the big picture.

Though system state diagrams sometimes have the connotations of deep computational theory, they can also be useful for collaboration. Peter Ringset, senior consultant at Kodeworks, for example, points out that system state diagrams can help designers communicate with developers.

“Designers and developers are often very task-oriented when they work,” Ringset writes, “and it’s easy to forget to take a step back and look at the bigger picture.” If designers are giving developers static UI screens, for example, they might not realize the states in between might need designing and developing, too.

“Using state diagrams can help us take that step back,” Ringset says, “and it’s also a great way for developers and designers to collaborate and speak the same language.”

System state diagrams in Mermaid Chart #

With Mermaid Chart, you can go from simple system state diagrams to complex ones with nested states, choices, and forks.

Once you load the Mermaid Chart editor, you can start with a fairly simple diagram that illustrates, in this example, a vending machine. Here, the vending machine only has a few states: idle, selecting, dispensing, and out of order.

For a more complex example, let’s take a look at an authentication system that includes an additional path for users who need to reset their password or create an account – both of which merge back into the system.

Finally, to show nested states relying on Mermaid syntax, let’s model an online shopping system. Here, users search for items, add them to the cart, and make a payment. During the order processing, there are sub-states, including preparing the order, shipping the order, and delivering the order.

The examples above were all generated using Mermaid Chart’s AI diagramming assistant. With just a simple, natural language input, the chatbot instantly generated diagrams that matched the parameters necessary for these examples.

We still have respects to pay Turing #

In 2009, British software engineer John Graham-Cumming wrote a post explaining why the British government should apologize to Alan Turing. Eventually, 30,000 people signed a petition demanding just that, and the Prime Minister called Graham-Cumming personally before releasing a statement to the press.

In 2013, Queen Elizabeth II offered a posthumous pardon, and in 2014, the movie The Imitation Game came out, further cementing Turing’s legacy. Today, Turing is widely recognized as an important figure in numerous histories, ranging from war histories to queer histories and from computer histories to cryptography histories.

Even then, we still have respects that have yet to be paid to Alan Turing. This article uncovered and explained only one ripple that resulted from the massive impact of his work, but there are many more. We finish, then, by urging you to do two things, one practical and one broad: Try system state diagrams and pay your respects to Alan Turing, who we owe so much to.