Biology, hybrid systems,
Statecharts today are widely used in
such application areas as aerospace, automotive, telecommunication, medical
instrumentation, hardware design, and
control systems. An interesting development also involves the language being used in such unconventional areas
as modeling biological systems. 4, 20, 21
Another important topic is hybrid systems. Statecharts can include probabilities, thus supporting probabilistic and
stochastic behavior, but their underlying basis is discrete. It is very natural for
a software or systems engineer to want
to model systems with mixed discrete
and continuous behavior, and it is not
difficult to imagine using mathematics
geared for continuous dynamics (such
as differential equations) to model the
activities within states in a statechart.
An active community today is carrying
out research on such systems.
Another topic involves exploiting
the structuring of behavior in statecharts to aid verification of the modeled system. We all know how difficult
program verification is, yet a number
of techniques work well in many cases.
While most common verification techniques do not exploit the hierarchical
structure or modularity models often
have, this structure can be used beneficially in verifying statecharts. Work has
indeed been done on the verification
of hierarchical state machines, though
much more remains to be done.
Finally, I should mention some recent work my colleagues and I have
carried out on a new approach to visual formalisms for complex systems.
It involves a scenario-based specification method, rather than the state-based approach of statecharts. The
idea is to concentrate on specifying
the behavior between and among the
objects (or tasks, functions, and components), not within them—
inter-object rather than intra-object. The
language we have proposed for this—
Live Sequence Charts—was worked
out jointly with Werner Damm. 2 The
associated play-in and play-out programming techniques were developed later with my Ph.D. student
Rami Marelly. 9 I published a paper
last year describing a long-term vision on how this could be made much
more general. 5
If asked about the lessons to be learned
from the statecharts story, I would definitely put tool support for executability
and experience in real-world use at the
top of the list. Too much computer science research on languages, methodologies, and semantics never finds its
way into the real world, even in the long
term, because these two issues do not
get sufficient priority.
One of the most interesting aspects
of this story is the fact that the work
was not done in an academic tower, inventing something and trying to push
it down the throats of real-world engineers. It was done by going into the
lion’s den, working with the people in
industry. This is something I would
not hesitate to recommend to young
researchers; in order to affect the real
world, one must go there and roll up
one’s sleeves. One secret is to try to get
a handle on the thought processes of
the engineers doing the real work and
who will ultimately use these ideas and
tools. In my case, they were the avionics engineers, and when I do biological
modeling, they are biologists. If what
you come up with does not jibe with
how they think, they will not use it. It’s
Looking back over the past 26 years,
the main mistakes I made during the
early years of statecharts concerned
getting the message out to real-world
software and systems engineers. This
involved the confusing process of deciding on a clear semantics for the
language and publicizing the chosen
semantics promptly in the public literature, as well as not recognizing how
important it was to quickly publish a
book to acquaint engineers in industry
with, and get them to use, a new language, method, and tool.
Nevertheless, despite the effort that
went into developing the language
(and later the tools to support it) I am
convinced that almost anyone could
have come up with statecharts, given
the right background, exposure to the
right kinds of problems, and right
kinds of people.
Many people influenced this work, but
my deepest gratitude goes to Jonah
Lavi, Amir Pnueli, Eran Gery, Rivi Sherman, and Michal Politi.
1. Benveniste, a., caspi, P., edwards, s.a., halbwachs,
n., le guernic, P., and de simone, r. the synchronous
languages 12 years later. Proceedings of the IEEE 91
2. damm, W. and harel, d. lscs: Breathing life into
message sequence charts. Formal Methods in System
Design 19, 1 (2001), 45–80.
3. drusinsky, d. and harel, d. on the power of bounded
concurrency i: finite automata. J. ACM 41 (1994),
4. efroni, s., harel, d., and cohen, i.r. towards
rigorous comprehension of biological complexity:
modeling, execution, and visualization of thymic t cell
maturation. Genome Research 13 (2003), 2485–2497.
5. harel, d. can programming be liberated, period? IEEE
Computer 41, 1 (Jan. 2008), 28–37.
6. harel, d. statecharts in the making: a personal
account. in Proceedings of the Third ACM SIGPLAN
Conference on History of Programming Languages
(san diego, ca, June 9-10). acm Press, new york,
7. harel, d. and rumpe, B. meaningful modeling: What’s
the semantics of ‘semantics’? IEEE Computer 37, 10
8. harel, d. and kugler, h. the rhapsody semantics of
statecharts (or, on the executable core of the uml). in
Integrations of Software Specification Techniques for
Applications in Engineering, LNCS, Vol. 3147, h. ehrig
et al., eds. springer-Verlag, new york, 2004, 325–354.
9. harel, d. and marelly, r. Come, Let’s Play: Scenario-Based Programming Using LSCs and the Play-Engine.
springer-Verlag, new york, 2003.
10. harel, d. and Politi, m. Modeling Reactive Systems with
Statecharts: The Statemate Approach. mcgraw-hill,
new york, 1998.
11. harel, d. and gery, e. executable object modeling with
statecharts. IEEE Computer 30, 7 (1997), 31–42.
12. harel, d. and naamad, a. the statemate semantics
of statecharts. ACM Transactions on Software
Engineering Methods 5, 4 (oct. 1996), 293–333.
13. harel, d., lachover, h., naamad, a., Pnueli, a., Politi,
m., sherman, r., shtul-trauring, a., and trakhtenbrot,
m. statemate: a working environment for the
development of complex reactive systems. IEEE
Transactions on Software Engineering 16, 4 (1990),
14. harel, d. on visual formalisms. Commun. ACM 31, 5
(may 1988), 514–530.
15. harel, d., Pnueli, a., schmidt, J., and sherman, r. on
the formal semantics of statecharts. in Proceedings
of the Second IEEE Symposium on Logic in Computer
Science (ithaca, ny, 1987), 54–64.
16. harel, d. statecharts: a visual formalism for complex
systems. Science of Computer Programming 8, 3
(June 1987), 231–274.
17. harel, d. and Pnueli, a. on the development of reactive
systems. in Logics and Models of Concurrent Systems,
k.r. apt, ed. nato asi series, Vol. f- 13, springer-Verlag, new york, 1985, 477–498.
18. harel, d. and/or programs: a new approach to
structured programming. ACM Transactions on
Programming Languages and Systems 2, 1 (Jan.
19. heninger, k.l., kallander, J. W., shore, J.e., and Parnas,
d.l. Software Requirements for the A-7E Aircraft, NRL
Report 3876. Washington, d.c., nov. 1978.
20. setty, y., cohen, i.r., dor, y., and harel, d. four-dimensional realistic modeling of pancreatic
organogenesis. in Proceedings of the National
Academy of Science 105, 51 (2008), 20374–20379.
21. swerdlin, n., cohen, i.r., and harel, d. toward an
in-silico lymph node: a realistic approach to modeling
dynamic behavior of lymphocytes. in Proceedings of
the IEEE, Special Issue on Computational System
Biology 96, 8 (2008), 1421–1443.
22. von der Beeck, m. a comparison of statecharts
variants. in Proceedings of Formal Techniques in Real
Time and Fault Tolerant Systems, LNCS, Vol. 863.
springer-Verlag, new york, 1994, 128–148.
David Harel ( email@example.com) is the William
sussman Professorial chair in the department of computer
science and applied mathematics at the Weizmann
institute of science, rehovot, israel.
© 2009 acm 0001-0782/09/0300 $5.00