Model-Checking Behavioral Programs - PowerPoint PPT Presentation

sileas
slide1 n.
Skip this Video
Loading SlideShow in 5 Seconds..
Model-Checking Behavioral Programs PowerPoint Presentation
Download Presentation
Model-Checking Behavioral Programs

play fullscreen
1 / 48
Download Presentation
Model-Checking Behavioral Programs
114 Views
Download Presentation

Model-Checking Behavioral Programs

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Model-Checking Behavioral Programs Assaf Marron Weizmann Institute of Science

  2. Agenda • Introduction to behavioral programming • The model-checker

  3. Team / Acknowledgements • David Harel • Gera Weiss • Guy Wiener • Smadar Szekely • Robby Lampert • Michal Gordon • Nir Eitan • Amir Nissim • David Harel’s research group - past and present

  4. The Behavioral Programming Vision Can complex software be developed from simple threads of behavior by automatic interweaving ?

  5. Humans interweave behavior threads all the time… Driving Directions Daily Schedule … ... Drive for 4 hrs. Stop for Lunch Drive for 5 hrs. … … A 6-day trip from NY to LA … can software be developed this way?

  6. LSC & BPJ: From requirements to code • LSC: A visual language for scenario specification • Dammand Harel2001, Harel and Marelly2003 • Natural yet executable scenario-based specification • Initially for requirement specification, evolved into a programming language • PlayGo – an IDE for programming with LSC • 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, …). class AddHotFiveTimes extends BThread {     public void runBThread() {         for (int i=1; i<=5; i++) { bSync(addHot, none, none);         }     } }

  7. Incremental development in Java with BPJ Behavior Threads Req. 3.1 class AddHotFiveTimes extends BThread {     public void runBThread() {         for (int i=1; i<=5; i++) { bSync(addHot, none, none);         }     } } Req. 5.2.9 class AddColdFiveTimesBThread {     public void runBThread() {         for (int i=1; i<=5; i++) { bSync(addCold, none, none);         }     } } Patch 7.1 class Interleave extends BThread {     public void runBThread() {         while (true) { bSync(none, addHot, addCold); bSync(none, addCold, addHot);        }     } }

  8. Why do we need this? Need to accommodate a cross-cutting requirement? Add a module Need to refine an inter-object scenario?Add a module Need to remove a behavior?Add a module . . .?Add a module A key benefit: incremental development No need to modify existing code

  9. Behavior execution cycle • All behavior threads (b-threads) post declarations: • Requestevents: propose events to be considered for triggering; • Waitfor events: ask to be notified when events are triggered; • Block events: temporarily forbid the triggering of events. • When all declarations are collected: • An event that isrequestedand not blockedis selected. • All b-threadswaitingfor this event can update their declaration

  10. Behavior execution cycle Wait B-s Behavior Threads Request Block

  11. Behavior execution cycle Wait B-s Behavior Threads Request Block

  12. Behavior execution cycle Wait B-s Behavior Threads Request Block

  13. B-threads are Java threads • Events and event sets are Java objects and collections • Development and execution do not require special environments • Direct integration with other Java code: • The transition system is implicit classMyBThreadextendsBThread { voidrunBthread() { … bSync(requestedEvents, watchedEvents, blockedEvents); … } } The BPJ Library and API Online: The Group’s SVN

  14. Example: Coding b-threads in Java class AddHotFiveTimes extends BThread {     public void runBThread() {         for (int i=1; i<=5; i++) { bSync(addHot, none, none);         }     } } addHot addHot addHot addHot addHot addHot addHot addHot addHot addHot addColdaddColdaddColdaddColdaddCold addHot addColdaddHot addColdaddHot addCold addHot addCold addHot addCold class AddColdFiveTimesBThread {     public void runBThread() {         for (int i=1; i<=5; i++) { bSync(addCold, none, none);         }     } } class Interleave extends BThread {     public void runBThread() {         while (true) { bSync(none, addHot, addCold); bSync(none, addCold, addHot);        }     } }

  15. Main application: reactive systems Complexity stems from the need to interleave many simultaneous behaviors

  16. Alignment of code modules with requirements • When I put two Xs in a line, you need to put an O in the third square bSync(none, X<1,3>, none); bSync(none, X<2,2>, none); bSync(O<3,1>, none, none);

  17. Each new game rule or strategy is added in a separate b-thread without changing existing code

  18. Example: Flying a quadrotor helicopter To correct the angle: requestSpeedUpR1 blockSlowDownR1 blockSpeedUpR4 requestSpeedUpR4 requestSpeedUpR2 requestSpeedUpR2 blockSlowDownR4 Selected event: SpeedUpR2 requestSlowDownR4 blockSlowDownR2 To increase altitude: blockSlowDownR2 requestSpeedUpR3 blockSlowDownR3

  19. Balancing a quadrotor – behaviorally

  20. But… • How do we know when we are done? • When each module is programmed separately, how do we avoid conflicts? • An answer: Model Checking + Incremental Development

  21. Given a model of a system, test automaticallywhether this modelmeets a given specification. • Program model = state graph • Specification: • Safety conditions (including deadlocks) • Liveness • We are focused on explicit MCas opposed to symbolic. Model Checking

  22. A b-threadis a tuplehS, E, , initi, R, Bi • Where hS, E,,initiis a transition system, and • for each state s: • the set R(s) models the requestedevents • the set B(s)models the blocked events R(s1)={e1,e2}B(s1)={e3,e4} R(s2)={e1,e7}B(s2)={e8} s1 s2 e1,e2 e1,e7,e9 b-Thread: Formal Definition

  23. Composition of the b-threads fhSi, Ei, i, initi, Ri, Bii: i=1,...,ng is defined as a product transition system. The composition contains the transition if: The runs of a set of b-threads

  24. A . . labelNextVerificationState( “A” ); bSync( … ); if( lastEvent == event1 ) { . . . labelNextVerificationState( “B” ); bSync( … ); } if( lastEvent == event2 ) { . . . labelNextVerificationState( “C” ); bSync( … ); } event1 B event2 Behavior Thread States b-thread states at bSync C

  25. Program states are the Cartesian product of b-thread states D A G B H C ADG E I AEG BDG … … … … Behavioral Program State Graph BDH AEI

  26. Model-checking behavioral programs “in-vivo” (c.f. Java Path Finder) Transition using standard execution (by the native JVM) Backtrack using Apache javaflow continuations Notations for nondeterministic transitions State matching and search pruning by b-threads State tagging for safety and liveness properties by b-threads Deadlocks detected automatically

  27. Counterexample: A path to a bad state 1 2 3 4

  28. Demo

  29. Initial Development: • DetectXWin, DetectOWin, DetectDraw • EnforceTurns • DefaultMoves • XAllMoves • Modify b-threads to prune search / mark bad states • Model Check  Counterexample  Add b-thread / change priority: • PreventThirdX • PreventXFork • PreventAnotherXFork • AddThirdO • PreventYetAnotherXFork Development Summary

  30. Let c=e1, …, em, …,enbe a counterexample • Can generalize and code new b-threads or, • Can use the counterexample in a patch behavior. E.g., • Let em be the last event requested by the system • Wait for e1, …, em-1 • Block em • Other b-threads will take careof the right action, “the detour”. • Model-check again Counterexamples as scenarios

  31. Fairness Constraints • Unconditional : “Every process gets its turn infinitely often”. • Strong : “Every process that is enabled infinitely often gets its turn infinitely often” • Weak “Every process that is continuously enabled from a certain time instant on gets its turn infinitely often” B B A A B B A B B B A A B B A AB B AB B B B A A B B A AB AB AB B

  32. Input: fairness constraints as event sets • MC: Look for cold states only in FAIR cycles B B B B A A A A B B B B A A B A Liveness Testing with Fairness Constraints

  33. Bridge-crossing problem • Dining Philosophers • Scheduling in a signal-processing board Other examples and experiences

  34. Initial Performance

  35. Abstracts program only per behavioral states • Dependent on application for state labeling • Single threading during model-checking • Dependency on Javaflow • No support for dynamic B-Threads • Application-dependentperformance • Explicit MC only Limitations / opportunities

  36. The Java Pathfinder (JPF) attempt • The iterative execution version – “poor man’s verification” • The backtracking challenge and finding Javaflow Some Interesting research experiences

  37. Visualization and Comprehension Prioritizing program over user and defense over default moves Blocking to prevents playing out of turn Event trace(rows)withb-thread statesand R/W/B eventsets Understanding composite behavior – a trace visualization tool [ICPC ‘11] B-threads (columns) in priority order A lower priority event (on right), is selected because a higher-priority event (on left) is blocked.

  38. Visualization and Comprehension Prioritizing program over user and defense over default moves Blocking to prevents playing out of turn Event trace(rows)withb-thread statesand R/W/B eventsets Understanding composite behavior – a trace visualization tool [ICPC ‘11] B-threads (columns) in priority order A lower priority event (on right), is selected because a higher-priority event (on left) is blocked.

  39. But still … • Can it scale to large applications? • … and what about external events?

  40. Remote Events – Local Behavior

  41. Theory, tools, methodologies for: • Compositional model-checking check each b-thread separately • Run-time model-checking for event selection • Program synthesis for automatic b-thread generation (e.g., for patching) Research Directions around MC for BP

  42. Summary The behavioral programming paradigm Direct model checking of behavioral Java programs Synergies between BP and MC

  43. Interweaving Verification Scalability Thank You !

  44. Wargames: 1983, Dir. John Badham http://www.youtube.com/watch?v=NHWjlCaIrQo

  45. Backup Slides

  46. Example: A game strategy Move events: X<0,0>, … , X<2,2>, O<0,0>, … , O<2,2> Game events: OWin, XWin, Tie EnforceTurns: One player marks a square in a 3 by 3 grid with X, then the other marks a square with O, then it is X’s turn again, and so on; SquareTaken: Once a square is marked, it cannot be marked again; DetectWin: When a player marks three squares in a horizontal, vertical, or diagonal line, she wins; AddThirdO: After marking two Os in a line, the O player should try to mark the third square (to win); 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); DefaultOMoves:When other tactics are not applicable, player O should prefer the center square, then the corners, and mark an edge square only when there is no other choice;

  47. http://commons.apache.org/sandbox/javaflow/ • Save a thread’s stack in an object called a continuation. • Can restore the continuation in any thread – and continue execution from there • BPmc optionally serializes the continuation with all pointed objects • See BP user guide Javaflow

  48. Some answers to common questions and challenges • What about conflicting requirements? • Model Checking • Incremental development • … • Scalability in terms number of behaviors and interleaving complexity? • Agent oriented architectures • Machine learning for event selection • … • Comprehension of systems constructed by behavior composition? • Trace visualization tool • …