1 / 22

Raising the Level of Abstraction with Partial Models: A Vision

Raising the Level of Abstraction with Partial Models: A Vision. Arie Gurfinkel (SEI/CMU) with Marsha Chechik (Univ. of Toronto) Shoham Ben-David (Univ. of Toronto), Sebastian Uchitel (Univ. of Buenos Aires and Imperial College London). Requirements Design. Position.

hart
Download Presentation

Raising the Level of Abstraction with Partial Models: A Vision

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. Raising the Level of Abstraction with Partial Models: A Vision Arie Gurfinkel (SEI/CMU) with Marsha Chechik (Univ. of Toronto) Shoham Ben-David (Univ. of Toronto), Sebastian Uchitel (Univ. of Buenos Aires and Imperial College London)

  2. Requirements Design Position Add information Synthesis and merge analysis counterexamples, animation Partial Behaviour Models (e.g., MTSs) The keys to Usable Verification are abstraction (i.e., raising the level of abstraction as the software is designed) and automation (i.e., creating automated and scalable tools for reasoning about such software at the highest level of abstraction possible).

  3. Handling Incompleteness • Abstract models are incomplete • Must be able to specify and reason with incomplete models! • validation with respect to temporal properties using automated theorem provers and model-checkers … • …including properties for which the model is too incomplete for an exact Yes/No answer • refinement – integration of new information such as additional behavior and/or increasing vocabulary • Refinement must preserve properties established at a higher level of abstraction • merge – combining information from multiple sources • e.g., integrating (possibly conflicting) viewpoints of different stakeholders • operationalization – ability to simulate, test, and execute a model

  4. Handling inconsistency • Early in design life-cycle, models from multiple stakeholders and/or emerging from different sources are often inconsistent • Must be able to reason about and with inconsistency • identification – identify inconsistency and its sources • resolution – computer aided negotiation for resolving inconsistency • toleration – do not let inconsistency to trivialize the entire logical inference

  5. Moving from declarative to operational specifications (and back) • Code generation – produce running code • traceability to use original model for debugging and maintenance • Synthesis – generate models from high level specifications • Validation using simulation, testing, and model-checking

  6. Related Approaches • There are many related approaches including … • … traditional iterative refinement methods (e.g., B method) • … hardware synthesis from temporal logic specifications • … Model Driven Development • … Model Driven Architecture • … • Our Approach: Partial Behavioral Models • explicitly capture and reason about incompleteness (missing information) • explicitly model non-determinism (what environment can do) and incompleteness (what can be further specified) • operational models that support model-checking, simulation, and testing • synthesis of operational model from scenarios (lower bounds) and properties (upper bounds)

  7. Outline • Position • Related Work • Our Work • Modal Transition Systems (MTS) • Refinement • Analysis • Synthesis • Merge • Challenges

  8. Scenarios/Use Cases(i.e. Existential assertions) Describe what we want Provide a lower bound to system behaviour Properties/Requirements/Goals(i.e. Universal assertions) Describe what we don’t want Provide an upper bound to system behaviour Partial Models: Complementary Approaches

  9. Partial Models: reasoning about what we do not know? ? What is the behaviour that is between the upper and lower bounds? What is the behaviour that has not been explicitly described through use cases and scenarios that has not been prohibited by properties? Can we explore it? Can we say anything interesting even though we have these holes?

  10. request? Modal Transition Systems (MTS) - Larsen et. al. 1988 - • Extension of Labelled Transition Systems (LTSs): • Required transitions • Possible transitions • They describe • Explicitly what we do not know • Implicitly what we prohibit request reply Green = required behaviour Yellow = possible behaviour Red = the rest

  11. request request request reply? request? request reply reply reply [Huth 05’] [FSE04] Semantics of MTS • An MTS defines a set of LTS (or admissible implementations) • An LTS is an implementation of an MTS if • it preserves the required behaviour • and does not introduce prohibited behaviour • Definition: L is an implementation of M iff • L simulates Mreq • Mpos+req simulates L request request Implementations (LTS) reply reply request request Is implemented by reply reply

  12. request reply request request request request request? reply? request? reply reply reply reply MTS Refinement • Intuition: “has more information than” • Formally: inclusion of implementations - request? reply? Refinement + LTS

  13. MTS Analysis • How do we analyse a (potentially infinite) set of implementations? • Thorough semantics: Given a property P, M ⊧ P means: • True: All implementations of M satisfy P • False: No implementations of M satisfy P • Maybe: otherwise. • Efficient model checking procedures and approximations • exist for some logics LTS

  14. Merge Synthesis from heterogeneous specifications Synthesised MTSs Properties Scenario Refinements Refinements [FSE’04] [FM’06] [FSE’08]

  15. MTS Merging • Merging MTS resulting from... • Heterogeneous notations • Multiple stakeholders

  16. Tool Support: MTSA • Synthesis (Process Algebra, Scenarios, Properties) • FLTL Model Checking • Animation • Composition • Parallel • Merge • Others • Minimisation • Hiding • Determinisation • http://lafhis.dc.uba.ar/~suchitel/MTSA.html

  17. Outline • Position • Related Work • Our Work • Modal Transition Systems (MTS) • Refinement • Analysis • Synthesis • Merge • Challenges

  18. Challenge 1: “Green Field” Approach I’m a practitioner - get me out of here! Models !

  19. Challenge 2: Supporting Inconsistency • MTSs DO NOT allow analysis in the presence of inconsistency! • but MTSs can be used to detect inconsistency, facilitate negotiation, … • Alternative: Multi-Valued Kripke Structures [TOSEM 2003] • reasoning with inconsistency • temporal logics • model checking algorithms • Is there a Multi-Valued version of MTS?!

  20. Challenge 3: Complexity • Are MTSs the right formalism? • not closed under merge (no unique least common refinement) • alternatives: Disjunctive MTSs, Mix TSs, Tree Automata, … • (thorough) model checking and consistency checking are EXPTIME-complete • approximation techniques (e.g., 3-valued inductive semantics) • MTSs are too expressive! • support arbitrary branching properties • BUT, in case studies, properties are (almost) linear: • Linear (Fluent LTL), or • For all P, Exists Q (Use Cases) • Current Work: Is there an alternative to MTSs that captures “linear” semantics with lower complexity?!

  21. Requirements Design Conclusions Add information Synthesis and merge analysis counterexamples, animation Partial Behaviour Models (e.g. MTS) Partial behaviour models are the foundations for techniques and tools to develop support for the iterative construction and elaboration of behaviour models

  22. THE END

More Related