1 / 16

The Timeline formalism

The Timeline formalism. A visual formalism for expressing temporal constraints Eric Bodden. History . Developed by Smith, Holzmann , Etessami (Bell Labs) in 2001 Goal: to ease the specification of temporal patterns Have the visual spec translated into a low level spec which can be verified.

harlow
Download Presentation

The Timeline formalism

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. The Timeline formalism A visual formalism for expressing temporal constraints Eric Bodden

  2. History • Developed by Smith, Holzmann, Etessami (Bell Labs) in 2001 • Goal: to ease the specification of temporal patterns • Have the visual spec translated into a low level spec which can be verified. => Model transformation!

  3. Problems with current LTL • Example:When the phone goes offhook, a dialtone should occur. • In LTL: !( !offhook U(offhook /\ X[](!dialtone /\ !onhook)) ) • Already hard to read. But it comes worth…

  4. Requirements change! • Assume, an event i should be added in between offhook and response • Requires another nesting of Until formulae: X((eventi /\ !onhook) U (eventi /\ !onhook)) • Huge formulae, hard to understand.

  5. Solution • Circumvent awkward LTL syntax and use timeline notation instead

  6. Events • A timeline consists of a sequence of the events of the following types • Regular events – e – may occur • Required events – r – must occur • Fail events – X – must not occur

  7. Semantics • Fail events or required events must (not) happen depending on the context, i.e. on the events that have been seen before.

  8. Constraints • Express that certain intermediate events can weaken the requirement. • Drawn as horizontal bars. • Can include or exclude start/end.

  9. Scalability – adding an event

  10. Compositionality Notion of sub-requirements

  11. Operational semantics • Given by translation into Büchi automata (special FSM) • The automata reports an error if and only if it remains in an accepting state indefinitely.

  12. Example with constraints

  13. Fail events

  14. Statistics • Specified 177 requirements • Average: 4 to 5 events and 2 to 3 constraints • Most complex one: 11 events and 7 constraints • 38% required events, remainder of events provides context

  15. Availability • Timeedit tool for Windows and Unix • Visual tool, generates Büchi automata and SPIN never claims http://www.bell-labs.com/topic/swdist/

  16. Reading Margaret H. Smith, Gerard J. Holzmann, Kousha Etessami Events and Constraints: A Graphical Editor for Capturing Logic Requirements of Programs Proceedings of the 5th IEEE International Symposium on Requirements Engineering table of contents Pages: 14 - 22 Year of Publication: 2001

More Related