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, 6 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. 16 The
full version of the present article6 also
contains information (and anecdotes)
about other publications on statecharts,
including a paper I wrote with Pnueli defining reactive systems, 17 a
Communications article on visual formalisms and
higraphs, 14 an eight-author paper on
Statemate, 13 the definitive paper on the
Statemate semantics of statecharts, 13
and a Statemate book with Politi. 10
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 paper11 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.
on semantics
It is worth dwelling further on the issue
of semantics, which is a prerequisite for