1. Playing with Verification, Planning and Aspects Unusual Methods for Running Scenario- Based Programs David Harel The Weizmann Institute of Science

2. Examples of reactive systems (H & Pnueli, 85) command & control systems telecommunication systems avionics & aerospace systems automotive systems circuits & VLSI medical instrumentation interactive software... biological systems commercial systems, health care, …

3. Classical approach State-based Intra-object e.g., Statecharts (H, 84) tool: Rhapsody (H&Gery, 92) Newer approach Scenario-based Inter-object LSCs (Damm&H, 98) tool: Play-Engine (H&Marelly, 02) Two dual ways to model reactivity

4. intra-object behavior (all pieces of stories given for each relevant object) This leads naturally to implementation

5. inter-object behavior (each story given for all relevant objects) Can this be made powerful enough to be the implementation?

6. First, a quick introduction to LSCs, a visual formalism for scenario- based programming

7. Most popular visual formalism for requirements: Message Sequence Charts (MSCs) (CCITT 92 and before) (or UML Sequence Diagrams ) Most popular language for formal requirements: Temporal Logic (Pnueli 74)

8. MSC for a quick-dial feature Click Keyboard Click(digit) Retrieve(digit) Call(number) signal signal not busy Sent number Send Key

9. MSCs are usually used in practice for testing As a language for behavioral requirements, they are extremely weak in expressive power Semantics is mere partial order on events Hence, in principle, a system that does nothing at all (or one that does everything) satisfies all MSCs!

10. They cannot say: - under these conditions system must do this - instance will send message - message will arrive (within such and such time) - this is not allowed to happen - this condition must be true (otherwise abort)...

11. may/must; can/always; fragmental and overlapping scenarios; anti-scenarios; etc. So we need a lot more than MSCs:

12. Live sequence charts (LSCs) LSC s: Breathing Life into Message Sequence Charts (Damm & H, 1998 ) A multi-modal extension of classical MSCs, with logical modalities (universal/existential, hot/cold, etc.) and structure (subcharts, conditionals, loops, etc.)

13. elementmandatoryprovisional chartuniversal all system runs satisfy chart existential at least one run satisfies chart AE

14. elementmandatoryprovisional chartuniversal all system runs satisfy chart existential at least one run satisfies chart AE location in chart hot run of instance must progress beyond location cold run of instance need not progress beyond location message hot if message is sent it must be received cold receipt of message is not guaranteed condition hot condition must be met otherwise abort cold if condition not met exit current (sub) chart

15. Basic form of a (universal) LSC prechart (if) main chart (then) (similar to [a] b in dynamic logic)

16. Subcharts Loops Cold conditions enable control structures Hot conditions enable anti-scenarios: False the forbidden scenario

17. LSC specification : LS = M, pc, mod Set of LSC s pc(m) is the prechart mod(m) is mode of m: A E, Chart m satisfied by system run r : m existential: m universal: System S satisfies specification LS : existential. run. r m universal. run. r m r m S LS

18. inter-object behavior (one story for all relevant objects) Can this be made powerful enough to be the implementation?

19. Traditionally, scenario-based behavior was considered unsuitable for execution, and therefore no good for implementation How do you execute a bunch of scenarios?

20. Work done with R. Marelly (99-03) Extensive strengthening of the language of LSCs (e.g., symbolic instances, time & real-like time, weighted choice, forbidden elements,…) Play-In (friendly & convenient capture) Play-Out (algorithm for execution) The Play-Engine: A full supporting tool

21. Basic idea behind play-out Play-out works like an over-obedient, but strictly minimalistic citizen, zealously adhering to the Book of Rules. Universal charts drive the execution; relevant chart copies started and monitored continuously; instances & variables unified and bound on the fly. (external event; step*; stable?) = superstep Hot stuff will be done, cold stuff might. Play-engine can thus be viewed as a universal reactive machine.

23. At the very least, this provides many enhancements to the conventional system development life-cycle Such as …

24. Convenient GUI-based method for specifying desired behavior Ability to execute requirements (actually, executable use cases) A deep kind of rapid prototyping and more solid starting point for design Rich language for test generation; execution- based testing (much work done on this in W. Damms group) Strong basis for synthesis and verification (both groups) and more...

25. But one can be more ambitious, and actually use LSCs as the language for programming (and running) the system!

26. Come, Let s Play: Scenario-Based Programming Using LSCs and the Play-Engine D. Harel and R. Marelly Springer, June 2003 (includes the Play-Engine software) 2003 book attempts to describe it all (including formal semantics: )

27. The problem with naïve play-out LSCs are inherently declarative and non- deterministic: They may give rise to different legal runs, even within supersteps, due to partial order within a chart, and multiple charts interleaving. The Play-Engine takes a practical approach: implements policies and heuristics to execute system runs, not controllable by the user (unless programmed explicitly into the LSCs).

28. This talk: Three unusual ways to address this problem (using, respectively, hard-core CS, AI techniques, and a very different programming paradigm) Smart play-out (uses model-checking) Planned play-out (uses planning algorithms) Compilation (uses aspect-oriented programming)

29. I. Smart Play-out (with H. Kugler, A. Pnueli & R. Marelly, 02) We apply powerful methods taken from program verification (model checking, to be precise) to help find the correct run or identify inconsistencies So we use verification, but not to prove or analyze programs. We use it to run them!

30. The approach (all carried out on the fly, oblivious to the user) Formulate the question of whether there is a non-violating superstep as a verification problem Perform model-checking. Feed the super-step produced by the model- checker into the Play-Engine for execution.

31. Mapping to a transition system Variables: - chart m i is active (in main chart) - O j sends msg to O k - O k receives msg from O j - O j s location (0... l max )

32. Translation relation

33. Translation relation (cont.) There is an active chart causing msg, and all active charts must agree on msg

34. Chart activation Chart is active when the prechart reaches maximal locations, and is deactivated when the main chart reaches maximal locations.

35. Final step Ask the model checker to prove that at any time, at least one of the universal charts is still active: If this is true, there is no way to proceed, but if it isnt the model-checker finds a counter- example, which is exactly a desired superstep! The resulting sequence of events is then fed automatically to the Play-Engine for execution

36. A wonderful illustration of smart play-out

37. Being smart helps

38. II. Compilation via Aspects (with S. Maoz, 06) We exploit the similarities between aspect- oriented programming and the inter-object nature of LSCs, by compiling LSCs into AspectJ Scenario aspects are used to coordinate the simultaneous monitoring and direct execution of the LSCs.

39. Each chart is compiled into a Scenario Aspect –Pointcuts capture message calls + context –Corresponding advice advances the cut state A central Coordinator aspect is built, containing –A single pointcut to catch all message calls –An advice that collects cut state information from all active scenarios, and uses a strategy to choose the next method to execute

40. Actually, our compiler does not work on LSCs, but on a UML 2.0-complient variant, called MUSDs (H & Maoz, 06) The resulting code follows the naïve play- out execution strategy, but we are working on a mechanism for parameterizing strategies

41. public aspect MUSDAspectExample extends MUSDAspect { //... pointcut objAobjBmethodM1 (ClassA s, ClassB t): call(void classB.methodM1()) && this(s) && target(t); after (ClassA s, ClassB t): objAobjB1methodM1(s, t) { changeCutState(MUSDMethod.CLASSA_CLASSB_M1, s, t);} //... private void changeCutState (int MUSDMethod, Object sourceObject, Object targetObject) { //... switch (MUSDMethod) { case MUSDMethod.CLASSA_CLASSB_M1: if (isInCut(0,0,0)) { objB1 = (ClassB)targetObject; setCut(1,0,1); return; } if (isInCut(1,0,1)) { objB2 = (MemoryCard)targetObject; setCut(1,1,2); if (!objB1.isFoo(objB2)) { setCut(2,2,3); return; } break; case MUSDMethod.CLASSA_CLASSB_M2 : //... } MUSDCompletion(); //... } //... } objA:ClassA Example objB1:ClassBobjB2:ClassB methodM1() methodM2() methodM3() !objB1.isFoo(objB2)) Sample scenario aspect

42. Compilation to AspectJ

43. We adapt a planning algorithm (specifically, Graphplan) to do what smart play-out does; e.g., to plan and execute a superstep However, here we are able to detect and generate all solutions, if so desired. Weve also set-up a user-guided exploration mechanism for traversing supersteps III. Planned Play-out (with I. Segall, 06) (ack: Orna K.)

44. Planning graph Move (R1, R2) Insert (B, R1) Insert (A, R1)At (A, R1) At (B, R1) At (Bag, R1) In (A) In (B) At (Bag, R2) At (A, R1) At (B, R1) At (Bag, R1) Propositions Time 1 Actions Time 1 Propositions time 2 Actions Time 2 Propositions time 3 Actions Time 3 Propositions time 4 Move (R1, R2) Insert (B, R1) Insert (A, R1) At (A, R1) At (B, R1) At (Bag, R1) In (A) In (B) At (Bag, R2) Remove (B, R2) Remove (A, R2) At (A, R2) At (B, R2) In (A) In (B) Proposition LevelsAction LevelsPropositions True at time 1Possible actions at time 1Precondition edgesAdd edgesDelete edges No-op edges Result: Propositions possibly true at time 2

45. Mutual exclusions Mutex Actions: never chosen together in a timestep Mutex Propositions: never true together in a timestep

46. Mutex example Move (R1, R2) Insert (B, R1) Insert (A, R1) At (A, R1) At (B, R1) At (Bag, R1) In (A) In (B) At (Bag, R2) At (A, R1) At (B, R1) At (Bag, R1) Move (R1, R2) Insert (B, R1) Insert (A, R1) At (A, R1) At (B, R1) At (Bag, R1) In (A) In (B) At (Bag, R2) Remove (B, R2) Remove (A, R2) At (A, R2) At (B, R2) In (A) In (B) Propositions Time 1 Actions Time 1 Propositions time 2 Actions Time 2 Propositions time 3 Actions Time 3 Propositions time 4 Interference AInterference BMutex PropositionsCompeting Needs

47. Plan extraction Move (R1, R2) Insert (B, R1) Insert (A, R1) At (A, R1) At (B, R1) At (Bag, R1) In (A) In (B) At (Bag, R2) At (A, R1) At (B, R1) At (Bag, R1) Move (R1, R2) Insert (B, R1) Insert (A, R1) At (A, R1) At (B, R1) At (Bag, R1) In (A) In (B) At (Bag, R2) Remove (B, R2) Remove (A, R2) At (A, R2) At (B, R2) In (A) In (B) Propositions Time 1 Actions Time 1 Propositions time 2 Actions Time 2 Propositions time 3 Actions Time 3 Propositions time 4

48. Planned play-out

49. naïvesmart LSC feature naïve play-out compilation to AspectJ smart play-out planned play-out Execution strategy Kernel (msgs + conds) - variables in msgs - if, choice, etc. - loops - multiple copies - symbolic instances - time (discrete) - forbidden elements - probabilistic choice hard hard not bounded Status of current Play-Engine implementation easy easy ++

50. The two smart methods exhibit rather severe time complexity My feeling: some powerful idea, awaiting discovery, is needed to help ease performance

51. Which of the methods will turn out to be best? And what does best even mean? The jury is still far from being in. Stay tuned …

52. Thank you for listening