BP Intro

Behavioral programming (BP) is a modeling approach that aims to optimize the congruence between the model and how people perceive its intended behavior. It is a generalization and extension of the scenario-based programming framework that was first introduced with the language of live sequence charts (LSC).

The modules of a behavioral programming model are threads of behavior or scenarios or stories (the exact term may vary between languages), which can be thought of as corresponding to use cases appearing in a requirements document. Each of these threads of behavior represents a sequence of events that the system should, could, or should not carry out under certain conditions or following specific sequences of events. All the threads are interwoven at run-time, yielding an integrated system behavior.

For example, in a game-playing application, each of the game rules and playing strategies would be programmed separately and independently with little or no explicit awareness of other modules. At the run time, an execution mechanism interlaces the behaviors, choosing events based on each module’s demands and constraints, taking into account higher-level considerations that might include priorities, learning and planning, among others.

Behavioral programming integrates with and complements object-oriented programming, aspect-oriented programming, agent-based architectures, agile programming, and several other software engineering paradigms. The underlying principles of the approach are largely language-independent and can be implemented in many environments.

Behavioral Programming was introduced by Harel, Marron and Weiss in 2010 in a scientific paper.

The sync statement

BP programs are composed of threads of behavior, called b-threads. B-threads run in parallel to coordinate a sequence of events via a synchronized protocol. During program execution, when a b-thread wants to synchronize with its peers, it submits a statement to the central event arbiter using the sync statement.

A sync statement declares which events the b-thread requests, which events it waits for (but does not request), and which events it would like to block (that is, prevent from being selected). Blocked and waited-for events can be described using a predicate or a list. Requested events have to be specified explicitly.

After calling sync, the b-thread is blocked, waiting for the rest of the b-threads to synchronize (call sync) as well. When all b-threads have submitted their statements, the arbiter selects an event that was requested but not blocked. It then wakes up the b-threads that requested or waited for that event. The rest of the b-threads remain blocked, until an event they requested or waited for is selected.

See an online tutorial that demonstrates how BP techniques are applied using the BPjs library that the Provengo engine is based on.