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

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

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?

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

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

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.

An example – quick dialing

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.

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

Specifying the pre-chart

.. and the body

Final result

Another one – show number

A test case (existential LSC)

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)

Play-out by example

Situation after hit on plus

Situation at the end

… watch the test case!

Replaying recorded violations

Playing in internal objects

… and playing them out.

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

Life cycle of a “live copy”

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

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