Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Programming Books Media Book Reviews IT Technology

Practical Statecharts in C/C++ 121

Posted by timothy 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.
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.
This discussion has been archived. No new comments can be posted.

Practical Statecharts in C/C++ More

Practical Statecharts in C/C++

Comments Filter:

  • currently reading it (Score:4, Informative)

    by Tangurena ( 576827 ) on Thursday April 10, 2003 @11:40AM (#5702185)
    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.

    I recommend this book.

    • 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
    • C/C++ just aren't good languages for implementing state machines in. Languages with support for full coroutines (like uC++ [uwaterloo.ca]) make implementing state machines practically trivial.

  • Zing .... (Score:3, Interesting)

    by binaryDigit ( 557647 ) on Thursday April 10, 2003 @11:42AM (#5702194)
    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.

    • Re:Zing .... (Score:5, Informative)

      by broody ( 171983 ) on Thursday April 10, 2003 @12:03PM (#5702378)
      State Charts are one of the nine UML [google.com] diagrams. There are some tutorials here [google.com].

    • Re:Zing .... (Score:1, Insightful)

      by 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.
      • 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.
    • 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).

    • Real world examples. (Score:4, Interesting)

      by dsplat ( 73054 ) on Thursday April 10, 2003 @12:21PM (#5702540)
      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:

      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
      • 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.
    • 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
      • 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

  • what ever happened to Zone Logic? (Score:4, Interesting)

    by e4liberty ( 537089 ) on Thursday April 10, 2003 @11:47AM (#5702231)

    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 [nec.com]

  • What I use... (Score:4, Informative)

    by guido1 ( 108876 ) on Thursday April 10, 2003 @11:48AM (#5702241)
    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?)

  • BUY THIS BOOK NOW! (Score:1, Funny)

    by Anonymous Coward
    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.

  • gee, thanks (Score:5, Informative)

    by joenobody ( 72202 ) on Thursday April 10, 2003 @11:57AM (#5702316)
    Would it have killed the author to mention what a statechart is?

    Ah, well, google to the rescue: here's good example [dotnetcoders.com] of a statechart.

    • Re:gee, thanks (Score:3, Informative)

      by jjjefff ( 525754 )
      Here's a longer overview [216.239.39.100]... Could only find it in Google's cache.
    • Ah, so "StateChart diagrams" are just what the softies are calling "state diagrams" or "state machines" these days. Look mom, I can write a switch/case statement and diagram it in UML. Yawn.

      • What Statecharts are (Score:3, Informative)

        by Aron S-T ( 3012 )
        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.

      Explanation of [degenerate]:
      Markov chains can be represented
      • 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.

  • The UML crowd discovers finite state automata (Score:5, Insightful)

    by Animats ( 122034 ) on Thursday April 10, 2003 @11:58AM (#5702330) Homepage
    ...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?"

    • > 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.

          Rather,

          • 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,

    • "...and act like they invented them."

      They do?

      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.

      For example
    • 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

  • State charts and C (Score:3, Funny)

    by mao che minh ( 611166 ) on Thursday April 10, 2003 @12:00PM (#5702344) Journal
    I decided to read between the lines:

    "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)."

  • Ok, state machines (Score:5, Informative)

    by pclminion ( 145572 ) on Thursday April 10, 2003 @12:04PM (#5702386)
    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:

    1. read input
    2. decide which state to move to based on input and current state
    3. execute transition action
    4. actually move to the new state
    5. 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.

    • When I heard the author speak at a meeting of the ACCU [accu-usa.org] recently, he described statecharts somewhat differently from the basic FSMs I knew.

      Basically, statecharts allow some extensions to FSM: nested states, init/entry/exit actions for states, and probably some others. Apparently these are all defined in UML.

      The author's basic approach is to represent the state as a pointer-to-member-function. Except that he's working on embedded systems, which means he uses C, which means he hacks his own OO in C. I m

    • He's not talking about finite state machines. Statecharts are much more. For example:
      • You have nesting: it is easy to jump out of a sub-statechart. No need to draw arrows from all the states inside to the outside world.
      • 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.

      Statecharts are actually used to fully describe beasts like factory process control systems (the tools then generate C

      • You have nesting: it is easy to jump out of a sub-statechart.

        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.

        • Yes, the book is mainly about implementing HSMs. One of his classes is called "QHsm", for example. The distinction is that a Statechart is the drawing of the HSM (Samek just uses Visio for that).

          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 stat

    • Differences between a statechart and an FSM:

      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

    • 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.

      A quick google search shows the following reference:

      • D. Harel. Statecharts: A Visual Formalism for Complex Systems. Science of Computer Programming, July 1987, pp. 231-274
    • 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)")

  • Huh, you finally figured it out? (Score:5, Insightful)

    by cybermace5 ( 446439 ) <g.ryan@macetech.com> on Thursday April 10, 2003 @12:05PM (#5702398) Homepage Journal
    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.
    • 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.

    • And we in the Mathamatical realm have been doing it since.....hey didn't we come up with it in the first place?

  • A little background information... (Score:3, Informative)

    by MmmmAqua ( 613624 ) on Thursday April 10, 2003 @12:18PM (#5702502)
    For those readers who haven't before encountered state machines:

    Los Alamos National Lab has some good info (overview mostly) [lanl.gov]
    Lecture notes from MIT [mit.edu]
    An interesting research project from The Beast [microsoft.com]
    Some info on how FSMs are used for AI in computer games [gameai.com]

  • Statecharts Driven (Score:3, Insightful)

    by jetkust ( 596906 ) on Thursday April 10, 2003 @12:20PM (#5702530)
    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 examples oh, and we're "modelling" here we don't actually need to do any coding

  • Ed Nisley had reviewed this in Dr. Dobb's Journal. The review is available here [ddjembedded.com]. 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.
  • 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

  • Some good readings ... (Score:2, Interesting)

    by Anonymous Coward
    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
  • A book about using statecharts for UI design and implementation

    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/downlo ads/in dex

    Charles Rapp's state machine compiler
    http://smc.sourceforge.net/

    Michael

  • What Statecharts Are (Score:4, Insightful)

    by Aron S-T ( 3012 ) on Thursday April 10, 2003 @04:23PM (#5704943) Homepage
    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.

  • Statecharts were originally developed by David Harel. His original paper is here: Statecharts.pdf [weizmann.ac.il]

    He is an ACM Fellow [acm.org], whose citation reads

    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

  • Subject: AI Interface Standards: Report of the GDC 2003 Roundtable

    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
  • 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
  • I've just finished reading Executable UML: A Foundation for Model Driven Architecture [amazon.com] 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 re

Slashdot Top Deals

He has not acquired a fortune; the fortune has acquired him. -- Bion

Close