Abstract. Following the scenario-based approach to programming which centered around live sequence charts (LSCs), we propose a general approach to software development in Java. A program will consist of modules called behavior threads (b-threads), each of which independently describes a scenario that may cross object boundaries. We identify a protocol and a coordination mechanism that allow such behavioral programming. Essentially, runs of programs are sequences of events that result from three kinds of b-thread actions: requesting that events be considered for triggering, waiting for triggered events, and blocking events requested by other b-threads. The coordination mechanism synchronizes and interlaces b-threads execution yielding composite, integrated system behavior. The protocol idioms and the coordination mechanism of b-threads are implemented as a Java library called BPJ. Throughout the exposition we illustrate benefits of the approach and discuss the merits of behavioral programming as a broad, implementation-independent paradigm.

System specifications are often structured as collections of scenarios and use-cases that describe desired and forbidden sequences of events. A recently proposed behavioral programming approach, which evolved from the visual language of live sequence charts (LSCs), calls for coding software modules in alignment with such scenarios. We present a methodology and a supporting model-checking tool for verifying behavioral Java programs, without having to first translate them into a specific input language for the model checker. Our method facilitates early discovery of conflicting or under-specified scenarios, which can often be resolved by adding new scenarios rather than by changing existing code. Also, counterexamples provided by the tool are themselves event sequences that can serve directly for refinements and corrections. Our tool reduces the size of the execution state-space using an abstraction that focuses on behaviorally interesting states and treats transitions between them as atomic.

sPeLLing oUT The requirements for a software system under development is not an easy task, and translating captured requirements into correct operational software can be even harder. Many technologies (languages, modeling tools, programming paradigms) and methodologies (agile, test-driven, model-driven) were designed, among other things, to help address these challenges. 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. Specifically, we propose scenario-coding techniques and design approaches for constructing reactive systems 28 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. 11,21 The initial purpose was to enable testing and refining specifications and prototypes, and it was later extended toward building actual systems. To this end, the underlying behavioral principles have also been implemented in Java via the BPJ package 25 and in additional environments, 26,34,42,43 adding a programming point of view to that of requirement specification. To illustrate the naturalness of constructing systems by composing behaviors , consider how children may be taught, step-by-step, to play strategy games (See Gordon et al. 14). For example , in teaching the game of Tic-Tac-Toe, we first describe rules of the game, such as: EnforceTurns: To play, one player marks a square in a 3 by 3 grid with X, then the other player marks a square with O, then X plays again, and so on; SquareTaken: Once a square is marked, it cannot be marked again; DetectXWin/DetectOWin: When a player places three of his or her marks in a horizontal, vertical, or diagonal line, the player wins; Now we may already start playing. Later, the child may infer, or the teacher may suggest, some tactics: AddThirdO: After placing two Os in a line, the O player should try to mark the third square (to win the game); PreventThirdX: After the X player marks two squares in a line, the O player should try to mark the third square (to foil the attack); and DefaultOMoves: When other tactics are not applicable, player O should prefer the center square, then the cor-key insights Behavioral programming is a novel, language-independent paradigm for programming reactive systems, centered on natural and incremental specification of behavior, and implemented in the visual formalism of live sequence charts (LsC), and in the BPJ Java package. 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...

Behavioral programming is a recently proposed approach for nonintrusive incremental software development. We propose that behavioral programming concepts, such as behavioral decomposition, synchronized execution of independent behaviors, and event blocking, can help in the incremental and natural coding of complex decentralized systems, complementing actor-oriented and agentoriented approaches. We also contribute to the existing research on behavioral programming a method for coordinating behaviorallyprogrammed components which, due to different time scales or interaction with the external environment, cannot synchronize and thus cannot employ event blocking. We show that the resulting decentralized system retains many of the advantages present in a purely behavioral, fully synchronized system.

No abstract