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