Buy it from Amazon.com
Buy it from Amazon.co.uk

Other Reviews

Prof. Harel is one of those rare people in our times who deserves to be called a polymath (a master in many fields of learning, if your Greek is a bit rusty). Early in his career, he did pioneering research on basic computer science, such as on what can be computed, on database query languages, and on the theory of automata. More recently he invented statecharts (in 1983, aka state transition diagrams) and helped to design the commercial tools Statemate (1984, strikingly automating the use of statecharts, and showing that formal properties like reachability had a practical use in industry; the tool can generate code directly from the diagrams) and Rhapsody (1997, a model-driven software development environment). He contributed centrally to the design of UML, which incorporates statecharts and sequence charts to define system behaviour. He's well-known for his wonderful book Algorithmics: The Spirit of Computing.

With this background, it isn't surprising that Harel, ably assisted by his graduate student Rami Marelly, has turned his attention to scenarios, and in particular to making them both precise and executable. Scenarios can be represented in a limited way (without nuances such as what is mandatory, and hence, which scenarios are actually possible!) as UML sequence diagrams, a notation which shows a vertical timeline for each role -- human or machine -- of interest, with boxes on the timelines to indicate when each role is active, and connecting lines to show communication between roles (including software objects). The ITU Message Sequence Chart (MSC) is similarly widely adopted, but limited in its expressive power.

Harel has therefore extended the idea of defining behaviour by inventing (1998, with Werner Damm) the Live Sequence Chart (LSC), essentially an MSC with a richer visual language to express constraints on what is allowed to happen. As Harel is a practical engineer who likes to show that his ideas work, the book includes a CD with working software, the "Play Engine" -- fun, but described as "not a commercial product" -- and there's a website (http://www.wisdom.weizmann.ac.il/~playbook) where you can find out more.

In Harel's view, conventional development rather weakly connects use cases to requirements, and similarly weakly connects requirements to tests and other forms of verification. Code generation or synthesis is mainly by hand. He suggests that a better approach is for system developers to "play in" scenarios into a system's GUI (or object model diagram if there is no GUI), "clicking buttons, rotating knobs and sending messages (calling functions) to hidden objects, in an intuitive drag & drop manner." The developer using the Play Engine plays in both the incoming events (e.g. clicks) and "the desired reactions of the system and the conditions that may or must hold." The Play Engine performs the magic of simultaneously showing the current status on the GUI and constructs the corresponding LSCs to record the played-in scenario.

The developer can then at once "play out" the recorded scenario to test that the behaviour is as intended. The Play Engine lets the developer play at using the system as if the product under development already existed (Harel does use the horrible words user and end-user to mean developer and product operator). The GUI does what it should, and the system under development behaves as an executable model.

Harel accordingly modifies the system development life-cycle as illustrated below.

So far so simple. The rest of the book illustrates these concepts with worked examples (in colour), gradually introducing all the complexities that are needed to give LSCs precise semantics rich enough to capture scenarios, variations, exceptions, and indeed "anti-scenarios", anything that is required NOT to happen. (These aren't the same thing as threats or misuse cases, though those can generate specific anti-scenarios, namely ones with hostile intent. Many anti-scenarios are simply errors, like lift doors opening when they shouldn't.)

The LSC notation is inevitably more difficult than familiar MSCs or sequence diagrams, as it has more work to do. It is quite code-like, as indeed it has to be as precise as code. Harel is plainly sensitive to the complaint that LSCs would therefore be just as tricky to debug as code, and tools such as the Play Engine are clearly part of his answer: the notation is quite formal with an exact meaning, but that meaning can be translated into terms that everyone can understand and validate, namely a system's behaviour as seen via its GUI. Thus there are in fact three levels of formality: the pages of logical definition and proof at the ends of the chapters in the body of the book; the graphical LSCs whose meaning is thus formally defined; and the scenarios that correspond to those diagrams. This is a satisfying answer, but for the fact that the Play Engine is still largely a toy. Does it only apply to software? Not necessarily; any system that can be modelled as communicating objects (The Accounts Department, Purchasing, ...) could be so treated, so in principle it applies to systems of all types, whether software, hardware or peopleware.

Will LSCs be as successful as statecharts? Will Play-in and Play-out be part of the development methods of the future? Maybe they will; but in any case, making development less hit-and-miss, and more closely tied to requirements and scenarios, is certain to remain a challenge to researchers and industry alike.

Come, Let's Play is a book that can be read at different levels by different audiences: few other than researchers will check the formal proofs that are written out in full; students may learn the semantics of the LSC, and do projects with GUIs and code generation; while curious practitioners will probably skim the book and perhaps pass an evening playing with the demonstrations.

© Ian Alexander 2003

You may also like: