Statecharts: A Visual Formalism For Complex Systems (1987) [pdf]

Harel's Statecharts are used a lot in automotive with Stateflow, the state machine tool of Mathworks MAtlab/Simulink.

It is. If you're a front-end web dev, check out SproutCore. It has a built in statecharts library acting as the Controller in MVC apps.

The paper has some good insights into how statecharts can obscure or confuse solutions, but some of the issues are avoided by experience or practice of using statecharts. Combining orthogonal states and history, for example, is rightly criticised in the paper and is the equivalent of a 'code smell' for me personally, largely because it becomes difficult to reason about the behaviour of the system being modelled. The two main benefits of state charts are the clustering notation and separation of concerns by linking statecharts with directed events (rather than using orthogonality). History is sometimes useful in specific circumstances, though those often arise from how you structured the statechart rather than a system design issue.

In short I'd say to try not using deep history or orthogonality and see how you get on. Use them minimally and rarely in combination. I've found statecharts to be fantastic at clarifying my understanding of systems and their design, but like any tool, they take practice.

One of my favorite tools! I've implemented many (too many) protocols with HSMs. I've also implemented lots with traditional FSMs. I've met people like me who have done both. Most would choose HSMs for most applications. If you're into SM compilers then they might not be that interesting (I'm not -- I like to see the logic in code that _I_ write).

As an exercise in seeing the advantages, take a look at a network protocol RFCs like for TCP, BGP or SIP, and redraw the state diagrams there as statecharts. I've found that HSMs help in the beginning when I'm understanding what I'm doing (how about finding omitted states!); in the middle as I'm implementing; and in the end, when I'm maintaining. In my experience they definitely commend themselves vis-a-vis FSMs in commando ops (i.e. parachute a smart engineer into hostile unknown territory and have them fix a broken state machine under heavy fire).

Of course, much depends on your HSM implementation itself. This book (http://www.state-machine.com/psicc/) is a good resource, though the last time I looked the code is sorta old-timey C++. There are definitely more contemporary/template-ly ways to do it.

This paper was superseded, in a sense, by two of Dr. Harel's later papers:

The STATEMATE Semantics of Statecharts (1996)[1]

The Rhapsody Semantics of Statecharts (or, On the Executable Core of the UML)[2]

There is also a full-length (out of print) book on the STATEMATE system, which shows how Statecharts can be used used in combination with two other chart types (Activity and Module charts):

Modeling Reactive Systems with Statecharts: The STATEMATE Approach (1998)[3]

With permission of the publisher, the entire book can be downloaded for free from the professor's website[4].

The 1987 paper is worthwhile, but it can be skipped in favor of the more recent papers and the reader won't miss anything essential.

Dr. Harel has also published a detailed history of the development of Statecharts (i.e. the formalism itself):

Statecharts in the Making: A Personal Account (2007)[5]

[1] http://www.wisdom.weizmann.ac.il/~harel/SCANNED.PAPERS/Seman...

[2] http://www.wisdom.weizmann.ac.il/~harel/papers/RhapsodySeman...

[3] http://www.wisdom.weizmann.ac.il/~harel/reactive_systems.htm...

[4] http://www.wisdom.weizmann.ac.il/~harel/STM.Book

[5] http://www.wisdom.weizmann.ac.il/~harel/papers/Statecharts.H...