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, when there aren't some good examples to drive the points home. In that regard, both Horrocks and Samek show some good real world examples (Horrocks - design flaws in the Microsoft Windows calculator, Samek - the Therac-25 medical device that killed people as a result of design flaws in the capturing of machine state).
I agree with you completely that there is nothing magical about a statechart. I think Samek's point is exactly that -- too often, statecharts are seen in association with expensive tools, and so the message is that you need an expensive tool to work with them. Samek argues that statecharts will have their greatest value as a developer-empowering design methodology, not the output of a code generation program for the high-level user. I think the tool companies too often try to sell it to high-level people rather than get down and dirty and explain how statecharts can help the low-level developers.
I also agree with you that this is not new or innovative -- it has been around for almost 20 years! Still, however, many developers haven't heard about them or have dismissed them outright because of lack of knowledge. Yet programs today routinely are HUGE and have life cycles easily of years if not decades. With big pressures on developers to meet deadlines, less emphasis is placed on design for longevity, and future developers (and users) will suffer.
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 in a rapidly-changing environment, you need to use a solid methodology so you don't end up with spaghetti design and code.
Ian Horrocks, in his book Constructing the User Interface with Statecharts, contrasts the traditional "bottom-up" design/programming approach with the "top-down". The bottom-up is kind of code as you go, and quickly becomes a real mess (and much more prone to bugs). The top-down approach is about thinking at the high-levels of behaviors for the system, and progressively working down the branches. Statecharts (and even linear FSM's, as appropriate), are an excellent way to organize thoughts, designs, and then eventually the programming.
Sorry to go off on a project that you say statecharts are overkill for, but even based on your short description, it sounds like you may need them more than you realize.
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 possible (this is the reluctance you describe).
The solution is to explain the concepts behind statecharts better so that the developer is in control. In other words, to empower the developer, not make a tool that dumbs things down.
Miro Samek (and Ian Horrocks, in his book, Constructing the User Interface with Statecharts, and me, in mine - Flash MX for Interactive Simulation) teaches the concepts so that you see the meaning and not confuse it as requiring some visual (and expensive) tool.
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 people who make the comments like you made really haven't taken any time to read about statecharts, or perhaps have seen them in expensive tools and dismissed them as just something else to learn and not worthwhile. A lot of times, people dismiss them because they have not seen good examples of their use.
I'd strongly suggest you read Ian Horrocks' book about using statecharts for user interface design (Constructing the User Interface with Statecharts), or Miro Samek's book on embedded systems, or my book on simulation construction with statecharts ("Flash MX for Interactive Simulation"). You will see that much traditional software, made by people with more than enough CS background to go around, in many cases still suffers from design problems. Horrocks has a great example of problems with the Visual Basic calculator that comes with Windows, and Samek has a great example (Therac-25) of a therapeutic medical device that killed people because of programming design flaws.
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
Slashdot Mirror
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, when there aren't some good examples to drive the points home. In that regard, both Horrocks and Samek show some good real world examples (Horrocks - design flaws in the Microsoft Windows calculator, Samek - the Therac-25 medical device that killed people as a result of design flaws in the capturing of machine state).
I agree with you completely that there is nothing magical about a statechart. I think Samek's point is exactly that -- too often, statecharts are seen in association with expensive tools, and so the message is that you need an expensive tool to work with them. Samek argues that statecharts will have their greatest value as a developer-empowering design methodology, not the output of a code generation program for the high-level user. I think the tool companies too often try to sell it to high-level people rather than get down and dirty and explain how statecharts can help the low-level developers.
I also agree with you that this is not new or innovative -- it has been around for almost 20 years! Still, however, many developers haven't heard about them or have dismissed them outright because of lack of knowledge. Yet programs today routinely are HUGE and have life cycles easily of years if not decades. With big pressures on developers to meet deadlines, less emphasis is placed on design for longevity, and future developers (and users) will suffer.
-jonathan
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 in a rapidly-changing environment, you need to use a solid methodology so you don't end up with spaghetti design and code.
Ian Horrocks, in his book Constructing the User Interface with Statecharts, contrasts the traditional "bottom-up" design/programming approach with the "top-down". The bottom-up is kind of code as you go, and quickly becomes a real mess (and much more prone to bugs). The top-down approach is about thinking at the high-levels of behaviors for the system, and progressively working down the branches. Statecharts (and even linear FSM's, as appropriate), are an excellent way to organize thoughts, designs, and then eventually the programming.
Sorry to go off on a project that you say statecharts are overkill for, but even based on your short description, it sounds like you may need them more than you realize.
-jonathan
The solution is to explain the concepts behind statecharts better so that the developer is in control. In other words, to empower the developer, not make a tool that dumbs things down. Miro Samek (and Ian Horrocks, in his book, Constructing the User Interface with Statecharts, and me, in mine - Flash MX for Interactive Simulation) teaches the concepts so that you see the meaning and not confuse it as requiring some visual (and expensive) tool.
-jonathan
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 people who make the comments like you made really haven't taken any time to read about statecharts, or perhaps have seen them in expensive tools and dismissed them as just something else to learn and not worthwhile. A lot of times, people dismiss them because they have not seen good examples of their use.
I'd strongly suggest you read Ian Horrocks' book about using statecharts for user interface design (Constructing the User Interface with Statecharts), or Miro Samek's book on embedded systems, or my book on simulation construction with statecharts ("Flash MX for Interactive Simulation"). You will see that much traditional software, made by people with more than enough CS background to go around, in many cases still suffers from design problems. Horrocks has a great example of problems with the Visual Basic calculator that comes with Windows, and Samek has a great example (Therac-25) of a therapeutic medical device that killed people because of programming design flaws.
If you're looking for something on the web to preview, I would suggest reading David Harel's original 1987 paper that started things out (http://www.wisdom.weizmann.ac.il/%7Eharel/SCANNED .PAPERS/Statecharts.pdf), or you can look at some references I have from my web site (http://www.flashsim.com/flash_resources-uml.html# state).
-jonathan
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