abstractions. outline informal intuition why do we need abstraction? what is an abstraction and what...

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