the right track (see Figure 3). Very encouraging.
So much for clarity. As for precision
and formality, full executability was always 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 dynamics 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 everything must be rigorous enough to be
run (executed) just like software written
in a programming language. Executability 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.
figure 3: Page from the iai notes (1983, events in hebrew) showing a relatively “clean” draft
of the top levels of behavior for the main flight modes of the Lavi avionics, including
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.
sitions, default entries, and more.
Interestingly, the same quick comprehension applied to nonexperts outside
the avionics group. I recall an anecdote
from late 1983 in which in the midst of
one session the blackboard showed a
complicated statechart specifying the
behavior of some intricate portion of
the Lavi’s avionics. A knock on the door
brought in an Air Force pilot from the
“customer” team who knew a lot about
the aircraft being developed and its desired behavior but had never seen a state
machine or a state diagram before, not
to mention a statechart. I remember
him staring at this intricate diagram (the
statechart) on the blackboard, with its
complicated mess of blobs inside other
blobs, arrows splitting and merging, and
asking, “What’s that?” One of the engineers said, “That’s the behavior of the
so-and-so part of the system, and, by the
way, these rounded rectangles are states,
and the arrows are transitions between
states.” The pilot studied the blackboard
for a couple of minutes, then said, “I
think you have a mistake down here; this
arrow should go over here and not over
there.” He was right.
For me, this little event indicated that
we might be doing something right, that
maybe what I was proposing was a good
and useful way of specifying reactive
behavior. If an outsider could come in,
just like that, and grasp something that
complicated without being exposed to
the technical details of the language or
the approach, then maybe we were on
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
branch. By 1986, we had built a tool for
statecharts called Statemate.
In extensive discussions with the
two most senior technical people associated with the company, Rivi Sherman and Michal Politi, along with
Amir Pnueli, we were able to figure out
during the Ad Cad period how to embed statecharts into a broader framework that was capable of capturing
the structure and functionality of a
large complex system. To this end, we
proposed a diagrammatic language
to structure a model that we called
activity-charts, an enriched kind of hierarchical data-flow diagram whereby
arrows represent the possible flow
of information between the incident
functions (activities). Each activity
can be associated with a controlling
statechart (or code) that would also be
responsible for interfunction communication and cooperation.