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
