HN Books @HNBooksMonth

The best books of Hacker News.

Hacker News Comments on
Practical UML Statecharts in C/C++: Event-Driven Programming for Embedded Systems

Miro Samek · 5 HN comments
HN Books has aggregated all Hacker News stories and comments that mention "Practical UML Statecharts in C/C++: Event-Driven Programming for Embedded Systems" by Miro Samek.
View on Amazon [↗]
HN Books may receive an affiliate commission when you make purchases on sites after clicking through links on this page.
Amazon Summary
Practical UML Statecharts in C/C++ Second Edition bridges the gap between high-level abstract concepts of the Unified Modeling Language (UML) and the actual programming aspects of modern hierarchical state machines (UML statecharts). The book describes a lightweight, open source, active object (actor) framework, called QP that enables direct manual coding UML statecharts and concurrent event-driven applications in C or C++. This book is presented in two parts. In Part I, you get a practical description of the relevant state machine concepts starting from traditional finite state automata to modern UML state machines followed by state machine coding techniques and state-machine design patterns, all illustrated with executable examples. In Part II, you find a detailed design study of a generic real-time framework indispensable for combining concurrent, event-driven state machines into robust applications. Part II begins with a clear explanation of the key event-driven programming concepts such as inversion of control (”Hollywood Principle”), blocking versus non-blocking code, run-to-completion (RTC) execution semantics, the importance of event queues, dealing with time, and the role of state machines to maintain the context from one event to the next. This background is designed to help software developers in making the transition from the traditional sequential to the modern event-driven programming, which can be one of the trickiest paradigm shifts. The lightweight QP active object framework goes several steps beyond the traditional real-time operating system (RTOS). In the simplest configuration, QP runs on bare-metal microcontroller completely replacing the RTOS. QP can also work with almost any OS/RTOS to take advantage of the existing device drivers, communication stacks, and other middleware. The accompanying website to this book ( contains complete open source code for QP and the free QM graphical modeling tool for QP, ports to popular processors, including ARM Cortex-M, ARM7/9, MSP430, AVR/AVR32, PIC24, RX, etc., as well as QP ports to operating systems, such as Linux, Windows, and Android.
HN Books Rankings

Hacker News Stories and Comments

All the comments and stories posted to Hacker News that reference this book.
I'm not sure about that book however this one:

got on my reading list by virtue of the misfortune of dealing with code written by programmers who adopted the book's approach.

The thesis was that state machines are a powerful formalism that can be fully verified because all the states and edges between them are known. That's half-right: they are powerful because state transitions are essentially "goto" by another name. In practice goto-based programming is brittle to requirement change. The damning part is that state machines don't live in isolation: they interact asynchronously with other state machines and the world at large. The dynamic behavior of these interactions is probably important! and not part of individual state machines. You'd need to co-simulate them.

I feel state machines have their place where no higher-level construct (usually I prefer coroutines) fits the job and it can be kept small and rewritten on requirement change.

That's interesting.. Well I've been thinking of how well would they work along with a rich domain model and high level programming in general.. The book also has a chapter on systems of state machines, one of the suggested approaches was of an hierarchical model in which the lower stms input the higher ones only through their states.. Was the project you talked about embedded sw? BTW UML is also criticized by the book I mentioned, so hopefully it's not the UML trap again :P
In the article the author states:

  From this, we get that accounts should certainly behave like state machines.
  And from that, it’s reasonable that other pieces of code ought to be able to
  dynamically inspect an account’s current state, as well as its complete graph
  of states and transitions. That’s as much a part of its public interface as
  any particular method.
I disagree with this a bit. I think that the state transitions are not part of the public interface -- they're an implementation detail of the SM. The public interface of a SM are its states and the events it responds too. It's up to the SM to decide when to do the transitions. (The _author_ of the SM would be very interested in it's transition graph/conditions of course.)

For example, reviewing a bunch of the javascript SM libraries I see a few have the SM define a "transition table". This works for simple SM but makes it difficult to conditionally transition. Perhaps we want our bank account SM to automatically transition to the "hold" state if the balance goes below zero. With a fixed (i.e. as configuration) transition table we can't do this (or we have to fight against the SM library, or the SM library has to be more complicated).

I guess I'm fairly influenced by this book: I found that approach worked very well when I used it to implement a fairly sophisticated UI on an embedded device. It was easy to rationalize about, easy to read in the code, and easy to maintain (add/move states). Seems like something similar in javascript would be nice, except doing things in a javascript way.

Author here.

Conditional transitions, before- and after- actions, state entry conditions/validations, ... There are all sorts of places to go that have been proven fertile for developing robust software.

But you know... In one essay (two if you count its predecessor)... You have to draw the line somewhere. The goal is not to present a unified theory of modelling domain objects with state, nor is it to introduce some code that should be copied and pasted into a production pull request.

The simple goal is to provoke a conversation.

And if the outcome of that conversation for some people is, "We need conditional transitions, so the exact thing articulated in the essay is NoDamnGoodForUs," then I am actually quite satisfied that I've done my job as a blogger.

And if I can address your specific point--which I hope you understand that I agree with, even if it disagrees with that one paragraph--there are multiple approaches, and I think that if we really were modelling bank accounts as domain object with .deposit or .withdraw methods, we could do just as you suggest and bake a conditional transition to a Held state.

But we could also ask if the bank account is responsible for making that decision? In some architectures, we might say that this is burdening it with too much responsibility. I actually mulled this over with the following use case, which I decided to cut from the essay:

Consider a "suspicious deposit," or maybe a "suspicious transaction pattern," like a series of deposits and immediate withdrawals. PayPal is notorious for freezing accounts that violate some set of hidden rules.

Should the .deposit and .withdraw methods know about this and sometimes transition to "held?" One could argue this is not the account's responsibility, especially if some aspects of what makes a transaction suspicious involve things outside of the balance, like how long the customer has been with the institution.

Of course, there could be a line of code that calls a "Transaction Evaluator" thingummy from within the .deposit and .withdraw methods, or even a .validate method that always checks for this kind of thing after any action.

Or... Maybe this is a lot more like an MVC architecture, and the responsibility for checking the transaction falls to the controller, not the account model. So the controller calls .deposit or .withdraw, and the controller checks for suspicious transactions (or for negative balances), and the controller calls .placeHold on the account if necessary (and possibly on ALL accounts for the customer).

I'm not suggesting that this is superior to your suggestion, but it was something I thought about, and in some application architectures, I think what I just described is the way to do it. In others, what you described is the way to do it.

JM2C. Thanks for your comment.

Good points, I pretty much agree with everything you said. "NoDamnGoodForUs" is a little strong, more like "AlmostButThisOneUseCaseNeedsALittleMore" :)

Interestingly, that embedded device I made wound up being MVC without explicitly intending so -- the statecharts were the controllers. The only conditional transitions had to do with code reuse, where a single implementation lead to slightly different transitions depending on how it was configured.

Practical UML Statecharts in C/C++: Event-Driven Programming for Embedded Systems by Miro Samek.

State charts can be a powerful method for rapid prototyping of embedded systems if you use a minimalist code generation tool like Quantum Leaps QM.

It is a little difficult to get a hang of, but with familiarity it greatly increases the speed at which I can iterate on designs.

See: and

Note: I am not affiliated with Quantum Leaps, but I have found the tools to be very useful.

This book[1] seems to really help people (don't be put off by the title):

Practical UML Statecharts in C/C++: Event-Driven Programming for Embedded Systems

In particular, it discusses the main implementation strategies and why you'd want to use them. Also, the specific codebase described in the book is excellent. I use it all the time in implementing server software.


HN Books is an independent project and is not operated by Y Combinator or
~ [email protected]
;laksdfhjdhksalkfj more things ~ Privacy Policy ~
Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.