Most Helpful Customer Reviews
|
|
37 of 38 people found the following review helpful:
5.0 out of 5 stars
Thank you Miro Samek., June 28, 2003
I seldom write reviews. This book changed my life, and I've been developing embedded software for twenty-five years. Samek's nested finite state machines, which he calls Hierarchical State Machines (HSMs) give the embedded software architect a framework arguably as fundamental as an RTOS. If you are creating event-driven embedded software where objects have member variables representing their state at any given time, this book is required reading.For those of you unfamiliar with state machines, the book gets you up to speed in a hurry. For those of you unfamiliar with the advantages of state machines, especially HSMs, permit me to summarize. They allow you to create design diagrams (the book uses UML-plus) that map directly and clearly to code, they let you keep the code and diagrams in sync more easily, they allow you to create better designs because you are thinking in terms of events, states, and transitions as well as in terms of objects, they allow you to have more effective reviews, and they allow you to create more testable code since events serve as inputs and states serve as outputs. To some degree, object-oriented design without HSMs provides those benefits, but state machines let you define the complete set of events and state transitions so you can test more rigorously and more completely - and more automatically. By the way, the book does read well and read quickly. After your first read, as you begin using HSMs to design software, you will reference sections of the book and begin acquiring a more in-depth understanding of the details. You'll find yourself talking with your peers about the book, and then they'll read it. Soon you'll be enjoying collaborative design based on use cases that spawn statecharts, classes (each HSM is an object), and real-time constraints. Read the book, use the book, and enjoy a new level of software engineering. Other books I recommend highly: Bloch - Effective Java, Brooks - Mythical Man Month, DeMarco and Lister - Peopleware, Howlett - Visual Interface Design for Windows, Kaner - Lessons Learned in Software Testing, Kaner - Testing Computer Software, McConnell - Rapid Development, McConnell - Code Complete, McGuire - Debugging the Development Process, Meyers - Effective C++, Microsoft, Windows User Experience (reference book), Norman - The Design of Everyday Things, Riel - Object-Oriented Design Heuristics (Want to learn OO? Read this), Strunk and White - Elements of Style, Vermeulen - The Elements of Java Style
|
|
|
34 of 37 people found the following review helpful:
3.0 out of 5 stars
less useful than I initially thought, June 1, 2006
A couple of months ago I would have fully agreed with most of the reviewers: yes, statecharts is an important topic, and Samek covers it well. Indeed he does: The book is chock-full of (working!) code and will give you a head-start at tackling difficult behavioral control problems. I do not develop real-time software, but thinking of _every_ software as if it were real-time can increase quality. I feel I gained a lot of insight, and it made me rethink some architecture issues.
You can brush over the quantum-babble, mainly because it's irrelevant and an already overstreched analogy-for-everything. With regards to Statecharts, no harm is done that Samek is evangelizing a little bit too forcefully.
So why 3 stars only? After working with the concepts and coding a number of statemachines the Samek-way, I started to notice that Samek's approach does not quite deliver as promised:
* Be prepared to be disconnected from the community: Samek's statecharts part in a lot of aspects from the UML 2.0 statecharts (although there is a website w/ quite a lot of activity). Looking at UML-compliant statecharts from fellow developers you will realize that you cannot transcribe them easily using Samek's framework. Main reason: UML has functionality (= non-statemachine code) in transition actions and event guards, Samek in state event handlers.
* Samek's statemachines are "run-to-completion", which results excessive self-posting of events and queuing. Although the code is not spaghetti, the execution is - and debugging is _very_ difficult.
* After a while, it is very difficult to infer the statechart semantics from the code. I certainly want to believe Samek that there is no real value in separating semantics (= statechart description) from functionality (= code which uses the statemachine), but this turned out to be a maintainance nightmare.
* Samek's statemachines do not offer orthogonal states, but for bigger projects you will need orthogonality to model concurrent aspects of a system. The lack of orthogonality is salvaged by the publish/subscribe framework also included in the book: You just use a number of statemachines and connect them via a message bus. This might work in the real-time space but it's obviously not something you will be able to include in your software. As a consequence, it is difficult to use statemachines in a "tactical" fashion.
David Harel (the inventor of statecharts, see his paper from '87, e.g. on citeseer) designed statecharts as a visual language to enable thinking (alone and in the team) about the behaviour of systems. Samek disagrees: coding and thinking go hand in hand. This might seem to be very "agile" but there are pitfalls. Actually he seems to be as strict in his assertions than Harel is - not agile at all.
There are approaches which are more balanced in that they mimic statechart semantics "better" (= more UML-compliant) than his. Take a look at SCXML (XML-driven, Java-interpreted) or at CHSM (C++/Java code generation). Also take a look at the roundtrip modelling tools which (most likely) ship w/ your preferred development environment.
Samek is very up-beat and a strong believer in what he says. I bought into his vision and hoped for a productivity / morale boost comparable to using unit tests (like JUnit). It never really turned out that way, and statemachine coding à la Samek remained a trial-and-error business until I decided to use a different approach.
It's an important, very original book, and an interesting read. My advice: Give it a try, but don't get carried away.
|
|
|
24 of 25 people found the following review helpful:
5.0 out of 5 stars
Excellent, thoughtful and technical treatise on statecharts, April 2, 2003
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.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 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, 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!).
|
|
|
Most Recent Customer Reviews
|
by Christopher Hallinan
by Jean J. Labrosse
See all 15 books this book cites
