understanding the true meaning of any
language, particularly executable ones.
In a letter to me in 1984, Tony Hoare
said that the statecharts language “badly
needs a semantics.” He was right. Being
overly naïve at the time, I figured that
writing a paper that explained the basics
of the language’s operation and then
building a tool that executes statecharts
and generates code from them would
be enough. This approach took its cue
from programming language research,
where developers invent languages and
then simply build compilers for them.
In retrospect, I didn’t fully realize
in those early years how different statecharts are from previous specification
languages for real-time embedded systems. I knew, of course, that the language had to be executable, as well as
easily understandable, even by people
with no training in formal semantics. At
the same time, as a tool-building team,
we also had to demonstrate quickly to
our sponsors, the first being IAI, that our
efforts were economically viable. Due
to the high level of abstraction of statecharts, we had to make decisions regarding rather deep semantic problems that
apparently hadn’t been adequately considered in the literature, at least not in
the context of building a real-world tool
intended for large, complex systems.
Moreover, some of these issues were
then being investigated independently
by leading French researchers, including
Gérard Berry, Nicholas Halbwachs, and
Paul le Guernic, who coined the French
phrase L’approche synchrone—the synchronous approach—for this kind of
work. Thus, when designing Statemate
1
from 1984 to 1986, we did not do such a
good job of deciding on the semantics.
We had to address a number of dilemmas regarding central semantic issues. One had to do with whether a step
of the system should take zero time or
more; another had to do with whether
the effects of a step should be calculated
and applied in a fixpoint-like manner in
the same step or take effect only in the
following step. The two issues are independent. The first concerns whether or
not one adopts Berry’s pure synchrony
hypothesis, 1 whereby each step takes
zero time. Clearly, these questions have
many consequences in terms of how
the language operates, whether events
might interfere with chain reactions triggered by other events, how time itself is
modeled, and how time interleaves with
the system’s discrete event dynamics.
At the time, we used the terms Semantics A and B to refer to the two main
approaches we were considering. Both
were synchronous in the sense of Benveniste et al., 1 differing mainly in the
second issue—regarding when the effects of a step take place. In Semantics A
all events generated in the current step
serve as inputs to the next step, whereas
in Semantics B the system responds to
all events generated internally in the
current step until no further system response is possible. We called this chain
of reactions a “super-step.” The paper we
published in 1987 was based on Semantics B, 15 but we later adopted semantics
A for the Statemate tool itself. 10, 13 Thus,
Statemate statecharts constitute a synchronous language1 and in that respect
are similar to other, nonvisual languages in that family, including Esterel,
Lustre (in commercial guise, known as
Scade), and Signal.
We decided to implement Semantics A mainly because calculating the
total effects of a step and carrying them
out in the following step was easier to
implement; we were also convinced
that it was easier to understand for a
typical systems engineer. Another consideration was related to the semantic
level of compositionality; Semantics B
strengthens the distinction between the
system and its environment or between
two parts of the system. If at some point
in the development a system developer
wants to consider part of the system to
serve as an environment for the other
part, the behaviors under Semantics B
will be separated (as they should be), because chain reactions that go back and
forth between the two halves are no longer all contained in a single super-step.
A number of other researchers had
also begun looking into statechart semantics, often severely limiting the language (such as by completely dropping
orthogonality) so the semantics are easier to define. Some of this work was motivated by the fact that our implemented
semantics had not been published yet
(we published in 199612) and was not
known outside the Statemate circle.
This pre-object-oriented situation was
summarized by Michael von der Beeck
who tried to impose some order on the
multitude of semantics of statecharts
that were then being published. His re-
sulting paper22 claimed implicitly that
statecharts are not well defined due
to these many different semantics (it
listed approximately 20). Interestingly,
while 22 reported on the many variants
of the language with their semantics,
it did not report what should probably
have been considered the language’s
“official” semantics, the one we defined and adopted in 1986 when building Statemate13 but unfortunately also
the only semantics not published at the
time in the open public literature.
As to the semantic issues themselves, von der Beeck22 discussed only
the differences between variants of
pre-object-oriented statecharts, but
they are far less important than the differences between the non-object-ori-ented and the object-oriented versions
of the language. The main semantic
difference between Statemate and
Rhapsody semantics is in synchron-icity. In Statemate, the version of the
statecharts language is based on functional decomposition and is a synchronous language, whereas the object-oriented-based Rhapsody version of
statecharts is asynchronous. There are
other substantial differences in modes
of communication between objects;
there are also issues arising from the
presence of dynamic objects and their
creation and destruction, inheritance,
composition, and multithreading. The
semantics of object-oriented statecharts was described in my 2004 paper
with Hillel Kugler8 (analogous to 12) describing the differences between these
two versions of the language.
Meanwhile, the Unified Modeling
Language, or UML, which was standardized by the Object Management
Group in 1997, featured many graphical languages, some of which are still
not endowed with satisfactorily rigorous semantics. The heart of UML—
its driving behavioral kernel—is the
object-oriented version of statecharts.
In the mid-1990s Eran Gery and I took
part in helping the UML design team
define the intended meaning of statecharts, resulting in UML statecharts
being similar to those in 11 that we implemented in Rhapsody. For a manifesto about the subtle issues involved
in defining the semantics of languages for reactive systems, see 7, with its
whimsical subtitle “What’s the Semantics of ‘Semantics’?”