Raising the Level of Abstraction with Partial Models: A Vision
description
Transcript of Raising the Level of Abstraction with Partial Models: A Vision
© 2010 Carnegie Mellon University
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
Raising The Level of Abstraction with Partial Models: A VisionChechik, Gurfinkel, Ben-David, Uchitel© 2010 Carnegie Mellon University
Position
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).
Requirements Design
counterexamples,
animation
analysis
Synthesis and merge
Add informati
on
Partial Behaviour Models (e.g., MTSs)
3
Raising The Level of Abstraction with Partial Models: A VisionChechik, Gurfinkel, Ben-David, Uchitel© 2010 Carnegie Mellon University
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
Raising The Level of Abstraction with Partial Models: A VisionChechik, Gurfinkel, Ben-David, Uchitel© 2010 Carnegie Mellon University
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
Raising The Level of Abstraction with Partial Models: A VisionChechik, Gurfinkel, Ben-David, Uchitel© 2010 Carnegie Mellon University
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
Raising The Level of Abstraction with Partial Models: A VisionChechik, Gurfinkel, Ben-David, Uchitel© 2010 Carnegie Mellon University
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
Raising The Level of Abstraction with Partial Models: A VisionChechik, Gurfinkel, Ben-David, Uchitel© 2010 Carnegie Mellon University
Outline
Position
Related Work
Our Work•Modal Transition Systems (MTS)•Refinement•Analysis•Synthesis•Merge
Challenges
8
Raising The Level of Abstraction with Partial Models: A VisionChechik, Gurfinkel, Ben-David, Uchitel© 2010 Carnegie Mellon University
Partial Models: Complementary Approaches
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
9
Raising The Level of Abstraction with Partial Models: A VisionChechik, Gurfinkel, Ben-David, Uchitel© 2010 Carnegie Mellon University
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
Raising The Level of Abstraction with Partial Models: A VisionChechik, Gurfinkel, Ben-David, Uchitel© 2010 Carnegie Mellon University
Modal Transition Systems (MTS)
Extension of Labelled Transition Systems (LTSs):•Required transitions•Possible transitions
They describe•Explicitly what we do not know• Implicitly what we prohibit
request?
request
reply
- Larsen et. al. 1988 -
Green = required behaviourYellow = possible behaviour
Red = the rest
11
Raising The Level of Abstraction with Partial Models: A VisionChechik, Gurfinkel, Ben-David, Uchitel© 2010 Carnegie Mellon University
Implementations (LTS)
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
request
reply
request
request
reply
request
reply
request
reply
reply? request?
request
reply
[Huth 05’] [FSE04]
Is implemented byreply
requestrequest
reply
Definition: L is an implementation of M iff • L simulates Mreq
• Mpos+req simulates L
12
Raising The Level of Abstraction with Partial Models: A VisionChechik, Gurfinkel, Ben-David, Uchitel© 2010 Carnegie Mellon University
request?request
reply
reply? request?
request
reply
MTS RefinementIntuition: “has more information than”Formally: inclusion of implementations
request?reply?
Refin
emen
t+
-
request
reply
request
requestreply
reply
LTS
13
Raising The Level of Abstraction with Partial Models: A VisionChechik, Gurfinkel, Ben-David, Uchitel© 2010 Carnegie Mellon University
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
13
LTS
14
Raising The Level of Abstraction with Partial Models: A VisionChechik, Gurfinkel, Ben-David, Uchitel© 2010 Carnegie Mellon University
Synthesis from heterogeneous specifications
14
Synthesised MTSs
Refinements
Scenario
Refinements
Merge
Properties
[FSE’04][FM’06][FSE’08]
15
Raising The Level of Abstraction with Partial Models: A VisionChechik, Gurfinkel, Ben-David, Uchitel© 2010 Carnegie Mellon University
MTS Merging
Merging MTS resulting from...•Heterogeneous notations•Multiple stakeholders
16
Raising The Level of Abstraction with Partial Models: A VisionChechik, Gurfinkel, Ben-David, Uchitel© 2010 Carnegie Mellon University
Tool Support: MTSA
Synthesis (Process Algebra, Scenarios, Properties)FLTL Model CheckingAnimationComposition•Parallel •Merge
Others•Minimisation•Hiding•Determinisation
http://lafhis.dc.uba.ar/~suchitel/MTSA.html
17
Raising The Level of Abstraction with Partial Models: A VisionChechik, Gurfinkel, Ben-David, Uchitel© 2010 Carnegie Mellon University
Outline
Position
Related Work
Our Work•Modal Transition Systems (MTS)•Refinement•Analysis•Synthesis•Merge
Challenges
18
Raising The Level of Abstraction with Partial Models: A VisionChechik, Gurfinkel, Ben-David, Uchitel© 2010 Carnegie Mellon University
Challenge 1: “Green Field” Approach
I’m a practitioner - get me out of here! Models !
19
Raising The Level of Abstraction with Partial Models: A VisionChechik, Gurfinkel, Ben-David, Uchitel© 2010 Carnegie Mellon University
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
Raising The Level of Abstraction with Partial Models: A VisionChechik, Gurfinkel, Ben-David, Uchitel© 2010 Carnegie Mellon University
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
Raising The Level of Abstraction with Partial Models: A VisionChechik, Gurfinkel, Ben-David, Uchitel© 2010 Carnegie Mellon University
Conclusions
Partial behaviour models are the foundations for techniques and tools to develop support for the iterative construction and elaboration of behaviour models
Requirements Design
counterexamples,
animation
analysis
Synthesis and merge
Add informati
on
Partial Behaviour Models (e.g. MTS)
© 2010 Carnegie Mellon University
THE END