Outline Lecture 1, part 1 Motivation Model Checking Lecture 1, - - PowerPoint PPT Presentation
Outline Lecture 1, part 1 Motivation Model Checking Lecture 1, part 2 State/Event-based software model checking Lecture 2 Component Substitutability Substitutability Check Assembly A P ? Component C Component C
Lecture 1, part 1
Lecture 1, part 2
Lecture 2
Assembly A
Component C Component C’
P ?
– Software modules shipped by separate developers – An assembly consists of several components – Undergo several updates/bug-fixes during their lifecycle
– Necessary on update of any component – High verification costs of global properties – Instead check for substitutability of new component
– Check if C’ is substitutable for C in A
– Containment check
– Compatibility check
specifications satisfied
– Obtain a finite behavioral model of all components by abstraction: labeled kripke structures – Use regular language inference in combination with a model checker
– <Q,Σ,T,P,L>
– Synchronize on shared actions
– <p,β,q,γ, …..>
p !q q
β α
γ !p
– A set of communicating concurrent C programs or libraries
– Abstracted into a Component Interface LKS – Communication between components is abstracted into interface actions
C1 C2 C3 M1 M2 M3 Component C Component LKS M
Predicate Abstraction
L* learner
counterexample
Minimally adequate Teacher
I sMem ber( trace ρ ) I sCandidate( DFA D )
a b a b
Unknown Regular Language
± Counterexam ple/ Yes
Modelchecker
Yes/ No
Minim um DFA
– Learn useful behaviors from previous component into the new one
– Unknown U = L(M’) ∪ (L(M)\ L(B)) – Iteratively learn the DFA SM’i using L*
– IsMember Query: ρ ∈ U – IsCandidate Query: U ≡ L(SM’i)
M M’
B
IsMember Query: ρ ∈ U IsCandidate Query: U ≡ L(SM’i)
L* Learner
Modelchecker
Old
Component LKS
M
New
Component LKS
M’
+
Bug LKS
SM’
– Containment allows adding new behaviors in M’ e.g. M, M’ have different interleavings of same interface actions – Erroneous new behavior detected in Compatibility check
– substitutable candidate – may not be safe with respect to other components – must verify the global behavioral specifications
– A: most general environment so that P holds – Constructed iteratively using L* and R1, R2
R1: M1 || A ² P R2: M2 ² A M1 || M2 ² P
R1: M1 || Ai ² P R2: M2 ² Ai
true
L* Assumption Generation
Ai
true true CE ρ
CE Analysis
True CE M1 | | ρ P False CE
+ CE for Ai
– M1 = SM’ – M2 = M\ M (all other component LKSs)
– SM’ || ρ ⊆ P
– SM’ || A ⊆ P – M2 ⊆ A
– Yes ⇒ False CE – No ⇒ True CE
– Either SM’ is substitutable – Or counterexample CE
– CE is present in component LKS M or M’ – Must refine M, M’ – Repeat substitutability check
C C’ A\ A\ C
Containment
U ≡ L(SM’i) L* SM’
Compatibility
SM’ || A ² P M \ M ² A
true Provide SM’ to developer
M \ M
M M’ B
Predicate Abstraction
false
CE
spurious? refine M, M’ SM’ not substitutable, CE provided
– LKS showing how SM’ differs from M’
– counterexample showing the erroneous behavior in M’
– Do not consider state labeling of abstract models – Do not incorporate a CEGAR framework for AG
– Do not consider temporal sequence of actions in generating invariants
– Do not have CEGAR, AG – No procedure for computing interface automata
framework
– modified WriteMessageToQueue component – checked for substitutability inside the assembly of four components (read, write, queue, critical section)
ComFoRT: Component Formal Reasoning Framework
High-level Specification
System Design MODEL CHECKER Formal Model
Temporal Properties
DESIGN CORRECT
SYSTEM SYSTEM ENGINEERING ENGINEERING FORMAL FORMAL VERIFICATION VERIFICATION