Slashdot Mirror
Practical Statecharts in C/C++
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.
It is easy enough to use a standard library that helps you maintain such buffers/stacks/queues. No need to mess around with standard c arrays.
I miss my rubber keyboard.(Homepage)
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.
I recommend this book.
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.
uh, this is realtime, baby. screw the unecessary overhead of STL. i'm a big boy and can handle native c arrays just fine.
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.
R. Roberts. Zone Logic: A Unique Method of Practical Artificial Intelligence. Radnor, PA, Compute! Books, 1989. citeseer
I use Bruce Powel Douglass' Real-Time UML, Second Edition, Developing Efficient Objects for Embedded Systems .
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?)
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.
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.
For those that have read it or are reading it.
Does it address programming general/arbitrary FSMs or managing Object state al-la UML state charts?
Thanks.
Ah, well, google to the rescue: here's good example of a statechart.
A good knowledge of C ... blablabla. No need to mess around with C++.
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?"
What overhead? Perform some tests with decent compilers. You might be surprised.
And he never said STL. He said *a* standard library. But anyway...
It's always a long day... 86400 doesn't fit into a short.
"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)."
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.
Ok, there's your dose of CS for the day.
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.
...
For those readers who haven't before encountered state machines:
Los Alamos National Lab has some good info (overview mostly)
Lecture notes from MIT
An interesting research project from The Beast
Some info on how FSMs are used for AI in computer games
Arr! The laws of physics be a harsh mistress!
I once had to use an authoring tool (Rapid CBT), 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.
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.
The net will not be what we demand, but what we make it. Build it well.
submitted by JonKatz, and then promptly skip down to the next story?
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:
Set up some moving floors that will carry an object (zombie doll).
Player crosses line.
Open a door and release zombie doll.
Zombie doll 1 moves, crosses a line and turns up the lighting.
Zombie doll 1 moves crosses a line and opens trap door releasing monsters at player.
Zombie doll 1 moves crosses a line and opens another door releasing Zombie doll 2
Zombie doll 2 moves crosses line opens exit for player.
Zombie doll 1 stops.
Zombie doll 2 moves crosses a line drops floor player may be on.
Zombie doll 2 moves crosses line which turns pit floor into lava.
Zombie doll 2 moves.
Zombie doll 2 moves.
Zombie doll 2 crosses line and opens an exit for the player.
Zombie doll 2 stops.
A friend rendered a bloated complex microprocessor design into a state machine he placed on an eprom.
The eprom was clocked and some other chips added to step it through a rather complex routine. It could take input, it could 'make decisions' based on that input, all of it was encoded on the eeprom.
It required no microprocessor, minimal support hardware ect etc. Just a clock, an eprom, some logic chips and someone who knew state machines.
It was 1000 times less expensive than the buggy, non-working microprocessor design.
All he had to do was see what the customer wanted to do and purpose program it for that task. If it needed reporgramming, burn another eprom.
I'd go on a Vegan diet but the delivery time from Vega is too long. --brownkitty
> 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.
Though I suppose the you could write on that doesn't take input and doesn't produce output; but why bother?
... 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 examples oh, and we're "modelling" here we don't actually need to do any coding
(aka a class) with various interface methods (messages/questions you can command/ask of this object) that I choose to dangle off of it:Buried underneath/within/externally/remotely of this object somewhere, that no one needs to know about, is some storage that somehow indicates whether the button is currently "up" or "down." I guess some might call this the "state" of the button.
clear as mud
He's talking about the overhead you see if you actually perform the tests on STL and compare to a custom implementation. It's there, but you have to be slightly insane to care about it, in most circumstances. Actually, you'd have to be slightly insane to use C++ in most circumstances, if not for the fact that co-operating with the rest of the world is easier if you share their insanity.
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 fundamental concept. This is even more true for embedded systems, where many (machine based) optimization techniques involve using a strict Meely or Moore implementation of a state machine (I'm thinking right now about how much better it works if you program using one of these models when writing in VHDL for an FPGA).
Mod me down and I will become more powerful than you can possibly imagine!
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.
vi +
Ed Nisley had reviewed this in Dr. Dobb's Journal. The review is available here. I had just read the article this morning and was pleasently surprised to see the review here.
...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.
I've never seen assembly that's as horrible to read as C++.
Maybe if you look at the bits in the binary form of machine language, and then poke a pencil in your eye at the same time.
-Kevin
I thought it was "all the power and speed of assembly with the readability and abstraction power of assembly".
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.
Most of those additions have been mentioned already (e.g. nesting) but there are also guard conditions (i.e. transition if X except if y), and indications of entrance, presence, and exit behavior. Very handy for describing behavior.
IP is just rude.
Is there any torture so subl
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.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
When I was still employed, I implemented networking protocols in C++, and that means implementing lots of interacting state machines.
The simplest way to model messages between the state machines is a function call, but function calls come with a severe penalty: it can be really difficult to know when you can destroy an object. The message that triggered the destruction may have been called from a function that was called from a function that was called from a function belonging to the object to be destroyed.
The most straightforward trick is to move all interobject function calls to the end of the function leaving only return statements hanging in the air in case the object gets destroyed within the function call. However, that is often impossible to arrange.
Another possibility is to marshal all interobject messages into a message queue, but that will degrade the performance significantly and still forces you to keep track of dead objects that have messages pending in the queue.
In practice you are left with error-prone optimizing tricks and flags for pending conditions.
The whole thing is much easier to manage with languages that have garbage collection built in, although you are again paying a performance penalty.
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.
x .c fm
:)
Alsthom Alcatel, for example, used our tool to discover flaws in the high-speed TGF before they started actually building it. They thereby saved millions of dollars in construction retooling costs and probably some lives as well.
You can find a whole bunch of whitepapers here:
http://ilogix.com/quick_links/white_papers/inde
Full disclosure: I still have in a drawer somewhere some stock options in i_logix, which was founded in 1984 but never did go public
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-forward; petri nets also provide more robust options for modelling concurrency (it is possible to model non-deterministic choices using petri nets). Colored petri nets add the ability to factor time into the model as well.
There are many petri net tools (of varying usefulness) available for a multitude of OSes; an impressive list can be found here.
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.
... but what one can then do is then run a verifier on the statechart, to sort out these niggly bits.
S tateflow - http://www.ilogix.com/products/magnum/index.cfm
U ppaal - http://www.uppaal.com/ ... and quite powerful
e d_Articles/EmbeddedSystemsArticle.html
t ternAlmanac/review.htm
# example
p ositional.ppt
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 all the STATES of the system are known.
Note however that this DOES NOT mean that the code is verified. Things such as deadlocks, livelocks, and unreached states may exist
Another problem that some Statechart autocoders create is that they use a lot of GOTO statements. If you hate GOTOs then you may encounter them a lot with some tools.
Some good references:
Statemate - http://www.ilogix.com/products/magnum/index.cfm
FREE and looks very good, it is a real time model checker for timed automata.
Spin - http://www.spinroot.com/spin/whatispin.html
Also very good
Good reads are some of
1. The work by Eric Klavins of Caltech
http://www.cs.caltech.edu/~klavins/pubs.html
http://www.eecs.umich.edu/gasm/ (Abstract State Machines @ Umich)
Particularly Eric Klavins work on "Object Oriented State Machines"
- http://ai.eecs.umich.edu/CNM/Publications/Publish
- http://www.embedded.com/story/OEG20020429S0053
2. Miro Samek's website
- http://www.quantum-leaps.com/
3. "The Curiously Recurring Template Pattern"
- http://www.langer.camelot.de/Articles/Fawcette/Pa
4. The Boost C++ Metapramming Library (how can one forget Boost?)
- http://www.mywikinet.com/mpl/paper/mpl_paper.html
5. Gerrard Holzmann's Spin Tool
http://www.spinroot.com/spin/whatispin.html
But you should also read Eric Klavin's Propositional Logic Tutorial
- http://www.cs.caltech.edu/~klavins/lpe/slides/pro
6. The work of Nancy Day at the University of British Columbia
ftp://ftp.cs.ubc.ca/pub/local/statecharts/README
And many many more
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.
Libertarianism is rich wolves and poor sheep playing gambler's ruin for dinner.
Granularity?
Karnaugh maps pretty much define the minimal set of states that a machine should have. PERIOD. this is deterministic and does not "depend on granularity". I, too, am disturbed by the lack of basic logic developers have.
Zing... you can fill a whole book with how to turn a state diagram into essentially:
.
switch(statevar) {
case STATE1:
outvar = boolfunc1(invar1, invar2...);
statevar = STATE2;
break;
case STATE2:
outvar = boolfunc2(invar1, invar2...);
statevar = STATE3;
break;
. .
}
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 digital circuitry much in the same way someone learning a new language will tend towards mentally translating into english.
Hmm...I guess those without a background in electrical engineering--particularly digital design--really do get a view from a completely different perspective.
After a second or two of clue-in time (state CHART == state DIAGRAM == state MACHINE) I was thinking "and the big deal is...?". This concept was covered in an INTRODUCTORY electrical engineering course in my case. We started with "welcome to the world of boolean logic"--working with equations and karnaugh-maps and what not--then went straight onto using those concepts to implement state machines with 74LS... TTL chips stuck in breadboards.
I guess being that is what I learned and how I always thought is why I carried the concept with me into programming. State machines were central in implementing VHDL. Subsequently, my C programs kind of look like my VHDL did. One observation I've made--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.
Such fond memories! The pop machine is the "Hello, world!" of Engineerland!
.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.
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
A book about using statecharts for UI design and implementation
o ads/in dex
Ian Horrocks
Constructing the User Interface with Statecharts
Addison-Wesley 1999
Robert Martin's state map compiler for/in C(++) and Java
http://www.objectmentor.com/resources/downl
Charles Rapp's state machine compiler
http://smc.sourceforge.net/
Michael
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.
x .c fm
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/inde
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.
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 programs down so those business programmers (or power users, as I like to call them when I'm in a good mood; or fucktards when I'm feeling particulary nasty) who took an abundance of programming courses can understand them. Proof that the universe cannot be described strictly in states of true or false!
Spread the RC luvin'
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!
A deep unwavering belief is a sure sign you're missing something...
And for some people everything will look like a nail. We evaluated this book/methodology recently for a project that I work on, and found it to be overkill for what we wanted. Statecharts/FSMs are great for the niches that suit them (stateful protocols, parsers, critical systems) but for our needs, it was too much. If your project works within strict design parameters, and you can take the time to design the UML/statecharts/FSM then this will be a good tool. 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.
Also, Quantum comes from the fact he has a PhD in nuclear physics (and likes to tell you about it!), so he understands the analogy. Basically if you've coded a statemachine before, there won't be too much new in here.
Cheers
He is an ACM Fellow, whose citation reads
If you are interested at all in theoretical computer science, you should read his book, which is coming out in a 3rd edition this year.
Subject: AI Interface Standards: Report of the GDC 2003 Roundtable
l e/
The roundtable discussion from the Game Developers Conference was recently
posted. 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 with
other systems
Definitions
Overview like UML statecharts, with some simplifications FuSM, HSM
XML Description
See the link: http://www.ai-center.com/events/gdc-2003-roundtab
at least that is what many decision makers would say. I never understood why there is such a large pool of ready fools out there whom will dictate specific implementations for no better reason than that it sounds cool. Sure, saying something like "Yes, but we want something extensible and modular since we will be adding to its feature set in the future often" is great. Saying, "We want Java because it is so good at networking, blah blah blah" Well if you are aware of that when why did you not simply get some programmers and instead gathered up architects, engineers and various analysts? Save money and develop it yourself. Granted there is nothing really "wrong" with this approach but they should not be too surprised if problems arise soon after development due to a lack of open minded planning.
There are many many tools, some of them are VERY interesting - Uppaal and XJTek are from Europe and have very nice user interfaces ... (some result from google and other)
d ex.html]
. cfm]
t e.html]
DiaGen [http://www2.informatik.uni-erlangen.de/DiaGen/in
DOME [http://www.htc.honeywell.com/dome/]
STATEMATE [http://www.ilogix.com/products/magnum/index.cfm]
Rhapsody [http://www.ilogix.com/products/rhapsody/rhap_inc
Rational Rose [http://www.rational.com]
tateflow [http://www.mathworks.com/products/stateflow/]
XJTek [http://www.xjtek.com/products/xjcharts/]
Poseidon for UML [http://www.GentleWare.com]
ArgoUML [http://argouml.tigris.org/]
BetterState Lite [http://www.windriver.com/products/html/bettersta
visualSTATE [http://www.iar.com/Products/VS/]
Uppaal [http://www.uppaal.com]
Let's deconstruct that statement:
start state:
- traditional state diagram represents as a circle with a "greater than sign" (e.g., >O)
- UML represents as a filled-in circle
intermediate states:- traditional state diagram represents as a circle
- UML represents as a rectangle with rounded edges
terminal state(s):- traditional state diagram represents as a circle within a circle
- UML represents as a filled-in circle within a circle
Yep, that's definitely "better"...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 need will ultimately be a decision you have to make for yourself, no framework will fit every occasion. The main strength of the book, IMHO, lies in the clear explanations of concepts and implementation, not only in the supplied framework.
As a sidenote: I misplaced the CD that comes with the book and emailed the author. He replied within the hour, and he had put the full CD zipped on an FTP-site and provided me with a login/password. You've gotta love that kind of response.
All in all, I pretty much agree with the review and think the book deserves a strong 9/10. I recommend it to anyone who wants to rethink the way they currently write applications.
I think the UML mechanism to express a hierarchy of states is called "submachines". It's hailed as the Next Coming, but it's similar to the decomposition of "processes" into subprocesses in the now out-of-favor Structured Analysis.
I'm a little surprised that the poster didn't use the term, it's not like Samek doesn't use it everywhere in his book.
The first half of the book is just exploring different ways of implementing FSMs/HSMs in C and C++. It doesn't seem like a hard thing to do, but a simplistic version with nested switch/case statements is really a recipe for hard to maintain code.
The sencond half of the book though, explains Samek's "Quantum Framework", of interacting HSMs. I don't think that this is earth-shattering, but it's not the way most people are taught to code in C/C++, and I think it is a neat framework to use, especially in embedded/safety-critical systems.
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) . Keep in mind, however, it's not a method. What you do with it determines it's effectiveness.
I've just finished reading Executable UML: A Foundation for Model Driven Architecture which basically implements the Schlaer Mellor methodology in a subset of UML, as part of a project to create the compilable and and executable UML of the title.
I have a lot of time for Schlaer Mellor. As a methodology coming from the real-time world, it takes my softer async requirements (eg client-and-server or browser-and-application) well in its stride.
It's also very much based on UML statecharts, and if anyone has read both I'd like to know how these two books compare.
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.
Explanation of [degenerate]:
Markov chains can be represented by both matricies and graphs. The primary difference I see between a graphed Markov chain and a statechart is that the Markov transitions are typically weighted. Knowing the event probabilities allows you to do some rather interesting stuff, like make predictions as to the number of trasitions before entering a terminal state, etc.