emerging as developers and users
learn about and experiment with the
Similarly to the case of conflicts,
new requirements in behavioral programming can often be coded as new
behaviors. For example, while developing the quadrotor application we realized that rotor speed (RPM) cannot be
negative. We solved this by adding a
b-thread that blocks speed reduction
events when the speed is too low.
Obviously, both model checking and
the look-ahead mentioned here may
help detect and deal with such underspecification. The problem can also be
handled by making the program learn
and adapt as part of its development.
For example, extending the semantics
of behavioral programming with reinforcements allows applications that
also specify, in addition to what should
be done or not done at every step, broader goals.
13 Reinforcements are captured
by b-threads, each one contributing a
narrow assessment of the current situation relative to a longer-term goal. Leveraging the unique structure of behavioral programs, an application-agnostic
learning mechanism translates the reinforcements into event-selection decisions that improve over time. This ability to learn and adapt allows removal of
the need for a total order on b-threads
and event requests, thus simplifying
development. For example, a salad-making robot is specified in Eitan and
13 with scenarios for picking up
vegetables, and washing, cutting, and
serving them in designated locations.
With the help of reinforcements, the
robot learns to perform these tasks in
the correct order, while overcoming obstacles in the kitchen and dealing with
Another concern around behavioral
programming execution is that if one divergent b-thread (a runaway) fails to synchronize, the entire application stops.
The problem is of course aggravated
when many behaviors are involved.
As described in Harel et al.
following the work in Barak et al.,
expect that in large behavioral applica-
tions not all behaviors will be required
to synchronize with each other. In-
stead, we anticipate that synchroniza-
tion requirements will be reduced by
dividing large numbers of naturally
specified behaviors into nodes; each of
which is fully synchronized internally,
and where the communication be-
tween nodes is carried out by external
events. The resulting system will still
be incremental, in that new functional-
ity can be implemented by adding sce-
narios to different behavior nodes to
generate and interpret (new) external
events, with little or no modification to
Related Work and Future Directions
In some languages (for example, workflow engines or simulation specifications) scenarios and behaviors may be
encoded quite directly and visibly. In
others (for example, procedural and object oriented programming, functional
programming and logic programming)
different modularization may cause
scenario encodings to be more subtle;
rendering them visible only at runtime. One of the main contributions
of behavioral programming is the ability to program multimodal scenarios
incrementally using modules that are
aligned with requirements.
Relative to object-oriented programming, behavioral modules and events
may involve objects, but they are not
necessarily anchored to a single one.
When programming behaviorally, one
focuses on system behavior, and less
on identifying actors. Often, behavior
threads represent inter-object scenarios that are not directly visible when the
software is implemented as methods
of individual objects. The states of such
scenarios often conveniently replace or
complement data in standard objects.
Ideas for using behaviors that are
specified as refinements and constraints over other modules are discussed in the context of superimpositions.
7 Behavioral programming offers
practical programming mechanisms
for implementing implicit, indirect
control of one behavior over all other
relevant behaviors, without explicit
references from a controlling or constraining module to the controlled,
base module. Additionally, in behavioral programming all system behaviors
are treated equally, without the distinction between base and refinements.
Aspect-oriented programming (AOP)
focuses on implementing cross-cut-ting concerns as separate modules
that can modify the behavior of base
application modules. AOP’s relation
to superimposition was pointed out
in Katz and Gil.
32 We believe behavioral programming can contribute
toward implementing symmetric aspects, complementing the currently
prevalent asymmetric approach that
distinguishes base code from aspects.
In addition, while behavioral programming allows the triggering of behaviors
by sequences of events, in present AOP
implementations, join-points commonly represent individual events, and
triggering behaviors following rich sequences of events requires non-trivial
state management in the aspect code.
In robotics and hybrid-control there
are behavior-based architectures, including Brooks’s subsumption architecture,
9 Branicky’s behavioral program-