Transitions are Important! - State Machines Done Right

[swatts]

Hello Lovelies.

I gave this little presentation at GDevCon#2 and the video is linked below. This article briefly explains the presentation and is a good placeholder for the example code.

History and Perspective

I started with a brief history and described the different types of state machine.

This was followed by Turing, Mealy and Moore.

People misconstrue the point of these early state machines and IMO forget that originally they were for reducing switching circuits in telecomms systems. There is therefore a point to some rigour and discussion about them. Whereas in a software system a state will nearly always have data input, this makes them pretty much a Mealy Machine. The State Transition Diagrams we are most used to are Moore State Machines. And you know what, who cares. In software these diagrams are only useful at the initial architecture stage and when in early discussions with an end user.

From a software perspective, if you want rigour use an Harel diagram, it's got everything you need. Me? I just use the diagram above.

Transitions

Most state machine patterns in LabVIEW are either QMHs (not a state machine) or they don't separately describe the transition. This is a shame because it's an enormously useful way to make nice flexible, readable code that matches your diagrams.

I show one way that SSDC describes a state machine with transitions in LabVIEW.

As you can see here that we have a state enum and a transition enum. The transition enum drives the exit from the state.

Language

Simplicity is related to language and language drives design

Adding some language based rigour to our State Machine.

States should be Do-ing something (Present Participle)
Idling, Waiting to Connect, Connecting

Transitions should be an imperative verb.
Connect, Stop, Disconnect

Changing to a present participle has actually effected my expectation about what should be in a state. It's a subtle thing but really helpful.

I'll probably do some more on Language and Software Design in a future article.

Car Wash Example

The state machine diagram looks like this.

The code is attached in LabVIEW 2015 only Loop 4 is the state machine. Have a play, use it if you like it, don't use it if you don't. I've used this template in loads of projects from the tiny to the huge. State machines are more useful for control systems, but I nearly always find a use for them.

Don't put Everything Everywhere!

Use Event loops to fire transitions, you want to get out of events quickly!

Use the UI QMH to just update the UI, a responsive UI will be your reward.

Put everything you can in the state machine!.

Lots of Love

[ConnerP]

Hey Steve, I have been doing a deep dive on state machines and I think I just had a lightbulb moment. I've mostly been looking at your implmementation and HSE's derivative. I've also been looking at TLB'. In a talk, Norm said state machines shouldn't have "Do" all over them, and instead the meat should be in the transitions. In your flavor, the action does happen in the state cases themselves, i.e. they are "Do"ing.

Now to my observation: Would you say your design falls in line with a Moore style and that TLB' is more of a Mealy style? I never really got the difference between Moore and Mealy before, but last night it clicked (I think). As you say, it doesn't really matter as long as you remain consistent, but I think that label marks a clear difference between these two implementations and may offer insight about how each -wants- to be used, beyond what the authors might say, or may be obvious at first glance to someone without a CS degree.

[swatts]

The main difference for me is how a diagram converts to software. And as you say consistently following a pattern or s the key.. I tend to want to break down to the simplest pattern. But finding a pattern that suits how you think is also a good choice.

[swatts]

The other easy trap to fall into is "everything can go anywhere", in LabVIEW you can have 5 or 6 parallel loops running on your main diagram. With us we have an event loop, a QMH for screen updates, a state machine and an error loop as a minimum. It takes a certain amount of discipline to put most of you're business logic in the state, especially when an event could handle it quite easily..

This is probably one of the biggest issues (apart from dependency management) I see when I'm rescuing projects or working with unfamiliar code.