Extracts below from Behavioral Programming article. Behavioral Programming.pdf
A novel paradigm for programming reactive systems centered on naturally specified modular behavior.
One widely accepted practice is to formalize requirements in the form of use cases and scenarios. Our work extends this approach into using scenarios for actual programming.
we propose scenario-coding techniques and design approaches for constructing reactive systems incrementally from their expected behaviors.
The work on behavioral programming began with scenario-based programming, a way to create executable specifications of reactive systems, introduced through the language of live sequence charts (LSC) and its Play-Engine implementation.
The initial purpose was to enable testing and refining specifications and prototypes, and it was later extended toward building actual systems.
The approach allows coding applications as multi-modal scenarios, each corresponding to an individual requirement, specifying what can, must, or may not happen following certain sequences of events.
To facilitate full behavioral modularity via the independent coding of separate facets of behavior, all scenarios run simultaneously, and all are consulted at every decision point during execution.
We show how model-checking technologies allow discovery of unhandled scenarios, enabling the user to incrementally develop behaviors for new tactics (and forgotten rules) until a software system is achieved that plays legally and assures the computer never loses.
We were able to code the application incrementally in modules that are aligned with the requirements (game rules and tactics), as perceived by users and programmers.
We added new tactics and rules (and still more can be added) without changing, or even looking at, existing code.
The resulting product is modular, in that tactics and rules can be flexibly added and removed to create versions with different functionalities.
We propose the term behavioral ap-plication for software consisting of independent components (called b-threads) that generate a flow of events via an enhanced publish/sub-scribe protocol.
Note: There's a technical description of the way b-threads work in Page 3 under "Basic Behavioral Idioms".
The programming idioms of request, wait for, block thus express multimodality. Reminiscent of modal verbs in a natural language (such as shall, can or mustn’t), they state not only what must be done (and how) as in standard programming, but also what may be done, and, more uniquely to behavioral programming, what is forbidden and therefore must not be done.
In behavioral programming, all one must do in order to start develop-ing and experimenting with scenarios that will later constitute the final system, is to determine the common set of events that are relevant to these scenarios.
Play-in is similar to programming by example in that both try to make programming easier for humans using visualization and physical actions, and the approaches can certainly gain from one another. The main difference is that programming by example is a way to avoid writing code in small programs, for educational purposes, where play-in is intended for use as part of programming modal scenar-ios to be executed collectively as a complex system.
The Playbook and Play-Engine Site
One concern associated with align-ing application scenarios with requirements is that individually valid requirements may conflict. Thus, coding them independently of each other and composing them without consideration may yield undesired joint behavior.
Our approach suggests resolving con-flicts using new b-threads and priorities.
We present a methodology and a supporting model-checking tool (called BPmc) for verifying behavioral programs without having to first translate them into a specific input language for the model checker. Our method facilitates early discovery of conflicting or underspecified scenarios.
From the model-checking perspective, the BPmc tool reduces the size of the state-space of a Java pro-gram using an abstraction that focuses on the behaviorally interesting states and treats transitions between them as atomic. To the existing standard execution control, which consists of deterministic progression along a single path in the behavioral program state graph, we add two model-checking execution modes: safety and liveness. The safety mode explores the different paths in the graph in search of a state that violates the given safety property, while the liveness mode seeks cycles that violate the given liveness property.
Note: The previous part sounds really similar to TLA+.
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.
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.
Note: A good summary of Behavior-based Robotics (Bielefeld exists?)
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 pub-lish/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/subscribe idioms.
Behavioral programming may also accommodate customization as part of the development cycle, where end-users can enhance, change, or remove functionality of delivered systems (for example, smartphones), by coding or downloading new behaviors without accessing the core product code.