Posted
by
timothy
on Thursday April 10, 2003 @11:30AM
from the gruntwork dept.

Reader JonKaye contributed this review of Reviewing Practical Statecharts in C/C++. He writes "Since I am not from the embedded system world, I was a bit apprehensive about approaching this book. While I can see that author Miro Samek has a directed target for his audience, I strongly feel that this book is a 'must read' for technical developers in all areas who want to improve their program design abilities or developers who want to understand the philosophy, use, and implementation of statecharts intimately." Read on for the rest.

As the title indicates, this book brings the topic of statecharts from the realm of expensive design tools to the practical realm, illustrating its points with full examples and extensive commentary.

Essentially Samek postulates that the slow adoption by developers of best practices by statechart design is due to lack of understanding of the fundamental nature of statecharts and how it is perceived as requiring expensive tools to use well. Samek insightfully discusses how statecharts as a best practice embody "behavioral inheritance" as a fundamental design concept that stands as a peer alongside the conventional pillars of object-oriented programming, namely inheritance, encapsulation, and polymorphism.

The book is very technical and written in an academic style, with ample references to original sources as well as detailed code reviews and many reader exercises. I would caution anyone from approaching this book as a quick or light read. For me, it took a seriousness and good understanding of C and C++ to follow Samek's examples and achieve the "a-ha", which was always worth it in the end. The book contains full, working code to incorporate statecharts into my own work, implemented both in C and C++.

The two basic parts of the text are (1) an explanation of statecharts and their methodological implications, and (2) a description of how to apply statecharts as a data structure in real applications, namely embedded as control strategies for "active objects." In several places in the text, Samek makes an analogy between statechart (and active object) semantics and quantum mechanics. This parallel was an interesting philosophical argument, but didn't add much for me in terms of accepting his "quantum framework" as a best practice -- I was sold by his methodological arguments he had presented already.

Speaking from experience in writing a book about using statecharts to build simulations (www.FlashSim.com), I can say Samek is a visionary who extended my perception of statecharts several steps. I know I will be quoting from it and referring to it in my work to come. This book has earned a prominent place on my bookshelf, and I would heartily recommend it to any other developer who wants to create correct, verifiable, scaleable, and solid designs (which should be ALL developers!)

I have not really seen where the word quantum comes in, except as a buzzword. Since I have been looking for a decent, expandable, well written state machine, I picked this book. Perhaps some code bigots will criticize the code, but for my uses, it is good enough. I am tired of having to re-invent the wheel everytime I change employers.

Most other programmers I meet in the workplace have a hard time understanding state machines. All of those programmers are self taught or picked up "learn programming in 21 days" type of books.

Quantum...my guess is that they're referring to the quanta of an embedded system - which would be states.

I seem to recall that state machines were the first thing that I learned when I started learning about computer architecture. They are, after all, the basis. What I find disturbing is that programmers that you meet in the workplace have a hard time understanding state machines and they're still in the workplace.

Isn't that a like knowing how for loops work? Or how to do recursion? It's a basic funda

That's the sound of a topic that went zooming over the heads of most/.'ers (me included). It would have been quite nice of the author to include some links that describe what a statechart is and why a C++ programmer should care. It might be one of those things where the book is geared towards those who already know, but it would still be good so those who don't could get some background.

I know, I know, you can just google it yourself. But why have hundreds of people searching for exactly the same thing when one person could save a lot of people some time.

Most objects, C++ or otherwise, are stateful (have local data) and have operations or methods which are basically state transition mechanisms. That is, they are basically finite state machines. So it would be very sad indeed if the concept of a state machine or state chart should be "over the heads of most/.'ers". When working with object, the only choice is between a well-designed state machine and an accidentally-designed state machine.

Well, a lot depends on the granularity of the "states" you're talking about. It's generally impractical to design a fine-grained state machine for anything but the simplest system because of state explosion.

Even if the result can be thought of as a state machine, it's often better not to model it as one.

Karnaugh maps were traditionaly used by hardware logic designers to minimize the number of gates required to implement a logical function at the bit level.

If the system uses a single byte that means you have 256 possible states. If you have two bytes it's 65,536 states and so on. I don't think you want to draw a Karnaugh map for something like Emacs, you won't live long enough.

That's what I mean by fine-grained state, a single state of the system is defined by the state of all the bits in the system.

I gave a lecture on state machines once, and my
notes [steeds.com] are still online. I'm not sure that enough of the lecture is there (just the outline) to educate someone, but it's a start, and has some code examples.

And, these are really informal "state machine diagrams", so I can't say whether they conform to UML "statechart" standards (I don't think UML was around in the mid 80's when I was learning this stuff).

It would have been quite nice of the author to include some links that describe what a statechart is and why a C++ programmer should care.

I learned about state diagrams in college years ago. The examples that we used at the time were all the sorts of things that could be done as stand-alone projects. They typically involved parsing strings that had to match a description given by a state diagram. If you are building a lexical scanner by hand or a regular expression library, it's good stuff to know. However, I wondered how often I'd see it in the real world.

Well folks, this can be real world stuff if you apply it. It's all about retaining a state that summarizes inputs that you have seen so far. This is about communication between autonomous devices (or with a user). If nothing else, state information is useful in retaining position within a set of search results when a user is paging through them. It can be used in the session layer of a communication protocol to track handshaking. If you have to asynchronously do two things concurrently within your program, unless each of them involves completely separate transactions that are completely atomic, one or both can be modelled as state machines.

If you write GUI code where you have buttons being toggled, check boxes checked or fields filled, you have a state machine, whether you coded it or not.

If you are writing embedded systems, you don't need me to tell you that you are maintaining real time state information about the devices you are talking to.

If you've ever used one of the source ports that allow more triggerable actions and used a 'zombie doll' you've designed a state machine.

For instance. When the player crosses a line I want the following to happen. I don't really know state semantics so it's in english which for a programmer is very poor. This can be as complex as you want, this is just a simple one:

Actually this is a good example of why I made my comment. If statecharts are simply a way of representing state machines (which makes sense, but I was wondering if there was more to it to warrant a "new" book on a old subject) then that mere mention would have clarified things significantly. A great deal many programmers are familiar with state machines that have no clue about the UML statechart.

Am I missing something here? I'll be first to admit I'm far from a C guru but I fail to see what is groundbreaking about the concept. Of course, I'm an oddball and tend to mentally envision a program as

those with an engineering background often write code dominated by boolean logic and switch statements very obviously describing a state machine, and those who have an abundance of programming courses don't.

I take offense to your to your boolean statement of programmers being one or the other. You may have to revise your logic to include an indeterminate state: those of us who have the same background as you and traditionally prefer to code the way you describe for the most part, but have to dumb our

Zone Logic is a nice combination of state charts and autononmous agent design. It was used in the 80s and early 90s for industrial automation, and was particularly good at recovery from hardware failures.

Real-time systems depend on sensors to report the state of the outside world. These sensors often fail, putting the system in an illogical state. Zone Logic offered a nice structured way to deal with this.

It only has 1 chapter on UML statecharts, but after reading through it, I was able to describe in 1 diagram LCD behavior that used to take ~20 weakly worded requirements. (Shall do this, except when this, etc...)

If you're having trouble being explicit and clear in requirements, I would highly recommend looking at statecharts. (Picture speaks a thousand words, eh?)

State charts are teh next big thing (or at least, next big buzzword). I do a lot of consulting, and I've seen "Object Oriented" supplanted by "Unifide Model" supplanted by "XML". Well, Statecharts are likely to be the next buzzword. Sure, they're overrated, and will be forgotten ina couple years, but if you're on the job market, you need to know the lingo.

The book sketches the process and gives C and C++ code for programming both linear finite state machines (what we typically think of as FSM's), and the more powerful hierarchical state machines (aka, statecharts). It doesn't get into some of the nuances of UML statecharts, but in my opinion, it addresses a very large percentage of them (maybe 80-90% or more) and you can add the ones you need with the basis provided.
-jonathan

As one of the original developers of Statemate, a tool for modelling with Statecharts, I have to step in here. Statecharts are not flow charts nor are they state diagrams. They are an extension of the latter, but they are actually a mathematical language based on temporal logic. As such, Statecharts can be processed to prove or disprove assertions about your design.

Alsthom Alcatel, for example, used our tool to discover flaws in the high-speed TGF before they started actually building it. They thereby save

The description of a statechart is remarkably similar to my understanding of Markov chains. Markov chains are representations of finite state systems used by mathematicians. There are several instances of folks attributing the 'invention' of statecharts to particular computer scientists in the discussions below. I think it would be more accurate to say that a cs person pioneered the implementation of [degenerate] Markov chains as a cs application.

A Markov chain can be defined as a finite state machine with a probability assigned to each transition. The history of if the theory is firmly rooted in probability theory. Key figures include Markov, Wiener, and Kolmogorov, all of whom were definitely mathematicians.

State machines aren't that complicated. The UML people are just burying them under a mess of jargon.
This is probably not helpful.

UML is a reasonable idea that's turning into a management fad and is being used to sell overpriced tools. Such fads come around from time to time. Anyone remember decision logic tables? "Bubtangles?" The Kepner-Tregoe method? "Business Objects?"

> Anyone remember decision logic tables?
> "Bubtangles?" The Kepner-Tregoe method?
I remember Kepner-Tregoe, and apparently am not alone:
http://www.kepner-tregoe.com/
I also still use Problem and Decision analysis.

There's no such claim by the "UML crowd". All statecharts are is a better notation for documenting an FSM than a traditional state diagram.
A statechart allows you to naturally decompose the FSM into simpler parts, which scales better (in terms of diagram size) for large FSMs. There is also some other nice "diagrammatic sugar" such as symbols for the default entry point into a sub-system and so on.

Here's
a book [amazon.com] that presents a good case for using statecharts in one particular problem domain. Like any

As I see it, this looks like the kind of thing that people who don't have a formal CS background might "discover". I mean, I thought it was basically obvious to use FSA diagramming to document state transitions in software systems. I've been doing this for years, without the guidance of a UML "statechart" system. The only benefit of these things is providing examples of "real world" usage and how a particular problem domain was mapped into a FSA, which might make it more obvious how to use the formalism

As a notation for FSA diagramming, statecharts actually are pretty good. They have some handy shorthands that factor out common parts of the state to keep diagrams from blowing up to enormous numbers of states, as would happen if you enumerated all possible states as in a traditional FSA diagram. Sort of a hierarchical way of doing FSA diagramming, which is well-suited to some problems.

As I see it, this looks like the kind of thing that people who don't have a formal CS background might "discover". I mean, I thought it was basically obvious to use FSA diagramming to document state transitions in software systems...

Excuse me, hardgrok, but you might say my PhD in Computer Science is kind of a "formal CS background." I learned about FSA in my algorithms class both as an undergrad and grad student, and I can clearly see that statecharts are not the same thing by any means. I find that p

Well, I appreciate your reply, but there is no need for you to be defensive - I wasn't attacking you on an ad hominem basis, merely hypothesizing that sometimes the industry community gets hot and bothered over ideas that are old hat in academic computer science. After skimming David Harel's paper, I agree that there are some additions and extensions to the statechart formalism vs. traditional FSA diagrams. I was never denying that people had proposed such additions nor that they could be useful.

I wasn't attacking you on an ad hominem basis, merely hypothesizing that sometimes the industry community gets hot and bothered over ideas that are old hat in academic computer science

Sorry -- I didn't mean to go off on you or anyone in particular, and I understood your comments in the non-personal context.

I am no 'statechart-does-everything' zealot, but I've found even among CS educated people, that they tend to dismiss things because the value is not immediately obvious, especially as I infer from you,

Funny, every UML book where i have read something about statecharts mentions they're just state diagrams for finite automata.

"State machines aren't that complicated. The UML people are just burying them under a mess of jargon."

They are?

It seems to me this is necessary, as it is in other UMLized diagrams, in order to generalize it so it can be useful out of the context they got it from in the first place. It's part of the "universalizing" process.

Have the "statecharts" people developed a way to provide something subroutine-like for finite state machines? A big problem with finite-state machines tends to be a need for multiple copies of very similar subgraphs to handle similar situations.

UML is a worthy idea, and it can be saved. But people will have to realize "there is no silver bullet for software development [virtualschool.edu]". It won't make the problems go away, but hey, at least it's a starting point for software development more than two people can agree on.

Plus, it's rooted in object-oriented design. That, at the very least, is a step in the right direction (i.e. away from the long-term logistics nightmare of functional decomposition [wikipedia.org]) . Keep in mind, however, it's not a method [softed.com]. What you do wi

"While I can see that author Miro Samek has a directed target for his audience, I strongly feel that this book is a 'must read' for technical developers that wish to eliminate their chances at successfully mating within the next three to four days. In most cases, the knowledge gleaned from this book will also allow the reader to avoid sexual intercourse indefinately (excluding mating rituals that involve the transfer of monetary units first)."

I wss a little confused by the term "statechart," but it turns out he's talking about finite state machines. I guess he figured one more new buzzword wouldn't kill anybody...

A state machine is a way of representing a computational task. The machine or program can be in precisely one of a number of possible states at a given time. Different kinds of events cause the system to move from one state to another state (called a transition). Each transition can have an associated side effect. Therefore, the model of computation is:

read input

decide which state to move to based on input and current state

execute transition action

actually move to the new state

return to step 1

State machines are theoretically limited in the kinds of input sequences they can process. As it turns out, a state machine can only process inputs which can be described by regular expressions. However, it is possible to "augment" a state machine to extend its power. If you do this by adding a data stack, you have produced what is called a "pushdown automaton" and this gives you a great deal of power. But that is a departure from a pure "CS" FSM.

The FSM is sort of the bottom rung of the computational ladder. FSMs can process regular languages (i.e. the languages describable by regular expressions). PDAs can process context-free languages (like most programming languages). Even more powerful than a PDA is a Turing machine, the theoretical "ultimate" model of a computing machine.

It might seem odd to think of the input events to the program as comprising sentences in some "language," but it makes sense when you consider it. Input events have an inherent structure to them, and this structure can often be described in the form of a regular language. In these situations, using an FSM model of the code is very natural since the code is directly, structurally related to the events it is processing.

Without knowing more detail, I can only speculate here but from this statement, it appears this allows you to "call" another FSM from a particular state. Ok, now you have a PDA, the next step up from a FSM.

You have parallelism: if a statechart is subdivided with dashed lines (or whatever the fashionable notation for this is now), you have two (or more) control flows.

This is known as nondeterminism in computer science. Any nondeterministic

So, it sounds like hierarchical finite state machines (HFSMs). I'm not dissing on statecharts, btw -- just from all the descriptions so far, it sounds like "statechart" is a technical term used by one crowd to refer to what my crowd usually refers to as HFSMs.

I'd be curious to hear if I'm mistaken and there's more to it than that.

First and absolutely foremost: an FSM is an adstract concept born of graph theory. A statechart is a diagram of an FSM, which complies to a rigorous specification for what each notation means.

The statechart spec adds a few semantically trivial notations (i.e. they can be easily translated into standard digraph style FSM), which are nonetheless extremely useful for presenting clear, easy to understand diagrams.

I wss a little confused by the term "statechart," but it turns out he's talking about finite state machines

The term statechart has been in the Comp Sci and then OO literature for a number of years, it was later adopted by the UML group. IIRC they often refer to David Harel as a source of much of the background on the concepts.

This might be useful for game programming. Instead of creating dozens of event handlers for my gui-based state game, and having lots of enums and switch statements everywhere and really getting lost in spaghetti, I could make one of these statecharts and code a FSM for it.

Is there a good visual representation of states that is more efficient than listing them out in words? (sort of like flowcharts are easier to look at than "IF (blah) GOTO (blah) ELSE (blah)")

Such fond memories! The pop machine is the "Hello, world!" of Engineerland!

Of couse, these days thanks to Microsoft, we have "popmachine.NET". What once was implemented with a smattering of TTL logic must now posess a Pentium chip, megabytes of RAM and embedded Windows with the.NET framework. At least now there's a book out there that will inform today's enlightened pop machine programmers how to use "state charts" to develop efficient C# code for such a beast.

Five years ago, I was working for a non-profit SW firm that produced multimedia educational tools -- helped kids learn to read, do elementary math. Not only was it the most fun sw place I've ever worked (we were supposed to all go see "A Bug's Life" for iddeas, for example) but they actually engineered their software....

And the tech specs were described with states. Beautiful, simple, clean. Yep. Good stuff.

I once had to use an authoring tool (Rapid CBT) [e-sim.com], priced in the thousands of dollars, which was completely driven by statecharts. In my opinion, the statecharts offered no advantage at in the development as most of the logic needed wasn't suitable for statecharts. My guess is that statecharts are an easy way to make a visual representation of what is happening in the code, but is restrictive to the coding itself.

hmmm... my experience has been it depends on several factors (problem/solution/environment, etc.) that might govern "advantage". e.g. Kabira's [kabira.com] Design Center utilizes a really sweet plugin to Rose - almost 100% driven by UML/statecharts. I can't imagine a better tool for deriving solutions for the types of problems its best suited to solve. But as you point these tools are costly $$$!.

I've seen Rapid, and it is a very good tool for some purposes. However, the point of Samek's book is that the concept behind statecharts is valuable as a way to design and program better. Too often, statecharts are seen in association with expensive tools (like Rapid), and the vendor doesn't do a good job of teaching the thought process for designing in this way. Also, because the coding is hidden behind the visual tool, the developer doesn't feel comfortable making changes to the code even when it is po

... methinks SlashDot may be spammed by m$monkeys. Many of my Google searches on this topic ended me up at the msdev site.I resist temptation to drop US$15000 to be m$certified.

State machines, statecharts, all seems a tad modal to me. State, to me, is simply a piece of information and calling it "state" and giving it this whole modal metaphor simply confuses. I hear a FUDding sound

progging by example, examples, lots of examplesoh, and we're "modelling" here we don't actually need to do any coding

...to be familiar with state charts is that there are some good tools out there that can generate code straight from a state chart diagram. The implementation from IAR (www.iar.com) even handles real-time designs.

The reviewer makes a great point (both philosophically and as a selling point for the book) - the ability to model state is absolutely invaluable when it comes to designing systems that are both effective and efficient.My new hammer in the state modelling department is petri nets; I would recommend any developer looking to learn about state modelling investigate petri nets as a supplement and/or replacement for state charts.The translation of state chart to petri net (and vice-versa) is fairly straight-forw

Statecharts are not just buzzword... I think that the comments should treat this topic as effectively as possible. Statecharts are perhaps one of the most useful ways of representing and specifiying system behavior.

It is very interesting to see Statecharts mentioned on Slashdot. Statecharts are very useful for many reasons. I know that at NASA, in Europe and in the embedded world, generating code from directly from statecharts is very useful in having a very effective way of producing good code such that

I wrote about this in an internal reply but apparently people didn't seeit and are continuing to make some very ignorant statements about Statecharts.

Statecharts are not a fancy way to do state machines. They are an extremely sophisticated graphics based notation with a formal mathematical semantics for modelling reactive systems. The ideas behind statecharts were developed by David Harel and Amir Pnueli (a winner of the prestigious Touring award and a world expert in Temporal Logic which heavily influenced the semantics of Statecharts).

I was one of the early programmers (later manager) in the company that Harel and Pnueli founded in the early 80s. Because of its mathematical basis, we were able to build a tool that "executed" the statechart designs - not a probabilistic execution, but more akin to a mathematical proof done via a computer program.

This isn't just a nice toy. It was used by companies like Alsthom-Alcatel to build the high-speed TGF train. The reactive model of the train was designed in Statecharts and the model executed. In this way they were able to discover serious flaws in the design (e.g. situations where the doors would open while travelling at high speeds). The only alternative to doing this is to build prototypes and do real world testing. By finding flaws in the very earliest design stage, the company was able to save millions of dollars and perhaps some lives.

For more online information see:

http://ilogix.com/quick_links/white_papers/index .c fm

There is also a paper about Statechart semantics which I am listed as an author out there, but I have only found citations online. UML adopted Harel's Statecharts with some minor modifications, as part of the standard. They never claimed to invent it.

Disclaimer: I still have some stock options in i-Logix which was founded in 1984 but never did go public.

If (like us) the requirements and design are more fluid, then you will likely find yourself hampered by this, as the design cannot be known until you've coded a little.

Boy, I had to jump in on this one.

True, not all projects benefit from statecharts. If you have something simple to do, you do it simply. However, the poster's comment about fluid designs actually makes a strong case for using a rigorous design methodology. There's nothing wrong with coding a little bit and then revising designs, but i

For his fundamental work in various areas of theoretical science, his invention of the visual language of statecharts for specifying reactive systems, and his expository contributions, especially via the widely acclaimed 1987 book "Algorithmics, the Spirit of Computing".

If you are interested at all in theoretical computer science, you should read his book, which is

The roundtable discussion from the Game Developers Conference was recentlyposted. One area that may be of interest is Session 6.

Session 6:

* Finite State Machines
Objectives
Identify how FSMs are commonly embedded in games
Define a common language to describe finite state machines
Define an XML description of FSMs for interoperability between tools
Define an API whereby FSMs can be efficiently and easily interfaced withother

This is a great book which concisely explains state charts, their application and the numerous ways to implement them.

The illustrated examples of how hierarchical state machines really work are great for anyone looking to really utilize the concepts embraced by among others the UML to their full potential.

That said, the approach used by the supplied framework is not without flaws (exception safety versus Run-To-Completion discrete steps, etc), as pointed out in discussions on USENET. Whether it fits your

That's funny. On my machine, Intel C++ 7.x compiles a simple std::string/std::vector test into code that executes slight faster than the equivilent const char */const char ** test. Unless you have the time to hand optimize every little data structure, the STL will be faster in the long run. I always find it silly when I read C books, and see something like "a linked list isn't the most efficient data structure for this, but this operation isn't *that* critical, and using a list saves implementation complexi

C and C++ are not going away. They will never go away. There will always be a need for that sweet spot that gives the power of assembly and the readability of a HLL. And sorry Java just doesn't cut it.

FSM's are often used in FORTH. Since it is easy to create an array of functions to be called.

Create a buffer, fill it with input and call the function for the inital "state", which processes the input and passes it off to the next state in the array, till you hit a function which "finishes" the transformation of the input string.