1. Specifying and executing behavioral requirements The play-in/play-out approach David Harel, Rami Marelly Weizmann Institute of Science, Israel An interpretation by Eric Bodden

2. Outline  Problem statement: How to specify requirements? Easily and Consistently  Background (LSCs)  Play-in  Play-out  Prototype tool, challenges  Conclusion

3. Requirements specification  Usually start from informal use case specification by domain experts  Then manual mapping to formal spec Error prone Tedious  No direct link between original spec and the actual implementation!  Can we do any better?

4. Play-in / play-out  Has similarities to machine learning and…  Actually also to the way one teaches people! Philosophy: “I’ll show you how it works and then you try yourself! Play-in Play-out

5. Workflow 1.Prototype a GUI or object model of you app. – dummy only! 2.Play-in behavior into this prototype. “Play engine” connects and automatically generates Live Sequence Charts 3.Replay (play-out) behavior, modify and generalize; verify 4.Give the debugged spec to developers

6. Live Sequence Charts (LSCs)  Similar to Message Sequence Charts and Sequence Diagrams but more powerful…  Universal charts: Specify behavior w.r.t. a given “prechart” (preamble).  Existential charts: Specify test cases that must hold in the universal LSCs.

7. An example – quick dialing

8. The play engine  Backend which communicates with the prototype via Microsoft’s Component Object Model (COM)  Generates LSCs in play-in mode  Can then be generalized / modified  Are verified in play-out mode.  Also: Recording, modification and replay of traces.

10. Play-in – an example n1 “+” n2 “=” (n1+n2) Pre-chart Body

11. Specifying the pre-chart

12. .. and the body

13. Final result

14. Another one – show number

15. A test case (existential LSC)

16. Play-out “Now that I have shown you how it works, try on your own!” (and I will watch you meanwhile and record what goes wrong)

17. Play-out by example 345+12345+12

18. Situation after hit on plus

19. Situation at the end

20. … watch the test case!

21. Replaying recorded violations

22. Playing in internal objects

23. … and playing them out.

24. How does it work  “Execution manager” schedules “live copies” of universal LSCs -> behavior  At the same times evaluates existential LSCs -> testing  “Run manager” records/replays traces

25. Life cycle of a “live copy”

26. Challenges and problems  Need for symbolic evaluation  Nondeterminism (?) SELECT function  Scalability (?)  Performance (?)  Deadlocks/livelocks (?)  Support for multiple platforms (?)

27. Conclusion  Easy way to derive a “debugged” requirements specification.  Immediate link between use cases, specs and implementation.  Performance and scalability issues not discussed.