1 / 27

Specifying and executing behavioral requirements

This paper introduces the Play-In/Play-Out methodology for specifying behavioral requirements in software development, presented by David Harel and Rami Marelly from the Weizmann Institute of Science. The approach addresses the challenges of traditional requirements specification, which often involves tedious and error-prone manual mappings from informal use cases to formal specifications. By employing a prototype tool that utilizes Live Sequence Charts (LSCs), the Play-In/Play-Out method fosters a more intuitive and automated way to capture, verify, and communicate requirements—ultimately bridging the gap between high-level specifications and actual implementation.

emmy
Download Presentation

Specifying and executing behavioral requirements

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. Specifying and executing behavioral requirements The play-in/play-out approach David Harel, Rami MarellyWeizmann 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-out Play-in

  5. Workflow • Prototype a GUI or object model of you app. – dummy only! • Play-in behavior into this prototype. “Play engine” connects and automatically generates Live Sequence Charts • Replay (play-out) behavior, modify and generalize; verify • 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.

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

  10. Specifying the pre-chart

  11. .. and the body

  12. Final result

  13. Another one – show number

  14. A test case (existential LSC)

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

  16. Play-out by example 3 4 5 + 1 2

  17. Situation after hit on plus

  18. Situation at the end

  19. … watch the test case!

  20. Replaying recorded violations

  21. Playing in internal objects

  22. … and playing them out.

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

  24. Life cycle of a “live copy”

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

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

More Related