Behavioral ProgrammingMethodologies and Tools for Developing Reactive Systems

Gera WeissDepartment of Computer Science

Ben Gurion University of The Negev

Main idea:

» Program a separate code module for each "paragraph" in the requirements document

» When requirements are added or refined, add modules with little or no change to existing code

» Use an application-agnostic interweaving mechanism to run the modules together

» ... In the framework of the familiar programming languages, constructs, and concepts

3A 6-day trip from NYC to LA

Daily Schedule

...Drive for 4 hrs.

Stop for Lunch

Drive for 5 hrs. …

Driving Directions

…

Can Complex Reactive Software be built of modules that reflect requirements

similar to how people interweave plans?

4

Maintenance without modifying existing code ?!

… and can we implement new requirements without expertise in the legacy code?

Proposed answer: Consider all requirements before each action» The program modules, called behavior-threads (b-threads), are

ordinary procedures in a programming language

» All b-threads meet before each action the system takes

» In each meeting, b-threads specify what they request and what they forbid for the next step

» At the end of each meeting, an application-agnostic mechanism selects an action (event) that isrequested but not forbidden

6

Behavior execution cycle

B-s

Block

Wait

Request

Behavior Threads

7

Behavior execution cycle

B-s

Block

Wait

Request

Behavior Threads

8

Behavior execution cycle

B-s

Block

Wait

Request

Behavior Threads

9

Behavior execution cycle

B-s

Block

Wait

Request

Behavior Threads

10

addHotaddHotaddHotaddHotaddHot

Example: Coding b-threadsAddHotFiveTimes() {    for i=1 to 5 {       bSync(request=addHot, wait-for=none, block=none);    } }

AddColdFiveTimes() {    for i=1 to 5 {        bSync(request=addCold, wait-for=none, block=none);    } }

Interleave() {    forever { bSync(request=none, wait-for=addHot, block=addCold); bSync(request=none, wait-for=addCold, block=addHot);    } }

addHotaddHotaddHotaddHotaddHot addCold addCold addCold addCold addCold

addHot addColdaddHot addColdaddHot addColdaddHot addColdaddHot addCold

ColdWater

HotWater

11

Behavior execution cycle

1. All behavior threads (b-threads) post declarations:

• Request events: propose events to be considered for triggering;

• Wait for events: ask to be notified when events are triggered;

• Block events: temporarily forbid the triggering of events.

2. When all declarations are collected:

An event that is requested and not blocked is selected.

All b-threads waiting for this event can update their declaration

12

Main application: reactive systems

Complexity stems from the need to interleave many simultaneous behaviors

RoboticsDistributed Data Processing

Mobile Computing

13

Present and future research

Scalability • Tools for developing many b-threads• Architectures for efficient execution of many b-threads

Dealing with conflicts and under-specification • Model checking• Automatic program repair• Machine learning• Planning

Evaluation• Empirical studies• Complex applications• Theoretical advantages

and limitations

And more…

Team – past and present» David Harel» Werner Damm» Rami Marelly» Hillel Kugler» Shahar Maoz» Itai Segall

» Assaf Marron» Robby Lampert » Guy Wiener» Amir Nissim » Nir Eitan » Michal Gordon» Guy Katz» Moshe Weinstock» Michael Bar-Sinai» Ronen Brafman» . . .

From requirements to code

15

LSC: A visual language for scenario specification

Damm and Harel 2001, Harel and Marelly 2003

Natural yet executable scenario-based specification

Initially for requirement specification, evolved into a programming language

PlayGo – an IDE for programming with LSC

class AddHotFiveTimes extends BThread {     public void runBThread() {         for (int i=1; i<=5; i++) {             bSync(addHot, none, none);         }     } }

BPJ: A package for programming scenarios in Java (and equivalents for other languages)

Harel, Marron, and Weiss 2010

Bringing advantages of scenario-based specification to programming

Integrate with & complement other paradigms (OOP, aspects, rule-based, agile, …).

Programming by dragging & dropping Scratch like bricks: You will soon see…

16

World

A proposed architecture for large-scale real-world applications

Sensors and Actuators

Behavior Nodes

B-thread

AsynchronousCommunication

B-thread

B-thread

B-thread

B-thread

B-thread

B-thread

B-thread

17

Demo: Hot / Cold in waterbear

Example: Alignment of code modules with requirements

18

bSync(none, X<1,3> , none);

bSync(none, X<2,2> , none);

bSync(O<3,1> , none, none);

When I put two Xs in a line, you need to put an O in the third square

19

Demo: Tic-Tac-Toe in waterbear

20

Each new game rule or strategy is added in a

separate b-thread

without changing existing code

21

But…» What about conflicts?

» Sources of conflicts:

» Implementation error / misunderstanding of a requirement

» Conflicting requirements

» In both cases: Good to catch as early as possible !

» Tools for catching conflicts: trace visualization, model-checking

22

Visualization and Comprehension

23

Program states are the Cartesian product of b-thread states

Behavioral Program State Graph

A

B

C

D

E

G

I

HADG

BDG

…

…AEG

……

BDHAEI

24

Model-checking behavioral programs “in-vivo” (c.f. Java Path Finder)

Backtrack using Apache javaflow continuations

Transition using standard execution (by the native JVM)

State matching and search pruning by b-threads State tagging for

safety and liveness properties by b-threads

Notations for nondeterministic transitions

Deadlocks detected automatically

25

Do I need to make sure that only one event is proposed at each round?» What if several events are requested and not blocked ?

» The run-time environment can choose the next event :

1. Randomly and reinforce probabilities using machine learning; or,

2. By looking ahead and planning an optimal path

» Programmers can easily code assessment of states in b-threads

?

?

Summary of the proposed methodology

Capture each requirement in a separate code-module

Verify that requirements do not conflict

Interweave and execute using a general mechanism

B-s

Block

Wait

Request

Behavior Threads