doi:10.1145/ 1467247.

1 46 72 74

How avionics work led to a graphical language

for reactive systems where the diagrams
themselves define the system’s behavior.
by David Harel

Statecharts
in the Making:
A Personal
Account
Writing a historical paper about something you
yourself are heavily involved in is clearly difficult;
the result is bound to be personal and idiosyncratic
and might well sound presumptuous. I thus viewed
an invitation to write about statecharts for the third
History of Programming Languages conference in
2007 as an opportunity to put the language in a
broader perspective.6 The present ar- odologist responsible for evaluating
ticle is a greatly abridged version of and recommending software engineer-
the resulting conference paper. The ing methods and tools at IAI, described
implicit claim is that the emergence of some problems IAI avionics engineers
the language brought to the forefront a were having. This was part of the massive
number of ideas that today are central effort then under way to build a fighter
to software and systems engineering, aircraft, the Lavi (no connection with
including the general notions of visual Jonah’s surname). Following that meet-
formalisms, reactive systems, model- ing, I began consulting at IAI on a one-
based development, model executabil- day-a-week basis, and for several months
ity, and full code generation. Thursday became my IAI day.
In 1979 I published a paper on a The first few weeks were devoted to
tree-like language based on the idea of trying to understand the general issues
alternation called “And/Or Programs,”18 from Lavi. Then it was time to be exposed
prompting Jonah Lavi of Israel Aircraft to the details of the project and its specif-
Industries (IAI) to contact me. We met in ic difficulties, since I hadn’t yet met the
late 1982, at which time I’d been on the project’s engineers. For several weeks,
faculty of the Weizmann Institute of Sci- I spent my Thursdays with Lavi’s assis-
ence for two years. Lavi, who was a meth- tant, Yitzhak Shai, and a select group of

ma r c h 2 0 0 9 | vo l. 52 | n o. 3 | c om m u n ic at ion s of t he acm 67
contributed articles

experts from the Lavi avionics team, no- and internal events. this button is pressed?” In response, a
tably Akiva Kaspi and Yigal Livne. The Lavi avionics team consisted of weighty two-volume document would
An avionics system is a wonder- extremely talented people, including be brought out and volume A would be
ful example of what my colleague at those involved in radar, flight control, opened to page 389, clause 6.11.6.10,
Weizmann Amir Pnueli and I later electronic warfare, hardware, com- which says that if you press that button
identified as a reactive system.17 The munication, and software. The radar such then such a thing would occur. At
main behavior that dominates such people could provide the precise algo- which point (having by then learned
a system is its reactivity, that is, its rithm used to measure the distance to some of the system’s buzzwords) I would
event-driven, control-driven, event- a target. The flight-control people could say: “Yes, but is that true even when an
response nature. The behavior is of- talk about synchronizing the controls in infrared missile is locked on a ground
ten highly parallel and includes strict the cockpit with the flaps on the wings. target?” To which someone might say,
time constraints and possibly stochas- The communications people could talk “Oh no, in volume B, page 895, clause
tic and continuous behavior. A typical about formatting information traveling 19.12.3.7, it says that in such a case
reactive system is not predominantly through the MuxBus communication this other thing happens.” These Q&A
data-intensive or algorithmic in na- line. Each had his own idiosyncratic sessions would continue, and when it
ture. Behavior is the crucial problem ways of thinking about and explaining would get to the fifth or sixth question
in its development—the need to pro- the system, as well as his own diagrams the engineers were no longer sure of
vide a clear yet precise description of and emphases. the answer and would have to call the
what the system does or should do I would ask seemingly simple ques- customer (the Air Force people) for a re-
over time in response to both external tions, such as: “What happens when sponse. By the time we got to the eighth
or ninth question even the customer
didn’t have an answer.
Obviously, someone would eventual-
ly have to decide what happens when you
press a certain button under a certain
set of circumstances. However, this per-
son might turn out to be a low-level pro-
grammer assigned to write some remote
part of the code, inadvertently making
decisions that influenced crucial behav-
ior on a much higher level. Coming, as
I did, from a clean-slate background in
terms of avionics (a polite way of saying
I knew nothing about the subject), this
was shocking. It seemed extraordinary
that such a talented and professional
team knew in detail the algorithm used
to measure the distance to a target but
not many of the far more basic behavior-
al facts involving the system’s response
to a simple event.
To illustrate, consider the following
three occurrences of a tiny piece of be-
havior buried in three totally different
locations in a large specification of a
chemical manufacturing plant:
“If the system sends a signal hot then
send a message to the operator”;
“If the system sends a signal hot with
T >60° then send a message to the op-
erator”; and
“When the temperature is maximum,
the system should display a message on
the screen, unless no operator is on the
site except when T <60°.”
Despite my formal education in
Figure 1: Page from my early IAI notes (1983). Statechart constructs include hyper-edges, mathematical logic, I’ve never been
nested orthogonality (a kind of concurrency), and transitions that reset a collection of able to understand the third item. Sar-
states (chart on right). Note the use of Cartesian products of sets of states (set-theoretic
formulation at the top) to capture the meaning of the orthogonality and the straightforward casm aside, the real problem is that all
algebraic notation for transitions between state vectors (lower right). three were obviously written by three

68 communicatio ns o f th e ac m | m a r c h 2009 | vo l . 5 2 | no. 3

 contributed articles

different people for three different rea- vides no means for modularity, hiding
sons. It is almost certain that the code of information, clustering, and separa-
for this critical aspect of the chemical tion of concerns and would not work for
plant would be problematic in the best highly complex behavior. I was quickly
case and catastrophic in the worst. The
specification documents the Lavi avi- How should convinced of the need for a structured
and hierarchical extension of the con-
onics group had produced at IAI were
no better. If anything, they were longer
an engineering ventional state machine formalism.
Following my initial attempt to use
and more complex. Some subcontrac- team specify temporal-logic-like notation, I resorted
tors even refused to work from them,
claiming they were incomprehensible,
the behavior to writing down the state-based behav-
ior textually, in a kind of structured
inconsistent, and incomplete. of such a complex state-based dialect of “state protocols”
This confusion prompted the ques-
tion: How should an engineering team
reactive system made up on the fly (see the figures in 6).
The dialect was hierarchical; within a
specify the behavior of such a complex in an intuitively state there could be other states, and if
reactive system in an intuitively clear yet
mathematically rigorous fashion? This clear yet you were in this state and the event oc-
curred, you would enter the other state,
was what I aimed to try to answer. mathematically and so on. As this went on, things would

Statecharts Emerging rigorous fashion? get increasingly complicated. The avi-

onics engineers would bring up more
My initial goal was not to invent a lan-
guage but to try to recommend, from
This was what of the system’s behavior, and I would
respond by extending the state-based
the toolset of the software and systems I aimed to try structured description, often having to
engineer, appropriate means for saying
what the avionics engineers seemed to
to answer. enrich the syntax in real time.
When the multitude of emerging be-
already have in mind. It turned out they havioral details caused things to be even
really did understand the system and more complicated, I would doodle on
could answer many questions about be- the side of the page to explain (visually)
havior but often hadn’t thought through what was meant. I recall the first time I
things properly because the informa- used visual encapsulation to illustrate
tion wasn’t well-organized in their docu- for the engineers the state hierarchy and
ments (or heads). I had to spend a lot of an arrow emanating from the higher
the time getting them to talk; I kept ask- level to show a compound “leave-any-
ing questions, prodding them to state state” transition. I also recall the first
clearly how the aircraft behaves under time I used side-by-side adjacency with a
certain sets of circumstances. We would dashed separator line to depict orthogo-
then brainstorm, trying to make sense nal (concurrent) state components (see
of the information that had piled up. Figure 1).
It was clear from the start that the I drew these informal diagrams in
basic idea of states/modes was funda- order to explain what the nongraphical
mental to their way of thinking. (This text-based state protocols meant. The
insight was consistent with the work of text was still the real thing, however, and
David Parnas on the avionics of the A-7 the diagrams were merely an aid. But
jet fighter.19) The IAI avionics engineers after a while it dawned on me that ev-
would repeatedly say things like, “When eryone around the table seemed to un-
the aircraft is in air-ground mode and derstand these back-of-the-napkin dia-
you press this button, it goes into air-air grams much better, relating to them far
mode, but only if the radar is not locked more naturally. The pictures simply did
on a ground target.” This is familiar to a much better job of setting down on pa-
anyone in computer science; what we per the system’s behavior, as understood
have here is really the likes of a finite- by the avionics engineers, and we found
state automaton with its state transi- ourselves discussing the diagrams and
tion mechanism. Nevertheless, having arguing about the avionics over them,
one big state machine describing what not over the state protocols. Still, the
is going on would be fruitless, not only mathematician in me found this diffi-
because of the exponentially growing cult to accept; I told myself that doodled
number of states but also because sim- diagrams could not really be better than
ply listing all possible states and the a real mathematical-looking artifact. So
transitions leading from one to the other it really took a leap of my own faith to be
is unstructured and nonintuitive; it pro- able to think: “Hmmm…couldn’t the

ma r c h 2 0 0 9 | vo l. 52 | n o. 3 | c om m u n ic at ion s of t he acm 69
contributed articles

pictures be turned into the real thing, dard source-target; they can be full hy-
replacing, rather than supplementing, peredges, since both sources and targets
the textual structured-programming- of transitions can be sets of states. At any
like formalism?” So I gradually stopped given point in time a statechart is in a
using the text or used it only to capture
supplementary information inside the The pilot stood combination (vector) of states, the length
of which is not fixed, since entering and
states or along transitions, and the dia-
grams became the actual specification
there studying exiting orthogonal components on vari-
ous levels of the hierarchy changes the
we were constructing. the blackboard size of the state vector dynamically (see
This process of turning the diagrams
into the specification language had to be
for a couple of the nongraphical portions of the figure).
Default states generalize start states, and
done in a disciplined way, making sure minutes, then said, the small arrows leading to them can be
the emerging pictures were not just pic-
tures. You couldn’t just throw in features
“I think you have level-crossing and hyperedge in nature.
In addition, statecharts also have special
because they looked good and the avion- a mistake down history connectors, conditions, output
ics team seemed to understand them.
Unless the exact mathematical meaning here; this arrow events, selection connectors, and more.
The fact that the technical part of the
of an intended feature was given—in any should go over here statechart story started out with And/Or
allowed context and under any allowed
set of circumstances—it simply couldn’t and not over there.” Programs18 is interesting and relevant.
Encapsulated substates represent OR
be considered. This was how the basics
of the language emerged. I chose to use
He was right. (actually XOR, exclusive or), and or-
thogonality is AND. Thus, a minimalist
the term “statecharts” for the resulting might view statecharts as a state-based
creatures, which at the time was the only language with an underlying structur-
unused combination of “state” or “flow” ing mechanism of classical alternation.
with “chart” or “diagram” (see Figure 2). As for the graphic renditions, the two
novel visual constructs in statecharts—
Comments on the Language blob encapsulation and partitioning—
Besides a host of secondary constructs, are both topological in nature and
the two main ideas in statecharts— therefore worthy companions to edges
hierarchy and orthogonality—can be in graphs. Indeed, when designing a
intermixed on all levels (see the figure). graphical language, topology should
The language can be viewed as begin- be used whenever possible, since it is
ning with classical finite-state machines a more basic branch of mathematics
and their diagrams and extending them than geometry. Being inside something
through a semantically meaningful hi- is more fundamental and robust than
erarchical substating mechanism and being smaller or larger or than being a
through a notion of orthogonal simul- rectangle or a circle. Being connected
taneity. Both extensions are reflected in to something is more basic than being
the graphics—hierarchy by encapsula- green or yellow or being drawn with a
tion of the blobs depicting states and thick line or a thin line. The human vi-
orthogonality by partitioning a blob us- sual system notices and comprehends
ing dashed separator lines. Orthogonal such things immediately.
components of the state space coop- Still, statecharts are not exclu-
erate in several ways, including direct sively visual/diagrammatic. Transi-
sensing of the state status in another tions can be labeled not only with the
component or through actions. The events that cause the transitions but
mechanism within a statechart thus has also with the conditions that guard
a broadcasting flavor whereby any part against taking them and the actions
of the (same) statechart can sense what (output events) that are to be car-
is happening in any other part. ried out when they are taken. More-
As a result of the new constructs for over, statecharts borrow from both
hierarchy and orthogonality and their the Moore and the Mealy variants of
graphical renditions, transitions be- state machines, allowing actions on
come far more elaborate and rich than transitions between states, as well as
in conventional state machines. They on entrances to or exits from states.
are still labeled with their triggering Statecharts also allow “throughput”
events and conditions but can now start conditions attached to a state and are
or stop at any level of the hierarchy, cross to hold through the entire time the
levels, and in general be richer than stan- system is in that state.

70 communicatio ns o f th e acm | m a r c h 2009 | vo l . 5 2 | no. 3

 contributed articles

Figure 2: Explaining statecharts (1984); note the temporal logic bottom right.

Speaking in the strict mathematical and arrange the behavior in portions to be able to sense properties of a part
sense of power of expression, hierarchy that are conceptually and intuitively of the specification in another without
and orthogonality are but helpful ab- separate, independent, and orthogo- worrying about implementation details.
breviations and can be eliminated; the nal. I emphasize the word “conceptu- I definitely do not recommend having a
hierarchy can be flattened, writing ev- ally” because what counts is whatever single statechart for an entire system.
erything out explicitly on a low level, and is in the mind of the person doing the Rather, as I discuss later, there will al-
orthogonality can be removed by taking specification. most always be a decomposition of the
the Cartesian product of the compo- This motivation has many ramifica- system into functions, tasks, objects,
nents (as in the top of the figure). Thus, tions. I chose the broadcast communi- and the like, each endowed with its own
these features do not add raw expres- cation mechanism of statecharts not behavior (described by, for example, a
sive power, and their value is reflected because it is preferred for actual com- statechart). In this way, the concurrency
mainly in additional naturalness and munication between a system’s compo- occurs on a higher level.
convenience. However, they also (in gen- nents. It is merely one way to coordinate I return now to the two adjectives dis-
eral) provide great savings in size; for ex- the orthogonal components of the stat- cussed earlier—“clear” and “precise”—
ample, orthogonality can yield an expo- echart, between its “chunks” of state- behind the choice of the term “visual
nential improvement in succinctness in space, if you will; these will often not formalism.”14,16 Concerning clarity, the
both upper- and lower-bound senses.3 be the components—physical or soft- fact that a picture is worth a thousand
Incidentally, orthogonal state-com- ware—of the system itself. Broadcasting words demands special caution. Not ev-
ponents in statecharts do not necessari- is a way to sense in one part of the state erything is beneficially depicted visually,
ly represent concurrent or parallel com- space what is going on in another part but the basic topology-inspired graphics
ponents of the system being specified. and does not necessarily reflect actual of statecharts seemed from the start to
They need not represent different parts communication between tangible as- jibe well with the IAI avionics engineers;
of the system at all but can be intro- pects of the actual system. On certain lev- they quickly grasped the hierarchy and
duced to help structure its state space els of abstraction one often really wants orthogonality, high- and low-level tran-

ma r c h 2 0 0 9 | vo l. 52 | n o. 3 | c om m u n ic at ion s of t he acm 71
contributed articles

the right track (see Figure 3). Very en-

couraging.
So much for clarity. As for precision
and formality, full executability was al-
ways central to the development of the
language. I found it difficult to imagine
the usefulness of a method that merely
makes it possible to say things about
behavior, give snippets of the dynam-
ics or observations about what happens
or what could happen, or provide some
partially connected pieces of behavior.
The whole idea was that if one builds
a statechart-based specification every-
thing must be rigorous enough to be
run (executed) just like software written
in a programming language. Executabil-
ity was a basic, not-to-be-compromised,
underlying concern during the process
of designing the language. It might
sound strange to a reader 26 years later,
but in 1983 system-development tools
did not execute models at all. Thus,
turning doodles like those in the figure
into a real language could be done only
with great care.

Building a Tool
Once the basics of the language were
established, it seemed natural to want
a tool that could be used not only to
prepare statecharts but also to execute
them. So in April 1984, three colleagues
(the brothers Ido and Hagi Lachover and
Amir Pnueli) and I founded a company,
Ad Cad, Ltd., later (1987) reorganizing it
as I-Logix, Inc., with Ad Cad as its R&D
Figure 3: Page from the IAI notes (1983, events in Hebrew) showing a relatively “clean” draft branch. By 1986, we had built a tool for
of the top levels of behavior for the main flight modes of the Lavi avionics, including statecharts called Statemate.
A/A (air-air), A/G (air-ground), NAV (automatic navigation), and ON GRD (on ground).
Note early use of a history connector in the A/G mode. In extensive discussions with the
two most senior technical people as-
sitions, default entries, and more. asking, “What’s that?” One of the engi- sociated with the company, Rivi Sher-
Interestingly, the same quick compre- neers said, “That’s the behavior of the man and Michal Politi, along with
hension applied to nonexperts outside so-and-so part of the system, and, by the Amir Pnueli, we were able to figure out
the avionics group. I recall an anecdote way, these rounded rectangles are states, during the Ad Cad period how to em-
from late 1983 in which in the midst of and the arrows are transitions between bed statecharts into a broader frame-
one session the blackboard showed a states.” The pilot studied the blackboard work that was capable of capturing
complicated statechart specifying the for a couple of minutes, then said, “I the structure and functionality of a
behavior of some intricate portion of think you have a mistake down here; this large complex system. To this end, we
the Lavi’s avionics. A knock on the door arrow should go over here and not over proposed a diagrammatic language
brought in an Air Force pilot from the there.” He was right. to structure a model that we called
“customer” team who knew a lot about For me, this little event indicated that activity-charts, an enriched kind of hi-
the aircraft being developed and its de- we might be doing something right, that erarchical data-flow diagram whereby
sired behavior but had never seen a state maybe what I was proposing was a good arrows represent the possible flow
machine or a state diagram before, not and useful way of specifying reactive of information between the incident
to mention a statechart. I remember behavior. If an outsider could come in, functions (activities). Each activity
him staring at this intricate diagram (the just like that, and grasp something that can be associated with a controlling
statechart) on the blackboard, with its complicated without being exposed to statechart (or code) that would also be
complicated mess of blobs inside other the technical details of the language or responsible for interfunction commu-
blobs, arrows splitting and merging, and the approach, then maybe we were on nication and cooperation.

72 comm unicatio ns o f the acm | m a r c h 2009 | vo l . 5 2 | no. 3

 contributed articles

Statemate also enabled one to spec- but were deeply significant in bring- We also outlined a new tool for sup-
ify the actual structure of the system ing about the change in attitude that porting all this, and I-Logix promptly
itself, using module-charts that specify permeates modern-day software engi- built it under the name Rhapsody.11
the components in the implementation neering, as exemplified by such efforts One important difference between the
of the system and their connections. In as the Unified Modeling Language. A function-oriented Statemate and the
this way, the tool supported a three-way decade after Statemate, we built the ob- object-oriented Rhapsody is that the
model-based development framework ject-oriented Rhapsody tool at I-Logix semantics of statecharts in Statemate is
for systems consisting of structure, (discussed later). synchronous and in Rhapsody is (by and
functionality, and behavior. The user large) asynchronous. Another subtle but
could draw the statecharts and the mod- Woes of Publication significant difference is reflected in the
el’s other artifacts, link them together I wrote the first version of a paper de- fact that Statemate was set up to execute
rigorously, check and analyze them, pro- scribing statecharts in late 1983.16 The statecharts directly in an interpreter
duce documents from them, and man- process of trying to get it published mode separate from the code genera-
age their configurations and versions. was long and tedious but interesting in tor. In contrast, the model execution in
Most important, Statemate could fully its own right. The details appear in the Rhapsody is carried out by running the
execute them and generate from them, full version of the present article,6 but code generated from the model. A third
automatically, executable code in, say, I can say that the paper was rejected by difference is our decision to make the
Ada and C and later also in appropriate several leading journals, including Com- action language of Rhapsody a subset
hardware description languages. munications and IEEE Computer. My of the target programming language;
Even then, more than 20 years ago, files contain an interesting collection for example, the events, conditions, and
Statemate could link the model to a of referee comments and editor rejec- actions specified along state transitions
GUI mockup of the system under de- tion letters, one of which asserted: “The are fragments of, say, C++ or Java. In any
velopment (or even to real hardware). basic problem […] is that […] the paper event, the statechart language may be
Executability of the model could be does not make a specific contribution considered a level higher than clas-
done directly or by using the generated in any area.” It was only in July 1987 sical programming languages in that
code and carried out in many ways with that the paper was finally published, in the code generated from it is in, say,
increasing sophistication. Verification Science of Computer Programming.16 The C++, Java, or C; we thus might say that
wasn’t in vogue in the 1980s, so analy- full version of the present article6 also statecharts are high above C level.
sis of the models was limited to various contains information (and anecdotes) Several software vendors have since
kinds of testing offered by Statemate in about other publications on statecharts, developed tools based on statecharts
abundance. One could execute the mod- including a paper I wrote with Pnueli de- or its many variants, including RoseRT
el interactively (with the user playing the fining reactive systems,17 a Communica- (which grew out of ObjecTime),
role of the system’s environment), in tions article on visual formalisms and StateRover, and Stateflow (the statechart
batch mode (reading in external events higraphs,14 an eight-author paper on tool embedded in Matlab).
from files) or in programmed mode. Statemate,13 the definitive paper on the The implementation and tool-
One could use breakpoints and random Statemate semantics of statecharts,13 building issue can also be viewed in a
events to help set up and control a com- and a Statemate book with Politi.10 broader perspective. In the early 1980s,
plex execution from which you could no system-development tool based on
gather the results of interest. In prin- Object-Oriented Statecharts graphical languages was able to execute
ciple, you could thus set up Statemate In the early 1990s, Eran Gery from models or generate full running code.
to “fly the aircraft” for you under pro- I-Logix became interested in the work of Such CASE tools essentially consisted of
grammed sets of circumstances, then James Rumbaugh and Grady Booch on graphic editors, document generators,
come in the following day and find out the use of statecharts in an object-ori- and configuration managers and were
what had happened. These capabilities, ented framework. Gery did some gentle thus like programming environments
allowing us to “see” the model in opera- prodding to get me interested, with the without a compiler. In contrast, I have
tion, either via a GUI or following the ultimate result being a 1997 paper11 in always felt that a tool for developing
statecharts as they were animated on the which we defined object-oriented state- complex systems must have the ability
fly, were extremely useful to Statemate charts and worked out the way we felt to not only describe behavior but also to
users. The tool was an eye-opener for they should be linked up with objects analyze and execute it in full. This phi-
software and systems engineers used to and executed. In particular, we pro- losophy underlies the notion of a visual
writing and debugging code in the usual posed two modes of communication formalism, which must come endowed
way and was particularly beneficial for between objects: direct synchronous in- with sufficiently well-defined semantics
real-time and embedded systems. vocation of methods and asynchronous so as to enable tools to be built around
Statemate is considered by some to queued events. The paper considered it that can carry out dynamic analysis,
be the first real-world tool to carry out other issues, too, including creation full model execution, and the automatic
true model executability and full code and destruction of objects and multi- generation of running code.
generation. The underlying ideas were threaded execution. The main structur-
the first serious proposal for model- ing mechanism involved classes and ob- On Semantics
driven system development. They might jects, each of which could be associated It is worth dwelling further on the issue
have been somewhat before their time with a statechart. of semantics, which is a prerequisite for

ma r c h 2 0 0 9 | vo l. 52 | n o. 3 | c om m u n ic at ion s of t he acm 73
contributed articles

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

74 comm unicatio ns o f the ac m | m a r c h 2009 | vo l . 5 2 | no. 3

 contributed articles

Biology, Hybrid Systems, Conclusion References

Verification, Scenarios If asked about the lessons to be learned 1. Benveniste, A., Caspi, P., Edwards, S.A., Halbwachs,
N., Le Guernic, P., and de Simone, R. The synchronous
Statecharts today are widely used in from the statecharts story, I would defi- languages 12 years later. Proceedings of the IEEE 91
such application areas as aerospace, au- nitely put tool support for executability (2003), 64–83.
2. Damm, W. and Harel, D. LSCs: Breathing life into
tomotive, telecommunication, medical and experience in real-world use at the message sequence charts. Formal Methods in System
instrumentation, hardware design, and top of the list. Too much computer sci- Design 19, 1 (2001), 45–80.
3. Drusinsky, D. and Harel, D. On the power of bounded
control systems. An interesting devel- ence research on languages, method- concurrency I: Finite automata. J. ACM 41 (1994),
opment also involves the language be- ologies, and semantics never finds its 517–539.
4. Efroni, S., Harel, D., and Cohen, I.R. Towards
ing used in such unconventional areas way into the real world, even in the long rigorous comprehension of biological complexity:
as modeling biological systems.4,20,21 term, because these two issues do not Modeling, execution, and visualization of thymic T cell
maturation. Genome Research 13 (2003), 2485–2497.
Another important topic is hybrid sys- get sufficient priority. 5. Harel, D. Can programming be liberated, period? IEEE
Computer 41, 1 (Jan. 2008), 28–37.
tems. Statecharts can include probabili- One of the most interesting aspects 6. Harel, D. Statecharts in the making: A personal
ties, thus supporting probabilistic and of this story is the fact that the work account. In Proceedings of the Third ACM SIGPLAN
Conference on History of Programming Languages
stochastic behavior, but their underly- was not done in an academic tower, in- (San Diego, CA, June 9-10). ACM Press, New York,
ing basis is discrete. It is very natural for venting something and trying to push 2007.
7. Harel, D. and Rumpe, B. Meaningful modeling: What’s
a software or systems engineer to want it down the throats of real-world en- the semantics of ‘semantics’? IEEE Computer 37, 10
to model systems with mixed discrete gineers. It was done by going into the (2004), 64–72.
8. Harel, D. and Kugler, H. The Rhapsody semantics of
and continuous behavior, and it is not lion’s den, working with the people in statecharts (or, on the executable core of the UML). In
difficult to imagine using mathematics industry. This is something I would Integrations of Software Specification Techniques for
Applications in Engineering, LNCS, Vol. 3147, H. Ehrig
geared for continuous dynamics (such not hesitate to recommend to young et al., Eds. Springer-Verlag, New York, 2004, 325–354.
as differential equations) to model the researchers; in order to affect the real 9. Harel, D. and Marelly, R. Come, Let’s Play: Scenario-
Based Programming Using LSCs and the Play-Engine.
activities within states in a statechart. world, one must go there and roll up Springer-Verlag, New York, 2003.
An active community today is carrying one’s sleeves. One secret is to try to get 10. Harel, D. and Politi, M. Modeling Reactive Systems with
Statecharts: The Statemate Approach. McGraw-Hill,
out research on such systems. a handle on the thought processes of New York, 1998.
Another topic involves exploiting the engineers doing the real work and 11. Harel, D. and Gery, E. Executable object modeling with
statecharts. IEEE Computer 30, 7 (1997), 31–42.
the structuring of behavior in stat- who will ultimately use these ideas and 12. Harel, D. and Naamad, A. The statemate semantics
of statecharts. ACM Transactions on Software
echarts to aid verification of the mod- tools. In my case, they were the avion- Engineering Methods 5, 4 (Oct. 1996), 293–333.
eled system. We all know how difficult ics engineers, and when I do biological 13. Harel, D., Lachover, H., Naamad, A., Pnueli, A., Politi,
M., Sherman, R., Shtul-Trauring, A., and Trakhtenbrot,
program verification is, yet a number modeling, they are biologists. If what M. Statemate: A working environment for the
of techniques work well in many cases. you come up with does not jibe with development of complex reactive systems. IEEE
Transactions on Software Engineering 16, 4 (1990),
While most common verification tech- how they think, they will not use it. It’s 403–414.
niques do not exploit the hierarchical that simple. 14. Harel, D. On visual formalisms. Commun. ACM 31, 5
(May 1988), 514–530.
structure or modularity models often Looking back over the past 26 years, 15. Harel, D., Pnueli, A., Schmidt, J., and Sherman, R. On
have, this structure can be used benefi- the main mistakes I made during the the formal semantics of statecharts. In Proceedings
of the Second IEEE Symposium on Logic in Computer
cially in verifying statecharts. Work has early years of statecharts concerned Science (Ithaca, NY, 1987), 54–64.
indeed been done on the verification getting the message out to real-world 16. Harel, D. Statecharts: A visual formalism for complex
systems. Science of Computer Programming 8, 3
of hierarchical state machines, though software and systems engineers. This (June 1987), 231–274.
much more remains to be done. involved the confusing process of de- 17. Harel, D. and Pnueli, A. On the development of reactive
systems. In Logics and Models of Concurrent Systems,
Finally, I should mention some re- ciding on a clear semantics for the K.R. Apt, Ed. NATO ASI Series, Vol. F-13, Springer-
cent work my colleagues and I have language and publicizing the chosen Verlag, New York, 1985, 477–498.
18. Harel, D. And/Or programs: A new approach to
carried out on a new approach to vi- semantics promptly in the public lit- structured programming. ACM Transactions on
Programming Languages and Systems 2, 1 (Jan.
sual formalisms for complex systems. erature, as well as not recognizing how 1980), 1–17.
It involves a scenario-based specifica- important it was to quickly publish a 19. Heninger, K.L., Kallander, J.W., Shore, J.E., and Parnas,
D.L. Software Requirements for the A-7E Aircraft, NRL
tion method, rather than the state- book to acquaint engineers in industry Report 3876. Washington, D.C., Nov. 1978.
based approach of statecharts. The with, and get them to use, a new lan- 20. Setty, Y., Cohen, I.R., Dor, Y., and Harel, D. Four-
dimensional realistic modeling of pancreatic
idea is to concentrate on specifying guage, method, and tool. organogenesis. In Proceedings of the National
the behavior between and among the Nevertheless, despite the effort that Academy of Science 105, 51 (2008), 20374–20379.
21. Swerdlin, N., Cohen, I.R., and Harel, D. Toward an
objects (or tasks, functions, and com- went into developing the language in-silico lymph node: A realistic approach to modeling
ponents), not within them—inter- (and later the tools to support it) I am dynamic behavior of lymphocytes. In Proceedings of
the IEEE, Special Issue on Computational System
object rather than intra-object. The convinced that almost anyone could Biology 96, 8 (2008), 1421–1443.
language we have proposed for this— have come up with statecharts, given 22. von der Beeck, M. A comparison of statecharts
variants. In Proceedings of Formal Techniques in Real
Live Sequence Charts—was worked the right background, exposure to the Time and Fault Tolerant Systems, LNCS, Vol. 863.
out jointly with Werner Damm.2 The right kinds of problems, and right Springer-Verlag, New York, 1994, 128–148.

associated play-in and play-out pro- kinds of people.

gramming techniques were devel- David Harel (dharel@weizmann.ac.il) is the William
oped later with my Ph.D. student Acknowledgment Sussman Professorial Chair in the Department of Computer
Science and Applied Mathematics at The Weizmann
Rami Marelly.9 I published a paper Many people influenced this work, but Institute of Science, Rehovot, Israel.
last year describing a long-term vi- my deepest gratitude goes to Jonah
sion on how this could be made much Lavi, Amir Pnueli, Eran Gery, Rivi Sher-
more general.5 man, and Michal Politi. © 2009 ACM 0001-0782/09/0300 $5.00

ma r c h 2 0 0 9 | vo l. 52 | n o. 3 | c om m u n ic at ion s of t he acm 75