abstractions. outline informal intuition why do we need abstraction? what is an abstraction and what...
Post on 19-Dec-2015
219 views
TRANSCRIPT
Abstractions
Outline
Informal intuition Why do we need abstraction? What is an abstraction and what is
not an abstraction A framework for abstractions Commonly used abstractions
Limitations of model checking
Finite state technique Cannot deal with general data
integers, lists, etc. unbounded message queues
Cannot deal with parameterized systems Suffers from state explosion
Concurrency Data domains
Abstraction
Represent the program using a smaller model.
Pay attention to preserving the checked properties.
Do not affect the flow of control.
Example
Use smaller data objects.
X:= f(m)Y:=g(n)if X*Y>0 then … else …X, Y never used again.
How to abstract?
Assign values {-1, 0, 1} to X and Y. Based on the following connection:
sgn(X) = 1 if X>0, 0 if X=0, and -1 if X<0.sgn(X)*sgn(Y)=sgn(X*Y).
Change f and g to produce abstract values for X and Y
Abstraction vs. simplification
Not every simplified system is an abstraction
The key question is: If we prove or disprove a property of
the simplified system, what have we learned about the original system?
Example False positive
Can sender overwrite a value?
True in the simplified system, false in original
False negative Can receiver deadlock? False in the simplified
system, true in the original
sendreceivenot empty
empty
...
receivesend
Precise abstractions
Accept neither false positives nor false negatives
Minimizations up to an equivalence
Elimination of unreachable states Very restrictive!
a a
a a a...
...
Precise abstractions
int i = 0while i < 2 do i = i + 1
Replace integer type with enumerated type {0,1,2}
Requires a deductive step With “on-the-fly” model
construction, this abstraction is free – but may not terminate if you “miss”
Over-approximations Throw in more behaviors Also called conservative approximations Accept false positives but not false
negatives If the property proved in the abstract
system, it also holds in the concrete system If the property fails in the abstract system,
may or may not fail in the concrete system
Abstraction w.r.t. properties
A conservative approximation is always with respect to a set of properties If your set of properties is closed under
negation, you have precise abstraction Why?
Commonly used sets of properties: Reachability, safety ACTL
Abstract LTL verification
Concrete correctness condition: L(ConcreteModel) L(Spec)
Over-approximation: L(ConcreteModel) L(AbstractModel)
Abstract correctness condition: L(AbstractModel) L(Spec)
Implies concrete correctness condition!
What is a good abstraction?
We want an abstraction that is as compact as possible, but preserves the properties we are interested in
An abstraction that is “too loose” is not useful: too many false alarms
Conservative analysis Iterative process of model checking and
abstraction refinement Verification is now semi-decidable!
concretemodel
abstractmodel
verify
counterexample
pass
fake
real
fail
abstract
fixmodel
refineabstraction
concrete model ok
Under-approximations
Is under-approximation a useful abstraction technique? Yes, but not as common
Testing Abstract the set of executions to the
(equivalence class of) tested executions
Found a bug – it is real! There is always one more bug…
Abstract interpretation
A framework for abstraction P. Cousot and R. Cousot (1977-2002) NOT constructive
Offers means of proving an abstraction Does not help finding an abstraction
Mathematically captured as Galois connections
Galois connections
A and C are partially ordered sets α is the abstraction function γ is the concretization function
Always an over-approximation:
,, AC
)()(:, yxyxAyCx
)(xx
Classical example
Abstract sets of integers as intervals C: Sets of integers ordered by inclusion A: Intervals with integer boundaries
[i1,i2] (i1≤i2) ordered by “lies within” relation
α : Set M [min(M),max(M)] γ : [i1,i2] {i1,i1+1,…,i2}
{1,4,5}
{1,2,3,4,5}[1,5]C A
α
γ
∩
Fixpoint abstraction In behavioral models, concrete and
abstract domains are often sets of states Most analysis algorithms involve fixpoint
computation We want to compute abstract fixpoints
and make concrete conclusions C and A are complete lattices F is a monotonic function on C Abstract fixpoint is an overapproximation
FF lfp) lfp(
State-to-state abstraction
Partition concrete states into disjoint sets
Map sets of states to abstract states α: s[s]
Initial abstract states: an abstract state contains a concrete initial state
Abstract transition: st implies [s][t]
go
stop
stop
go
stop
Example Map “yellow”
and “red” to “stop”
Map “green” to “go”
Transitions: gostop stopgo stopstop
What do we preserve?
go
stop
stop
go
stop
Every execution of the full model can be simulated by an execution of the reduced one.
Every LTL property that holds in the reduced model hold in the full one.
Properties
Preserved:[](go->O stop)
Not preserved:[]<>go
go
stop
stop
go
stop
Predicate abstraction
The concrete state space is partitioned according to a set of predicates.
Example:
Is the right state reachable? Predicates: x<5,x==5
x==5
x<5x=x+2
x=0
Predicate abstraction
Predicates define partitioning of the state space
Add transitions according to predicates
Property fails!
ff tt
ft tf
x==5
x<5x=x+2
x=0
Predicate abstraction
Counterexample is fake!
Refine abstraction: add predicates
New predicate: x is even
Property is true!
fft
ftt tft
fff
ftf tff
Symmetry A permutation is a one-one and onto
function p:A->A.For example, 1->3, 2->4, 3->1, 4->5, 5->2.
One can combine permutations, e.g.,p1: 1->3, 2->1, 3->2p2: 1->2, 2->1, 3->3p1@p2: 1->3, 2->2, 3->1
A set of permutations with @ is called a symmetry group.
Using symmetry in analysis
Want to find some symmetry group suchthat for each permutation p in it,R(s,t) if and only if R(p(s), p(t))and L(p(s))=L(s).
Let K(s) be all the states that can be permuted to s. This is a set of states such that each one can be permuted to the other.
Turn=0L0,L1
Turn=0L0,NC1
Turn=0NC0,L1
Turn=0CR0,NC1
Turn=0NC0,NC1
Turn=0CR0,L1
Turn=1L0,CR1
Turn=1NC0,CR1
Turn=1L0,NC1
Turn=1NC0,NC1
Turn=1NC0,L1
Turn=1L0,L1
init
Turn=0L0,L1
Turn=0L0,NC1
Turn=0NC0,L1
Turn=0CR0,NC1
Turn=0NC0,NC1
Turn=0CR0,L1
init
The quotient model
Partial order reduction
With independent transitions, you do not have to explore all transitions to prove a property