Practical Statecharts in C/C++

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.

Practical Statecharts in C/C++: Quantum Programming for Embedded Systems
author	Miro Samek
pages	389
publisher	CMP Books
rating	10/10
reviewer	Jonathan Kaye
ISBN	1578201101
summary	Practical and methodologically sound approach to improving software design using statecharts

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!)

---

You can purchase Reviewing Practical Statecharts in C/C++ from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Re:C and C++

[Anonymous Coward]

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.

The UML crowd discovers finite state automata

[Animats]

...and act like they invented them.

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?"

Re:Zing ....

[Anonymous Coward]

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.

Huh, you finally figured it out?

[cybermace5]

And it took an embedded systems developer to bring it to your attention.

It's not new. We've been doing state diagrams over here in Engineerland for decades.

Statecharts Driven

[jetkust]

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.

What Statecharts Are

[Aron S-T]

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.

Re:C and C++

[be-fan]

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 complexity." If we were using the STL, you could just use whatever data structure was best suited to the task at hand, without worrying about implementation complexity!