Model checking
Download
1 / 269

Model Checking - PowerPoint PPT Presentation


  • 69 Views
  • Uploaded on

Model Checking. Doron A. Peled University of Warwick Coventry, UK [email protected] Modelling and specification for verification and validation. How to specify what the software is supposed to do? How to model it in a way that allows us to check it?. Sequential systems.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Model Checking' - lyris


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Model checking

Model Checking

Doron A. Peled

University of Warwick

Coventry, UK

[email protected]


Modelling and specification for verification and validation
Modelling and specification for verification and validation

  • How to specify what the software is supposed to do?

  • How to model it in a way that allows us to check it?


Sequential systems
Sequential systems.

  • Perform some computational task.

  • Have some initial condition, e.g.,0in A[i] integer.

  • Have some final assertion, e.g.,0in-1 A[i]A[i+1].(What is the problem with this spec?)

  • Are supposed to terminate.


Concurrent systems
Concurrent Systems

Involve several computation agents.

Termination may indicate an abnormal event (interrupt, strike).

May exploit diverse computational power.

May involve remote components.

May interact with users (Reactive).

May involve hardware components (Embedded).


Problems in modeling systems
Problems in modeling systems

  • Representing concurrency:- Allow one transition at a time, or- Allow coinciding transitions.

  • Granularity of transitions.

    • Assignments and checks?

    • Application of methods?

  • Global (all the system) or local (one thread at a time) states.


Modeling the states based model
Modeling.The states based model.

  • V={v0,v1,v2, …} - set of variables.

  • p(v0, v1, …, vn) - a parametrized assertion, e.g., v0=v1+v2 /\ v3>v4.

  • A state is an assignment of values to the program variables. For example: s=<v0=1,v2=3,v3=7,…,v18=2>

  • For predicate (first order assertion) p:p (s ) is p under the assignment s.Example: p is x>y /\ y>z. s=<x=4, y=3, z=5>.Then we have 4>3 /\ 3>5, which is false.


State space
State space

  • The state space of a program is the set of all possible states for it.

  • For example, if V={a, b, c} and the variables are over the naturals, then the state space includes: <a=0,b=0,c=0>,<a=1,b=0,c=0>,<a=1,b=1,c=0>,<a=932,b=5609,c=6658>…


Atomic transitions
Atomic Transitions

  • Each atomic transition represents a small piece of code such that no smaller piece of code is observable.

  • Is a:=a+1 atomic?

  • In some systems, e.g., when a is a register and the transition is executed using an inccommand.


Non atomicity

Execute the following when x=0 in two concurrent processes:

P1:a=a+1

P2:a=a+1

Result: a=2.

Is this always the case?

Consider the actual translation:

P1:load R1,a

inc R1

store R1,a

P2:load R2,a

inc R2

store R2,a

a may be also 1.

Non atomicity


Scenario

P1:load R1,a

inc R1

store R1,a

Scenario

P2:load R2,a

inc R2

store R2,a

a=0

R1=0

R2=0

R1=1

R2=1

a=1

a=1


Representing transitions
Representing transitions

  • Each transition has two parts:

    • The enabling condition: a predicate.

    • The transformation: a multiple assignment.

  • For example:a>b  (c,d):=(d,c)This transition can be executed in states where a>b. The result of executing it isswitching the value of c with d.


Initial condition
Initial condition

  • A predicate I.

  • The program can start from states s such that I (s ) holds.

  • For example:I (s )=a>b /\ b>c.


A transition system
A transition system

  • A (finite) set of variables V over some domain.

  • A set of states S.

  • A (finite) set of transitions T, each transition et has

    • an enabling condition e, and

    • a transformation t.

  • An initial condition I.


Example
Example

  • V={a, b, c, d, e}.

  • S: all assignments of natural numbers for variables in V.

  • T={c>0(c,e):=(c-1,e+1), d>0(d,e):=(d-1,e+1)}

  • I : c=a /\ d=b /\ e=0

  • What does this transition system do?


The interleaving model
The interleaving model

  • An execution is a finite or infinite sequence of states s0, s1, s2, …

  • The initial state satisfies the initial condition, I.e., I (s0).

  • Moving from one state si to si+1 is by executing a transition et:

    • E (si ), I.e., sisatisfies e.

    • si+1 is obtained by applying t to si.


Example1
Example:

  • s0=<a=2, b=1, c=2, d=1, e=0>

  • s1=<a=2, b=1, c=1, d=1, e=1>

  • s2=<a=2, b=1, c=1, d=0, e=2>

  • s3=<a=2, b=1 ,c=0, d=0, e=3>

T={c>0(c,e):=(c-1,e+1), d>0(d,e):=(d-1,e+1)}

I: c=a /\ d=b /\ e=0


L0:While True do

NC0:wait(Turn=0);

CR0:Turn=1

endwhile ||

L1:While True do

NC1:wait(Turn=1);

CR1:Turn=0

endwhile

T0:PC0=L0PC0:=NC0

T1:PC0=NC0/\Turn=0

PC0:=CR0

T2:PC0=CR0

(PC0,Turn):=(L0,1)

T3:PC1=L1PC1=NC1

T4:PC1=NC1/\Turn=1

PC1:=CR1

T5:PC1=CR1

(PC1,Turn):=(L1,0)

The transitions

Initially: PC0=L0/\PC1=L1


The state graph successor relation between states

Turn=1

L0,L1

Turn=0

L0,L1

Turn=0

L0,NC1

Turn=0

NC0,L1

Turn=1

L0,NC1

Turn=1

NC0,L1

Turn=0

NC0,NC1

Turn=0

CR0,L1

Turn=1

L0,CR1

Turn=1

NC0,NC1

Turn=0

CR0,NC1

Turn=1

NC0,CR1

The state graph:Successor relation between states.


Some observations
Some observations

  • Executions : the set of maximal paths (finite or terminating in a node where nothing is enabled).

  • Nondeterministic choice : when more than a single transition is enabled at a given state. We have a nondeterministic choice when at least one node at the state graph has more than one successor.


Always pc0 cr0 pc1 cr1 mutual exclusion

Turn=0

L0,L1

Turn=1

L0,L1

Turn=0

L0,NC1

Turn=0

NC0,L1

Turn=1

L0,NC1

Turn=1

NC0,L1

Turn=0

NC0,NC1

Turn=0

CR0,L1

Turn=1

L0,CR1

Turn=1

NC0,NC1

Turn=0

CR0,NC1

Turn=1

NC0,CR1

Always ¬(PC0=CR0/\PC1=CR1)(Mutual exclusion)


Always if turn 0 the at some point turn 1

Turn=0

L0,L1

Turn=1

L0,L1

Turn=0

L0,NC1

Turn=0

NC0,L1

Turn=1

L0,NC1

Turn=1

NC0,L1

Turn=0

NC0,NC1

Turn=0

CR0,L1

Turn=1

L0,CR1

Turn=1

NC0,NC1

Turn=0

CR0,NC1

Turn=1

NC0,CR1

Always if Turn=0 the at some point Turn=1


Always if turn 0 the at some point turn 11

Turn=0

L0,L1

Turn=1

L0,L1

Turn=0

L0,NC1

Turn=0

NC0,L1

Turn=1

L0,NC1

Turn=1

NC0,L1

Turn=0

NC0,NC1

Turn=0

CR0,L1

Turn=1

L0,CR1

Turn=1

NC0,NC1

Turn=0

CR0,NC1

Turn=1

NC0,CR1

Always if Turn=0 the at some point Turn=1


Interleaving semantics execute one transition at a time

Turn=0

L0,L1

Turn=0

L0,NC1

Turn=1

L0,NC1

Turn=0

NC0,NC1

Turn=1

L0,CR1

Turn=0

CR0,NC1

Interleaving semantics:Execute one transition at a time.

Need to check the property

for every possible interleaving!


Interleaving semantics

Turn=0

L0,L1

Turn=0

L0,L1

Turn=0

L0,NC1

Turn=0

L0,NC1

Turn=1

L0,NC1

Turn=0

NC0,NC1

Turn=1

L0,CR1

Turn=0

CR0,NC1

Interleaving semantics


L0:While True do

NC0:wait(Turn=0);

CR0:Turn=1

endwhile ||

L1:While True do

NC1:wait(Turn=1);

CR1:Turn=0

endwhile

T0:PC0=L0PC0:=NC0

T1:PC0=NC0/\Turn=0PC0:=CR0

T1’:PC0=NC0/\Turn=1PC0:=NC0

T2:PC0=CR0(PC0,Turn):=(L0,1)

T3:PC1==L1PC1=NC1

T4:PC1=NC1/\Turn=1PC1:=CR1

T4’:PC1=NC1/\Turn=0PC1:=N1

T5:PC1=CR1(PC1,Turn):=(L1,0)

Busy waiting

Initially: PC0=L0/\PC1=L1


Always when turn 0 then sometimes turn 1

Turn=0

L0,L1

Turn=1

L0,L1

Turn=0

L0,NC1

Turn=0

NC0,L1

Turn=1

L0,NC1

Turn=1

NC0,L1

Turn=0

NC0,NC1

Turn=0

CR0,L1

Turn=1

L0,CR1

Turn=1

NC0,NC1

Turn=0

CR0,NC1

Turn=1

NC0,CR1

Always when Turn=0 then sometimes Turn=1

Now it does not hold!

(Red subgraph generates a counterexample execution.)


How can we check the model
How can we check the model?

  • The model is a graph.

  • The specification should refer the the graph representation.

  • Apply graph theory algorithms.


What properties can we check
What properties can we check?

  • Invariants: a property that need to hold in each state.

  • Deadlock detection: can we reach a state where the program is blocked?

  • Dead code: does the program have parts that are never executed.


How to perform the checking
How to perform the checking?

  • Apply a search strategy (Depth first search, Breadth first search).

  • Check states/transitions during the search.

  • If property does not hold, report counter example!


If it is so good why learn deductive verification methods
If it is so good, why learn deductive verification methods?

  • Model checking works only for finite state systems. Would not work with

    • Unconstrained integers.

    • Unbounded message queues.

    • General data structures:

      • queues

      • trees

      • stacks

    • parametric algorithms and systems.


The state space explosion
The state space explosion

  • Need to represent the state space of a program in the computer memory.

    • Each state can be as big as the entire memory!

    • Many states:

      • Each integer variable has 2^32 possibilities. Two such variables have 2^64 possibilities.

      • In concurrent protocols, the number of states usually grows exponentially with the number of processes.


If it is so constrained is it of any use
If it is so constrained, is it of any use?

  • Many protocols are finite state.

  • Many programs or procedure are finite state in nature. Can use abstraction techniques.

  • Sometimes it is possible to decompose a program, and prove part of it by model checking and part by theorem proving.

  • Many techniques to reduce the state space explosion.


Depth first search

Program DFS

For each s such that Init(s)

dfs(s)

end DFS

Procedure dfs(s)

for each s’ such that R(s,s’) do

If new(s’) then dfs(s’)

end dfs.

Depth First Search


How can we check properties with dfs
How can we check properties with DFS?

  • Invariants: check that all reachable statessatisfy the invariant property. If not, showa path from an initial state to a bad state.

  • Deadlocks: check whether a state where noprocess can continue is reached.

  • Dead code: as you progress with the DFS, mark all the transitions that are executed at least once.


Pc0 cr0 pc1 cr1 is an invariant

Turn=0

L0,L1

Turn=1

L0,L1

Turn=0

L0,NC1

Turn=0

NC0,L1

Turn=1

L0,NC1

Turn=1

NC0,L1

Turn=0

NC0,NC1

Turn=0

CR0,L1

Turn=1

L0,CR1

Turn=1

NC0,NC1

Turn=0

CR0,NC1

Turn=1

NC0,CR1

¬(PC0=CR0/\PC1=CR1) is an invariant!


Want to do more
Want to do more!

  • Want to check more properties.

  • Want to have a unique algorithm to deal with all kinds of properties.

  • This is done by writing specification in more complicated formalisms.

  • We will see that in the next lecture.


Turn 0 turn 1

Turn=0

L0,L1

Turn=1

L0,L1

Turn=0

L0,NC1

Turn=0

NC0,L1

Turn=1

L0,NC1

Turn=1

NC0,L1

Turn=0

NC0,NC1

Turn=0

CR0,L1

Turn=1

L0,CR1

Turn=1

NC0,NC1

Turn=0

CR0,NC1

Turn=1

NC0,CR1

[](Turn=0 --> <>Turn=1)


init

Turn=0

L0,L1

Turn=1

L0,L1

Turn=0

L0,NC1

Turn=0

NC0,L1

Turn=1

L0,NC1

Turn=1

NC0,L1

Turn=0

NC0,NC1

Turn=0

CR0,L1

Turn=1

L0,CR1

Turn=1

NC0,NC1

Turn=0

CR0,NC1

Turn=1

NC0,CR1


init

Turn=0

L0,L1

Turn=1

L0,L1

Turn=0

L0,L1

Turn=1

L0,L1

  • Add an additional initial node.

  • Propositions are attached to incoming nodes.

  • All nodes are accepting.


Correctness condition
Correctness condition

  • We want to find a correctness condition for a model to satisfy a specification.

  • Language of a model: L(Model)

  • Language of a specification: L(Spec).

  • We need: L(Model)  L(Spec).


Correctness
Correctness

Sequencessatisfying Spec

Program executions

All sequences


How to prove correctness
How to prove correctness?

  • Show that L(Model)  L(Spec).

  • Equivalently: ______Show that L(Model)  L(Spec) = Ø.

  • Also: can obtain L(Spec) by translating from LTL!


What do we need to know
What do we need to know?

  • How to intersect two automata?

  • How to complement an automaton?

  • How to translate from LTL to an automaton?



Properties of formalisms
Properties of formalisms

  • Formal. Unique interpretation.

  • Intuitive. Simple to understand (visual).

  • Succinct. Spec. of reasonable size.

  • Effective.

    • Check that there are no contradictions.

    • Check that the spec. is implementable.

    • Check that the implementation satisfies spec.

  • Expressive.

  • May be used to generate initial code.

    Specifying the implementation or its properties?


A transition system1
A transition system

  • A (finite) set of variables V.

  • A set of states .

  • A (finite) set of transitions T, each transition e==>t has

    • an enabling condition e and a transformation t.

  • An initial condition I.

  • Denote by R(s, s’) the fact that s’ is a successor of s.


The interleaving model1
The interleaving model

  • An execution is a finite or infinite sequence of states s0, s1, s2, …

  • The initial state satisfies the initial condition, I.e., I (s0).

  • Moving from one state si to si+1 is by executing a transition e==>t:

    • e(si), I.e., si satisfies e.

    • si+1 is obtained by applying t to si.

  • Lets assume all sequences are infinite by extending finite ones by “stuttering” the last state.


Temporal logic
Temporal logic

  • Dynamic, speaks about several “worlds” and the relation between them.

  • Our “worlds” are the states in an execution.

  • There is a linear relation between them, each two sequences in our execution are ordered.

  • Interpretation: over an execution, later over all executions.


Ltl syntax
LTL: Syntax

 ::= () | ¬ | /\ \/ U |O  | p

“box”, “always”, “forever”

“diamond”, “eventually”, “sometimes”

O “nexttime”

U“until”

Propositions p, q, r, … Each represents some state property (x>y+1, z=t, at-CR, etc.)


Semantics over suffixes of execution

Semanticsover suffixes of execution





O 

U


Combinations
Combinations

  • []<>p “p will happen infinitely often”

  • <>[]p “p will happen from some point forever”.

  • ([]<>p) --> ([]<>q) “If p happens infinitely often, then q also happens infinitely often”.


Some relations

b

a

a

a

b

b

a

b

a

b

b

Some relations:

  • [](a/\b)=([]a)/\([]b)

  • But <>(a/\b)(<>a)/\(<>b)

  • <>(a\/b)=(<>a)\/(<>b)

  • But [](a\/b)([]a)\/([]b)


What about
What about

  • ([]<>A)/\([]<>B)=[]<>(A/\B)?

  • ([]<>A)\/([]<>B)=[]<>(A\/B)?

  • (<>[]A)/\(<>[]B)=<>[](A/\B)?

  • (<>[]A)\/(<>[]B)=<>[](A\/B)?

No, just <--

Yes!!!

Yes!!!

No, just -->


Can discard some operators
Can discard some operators

  • Instead of <>p, write true U p.

  • Instead of []p, we can write ¬<>¬p,or ¬(true U ¬p).Because []p=¬¬[]p.¬[]p means it is not true that p holds forever, or at some point ¬p holds or <>¬p.


Formal semantic definition
Formal semantic definition

  • Let  be a sequence s0 s1 s2 …

  • Let i be a suffix of : si si+1 si+2 … (0 = )

  • i |= p, where p a proposition, if si|=p.

  • i |= /\ if i |=  and i |= .

  • i |= \/ if i |=  or i |= .

  • i |= <> if for some ji, j |= .

  • i |= [] if for each ji, j |= .

  • i |= U  if for some ji, j|=. and for each ik<j, k |=.


Then we interpret
Then we interpret:

  • s|=p as in propositional logic.

  • |= is interpreted over a sequence, as in previous slide.

  • P|=holds if |= for every sequence  of P.


Spring example
Spring Example

release

s1

s2

s3

pull

release

extended

extended

malfunction

r0 = s1 s2 s1 s2 s1 s2 s1 …

r1 = s1 s2 s3 s3 s3 s3 s3 …

r2 = s1 s2 s1 s2 s3 s3 s3 …


Ltl satisfaction by a single sequence

release

s1

s2

s3

pull

release

extended

extended

LTL satisfaction by a single sequence

r2 = s1 s2 s1 s2 s3 s3 s3 …

malfunction

r2 |= extended ??

r2 |= O extended ??

r2 |= O O extended ??

r2 |= <> extended ??

r2 |= [] extended ??

r2 |= <>[] extended ??

r2 |= ¬ <>[] extended ??

r2 |= (¬extended) U malfunction ??

r2 |= [](¬extended->O extended) ??


Ltl satisfaction by a system

release

s1

s2

s3

pull

release

extended

extended

LTL satisfaction by a system

malfunction

P |= extended ??

P |= O extended ??

P |= O O extended ??

P |= <> extended ??

P|= [] extended ??

P |= <>[] extended ??

P |= ¬ <>[] extended ??

P |= (¬extended) U malfunction ??

P |= [](¬extended->O extended) ??


The state space

Turn=1

L0,L1

Turn=0

L0,L1

Turn=0

L0,NC1

Turn=0

NC0,L1

Turn=1

L0,NC1

Turn=1

NC0,L1

Turn=0

NC0,NC1

Turn=0

CR0,L1

Turn=1

L0,CR1

Turn=1

NC0,NC1

Turn=0

CR0,NC1

Turn=1

NC0,CR1

The state space


Pc0 cr0 pc1 cr1 mutual exclusion

Turn=0

L0,L1

Turn=1

L0,L1

Turn=0

L0,NC1

Turn=0

NC0,L1

Turn=1

L0,NC1

Turn=1

NC0,L1

Turn=0

NC0,NC1

Turn=0

CR0,L1

Turn=1

L0,CR1

Turn=1

NC0,NC1

Turn=0

CR0,NC1

Turn=1

NC0,CR1

[] ¬(PC0=CR0/\PC1=CR1)(Mutual exclusion)


Turn 0 turn 11

Turn=0

L0,L1

Turn=1

L0,L1

Turn=0

L0,NC1

Turn=0

NC0,L1

Turn=1

L0,NC1

Turn=1

NC0,L1

Turn=0

NC0,NC1

Turn=0

CR0,L1

Turn=1

L0,CR1

Turn=1

NC0,NC1

Turn=0

CR0,NC1

Turn=1

NC0,CR1

[](Turn=0 --> <>Turn=1)


Interleaving semantics execute one transition at a time1
Interleaving semantics:Execute one transition at a time.

Turn=0

L0,L1

Turn=0

L0,NC1

Turn=1

L0,NC1

Turn=0

NC0,NC1

Turn=1

L0,CR1

Turn=0

CR0,NC1

Need to check the property

for every possible interleaving!


More specifications
More specifications

  • [](PC0=NC0  <> PC0=CR0)

  • [](PC0=NC0 U Turn=0)

  • Try at home:- The processes alternate in entering their critical sections.- Each process enters its critical section infinitely often.


Proof system

¬<>p<-->[]¬p

[](pq)([]p[]q)

[]p(p/\O[]p)

O¬p<-->¬Op

[](pOp)(p[]p)

(pUq)<-->(q\/(p/\O(pUq)))

(pUq)<>q

+ propositional logic axiomatization.

+ axiom:p []p

Proof system


Traffic light example
Traffic light example

Green --> Yellow --> Red --> Green

Always has exactly one light:

[](¬(gr/\ye)/\¬(ye/\re)/\¬(re/\gr)/\(gr\/ye\/re))

Correct change of color:

[]((grUye)\/(yeUre)\/(reUgr))


Another kind of traffic light

Needed only when we

can start with yellow

Another kind of traffic light

Green-->Yellow-->Red-->Yellow-->Green

First attempt:

[](((gr\/re) U ye)\/(ye U (gr\/re)))

Correct specification:

[]( (gr-->(grU (ye /\ ( yeUre ))))

/\(re-->(reU (ye /\ ( yeUgr ))))

/\(ye-->(yeU (gr \/ re))))


Properties of sequential programs
Properties of sequential programs

  • init-when the program starts and satisfies the initial condition.

  • finish-when the program terminates and nothing is enabled.

  • Partial correctness: init/\[](finish)

  • Termination: init/\<>finish

  • Total correctness:init/\<>(finish/\ )

  • Invariant:init/\[]


Automata over finite words

a

S0

b

S1

a

b

Automata over finite words

  • A=<, S, , I, F>

  •  (finite) the alphabet, S (finite) the states.

  • : S x  x S is the transition relation

  • I : S are the starting states

  • F: S are the accepting states.


The transition relation

a

S0

b

S1

a

b

The transition relation

  • (S0, a, S0)

  • (S0, b, S1)

  • (S1, a, S0)

  • (S1, b, S1)


A run over a word

a

S0

b

S1

a

b

A run over a word

  • A word over , e.g., abaab.

  • A sequence of states, e.g. S0 S0 S1 S0 S0 S1.

  • Starts with an initial state.

  • Accepting if ends at accepting state.


The language of an automaton

a

S0

b

S1

a

b

The language of an automaton

  • The words that are accepted by the automaton.

  • Includes aabbba, abbbba.

  • Does not include abab, abbb.

  • What is the language?


Nondeterministic automaton

S0

a

S1

A,b

a

Nondeterministic automaton

  • Transitions: (S0,a,S0), (S0,b,S0), (S0,a,S1),(S1,a,S1).

  • What is the language of this automaton?


Equivalent deterministic automaton

S0

a

S1

a,b

a

Equivalent deterministic automaton

a

S0

a

S1

b

b


Automata over infinite words

a

S0

b

S1

a

b

Automata over infinite words

  • Similar definition.

  • Runs on infinite words over .

  • Accepts when an accepting state occurs infinitely often in a run.


Automata over infinite words1

A

S0

B

S1

A

B

Automata over infinite words

  • Consider the word a b a b a b a b …

  • There is a run S0 S0 S1 S0 S1 S0 S1 …

  • This run in accepting, since S0 appears infinitely many times.


Other runs

a

S0

b

S1

a

b

Other runs

  • For the word b b b b b … the run is S0 S1 S1 S1 S1… and is not accepting.

  • For the word a a a b b b b b …, therun is S0 S0 S0 S0 S1 S1 S1 S1 …

  • What is the run for a b a b b a b b b …?


Nondeterministic automaton1

S0

a

S1

a,b

a

Nondeterministic automaton

  • What is the language of this automaton?

  • What is the LTL specification if b -- PC0=CR0, a=¬b?

  • Can you find a deterministic automaton with same language?

  • Can you prove there is no such deterministic automaton?


Specification using automata

a

S0

b

S1

a

b

Specification using Automata

  • Let each letter correspond to some propositional property.

  • Example: a -- P0 enters critical section, b -- P0 does not enter section.

  • []<>PC0=CR0


Mutual exclusion

S0

c

S1

b

a

Mutual Exclusion

  • A -- PC0=CR0/\PC1=CR1

  • B -- ¬(PC0=CR0/\PC1=CR1)

  • C -- TRUE

  • []¬(PC0=CR0/\PC1=CR1)


L0:While True do

NC0:wait(Turn=0);

CR0:Turn=1

endwhile ||

L1:While True do

NC1:wait(Turn=1);

CR1:Turn=0

endwhile

T0:PC0=L0==>PC0=NC0

T1:PC0=NC0/\Turn=0==>

PC0:=CR0

T2:PC0=CR0==>

(PC0,Turn):=(L0,1)

T3:PC1==L1==>PC1=NC1

T4:PC1=NC1/\Turn=1==>

PC1:=CR1

T5:PC1=CR1==>

(PC1,Turn):=(L1,0)

Initially: PC0=L0/\PC1=L1


The state space1

Turn=0

L0,L1

Turn=1

L0,L1

Turn=0

L0,NC1

Turn=0

NC0,L1

Turn=1

L0,NC1

Turn=1

NC0,L1

Turn=0

NC0,NC1

Turn=0

CR0,L1

Turn=1

L0,CR1

Turn=1

NC0,NC1

Turn=0

CR0,NC1

Turn=1

NC0,CR1

The state space


Pc0 cr0 pc1 cr1

Turn=0

L0,L1

Turn=1

L0,L1

Turn=0

L0,NC1

Turn=0

NC0,L1

Turn=1

L0,NC1

Turn=1

NC0,L1

Turn=0

NC0,NC1

Turn=0

CR0,L1

Turn=1

L0,CR1

Turn=1

NC0,NC1

Turn=0

CR0,NC1

Turn=1

NC0,CR1

[]¬(PC0=CR0/\PC1=CR1)


Turn 0 turn 12

Turn=0

L0,L1

Turn=1

L0,L1

Turn=0

L0,NC1

Turn=0

NC0,L1

Turn=1

L0,NC1

Turn=1

NC0,L1

Turn=0

NC0,NC1

Turn=0

CR0,L1

Turn=1

L0,CR1

Turn=1

NC0,NC1

Turn=0

CR0,NC1

Turn=1

NC0,CR1

[](Turn=0 --> <>Turn=1)


Correctness condition1
Correctness condition

  • We want to find a correctness condition for a model to satisfy a specification.

  • Language of a model: L(Model)

  • Language of a specification: L(Spec).

  • We need: L(Model)  L(Spec).


Correctness1
Correctness

Sequencessatisfying Spec

Program executions

All sequences


Incorrectness
Incorrectness

Counter

examples

Sequencessatisfying Spec

Program executions

All sequences


Intersecting m 1 s 1 t 1 i 1 a 1 and m 2 s 2 t 2 i 2 s 2
Intersecting M1=(S1,,T1,I1,A1) and M2=(S2,,T2,I2,S2)

  • Run the two automata in parallel.

  • Each state is a pair of states: S1 x S2

  • Initial states are pairs of initials: I1 x I2

  • Acceptance depends on first component: A1 x S2

  • Conforms with transition relation:(x1,y1)-a->(x2,y2) whenx1-a->x2 and y1-a->y2.


Example all states of second automaton accepting
Example (all states of second automaton accepting!)

a

s0

b,c

s1

a

b,c

a

t0

c

t1

b

States: (s0,t0), (s0,t1), (s1,t0), (s1,t1).

Accepting: (s0,t0), (s0,t1). Initial: (s0,t0).


a

s0

b,c

s1

a

b,c

a

t0

c

t1

b

a

s0,t0

s0,t1

s1,t0

b

a

c

Also state (s0,t1) is unreachable but we will keep it for thetime being!

s1,t1

b

c


More complicated when a 2 s 2
More complicated when A2S2

a

s0

b,c

s1

a

a

b,c

s0,t0

s0,t1

b

a

a

c

s1,t1

t0

c

t1

b

c

Should we have acceptance when both components accepting? I.e., {(s0,t1)}?

No, consider (ba) It should be accepted, but never passes that state.


More complicated when a 2 s 21
More complicated when A2S2

a

s0

b,c

s1

a

A

b,c

s0,t0

s0,t1

b

a

a

c

s1,t1

t0

c

t1

c

b

Should we have acceptance when at least one components is accepting? I.e., {(s0,t0),(s0,t1),(s1,t1)}?No, consider b c It should not be accepted, but here will loop through (s1,t1)


Intersection general case also propositions on nodes

A/\¬B

q0,q3

¬A/\B

q1,q2

¬A/\¬B

q1,q3

Intersection - general caseAlso: propositions on nodes

q0

q2

A/\¬B

¬A/\B

q0 and q2 give false.

q1

q3

¬A

A\/¬B


Version 0 to catch q 0 version 1 to catch q 2
Version 0: to catch q0Version 1: to catch q2

Version 0

A/\¬B

q0,q3

¬A/\B

q1,q2

¬A/\¬B

q1,q3

Move when see accepting of left (q0)

Move when see accepting of right (q2)

A/\¬B

q0,q3

¬A/\B

q1,q2

¬A/\¬B

q1,q3

Version 1


Make an accepting state in one of the version according to a component accepting state
Make an accepting state in one of the version according to a component accepting state

Version 0

A/\¬B

q0,q3,0

¬A/\B

q1,q2,0

¬A/\¬B

q1,q3,0

A/\¬B

q0,q3,1

¬A/\B

q1,q2 ,1

¬A/\¬B

q1,q3 ,1

Version 1


How to check for emptiness
How to check for emptiness? component accepting state

a

s0,t0

s0,t1

b

a

c

s1,t1

b

c


Emptiness
Emptiness... component accepting state

Need to check if there exists an accepting run (passes through an accepting state infinitely often).


Finding accepting runs
Finding accepting runs component accepting state

If there is an accepting run, then at least one accepting state repeats on it forever. This state appears on a cycle. So, find a reachable accepting state on a cycle.


Equivalently
Equivalently... component accepting state

  • A strongly connected component: a set of nodes where each node is reachable by a path from each other node. Find a reachable strongly connected component with an accepting node.


How to complement
How to complement? component accepting state

  • Complementation is hard!

  • Can ask for the negated property (the sequences that should never occur).

  • Can translate from LTL formula  to automaton A, and complement A. But:can translate ¬ into an automaton directly!


Model checking under fairness
Model Checking under Fairness component accepting state

Express the fairness as a property φ.To prove a property ψ under fairness,model check φψ.

Counter

example

Fair (φ)

Bad (¬ψ)

Program


Model checking under fairness1
Model Checking under Fairness component accepting state

Specialize model checking. For weak process fairness: search for a reachable strongly connected component, where for each process P either

  • it contains on occurrence of a transition from P, or

  • it contains a state where P is disabled.


Dekker s algorithm

P1::while true do component accepting statebeginnon-critical section 1c1:=0; while c2=0 do begin if turn=2 then begin c1:=1; wait until turn=1;

c1:=0; end end critical section 1 c1:=1; turn:=2 end.

Dekker’s algorithm

boolean c1 initially 1;

boolean c2 initially 1;

integer (1..2) turn initially 1;

P2::while true dobeginnon-critical section 2c2:=0; while c1=0 do begin if turn=1 then begin c2:=1; wait until turn=2;

c2:=0; end end critical section 2 c2:=1; turn:=1 end.


Dekker s algorithm1

P1::while true do component accepting state begin non-critical section 1 c1:=0;while c2=0 do begin if turn=2 then begin c1:=1; wait until turn=1;

c1:=0; end end critical section 1 c1:=1; turn:=2 end.

Dekker’s algorithm

boolean c1 initially 1;

boolean c2 initially 1;

integer (1..2) turn initially 1;

P2::while true do begin non-critical section 2 c2:=0; while c1=0 do begin if turn=1 then begin c2:=1; wait until turn=2;

c2:=0; end end critical section 2 c2:=1; turn:=1 end.

c1=c2=0,turn=1


Dekker s algorithm2

P1::while true do component accepting state begin non-critical section 1 c1:=0; while c2=0 dobegin if turn=2 then begin c1:=1; wait until turn=1;

c1:=0; end end critical section 1 c1:=1; turn:=2 end.

Dekker’s algorithm

boolean c1 initially 1;

boolean c2 initially 1;

integer (1..2) turn initially 1;

P2::while true do begin non-critical section 2 c2:=0; while c1=0 do begin if turn=1 then begin c2:=1; wait until turn=2;

c2:=0; end end critical section 2 c2:=1; turn:=1 end.

c1=c2=0,turn=1


Dekker s algorithm3

P1::while true do component accepting state begin non-critical section 1 c1:=0;while c2=0 do begin if turn=2 then begin c1:=1; wait until turn=1;

c1:=0; end end critical section 1 c1:=1; turn:=2 end.

Dekker’s algorithm

P1 waits for P2 to set c2 to 1 again.Since turn=1 (priority for P1), P2 is ready to do that. But never gets the chance, since P1 is constantly active checking c2 in its while loop.

P2::while true do begin non-critical section 2 c2:=0; while c1=0 do begin if turn=1 then begin c2:=1; wait until turn=2;

c2:=0; end end critical section 2 c2:=1; turn:=1 end.

c1=c2=0,turn=1


What went wrong

The execution is component accepting stateunfair to P2. It is not allowed a chance to execute.

Such an execution is due to the interleaving model (just picking an enabled transition.

If it did, it would continue and set c2 to 0, which would allow P1 to progress.

Fairness = excluding some of the executions in the interleaving model, which do not correspond to actual behavior of the system.

while c1=0 do begin if turn=1 then begin c2:=1; wait until turn=2;

c2:=0; end end

What went wrong?


Recall the interleaving model
Recall: component accepting stateThe interleaving model

  • An execution is a finite or infinite sequence of states s0, s1, s2, …

  • The initial state satisfies the initial condition, I.e., I (s0).

  • Moving from one state si to si+1 is by executing a transition et:

    • e(si), I.e., si satisfies e.

    • si+1 is obtained by applying t to si.

Now: consider only “fair” executions. Fairness constrains sequences that are considered to be executions.

Sequences

Executions

Fair executions


Some fairness definitions
Some fairness definitions component accepting state

  • Weak transition fairness:It cannot happen that a transition is enabled indefinitely, but is never executed.

  • Weak process fairness: It cannot happen that a process is enabled indefinitely, but non of its transitions is ever executed

  • Strong transition fairness:If a transition is infinitely often enabled, it will get executed.

  • Strong process fairness:If at least one transition of a process is infinitely often enabled, a transition of this process will be executed.


How to use fairness constraints
How to use fairness constraints? component accepting state

  • Assume in the negative that some property (e.g., termination) does not hold, because of some transitions or processes prevented from execution.

  • Show that such executions are impossible, as they contradict fairness assumption.

  • We sometimes do not know in reality which fairness constraint is guaranteed.


Example2

P1::x=1 component accepting state

P2: do

:: y==0  if

:: true :: x==1  y=1

fi od

Example

Initially: x=0; y=0;

In order for the loop to terminate we need P1 to execute the assignment. But P1 may never execute, since P2 is in a loop executing true. Consequently, x==1 never holds, and y is never assigned a 1.

pc1=l0-->(pc1,x):=(l1,1) /* x=1 */

pc2=r0/\y=0-->pc2=r1 /* y==0*/

pc2=r1pc2=r0 /* true */

pc2=r1/\x=1(pc2,y):=(r0,1) /* x==1 --> y:=1 */


Weak transition fairness

P1::x=1 component accepting state

P2: do

:: y==0  if

:: true :: x==1  y=1

fi od

Weak transition fairness

Initially: x=0; y=0;

Under weak transition fairness, P1 would assign 1 to x, but this does not guarantee that 1 is assigned to y and thus the P2 loop will terminates, since the transition for checking x==1 is not continuously enabled (program counter not always there).

Weak process fairness only guarantees P2 to execute, but it can still choose to do the true.

Strong process fairness: same.


Strong transition fairness

P1::x=1 component accepting state

P2: do

:: y==0  if

:: true :: x==1  y=1

fi od

Strong transition fairness

Initially: x=0; y=0;

Under strongtransitionfairness, P1 would assign 1 to x. If the execution was infinite, the transition checking x==1 was infinitely often enabled. Hence it would be eventually selected. Then assigning y=1, the main loop is not enabled anymore.


Some fairness definitions1
Some fairness definitions component accepting state

  • Weak transition fairness:/\T (<>[]en []<>exec).Equivalently: /\aT ¬<>[](en /\¬exec)

  • Weak process fairness: /\Pi (<>[]enPi []<>execPi )

  • Strong transition fairness:/\T ([]<>en []<>exec)

  • Strong process fairness:/\Pi ([]<>enPi []<>execPi )

exec  is executed.

execPi some transition of Pi is executed.

en  is enabled.

enPi some transition of process Pi is enabled.

enPi = \/Ten

execPi = \/Texec


Weaker fairness condition
“Weaker fairness condition” component accepting state

Strongtransitionfair execs

  • A is weaker than B if BA.

  • Consider the executions L(A) and L(B).Then L(B)L(A).

  • An execution is strong {process,transition} fair implies that it is also weak {process,transition} fair.

  • There are fewer strong {process,transition} fair executions.

Strongprocessfair execs

Weaktransitionfair execs

Weakprocessfair execs


Model checking under fairness2
Model Checking under fairness component accepting state

  • Instead of verifying that the program satisfies , verify it satisfies fair 

  • Problem: may be inefficient. Also fairness formula may involves special arrangement for specifying what exec means.

  • May specialize model checking algorithm instead.


Model checking under fairness3
Model Checking under Fairness component accepting state

Specialize model checking. For weak process fairness: search for a reachable strongly connected component, where for each process P either

  • it contains on occurrence of a transition from P, or

  • it contains a state where P is disabled.

  • Weak transition fairness: similar.

  • Strong fairness: much more difficult algorithm.


  • Abstractions
    Abstractions component accepting state


    Problems with software analysis
    Problems with software analysis component accepting state

    • Many possible outcomes and interactions.

    • Not manageable by an algorithm (undecideable, complex).

    • Requires a lot of practice and ingenuity (e.g., finding invariants).


    More problems
    More problems component accepting state

    • Testing methods fail to cover potential errors.

    • Deductive verification techniques require

      • too much time,

      • mathematical expertise,

      • ingenuity.

    • Model checking requires a lot of time/space and may introduce modeling errors.


    How to alleviate the complexity
    How to alleviate the complexity? component accepting state

    • Abstraction

    • Compositionality

    • Partial Order Reduction

    • Symmetry


    Abstraction
    Abstraction component accepting state

    • Represent the program using a smaller model.

    • Pay attention to preserving the checked properties.

    • Do not affect the flow of control.


    Main idea
    Main idea component accepting state

    • Use smaller data objects.

      x:= f(m)

      y:=g(n)

      if x*y>0 then …

      else …

      x, y never used again.


    How to abstract
    How to abstract? component accepting state

    • 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).


    Abstraction mapping
    Abstraction mapping component accepting state

    • S - states, I - initial states. L(s) - labeling.

    • R(S,S) - transition relation.

    • h(s) maps s into its abstract image.Full model --h--> Abstract model I(s) --> I(h(s)) R(s, t) --> R(h(s),h(t)) L(h(s))=L(s)


    go component accepting state

    Traffic light example

    stop

    stop


    go component accepting state

    go

    stop

    stop

    stop


    What do we preserve
    What do we preserve? component accepting state

    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.

    But there can be properties holding for the original model but not the abstract one.

    go

    go

    stop

    stop

    stop


    Preserved go o stop
    Preserved: component accepting state [](go->O stop)

    go

    Not preserved:

    []<>go

    Counterexamples need to be checked.

    go

    stop

    stop

    stop


    Symmetry
    Symmetry component accepting state

    • 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->[email protected]: 1->3, 2->2, 3->1

    • A set of permutations with @ is called a symmetry group.


    Using symmetry in analysis
    Using symmetry in analysis component accepting state

    • 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.


    init component accepting state

    Turn=0

    L0,L1

    Turn=1

    L0,L1

    Turn=0

    L0,NC1

    Turn=0

    NC0,L1

    Turn=1

    L0,NC1

    Turn=1

    NC0,L1

    Turn=0

    NC0,NC1

    Turn=0

    CR0,L1

    Turn=1

    L0,CR1

    Turn=1

    NC0,NC1

    Turn=0

    CR0,NC1

    Turn=1

    NC0,CR1


    init component accepting state

    Turn=0

    L0,L1

    Turn=0

    L0,NC1

    Turn=0

    NC0,L1

    Turn=0

    NC0,NC1

    Turn=0

    CR0,L1

    Turn=0

    CR0,NC1

    The quotient model


    What is preserved in the following buffer abstraction what is not preserved
    What is preserved in the following buffer abstraction? What is not preserved?

    e

    empty

    q

    quasi

    q

    q

    full

    f


    Translating from logic to automata is not preserved?Comment: the language of LTL is a proper subset of the language of Buchi Automata. For example,one cannot express in LTL the following automaton [Wolper]:

    a

    a ,¬a


    Why translating
    Why translating? is not preserved?

    • Want to write the specification in some logic.

    • Want model-checking tools to be able to check the specification automatically.


    Preprocessing
    Preprocessing is not preserved?

    • Convert into normal form, where negation only applies to propositional variables.

    • ¬[] becomes <>¬.

    • ¬<> becomes [] ¬.

    • What about ¬ ( U )?

    • Define operator V such that¬ ( U) = (¬) R (¬),

      ¬ ( R) = (¬) U (¬).


    Semantics of p r q the release operator dual to until
    Semantics of p is not preserved?R q(the Release operator, dual to Until)

    ¬p

    ¬p

    ¬p

    ¬p

    ¬p

    ¬p

    ¬p

    ¬p

    ¬p

    q

    q

    q

    q

    q

    q

    q

    q

    q

    ¬p

    ¬p

    ¬p

    ¬p

    p

    q

    q

    q

    q

    q


    • Replace is not preserved?¬T by F, and ¬F by T.

    • Replace ¬ ( \/ ) by (¬) /\ (¬) and¬ ( /\ ) by (¬) \/ (¬)


    Eliminate implications
    Eliminate implications, <>, [] is not preserved?

    • Replace  ->  by (¬) \/ .

    • Replace <> by (T U).

    • Replace [] by (F R).


    Example3
    Example is not preserved?

    • Translate ( []<>P )  ( []<>Q )

    • Eliminate implication ¬( []<>P ) \/ ( []<>Q )

    • Eliminate [], <>:¬( F R ( T U P ) ) \/ ( F R ( T U Q ) )

    • Push negation inwards:(T U (F R ¬P ) ) \/ ( F R ( T U Q ) )


    The data structure

    Incoming is not preserved?

    New

    Old

    Next

    The data structure

    Name


    The main idea
    The main idea is not preserved?

    • U =  \/ (  /\ O ( U ) )

    • R =  /\ (  \/ O ( R ) )

      This separates the formulas to two parts:one holds in the current state, and the other in the next state.


    How to translate
    How to translate? is not preserved?

    • Take one formula from “New” and add it to “Old”.

    • According to the formula, either

      • Split the current node into two, or

      • Evolve the node into a new version.


    Splitting

    Incoming is not preserved?

    New

    Old

    Next

    Incoming

    Incoming

    New

    Old

    New

    Old

    Next

    Next

    Splitting

    Copy incoming edges, update other field.


    Evolving

    Incoming is not preserved?

    New

    Old

    Next

    Incoming

    New

    Old

    Next

    Evolving

    Copy incoming edges, update other field.


    Possible cases
    Possible cases: is not preserved?

    • U , split:

      • Add  to New, add  U  to Next.

      • Add  to New.

        Because  U  =  \/ (  /\ O (U )).

    • R , split:

      • Add  to New.

      • Add  to New, R to Next.

        Because R =  /\ (  \/ O (R )).


    More cases
    More cases: is not preserved?

    •  \/ , split:

      • Add  to New.

      • Add  to New.

    •  /\ , evolve:

      • Add  to New.

    • O , evolve:

      • Add  to Next.


    How to start
    How to start? is not preserved?

    init

    Incoming

    New

    Old

    aU(bUc)

    Next


    Incoming is not preserved?

    Incoming

    a

    aU(bUc)

    bUc

    aU(bUc)

    aU(bUc)

    init

    Incoming

    aU(bUc)

    init

    init


    init is not preserved?

    Incoming

    bUc

    aU(bUc)

    init

    init

    Incoming

    Incoming

    b

    aU(bUc)

    c

    aU(bUc)

    (bUc)


    When to stop splitting
    When to stop splitting? is not preserved?

    • When “New” is empty.

    • Then compare against a list of existing nodes “Nodes”:

      • If such a with same “Old”, “Next” exists,just add the incoming edges of the new versionto the old one.

      • Otherwise, add the node to “Nodes”. Generate a successor with “New” set to “Next” of father.


    init is not preserved?

    Incoming

    a,aU(bUc)

    Creating a successor node.

    aU(bUc)

    Incoming

    aU(bUc)


    How to obtain the automaton

    Incoming is not preserved?

    New

    Old

    Next

    How to obtain the automaton?

    X

    There is an edge from node X to Y labeled with propositions P (negated or non negated), if X is in the incoming list of Y, and Y has propositions P in field “Old”.

    Initial nodes are those marked as init.

    a, b, ¬c

    Node Y


    The resulted nodes

    a, aU(bUc) is not preserved?

    b, bUc, aU(bUc)

    c, bUc, aU(bUc)

    b, bUc

    c, bUc

    The resulted nodes.


    a, aU(bUc) is not preserved?

    b, bUc, aU(bUc)

    c, bUc, aU(bUc)

    b, bUc

    c, bUc

    Initial nodes: All nodes with incoming edge from “init”.


    Acceptance conditions
    Acceptance conditions is not preserved?

    • Use “generalized Buchi automata”, wherethere are several acceptance sets F1, F2, …, Fn, and each accepted infinite sequence must include at least one state from each set infinitely often.

    • Each set corresponds to a subformula of form U . Guarantees that it is never the case that U  holds forever, without .

    • Translate to Buchi acceptance condition (will be shown later).


    Accepting w r t buc green

    a, aU(bUc) is not preserved?

    b, bUc, aU(bUc)

    c, bUc, aU(bUc)

    b, bUc

    c, bUc

    All nodes with c, or without bUc.

    Accepting w.r.t. bUc(green)


    Acceptance w r t au buc blue

    a, aU(bUc) is not preserved?

    b, bUc, aU(bUc)

    c, bUc, aU(bUc)

    b, bUc

    c, bUc

    All nodes with bUc or without aU(bUc).

    Acceptance w.r.t. aU(bUc)(blue)


    Translating multiple buchi into buchi automata
    Translating Multiple Buchi into Buchi automata is not preserved?

    • For acceptance sets F1, F2, …, Fn, generate n copies of the automaton.

    • Move from the ith copy to the i+1th copy when passing a state of Fi.

    • In the first copy, the states of F1 are accepting.

    • Same intuition as the unrestricted intersection:Need to see each accepting set infinitely often, and it does not matter that we miss some of them (there must be an infinite supply anyway…).


    Conclusions
    Conclusions is not preserved?

    • Model checking: automatic verification of finite state systems.

    • Modeling: affects how we can view and check the system’s properties.

    • Specification formalisms, e.g., LTL or Buchi automata

    • Apply graph algorithms (or BDD, or BMD).

    • Methods to alleviate state space explosion.

    • Translate LTL into Buchi automata.



    Why testing
    Why testing? is not preserved?

    • Reduce design/programming errors.

    • Can be done during development, beforeproduction/marketing.

    • Practical, simple to do.

    • Check the real thing, not a model.

    • Scales up reasonably.

    • Being state of the practice for decades.


    Part 1 testing of black box finite state machine
    Part 1: is not preserved? Testing of black box finite state machine

    Wants to know:

    • In what state we started?

    • In what state we are?

    • Transition relation

    • Conformance

    • Satisfaction of a temporal property

    Know:

    • Transition relation

    • Size or bound on size


    Finite automata mealy machines
    Finite automata is not preserved?(Mealy machines)

    S - finite set of states. (size n)

    S– set of inputs. (size d)

    O– set of outputs, for each transition.

    (s0S - initial state).

    • S  S S - transition relation.

       S  S O – output on edge.


    Why deterministic machines
    Why deterministic machines? is not preserved?

    • Otherwise no amount of experiments would guarantee anything.

    • If dependent on some parameter (e.g., temperature), we can determinize, by taking parameter as additional input.

    • We still can model concurrent system. It means just that the transitions are deterministic.

    • All kinds of equivalences are unified into language equivalence.

    • Also: connected machine (otherwise we may never get to the completely separate parts).


    Determ i nism

    a/1 is not preserved?

    b/1

    a/1

    Determinism

    When the black box is nondeterministic, we might never test some choices.


    Preliminaries separating sequences
    Preliminaries: separating sequences is not preserved?

    b/1

    s1

    s2

    a/0

    b/1

    b/0

    a/0

    s3

    a/0

    Start with one block containing all states {s1, s2, s3}.


    A separate to blocks of states with different output
    A: separate to blocks of states with different output. is not preserved?

    b/1

    s1

    s2

    a/0

    b/1

    b/0

    a/0

    s3

    a/0

    Two sets, separated using the string b {s1, s3}, {s2}.


    Repeat b separate blocks based on moving to different blocks
    Repeat B: Separate blocks based on moving to different blocks.

    b/1

    s1

    s2

    a/0

    b/1

    b/0

    a/0

    s3

    a/0

    Separate first block using b to three singleton blocks.Separating sequences: b, bb.Max rounds: n-1, sequences: n-1, length: n-1.For each pair of states there is a separating sequence.


    Want to know the state of the machine at end homing sequence
    Want to know the state of the blocks. machine (at end). Homing sequence.

    Depending on output, would know in what state we are.

    Algorithm: Put all the states in one block (initially we do not know what is the state).

    Then repeatedly partitions blocks of states, as long as they are not singletons, as follows:

    • Take a non singleton block, append a distinguishing sequence  that separates at least two states.

    • Update all blocks to the states after executing .

      Max length: (n-1)2 (Lower bound: n(n-1)/2.)


    Example homing sequence

    b/1 blocks.

    s1

    s2

    a/0

    b/1

    b/0

    a/0

    s3

    a/0

    Example (homing sequence)

    {s1, s2, s3}

    b

    1

    1

    0

    {s1, s2} {s3}

    b

    1

    1

    0

    {s1} {s2} {s3}

    On input b and output 1, still don’t know if was in s1or s3, i.e., if currently in s2 or s1.So separate these cases with another b.


    Synchronizing sequence
    Synchronizing sequence blocks.

    • One sequence takes the machine to the same final state, regardless of the initial state or the outputs.

    • Not every machine has a synchronizing sequence.

    • Can be checked whether exists and can be found in polynomial time.


    State identification
    State identification: blocks.

    • Want to know in which state the system has started (was reset).

    • Can be a preset distinguishing sequence (fixed), or a tree (adaptive).

    • May not exist (PSPACE complete to check if preset exists, polynomial for adaptive).

    • Best known algorithm: exponential length for preset,polynomial for adaptive [LY].


    Sometimes cannot identify initial state

    b/1 blocks.

    a/1

    b/1

    s1

    s2

    a/1

    a/1

    s3

    b/0

    Sometimes cannot identify initial state

    Start with a:in case of being in s1or s3we’ll move to s1and cannot distinguish.Start with b:In case of being in s1or s2we’ll move to s2 and cannot distinguish.

    The kind of experiment we do affects what we can distinguish. Much like the Heisenberg principle in Physics.


    C onformance testing
    C blocks.onformance testing

    • Unknown deterministic finite state system B.

    • Known: n states and alphabet .

    • An abstract model C of B. C satisfies all the properties we want from B.C has m states.

    • Check conformance of B and C.

    • Another version: only a bound n on the number of states l is known.


    Check conformance with a given state machine

    b/1 blocks.

    a/1

    b/1

    s1

    s2

    ?=

    a/1

    a/1

    s3

    b/0

    Check conformance with a given state machine

    • Black box machine has no more states than specification machine (errors are mistakes in outputs, mistargeted edges).

    • Specification machine is reduced, connected, deterministic.

    • Machine resets reliably to a single initial state (or use homing sequence).


    Conformance testing ch v

    a/1 blocks.

    a/1

    b/1

    b/1

    Conformance testing [Ch,V]

    a/1

    b/1

    b/1

    a/1

    a/1

    b/1

    Cannot distinguish if reduced or not.


    Conformance testing cont

    a blocks.

    Conformance testing (cont.)

    b

    b

    a

    a

    a

    a

    b

    b

    a

    a

    b

    Need: bound on number of states of B.


    Preparation construct a spanning tree

    b/1 blocks.

    a/1

    b/1

    s1

    s1

    s2

    a/1

    b/1

    a/1

    s3

    s2

    a/1

    s3

    b/0

    Preparation:Construct a spanning tree


    How the algorithm works
    How the algorithm works? blocks.

    Reset or homing

    Reset or homing

    According to the spanning tree, force a sequence of inputs to go to each state.

    • From each state, perform the distinguishing sequences.

    • From each state, make a single transition, check output, and use distinguishing sequences to check that in correct target state.

    s1

    a/1

    b/1

    s3

    s2

    Distinguishing sequences


    Comments
    Comments blocks.

    • Checking the different distinguishing sequences (m-1 of them) means each time resetting and returning to the state under experiment.

    • A reset can be performed to a distinguished state through a homing sequence. Then we can perform a sequence that brings us to the distinguished initial state.

    • Since there are no more than m states, and according to the experiment, no less than m states, there are m states exactly.

    • Isomorphism between the transition relation is found, hence from minimality the two automata recognize the same languages.


    Combination lock automaton
    Combination lock automaton blocks.

    • Assume accepting states.

    • Accepts only words with a specific suffix (cdab in the example).

    c

    d

    a

    b

    s1

    s2

    s3

    s4

    s5

    Any other input


    When only a bound on size of black box is known
    When only a bound on size of black box is known… blocks.

    • Black box can “pretend” to behave as a specification automaton for a long time, then upon using the right combination, make a mistake.

    a/1

    Pretends to be S1

    b/1

    a/1

    b/1

    b/1

    s1

    s2

    a/1

    a/1

    s3

    Pretends to be S3

    b/0


    Conformance testing algorithm vc
    Conformance testing algorithm [VC] blocks.

    Reset or homing

    Reset or homing

    • The worst that can happen is a combination lock automaton that behaves differently only in the last state. The length of it is the difference between the size n of the black box and the specification m.

    • Reach every state on the spanning tree and check every word of length n-m+1 or less. Check that after the combination we are at the state we are supposed to be, using the distinguishing sequences.

    • No need to check transitions: already included in above check.

    • Complexity: m2 n dn-m+1 Probabilistic complexity: Polynomial.

    s1

    a/1

    b/1

    s3

    s2

    Words of length n-m+1

    Distinguishing sequences


    Model checking1
    Model Checking blocks.

    • Finite state description of a system B.

    • LTL formula . Translate  into an automaton P.

    • Check whether L(B)  L(P)=.

    • If so, S satisfies . Otherwise, the intersection includes a counterexample.

    • Repeat for different properties.

    


    Buchi automata w automata
    Buchi automata ( blocks.w-automata)

    S - finite set of states. (B has l n states)

    S0S - initial states. (P has m states)

    S - finite alphabet. (contains p letters)

    d S  SS - transition relation.

    F S - accepting states.

    Accepting run: passes a state in F infinitely often.

    System automata: F=S, deterministic, one initial state.

    Property automaton: not necessarily deterministic.


    Example check a
    Example: check blocks.a

    a

    <>a

    a

    a, a


    Example check a1

    a blocks.

    a

    a

    a

    Example: check <>a

    <>a


    Example check a2
    Example: check blocks. <>a

    a, a

    <>a

    a

    a

    Use automatic translation algorithms, e.g.,

    [Gerth,Peled,Vardi,Wolper 95]


    System

    a blocks.

    c

    b

    System


    Every element in the product is a counter example for the checked property
    Every element in the blocks.product is a counter example for the checked property.

    a

    a

    <>a

    s1

    s2

    q1

    a

    c

    b

    a

    a

    s3

    q2

    a

    s1,q1

    s2,q1

    Acceptance isdetermined byautomaton P.

    b

    a

    s1,q2

    s3,q2

    c


    Model checking testing

    Given Finite state system blocks.B.

    Transition relation of B known.

    Property represent by automaton P.

    Check if L(B)  L(P)=.

    Graph theory or BDD techniques.

    Complexity: polynomial.

    Unknown Finite state system B.

    Alphabet and number of states of B or upper bound known.

    Specification given as an abstract system C.

    Check if B C.

    Complexity: polynomial if number states known. Exponential otherwise.

    Model Checking / Testing


    Black box checking pvy

    Property represent by automaton blocks.P.

    Check if L(B)  L(P)=.

    Graph theory techniques.

    Unknown Finite state system B.

    Alphabet and Upper bound on Number of states of B known.

    Complexity: exponential.

    Black box checking [PVY]

    


    Experiments

    reset blocks.

    a

    a

    b

    b

    c

    c

    try c

    try b

    a

    a

    b

    b

    c

    c

    a

    a

    b

    c

    b

    c

    fail

    Experiments


    Simpler problem deadlock
    Simpler problem: deadlock? blocks.

    • Nondeterministic algorithm:guess a path of length  n from the initial state to a deadlock state.Linear time, logarithmic space.

    • Deterministic algorithm:systematically try paths of length n, one after the other (and use reset), until deadlock is reached.Exponential time, linear space.


    Deadlock complexity
    Deadlock complexity blocks.

    • Nondeterministic algorithm:Linear time, logarithmic space.

    • Deterministic algorithm:Exponential (p n-1) time, linear space.

    • Lower bound: Exponential time (usecombination lock automata).

    • How does this conform with what we know about complexity theory?


    Modeling black box checking
    Modeling blocks. black box checking

    • Cannot model using Turing machines: not all the information about B is given. Only certain experiments are allowed.

    • We learn the model as we make the experiments.

    • Can use the model of games of incomplete information.


    Games of incomplete information
    Games of incomplete information blocks.

    • Two players: $-player, -player (here, deterministic).

    • Finitely many configurations C. Including:Initial Ci , Winning : W+ and W- .

    • An equivalence relation @ on C (the $-player cannot distinguish between equivalent states).

    • Labels L on moves (try a, reset, success, fail).

    • The $-player has the moves labeled the same from configurations that are equivalent.

    • Deterministic strategy for the $-player: will lead to a configuration in W+  W-. Cannot distinguish between equivalent configurations.

    • Nondeterministic strategy: Can distinguish between equivalent configurations..


    Modeling bbc as games
    Modeling BBC as games blocks.

    • Each configuration contains an automaton and its current state (and more).

    • Moves of the $-player are labeled withtry a, reset... Moves of the -player withsuccess, fail.

    • c1@ c2 when the automata in c1and c2 would respond in the same way to the experiments so far.


    A naive strategy for bbc
    A naive strategy for BBC blocks.

    • Learn first the structure of the black box.

    • Then apply the intersection.

    • Enumerate automata with n states (without repeating isomorphic automata).

    • For a current automata and newautomata, construct a distinguishing sequence. Only one of them survives.

    • Complexity: O((n+1)p (n+1)/n!)


    On the fly strategy
    On-the-fly strategy blocks.

    • Systematically (as in the deadlock case), find two sequences v1 and v2 of length <=m n.

    • Applying v1 to P brings us to a state t that is accepting.

    • Applying v2 to P brings us back to t.

    • Apply v1 v2 n to B. If this succeeds,there is a cycle in the intersection labeled with v2, with t as the P (accepting) component.

    • Complexity: O(n2p2mnm).

    v1

    v2


    Learning an automaton
    Learning an automaton blocks.

    • Use Angluin’s algorithm for learning an automaton.

    • The learning algorithm queries whether some strings are in the automaton B.

    • It can also conjecture an automaton Miand asks for a counterexample.

    • It then generates an automaton with more states Mi+1and so forth.


    A strategy based on learning
    A strategy based on learning blocks.

    • Start the learning algorithm.

    • Queries are just experiments to B.

    • For a conjectured automaton Mi , check if Mi  P = 

    • If so, we check conformance of Mi with B ([VC] algorithm).

    • If nonempty, it contains some v1 v2w . We test B with v1 v2n. If this succeeds: error, otherwise, this is a counterexample for Mi .


    Complexity
    Complexity blocks.

    • l - actual size of B.

    • n - an upper bound of size of B.

    • d - size of alphabet.

    • Lower bound: reachability is similar to deadlock.

    • O(l 3 d l + l 2mn) if there is an error.

    • O(l 3 d l + l 2 n dn-l+1+ l 2mn) if there is no error.

      If n is not known, check while time allows.

    • Probabilistic complexity: polynomial.


    Some experiments
    Some experiments blocks.

    • Basic system written in SML (by Alex Groce, CMU).

    • Experiment with black box using Unix I/O.

    • Allows model-free model checking of C code with inter-process communication.

    • Compiling tested code in SML with BBC program as one process.


    Conclusions1
    Conclusions blocks.

    • Black Box Checking: automatic verification of unspecified system.

    • A hard problem, exponential in number of states, but polynomial on average.

    • Implemented, tested.

    • Another use: when the model is given, but is not exact.



    Part 2 software testing
    Part 2: blocks.Software testing

    • Testing is not about showing that there are no errors in the program.

    • Testing cannot show that the program performs its intended goal correctly.

      So, what is software testing?

      Testing is the process of executing the program in order to find errors.

      A successful test is one that finds an error.


    Some software testing stages
    Some software testing stages blocks.

    • Unit testing – the lowest level, testing some procedures.

    • Integration testing – different pieces of code.

    • System testing – testing a system as a whole.

    • Acceptance testing – performed by the customer.

    • Regression testing – performed after updates.

    • Stress testing – checking the code under extreme conditions.

    • Mutation testing – testing the quality of the test suite.


    Some drawbacks of testing
    Some drawbacks of testing blocks.

    • There are never sufficiently many test cases.

    • Testing does not find all the errors.

    • Testing is not trivial and requires considerable time and effort.

    • Testing is still a largely informal task.


    Black box data driven input output testing
    Black-Box (data-driven, input-output) testing blocks.

    The testing is not based on the structure of the program (which is unknown).

    In order to ensure correctness, every possible input needs to be tested - this is impossible!

    The goal: to maximize the number of errors found.


    Testing
    testing blocks.

    White Box

    Is based on the internal structure of the program.

    There are several alternative criterions for checking “enough” paths in the program.

    Even checking all paths (highly impractical) does not guarantee finding all errors (e.g., missing paths!)


    Some testing principles
    Some testing principles blocks.

    • A programmer should not test his/her own program.

    • One should test not only that the program does what it is supposed to do, but that it does not do what it is not supposed to.

    • The goal of testing is to find errors, not to show that the program is errorless.

    • No amount of testing can guarantee error-free program.

    • Parts of programs where a lot of errors have already been found are a good place to look for more errors.

    • The goal is not to humiliate the programmer!


    Inspections and walkthroughs
    Inspections and Walkthroughs blocks.

    • Manual testing methods.

    • Done by a team of people.

    • Performed at a meeting (brainstorming).

    • Takes 90-120 minutes.

    • Can find 30%-70% of errors.


    Code inspection
    Code Inspection blocks.

    • Team of 3-5 people.

    • One is the moderator. He distributes materials and records the errors.

    • The programmer explains the program line by line.

    • Questions are raised.

    • The program is analyzed w.r.t. a checklist of errors.


    Checklist for inspections

    Data declaration blocks.

    All variables declared?

    Default values understood?

    Arrays and strings initialized?

    Variables with similar names?

    Correct initialization?

    Control flow

    Each loop terminates?

    DO/END statements match?

    Input/output

    OPEN statements correct?

    Format specification correct?

    End-of-file case handled?

    Checklist for inspections


    Walkthrough
    Walkthrough blocks.

    • Team of 3-5 people.

    • Moderator, as before.

    • Secretary, records errors.

    • Tester, play the role of a computer on some test suits on paper and board.


    Selection of test cases for white box testing
    Selection of test cases blocks.(for white-box testing)

    The main problem is to select a good coverage

    criterion. Some options are:

    • Cover all paths of the program.

    • Execute every statement at least once.

    • Each decision has a true or false value at least once.

    • Each condition is taking each truth value at least once.

    • Check all possible combinations of conditions in each decision.


    Cover all the paths of the program
    Cover all the paths of the program blocks.

    Infeasible.

    Consider the flow diagram on the left.

    It corresponds to a loop.

    The loop body has 5 paths.

    If the loops executes 20

    times there are 5^20 different paths!

    May also be unbounded!


    How to cover the executions
    How to cover the executions? blocks.

    IF (A>1)&(B=0) THEN X=X/A; END;

    IF (A=2)|(X>1) THEN X=X+1; END;

    • Choose values for A,B,X.

    • Value of X may change, depending on A,B.

    • What do we want to cover? Paths? Statements? Conditions?


    Statement coverage execute every statement at least once

    By choosing blocks.

    A=2,B=0,X=3

    each statement will be chosen.

    The case where the tests fail is not checked!

    IF (A>1)&(B=0) THEN X=X/A; END;

    IF (A=2)|(X>1) THEN X=X+1; END;

    Statement coverageExecute every statement at least once

    Now x=1.5


    Decision coverage each decision has a true and false outcome at least once

    Can be achieved using blocks.

    A=3,B=0,X=3

    A=2,B=1,X=1

    Problem: Does not test individual conditions. E.g., when X>1 is erroneous in second decision.

    IF (A>1)&(B=0) THEN X=X/A; END;

    IF (A=2)|(X>1) THEN X=X+1; END;

    Decision coverageEach decision has a true and false outcome at least once.


    Decision coverage

    A=3,B=0,X=3 blocks.

    IF (A>1)&(B=0) THEN X=X/A; END;

    IF (A=2)|(X>1) THEN X=X+1; END;

    Decision coverage

    Now x=1


    Decision coverage1

    A=2,B=1,X=1 blocks.

    The case where A1 and the case where x>1 where not checked!

    IF (A>1)&(B=0) THEN X=X/A; END;

    IF (A=2)|(X>1) THEN X=X+1; END;

    Decision coverage


    Condition coverage each condition has a true and false value at least once

    For example: blocks.

    A=1,B=0,X=3

    A=2,B=1,X=0

    lets each condition be true and false once.

    Problem:covers only the path where the first test fails and the second succeeds.

    IF (A>1)&(B=0) THEN X=X/A; END;

    IF (A=2)|(X>1) THEN X=X+1; END;

    Condition coverageEach condition has a trueand false value at least once.


    Condition coverage

    A=1,B=0,X=3 blocks.

    IF (A>1) & (B=0) THEN X=X/A; END;

    IF (A=2) | (X>1) THEN X=X+1; END;

    Condition coverage


    Condition coverage1

    A=2,B=1,X=0 blocks.

    Did not check the first THEN part at all!!!

    Can use condition+decision coverage.

    IF (A>1)&(B=0) THEN X=X/A; END;

    IF (A=2)|(X>1) THEN X=X+1; END;

    Condition coverage


    Multiple condition coverage test all combinations of all conditions in each test

    A>1,B=0 blocks.

    A>1,B≠0

    A1,B=0

    A1,B≠0

    A=2,X>1

    A=2,X1

    A≠2,X>1

    A≠2,X1

    IF (A>1)&(B=0) THEN X=X/A; END;

    IF (A=2)|(X>1) THEN X=X+1; END;

    Multiple Condition CoverageTest all combinations of all conditions in each test.


    A smaller number of cases

    A=2,B=0,X=4 blocks.

    A=2,B=1,X=1

    A=1,B=0,X=2

    A=1,B=1,X=1

    Note the X=4 in the first

    case: it is due to the fact

    that X changes before

    being used!

    IF (A>1)&(B=0) THEN X=X/A; END;

    IF (A=2)|(X>1) THEN X=X+1; END;

    A smaller number of cases:

    Further optimization: not all combinations.For C /\ D, check (C, D), (C, D), (C, D).For C \/ D, check (C, D), (C, D), (C, D).


    Preliminary relativizing assertions
    Preliminary: blocks.Relativizing assertions

    A

    (B) : x1= y1 * x2 + y2 /\ y2 >= 0

    Relativize B) w.r.t. the assignment becomes B) [Y\g(X,Y)]

    (I.e., (B) expressed w.r.t. variables at A.)

     (B)A =x1=0 * x2 + x1 /\ x1>=0

    Think about two sets of variables,before={x, y, z, …} after={x’,y’,z’…}.

    Rewrite (B) using after, and the assignment as a relation between the set of variables. Then eliminate after.

    Here: x1’=y1’ * x2’ + y2’ /\ y2’>=0 /\x1=x1’ /\ x2=x2’ /\ y1’=0 /\ y2’=x1now eliminate x1’, x2’, y1’, y2’.

    Y=g(X,Y)

    (y1,y2)=(0,x1)

    B

    A

    (y1,y2)=(0,x1)

    B


    Verification conditions tests
    Verification conditions: tests blocks.

    B

    T

    F

    C)  B)= t(X,Y) /\C)

    D)  B)=t(X,Y) /\ D)

    B)= D) /\ y2x2

    t(X,Y)

    C

    D

    B

    T

    F

    y2>=x2

    C

    D


    How to find values for coverage
    How to find values for coverage? blocks.

    • Put true at end of path.

    • Propagate path backwards.

    • On assignment, relativize expression.

    • On “yes” edge of decision, add decision as conjunction.

    • On “no” edge, add negation of decision as conjunction.

    • Can be more specific when calculating condition with multiple condition coverage.

    A>1 & B=0

    no

    yes

    X=X/A

    A=2 | X>1

    true

    no

    yes

    X=X+1

    true


    How to find values for coverage1
    How to find values for coverage? blocks.

    (A≠2 /\ X/A>1) /\ (A>1 & B=0)

    A>1 & B=0

    A≠2 /\ X/A>1

    no

    yes

    Need to find a satisfying assignment:

    A=3, X=6, B=0

    Can also calculate path condition forwards.

    X=X/A

    A≠2 /\ X>1

    A=2 | X>1

    true

    no

    yes

    X=X+1

    true


    How to cover a flow chart
    How to cover a flow chart? blocks.

    • Cover all nodes, e.g., using search strategies: DFS, BFS.

    • Cover all paths (usually impractical).

    • Cover each adjacent sequence of N nodes.

    • Probabilistic testing. Using random number generator simulation. Based on typical use.

    • Chinese Postman: minimize edge traversalFind minimal number of times time to travel each edge using linear programming or dataflow algorithms.Duplicate edges and find an Euler path.


    Test cases based on data flow analysis
    Test cases based on blocks.data-flow analysis

    • Partition the program into pieces of code with a single entry/exit point.

    • For each piece find which variables are set/used/tested.

    • Various covering criteria:

      • from each set to each use/test

      • From each set to some use/test.

    X:=3

    t>y

    x>y

    z:=z+x


    Test case design for black box testing
    Test case design for black box testing blocks.

    • Equivalence partition

    • Boundary value analysis

    • Cause-effect graphs


    Equivalence partition

    Valid equivalence blocks.

    class

    Invalid equivalence

    class

    Specification

    condition

    Equivalence partition

    • Goals:

      • Find a small number of test cases.

      • Cover as much possibilities as you can.

    • Try to group together inputs for which the program is likely to behave the same.


    Example a legal variable
    Example: A legal variable blocks.

    • Begins with A-Z

    • Contains [A-Z0-9]

    • Has 1-6 characters.

    Valid equivalence

    class

    Specification

    condition

    Invalid equivalence

    class

    Starting char

    Starts A-Z

    Starts other

    1

    2

    Chars

    [A-Z0-9]

    Has others

    3

    4

    1-6 chars

    0 chars, >6 chars

    Length

    5

    6

    7


    Equivalence partition cont
    Equivalence partition (cont.) blocks.

    • Add a new test case until all valid equivalence classes have been covered. A test case can cover multiple such classes.

    • Add a new test case until all invalid equivalence class have been covered. Each test case can cover only one such class.

    Valid equivalence

    class

    Invalid equivalence

    class

    Specification

    condition


    Example4

    (6) blocks.

    VERYLONG (7)

    AB36P (1,3,5)

    1XY12 (2)

    A17#%X (4)

    Example

    Valid equivalence

    class

    Specification

    condition

    Invalid equivalence

    class

    Starting char

    Starts A-Z

    Starts other

    1

    2

    Chars

    [A-Z0-9]

    Has others

    3

    4

    1-6 chars

    0 chars, >6 chars

    Length

    5

    6

    7


    Boundary value analysis
    Boundary value analysis blocks.

    • In every element class, select values that are closed to the boundary.

      • If input is within range -1.0 to +1.0, select values -1.001, -1.0, -0.999, 0.999, 1.0, 1.001.

      • If needs to read N data elements, check with N-1, N, N+1. Also, check with N=0.


    Test case generation based on ltl specification

    LTL blocks.Aut

    Model

    Checker

    Path

    Path condition

    calculation

    Flowchart

    Compiler

    Transitions

    First order

    instantiator

    Test

    monitoring

    Test case generation based on LTL specification


    Goals
    Goals blocks.

    • Verification of software.

    • Compositional verification. Only a unit of code.

    • Parametrized verification.

    • Generating test cases.

      A path found with some truth assignment satisfying the path condition. In deterministic code, this assignment guarantees to derive the execution of the path.

      In nondeterministic code, this is one of the possibilities.Can transform the code to force replying the path.


    Divide and conquer
    Divide and Conquer blocks.

    • Intersect property automaton with theflow chart, regardless of the statements and program variables expressions.

    • Add assertions from the property automaton to further restrict the path condition.

    • Calculate path conditions for sequences found in the intersection.

    • Calculate path conditions on-the-fly. Backtrack when condition is false.Thus, advantage to forward calculation of path conditions (incrementally).


    Spec at l 2 u at l 2 at l 2 at l 2 u at l 2

    l blocks.2:x:=x+z

    l3:x<t

    l1:…

    Spec:¬at l2U (at l2/\¬at l2/\(¬at l2U at l2))

    l2:x:=x+z

    ¬at l2

    X

    =

    at l2

    l3:x<t

    ¬at l2

    l2:x:=x+z

    at l2


    Spec at l 2 u at l 2 x y at l 2 at l 2 u at l 2 x 2 y

    l blocks.2:x:=x+z

    l3:x<t

    l1:…

    Spec: ¬at l2U (at l2/\ xy /\ (¬at l2/\(¬at l2U at l2 /\ x2y )))

    xy

    l2:x:=x+z

    ¬at l2

    X

    =

    at l2/\

    xy

    l3:x<t

    x2y

    ¬at l2

    l2:x:=x+z

    at l2/\

    x2y


    Example gcd

    l blocks.0

    Example: GCD

    l1:x:=a

    l2:y:=b

    l3:z:=x rem y

    l4:x:=y

    l5:y:=z

    no

    l6:z=0?

    yes

    l7


    Example gcd1

    l blocks.0

    Example: GCD

    l1:x:=a

    l2:y:=b

    Oops…with an error (l4 and l5 were switched).

    l3:z:=x rem y

    l4:y:=z

    l5:x:=y

    no

    l6:z=0?

    yes

    l7


    Why use temporal specification
    Why use Temporal specification blocks.

    • Temporal specification for sequential software?

    • Deadlock? Liveness? – No!

    • Captures the tester’s intuition about the location of an error:“I think a problem may occur when the program runs through the main while loop twice, then the if condition holds, while t>17.”


    Example gcd2

    l blocks.0

    Example: GCD

    l1:x:=a

    l2:y:=b

    a>0/\b>0/\at l0 /\at l7

    l3:z:=x rem y

    at l0/\a>0/\b>0

    l4:y:=z

    l5:x:=y

    no

    l6:z=0?

    yes

    at l7

    l7


    Example gcd3

    l blocks.0

    Example: GCD

    l1:x:=a

    l2:y:=b

    a>0/\b>0/\at l0/\at l7

    l3:z:=x rem y

    Path 1: l0l1l2l3l4l5l6l7a>0/\b>0/\a rem b=0

    Path 2: l0l1l2l3l4l5l6l3l4l5l6l7a>0/\b>0/\a rem b0

    l4:y:=z

    l5:x:=y

    no

    l6:z=0?

    yes

    l7


    Potential explosion
    Potential explosion blocks.

    Bad point: potential explosion

    Good point: may be chopped on-the-fly


    Drivers and stubs
    Drivers and Stubs blocks.

    l0

    l1:x:=a

    l2:y:=b

    • Driver: represents the program or procedure that called our checked unit.

    • Stub: represents a procedure called by our checked unit.

    • In our approach: replace both of them with a formula representing the effect the missing code has on the program variables.

    • Integrate the driver and stub specification into the calculation of the path condition.

    l3:z’=x rem y

    /\x’=x/\y’=x

    l4:y:=z

    l5:x:=y

    no

    l6:z=0?

    yes

    l7


    Conclusions2
    Conclusions blocks.

    • Black box testing: Know transition relation,or bound on number of states, want to find initialstate, structure, conformance, temporal property.

    • Software testing:Unit testing, code inspection, coverage, test case generation.

    • Model checking and testing have a lot in common.


    ad