Statechart Data 2 - Events and Entry

Second in a series of posts about how state machines can store and manipulate data. Figuring out how state machines integrate cleanly into a codebase -- how they do this essential task of data management - is, i think, one of their biggest impediments to adoption.

Jumping right in, one of the most obvious spots for data storage ( other than global storage ) are inside the events that the state machine is responding to.  There are good things, and bad things, about using events for data handling, and it turns out not all statechart implementations are created equal...

See full post...

Some statechart resources

As long as I'm writing about statecharts... maybe it'd be helpful if I shared some of the resources I've found useful.

David Harel is the person who formalized/invented what was adopted as the UML Statechart spec. He has a free book, Modeling Reactive Systems with Statecharts, that's a decent ( if a bit slow ) introduction. His original paper is useful too, but since UML has evolved things a bit, it's probably not a perfect starting place for newcomers.

Miro Samek wrote Practical UML Statecharts which I highly recommend to all.  Samek also published an article sized version ( as a pdf here ) which is definitely worthwhile. He is plugging the sale of his company's software, and he does overstate ( no pun intended ) the usefulness of statemachines ( to their detriment, I think: they're not perfect for everything, and a good analysis of their shortcomings would help to better illustrate how they fit in with everything else we as programmers do ), but that doesn't stop him from writing clear and informative explanations. I particularly like his look at all the different ways statemachines can be implemented. ( But, then, that's the kind of programming discussion I like the most. )

The Boost Meta State Machine tutorial is good for getting a quick read of statechart syntax; absent is the why and how of using state machines. Wikipedia's various articles are decent enough, and the old UML 1.3 docs ( scrib, or pdf of just the statechart bits ) are great. ( Unfortunately, I've found the new 2.x docs to be impossibly dense. )

It's interesting how few resources there are which discuss exactly how UI and statecharts fit together. Apparently, Constructing the User Interface with Statecharts by Ian Horrocks is a good one, but at 100+ dollars for a used paperback, it's a little pricey to pickup on blind faith.

If you've got any good links, be sure to let me know.

See full post...

Statechart Data 1 - Global and Machine Storage

In the previous post, i gave an example of a series of graphical menus, and asked how exactly do those statecharts interact with the menuing system, and specifically: how do statecharts create and manipulate user interface data?

Let's start right at the very top with the outermost menu:

   Main Menu:
   - entry / display_options();
   - button[0] >> New Game.
   - button[1] >> Continue Game.
   - button[2] >> Options.

And dig into some pseudo code.


See full post...

Statechart Data - Statecharts are not flowcharts.

Statecharts are meant to be descriptions of reactive behavior. The outside world generates events, a state machine processes those events, responds with predefined actions, and then waits for the next event. A flowchart, on the other hand, receives data as input and transforms that data as it passes it along; stage after stage. Wikipedia has a whole section on this difference, my favorite (paraphrased) quote being:
 
In a state diagram, processing is associated with transitions, whereas in a flowchart processing is associated with nodes. A state machine sits idle in a state waiting for an event to occur; a flowchart is busy executing activities.


I find that a useful mantra to mumble to myself while setting up states ( thank goodness only my cats are around to complain ) because programming state machines has a different feel than programming normal procedural code. Frequently, I think, we as programmers want our code to be *doing* something. But, with state machines, your code is just sitting there, waiting to react, waiting for a chance to do something.

Another way to think about all this is that you aren't are writing instructions to control movement from state to state, but rather only documenting how those changes happen. Your machine code is only "following along" with changes happening elsewhere.  At it's essence, that is what a purely reactive system means. It reacts to the world, it doesn't control the world. ( The prime example Harel uses in his book, for instance, is an emergency warning system for aircraft. )

So, that's all great in theory, but how does it stand up in practice?  Consider a simple main menu with several choices...


See full post...

Quick and dirty textual statecharts

I'm working on a few posts about statecharts -- but I don't want to write a introduction to statecharts as there are plenty of people out there who have done a better job than I would, so I'll more or less jump into the thick of it ( once I get there ). If I have my druthers, I'll post the C++ statechart toolkit I've been working on with as liberal a license as I can.... soon....

Textual Statecharts

The one thing I would like to note first, though it'll probably be pretty obvious, is the notation I've adopted for writing UML states without diagrams.  It's straightforward enough, but just to document once by example, here's Samek's toaster oven chart ( original posted below ) rendered as text:
    Heating:
    - enter /start_heater();
    - exit  /stop_heater(); 
    - init  >> Toasting.   
    - toast >> Toasting.
    - bake  >> Baking.
    - open  >> Open.
      Toasting:
      - enter /arm_timer();
      - exit  /disarm_timer();
      - do [timer elapsed] / eject_toast();
      Baking:
      - enter/set_temp();
      - exit /set_temp();
    Open:
    - enter /illuminate();
    - exit  /extinguish();
    - close >> Heating.
I think this is pretty easy to read even without knowing a thing about statecharts, but it more or less follows the UML syntax. And it's also vaguely YAML-like...

See full post...