Communications - March 2009

Statemate also enabled one to specify the actual structure of the system itself, using module-charts that specify the components in the implementation of the system and their connections. In this way, the tool supported a three-way model-based development framework for systems consisting of structure, functionality, and behavior. The user could draw the statecharts and the model’s other artifacts, link them together rigorously, check and analyze them, produce documents from them, and manage their configurations and versions. Most important, Statemate could fully execute them and generate from them, automatically, executable code in, say, Ada and C and later also in appropriate hardware description languages.

Even then, more than 20 years ago, Statemate could link the model to a GUI mockup of the system under development (or even to real hardware). Executability of the model could be done directly or by using the generated code and carried out in many ways with increasing sophistication. Verification wasn’t in vogue in the 1980s, so analysis of the models was limited to various kinds of testing offered by Statemate in abundance. One could execute the model interactively (with the user playing the role of the system’s environment), in batch mode (reading in external events from files) or in programmed mode. One could use breakpoints and random events to help set up and control a complex execution from which you could gather the results of interest. In principle, you could thus set up Statemate to “fly the aircraft” for you under programmed sets of circumstances, then come in the following day and find out what had happened. These capabilities, allowing us to “see” the model in operation, either via a GUI or following the statecharts as they were animated on the fly, were extremely useful to Statemate users. The tool was an eye-opener for software and systems engineers used to writing and debugging code in the usual way and was particularly beneficial for real-time and embedded systems.

Statemate is considered by some to be the first real-world tool to carry out true model executability and full code generation. The underlying ideas were the first serious proposal for model-driven system development. They might have been somewhat before their time

but were deeply significant in bringing about the change in attitude that permeates modern-day software engineering, as exemplified by such efforts as the Unified Modeling Language. A decade after Statemate, we built the object-oriented Rhapsody tool at I-Logix (discussed later).

Woes of Publication

I wrote the first version of a paper describing statecharts in late 1983. The

16

process of trying to get it published was long and tedious but interesting in its own right. The details appear in the full version of the present article, ⁶ but I can say that the paper was rejected by several leading journals, including Communications and IEEE Computer. My files contain an interesting collection of referee comments and editor rejection letters, one of which asserted: “The basic problem […] is that […] the paper does not make a specific contribution in any area.” It was only in July 1987 that the paper was finally published, in Science of Computer Programming. ¹⁶ The full version of the present article⁶ also contains information (and anecdotes) about other publications on statecharts, including a paper I wrote with Pnueli defining reactive systems, ¹⁷ a Communications article on visual formalisms and higraphs, ¹⁴an eight-author paper on Statemate, ¹³ the definitive paper on the Statemate semantics of statecharts, ¹³and a Statemate book with Politi. ¹⁰

object-oriented statecharts In the early 1990s, Eran Gery from I-Logix became interested in the work of James Rumbaugh and Grady Booch on the use of statecharts in an object-oriented framework. Gery did some gentle prodding to get me interested, with the ultimate result being a 1997 paper¹¹ in which we defined object-oriented statecharts and worked out the way we felt they should be linked up with objects and executed. In particular, we proposed two modes of communication between objects: direct synchronous invocation of methods and asynchronous queued events. The paper considered other issues, too, including creation and destruction of objects and multithreaded execution. The main structuring mechanism involved classes and objects, each of which could be associated with a statechart.

We we also outlined a new tool for supporting all this, and I-Logix promptly built it under the name Rhapsody.

11

One important difference between the function-oriented Statemate and the object-oriented Rhapsody is that the semantics of statecharts in Statemate is synchronous and in Rhapsody is (by and large) asynchronous. Another subtle but significant difference is reflected in the fact that Statemate was set up to execute statecharts directly in an interpreter mode separate from the code generator. In contrast, the model execution in Rhapsody is carried out by running the code generated from the model. A third difference is our decision to make the action language of Rhapsody a subset of the target programming language; for example, the events, conditions, and actions specified along state transitions are fragments of, say, C++ or Java. In any event, the statechart language may be considered a level higher than classical programming languages in that the code generated from it is in, say, C++, Java, or C; we thus might say that statecharts are high above C level.

Several software vendors have since developed tools based on statecharts or its many variants, including Ros-eRT (which grew out of ObjecTime), StateRover, and Stateflow (the statechart tool embedded in Matlab).

The implementation and tool-building issue can also be viewed in a broader perspective. In the early 1980s, no system-development tool based on graphical languages was able to execute models or generate full running code. Such CASE tools essentially consisted of graphic editors, document generators, and configuration managers and were thus like programming environments without a compiler. In contrast, I have always felt that a tool for developing complex systems must have the ability to not only describe behavior but also to analyze and execute it in full. This philosophy underlies the notion of a visual formalism, which must come endowed with sufficiently well-defined semantics so as to enable tools to be built around it that can carry out dynamic analysis, full model execution, and the automatic generation of running code.