8 and leJOS,
37 which construct
systems from behaviors (see the review
in Arkin1). Our behavioral programming
approach may serve as a formalism,
implementation, or possible extension,
of some coordination and arbitration
components in these architectures.
The test-driven or behavior-driven
development methodologies (for example, JBehave, see http://jbehave.
org) emphasize the importance of articulating scenarios of expected overall system behavior early in development. As the formal description of
scenarios is shown to be valuable, we
propose that with behavioral programming it may be possible to actually use
such specifications as part of the developed system.
We feel that a key contribution of
behavioral programming to established programming paradigms seems
to be the addition of a concise and autonomous way for a process to block, or
veto, events that other processes may
attempt to trigger. In common publish/subscribe mechanisms, for example, such blocking would require additional inter-process communication.
In research to be published separately,
we prove that the explicit blocking idiom can make behavioral programs exponentially more succinct (in the number of states) than traditional publish/
illustration by leandro Castelao
Clearly, behavioral programming
principles can be implemented in other
languages and environments. We view
the approach as an enrichment of, not
an alternative to, current programming
approaches. In particular, constructs
like semaphores/rendezvous, chan-nels/message queues, and threads/con-tinuations, can be used to implement
and to complement the synchronization and blocking of behavioral programming. More specifically, in rich
decentralized applications, behavioral
programming can coexist with actor-oriented, agent-oriented, and other
concepts that enable coordination of
concurrent processes (see, for example,
the survey in Bordini et al.
In this context, the main point
about behavioral programming is its
focus on interweaving independent
behaviors to yield a desired run (a sequence of events), and the lesser focus
on issues related to parallel execution
of independent behaviors and the re-
code from aspects.
sulting performance gains. In fact,
some implementations of the behavioral execution mechanism are single-threaded. It would be interesting
to explore the synergy of behavioral
programming with such languages,
which could be done, for example, by
introducing blocking and synchronization idioms into non-behavioral
platforms and using established platforms to connect behaviorally programmed nodes.
The execution semantics of behavioral programming has similarities
to the event-based scheduling of Sys-temC,
39 which performs co-routine
scheduling in three phases, evaluation,
update, and notification, as follows: all
runnable processes are run, one at a
time, up to a synchronization point;
queued updates are recorded; and,
processes affected by these updates are
then made runnable.
The BIP language (behavior, interaction, priority) and the concept of glue
for assembling components proposed
by Sifakis and his colleagues (see, for
example, Bliudze and Sifakis5) pursue
goals similar to ours. Though some of
the terminology is similar, the specifics
are different. BIP focuses on creating a
system that is correct-by-construction
with regard to safety properties like
freedom from deadlock, while behavioral programming concentrates on
programming in a natural way, and
turns to other techniques, including
model checking, to discover and resolve potential conflicts. A possible
research direction involves adding synchronization and blocking as composition idioms of BIP.
Finally, behavioral programming
may be suitable for software projects
that call for feature-oriented development40 and product-line packaging.
For example, an expert version of a
game-playing program could differ
from the novice version by simply including behavior threads for additional strategies. In Harel et al.
25 we discuss
behavioral programming in relation
to additional programming languages
As to application domains, we note
how features of behavioral programming contribute to making it useful for
particular domains, as follows. Coding
inter-object scenarios can be useful,
for example, for orchestrating valves,