Software Specification, Verification and Validation CIS 775

1
Software Specification, Verification and
Validation (CIS 775)

• Elsa L Gunter
• 4303 GITC
• NJIT, http//www.cs.njit.edu/elsa/775-spring2004

2
Verification problem

• Want to know that every behavior of
  implementation is allowed by specification
• Be(I) behaviors of implementation
• Be(S) behaviors specification
• Need Be(I) ? Be(S)

3
Correctness
Behaviors satisfying Spec Be(S)
All behaviors
4
Model checking properties

• Express implementation as transition system
• Translate transition system into Buchi automaton
  AI
• Express property as LTL formula
• Formula should refer to states of implementation
  specification

5
Model checking properties

• Negate LTL formula
• Translate negated LTL formula into Buchi
  Automaton A?S
• Check if L(AI) ?L(A?S ) ?
• Same as L(AI) ?L(AS )

6
Correctness
Sequences satisfying Spec L(AS)
All sequences
7
Correctness
Program executions L(AI)
Sequnces satisfying L(A?S)
8
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.

9
Combining Automata

• Given two Buchi automata over the same alphabet A
  lt ?,S1, ?1,I1,L1,F1 gt and B lt ?,S2, ?2, I2,
  L2, F2 gt want an automaton A o B whose language
  L(AoB)L(A) ?L(B)

10
A o B

• States S (s1,s2,i) s1? S1, s2? S2, I 1,2
• Initial states I (I1?I2 ?1)
• Accepting states
• F (F1 ? S2 ? 1 ? S1 ? F2 ? 2)
• Transitions ? ((s1,s2,i), (s1,s2,i)
  (s1,s1) ? ?1 and (s2,s2) ? ?2, and s1? F1 and
  s2? F2
• Labels L(s1,s2,i) L1(s1) ? L2(s2)
• Simplification remove (s1,s2,i) where
  L1(s1) ? L2(s2)?

11
A o B

• If F1 S1 then can take
• States S (s1,s2,i) s1? S1, s2? S2
• Initial states I (I1?I2 ) ? S
• Accepting states F (F1?F2) ? S
• Transitions ? ((s1,s2), (s1,s2) (s1,s1)
  ? ?1 and (s2,s2) ? ?2
• Labels L(s1,s2) L1(s1) ? L2(s2)
• Simplification remove (s1,s2) where L1(s1) ?
  L2(s2)?

12
Example

• Recall spring example
• Consider property
• ltgt extended

13
Example

• Negate property
• ? ltgt extended ltgt?extended

true
extended
14
Spring o ltgt?extended
release
s1,t
s3,t
s2,t
pull
release
release
s1,ne
s3,ne
s2,ne
pull
release
15
Spring o ltgt?extended
extended not malfunctioned
not extended not malfunctioned
extended malfunctioned
release
s1,t
s3,t
s2,t
pull
release
release
s1,ne
s3,ne
s2,ne
pull
release
extended malfunctioned and not extended
not extended not malfunctioned not extended
extended not malfunctioned and not extended
16
Spring o ltgt?extended
extended not malfunctioned
not extended not malfunctioned
extended malfunctioned
release
s1,t
s3,t
s2,t
pull
release
release
s1,ne
s3,ne
s2,ne
pull
release
extended malfunctioned and not extended
not extended not malfunctioned not extended
extended not malfunctioned and not extended
17
Spring o ltgt?extended
extended not malfunctioned
not extended not malfunctioned
extended malfunctioned
release
s1,t
s3,t
s2,t
pull
release
No accepted behaviors!
s1,ne
not extended not malfunctioned not extended
18
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!

19
Depth First Search

• Procedure dfs(s,p)
• If p(s) then return s
• else
• for each s such that R(s,s) do
• if new(s)
• then if dfs(s) s
• then return s
• else next s
• else next s
• return fail
• end dfs.

• Program DFS
• For each s such that Init(s)
• dfs(s,p)
• end DFS

20
Start from an initial state
Hash table
q1
q1
q3
q2
Stack
q1
q4
q5
21
Continue with a successor
Hash table
q1
q1 q2
q3
q2
Stack
q1 q2
q4
q5
22
One successor of q2.
Hash table
q1
q1 q2 q4
q3
q2
Stack
q1 q2 q4
q4
q5
23
Backtrack to q2 (no new successors for q4).
Hash table
q1
q1 q2 q4
q3
q2
Stack
q1 q2
q4
q5
24
Backtracked to q1
Hash table
q1
q1 q2 q4
q3
q2
Stack
q1
q4
q5
25
Second successor to q1.
Hash table
q1
q1 q2 q4 q3
q3
q2
Stack
q1 q3
q4
q5
26
Backtrack again to q1.
Hash table
q1
q1 q2 q4 q3
q3
q2
Stack
q1
q4
q5
27
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

28
How can we check LTL properties with DFS?

• Need to check no sequence of properties has an
  execution passing through an accepting state
  infinitely often
• Path passes through a state infinitely many times
  only if there is a cylce in graph containing that
  state
• DFS for a state that is an accepting state and
  through which passes a cycle
• Requires second DFS at each node for a cycle

29
How to check for emptiness?
A
S0,T0
S0,T1
S1,T0
B
A
C
S1,T1
B
C
30
Emptiness...

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

31
Finding accepting runs

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

32
Equivalently...

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

33
Model Checking under Fairness

• Express the fairness as a property Fair.To prove
  a property Fair under fairness,model check
  Fair?Spec.

Counter example
Fair
Bad (Spec)
Program
34
Model Checking under Fairness

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

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

• Model checking work only for finite state
  systems. Would not work with
• Unconstrained integers.
• Unbounded message queues.
• General data structures
• queues
• trees
• stacks
• parametric algorithms and systems.

36
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 232 possibilities. Two
  such variables have 264 possibilities.
• In concurrent protocols, the number of states
  usually grows exponentially with the number of
  processes.

37
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 (BDDs, Partial Order Reduction).

38
(No Transcript)
39
L(AoB) ? L(A) ?L(B)

• Execution (?1, ?2, ?3, ) ? L(AoB) if there
  exist states (s1,s1),(s2,s2),(s3, s3), where
  each (si, si1) ? ?1 and (si, si1) ? ?2 and
  each ?i ? L1(si) ? L2(si)
• s1, s2, s3, sequence of states in A such that ?i
  ? L1(si)
• (?1, ?2, ?3, ) ? L(A)
• s1, s2, s3,sequence of states in B such that
  ?i ? L2(si)
• (?1, ?2, ?3, ) ? L(B)

40
L(A) ?L(B) ? L(AoB)

• Execution (?1, ?2, ?3, ) ? L(A) ? L( B)
• s1, s2, s3, sequence of states in A such that
  each (si, si1) ? ?1 and ?i ? L1(si)
• s1, s2, s3,sequence of states in B such that
  each (si, si1) ? ?2 and ?i ? L2(si)
• Then (s1,s1),(s2,s2),(s3, s3), sequence in
  AoB with each ((si, si),(si1,si1)) ? ? and ?i
  ? L1(si) ? L2(si) L(si, si)
• (?1, ?2, ?3, ) ? L(AoB)