1 / 26

Behavioral Programming Methodologies and Tools for Developing Reactive Systems

Gera Weiss Department of Computer Science Ben Gurion University of The Negev . Behavioral Programming Methodologies and Tools for Developing Reactive Systems. Main idea:. Program a separate code module for each "paragraph" in the requirements document

kiele
Download Presentation

Behavioral Programming Methodologies and Tools for Developing Reactive Systems

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Gera Weiss Department of Computer Science Ben Gurion University of The Negev Behavioral Programming Methodologies and Tools for Developing Reactive Systems

  2. 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

  3. Can Complex Reactive Software be built of modules that reflect requirements similar to how people interweave plans? … Driving Directions Daily Schedule … ... Drive for 4 hrs. Stop for Lunch Drive for 5 hrs. … A 6-day trip from NYC to LA

  4. Maintenance without modifying existing code ?! … and can we implement new requirements without expertise in the legacy code?

  5. 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 theyrequest andwhat 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 Wait B-s Behavior Threads Request Block

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

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

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

  10. Example: Coding b-threads Hot Water Cold Water AddHotFiveTimes() {    for i=1 to 5 { bSync(request=addHot,wait-for=none,block=none);    } } addHot addHot addHot addHot addHot addHot addHot addHot addHot addHot addColdaddColdaddColdaddColdaddCold addHot addColdaddHot addColdaddHot addCold addHot addCold addHot addCold 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);    } }

  11. 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

  12. Main application: reactive systems Distributed Data Processing Robotics Mobile Computing Complexity stems from the need to interleave many simultaneous behaviors

  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 advantagesand limitations • And more…

  14. David Harel • Werner Damm • Rami Marelly • Hillel Kugler • ShaharMaoz • ItaiSegall • AssafMarron • Robby Lampert • Guy Wiener • Amir Nissim • Nir Eitan • Michal Gordon • Guy Katz • Moshe Weinstock • Michael Bar-Sinai • Ronen Brafman • . . . Team – past and present

  15. 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);         }     } } Programming by dragging & dropping Scratch like bricks: You will soon see…

  16. A proposed architecture for large-scale real-world applications Asynchronous Communication B-thread B-thread Behavior Nodes B-thread B-thread B-thread B-thread B-thread B-thread Sensors and Actuators World

  17. Demo: Hot / Cold in waterbear

  18. Example: 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);

  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 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.

  23. 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

  24. 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

  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 canchoose the next event : • Randomly and reinforce probabilities using machine learning; or, • By looking ahead and planning an optimal path • Programmers can easily code assessment of states in b-threads ? ?

  26. Summary of the proposed methodology Wait Captureeach requirement in a separate code-module Verifythat requirements do not conflict Interweaveand execute using a general mechanism B-s Behavior Threads Request Block

More Related