Procedure-Modular Veriﬁcation of Temporal Safety Propertiessiavashs/lic-presentation.pdf ·...

Procedure-Modular Verification of Temporal Safety Properties

Siavash Soleimanifard

School of Computer Science and CommunicationKTH Royal Institute of Technology

Stockholm

Licentiate Thesis Presentation23 May 2012

Wednesday, May 23, 2012

Outline• Scope and goal

•Modular verification

• CVPP framework & toolset

• Contributions

• ProMoVer

• Verification of product families

• Boolean flow graphs

• Conclusion & future work


Scope and Goals• Verification of software systems in the

presence of variability




- open systems




- open systems

- mobile code




- open systems

- mobile code

- code evolution




- open systems

- mobile code

- code evolution

- multiple implementation




- open systems

- mobile code

- code evolution

- multiple implementation

• Any solution should be modular


Modular Verification



A

B



A

B

Code



A

B: θ

Code

Global Property



A

B

φA

: θ

Code

Global Property



A

B

φA

φB

: θ

Code

Global Property



A

B

φA

φB

: θ

Code

Specification

Global Property



A

B

φA

φB

: θ

Task I: Local Check



A

B

φA

φB

: θ

Task II: Global Check


Modularity & Variability

A

B

φA

φB

: θ

• Code evolution

•Multiple implementations

•Open sys. & Mobile code



A

B

φA

φB

: θ

• Code evolution





A φA

φB

: θ

• Code evolution





A φA

φB• Code evolution


: θ




A

B

φA

φB

: θ

• Code evolution





A

B

φA

φB

: θ

• Code evolution





A

B

φA

φB

: θ

• Code evolution





A

B

φA

φB

: θ

• Code evolution





A

B’

φA

φB

: θ

• Code evolution





A

B’

φA

φB

: θ

• Code evolution





A φA

φB

: θ

• Code evolution


- Product Families

B

BI BII




A φA

φB

: θ

• Code evolution


- Product Families

B

BI BIIφBIIφBI




A φA

φB

: θ

• Code evolution


- Product Families

B

BI BIIφBIIφBI




A φA

φB

: θ

• Code evolution


- Product Families

B

BI BIIφBIIφBI




A φA

φB

: θ

• Code evolution


- Product Families

B

BI BIIφBIIφBI




A φA

φB• Code evolution


- Product Families

B

BI BIIφBIIφBI

: θ



Existing Techniques• Hoare logic

- procedure-modular verification

- predicate logic

- theorem proving

•Modular verification and model checking

- flexible level of granularity

- temporal logic

- model checking


Modular Verification•O. Grumberg and D. Long 1994

- finite-state models

- maximal models

•D. Gurov, M. Huisman and C. Sprenger 2004

- infinite-state models (pushdown systems)

- maximal models

- CVPP framework


CVPP

A

B: θ

• Verify specs locally

• Construct maximal models from local specs

• Compose Max model

• Model check global property


CVPP

A

B: θ





•Temporal control flow•Legal sequences of method invocation- a method to change sensitive data is

only called within authentication method


CVPP

A

B: θ






CVPP

A

B

φA

: θ• Verify specs locally




• Specify modules


CVPP

A

B

φA

φB





• Specify modules


CVPP

A

B

φA

φB





• Specify modules

•Abstract•Prohibiting illegal function calls sequences


CVPP

A

B

φA

φB





• Specify modules


CVPP

A

B

φA

φB





• Specify modules

Simulation Logic

φ ::= p | ¬p | X | φ1 ∧ φ2 | φ1 ∨ φ2 | [a]φ | νX. φ


CVPP

A

B

φA

φB





• Specify modules


CVPP

A

B

φA

φB





• Specify modules


CVPP

A

B

φA

φB





• Specify modules

•Extract Flow Graphs from module code-Finite-State transition system-Abstract away all program data-Program structure

•Employ standard model checking for verification


CVPP

A

B

φA

φB





• Specify modules


CVPP

A

B

φA

φB





• Specify modules


CVPP

A

B

φA

φB

: θ

MaxφA• Verify specs locally




• Specify modules


CVPP

A

B

φA

φB

: θ

MaxφA

MaxφB





• Specify modules


CVPP

A

B

φA

φB

: θ

MaxφA

MaxφB





• Specify modules

•Flow Graph of property -Simulates all flow graphs satisfying -Program structure-Finite-State transition system

φA

φA


CVPP

A

B

φA

φB

: θ

MaxφA

MaxφB





• Specify modules


CVPP

A

B

φA

φB

: θ

MaxφA

MaxφB





• Specify modules


CVPP

A

B

φA

φB

: θ

MaxφA

MaxφB





• Specify modules

Push Down Automata


CVPP

A

B

φA

φB

: θ

MaxφA

MaxφB





• Specify modules



CVPP

A

B

φA

φB

MaxφA

MaxφB




• Specify modules

: θ



CVPP

A

B

φA

φB

MaxφA

MaxφB




• Specify modules

: θ

Employ PDA/PDS model checking, Moped



CVPP

A

B

φA

φB

MaxφA

MaxφB




• Specify modules

: θ


Example Flow Graph:class Number {

}

if (n == 0) public static boolean even(int n){

return true; else

return odd(n−1); }

public static boolean odd(int n){

if (n == 0)

else

return even(n−1);

}

return false;

v5

v6

v7

v1

v3 v9

v0

v2

v4 v8

!

!

!

!

!

!

even

even

even

odd

odd

odd

even

even, r reven, rr odd, odd,

odd

Example Run:

(v0, !)"!"b (v1, !)

"!"b (v2, !)

even call odd!!!!!!!!!"b (v5, v3)

"!"b (v6, v3)

"!"b

(v7, v3)odd call even!!!!!!!!!"b (v0, v9 · v3)

"!"b (v1, v9 · v3)

"!"b

(v4, v9 · v3)even ret odd!!!!!!!!"b (v9, v3)

odd ret even!!!!!!!!"b (v3, !)

Dilian Gurov: Compositional Verification of Control–Flow Safety Properties 6

CVPP -- Program Model

Flow Graph:



}


return true; else



if (n == 0)

else

return even(n−1);

}

return false;

v5

v6

v7

v1

v3 v9

v0

v2

v4 v8

!

!

!

!

!

!

even

even

even

odd

odd

odd

even


odd

Example Run:

(v0, !)"!"b (v1, !)

"!"b (v2, !)


"!"b (v6, v3)

"!"b


"!"b (v1, v9 · v3)

"!"b





Flow Graph:



}


return true; else



if (n == 0)

else

return even(n−1);

}

return false;

v5

v6

v7

v1

v3 v9

v0

v2

v4 v8

!

!

!

!

!

!

even

even

even

odd

odd

odd

even


odd

Example Run:

(v0, !)"!"b (v1, !)

"!"b (v2, !)


"!"b (v6, v3)

"!"b


"!"b (v1, v9 · v3)

"!"b





Flow Graph:

even(3)odd(2)even(1)odd(0)return false

even(2)odd(1)even(0)return true



}


return true; else



if (n == 0)

else

return even(n−1);

}

return false;

v5

v6

v7

v1

v3 v9

v0

v2

v4 v8

!

!

!

!

!

!

even

even

even

odd

odd

odd

even


odd

Example Run:

(v0, !)"!"b (v1, !)

"!"b (v2, !)


"!"b (v6, v3)

"!"b


"!"b (v1, v9 · v3)

"!"b





Flow Graph:



}


return true; else



if (n == 0)

else

return even(n−1);

}

return false;

v5

v6

v7

v1

v3 v9

v0

v2

v4 v8

!

!

!

!

!

!

even

even

even

odd

odd

odd

even


odd

Example Run:

(v0, !)"!"b (v1, !)

"!"b (v2, !)


"!"b (v6, v3)

"!"b


"!"b (v1, v9 · v3)

"!"b





Flow Graph:



}


return true; else



if (n == 0)

else

return even(n−1);

}

return false;

v5

v6

v7

v1

v3 v9

v0

v2

v4 v8

!

!

!

!

!

!

even

even

even

odd

odd

odd

even


odd

Example Run:

(v0, !)"!"b (v1, !)

"!"b (v2, !)


"!"b (v6, v3)

"!"b


"!"b (v1, v9 · v3)

"!"b





Flow Graph:



}


return true; else



if (n == 0)

else

return even(n−1);

}

return false;

v5

v6

v7

v1

v3 v9

v0

v2

v4 v8

!

!

!

!

!

!

even

even

even

odd

odd

odd

even


odd

Example Run:

(v0, !)"!"b (v1, !)

"!"b (v2, !)


"!"b (v6, v3)

"!"b


"!"b (v1, v9 · v3)

"!"b





Flow Graph:



Flow Graph:

Example Run:

Behavior of Closed Flow Graph

v5

v6

v7

v1

v3 v9

v0

v2

v4 v8

!

!

!

!

!

!

even

even

even

odd

odd

odd

even

even, r reven,rr odd, odd,

odd


return true; else return odd(n−1); }

public static boolean odd(int n){ if (n == 0)

else return even(n−1);

}}

return false;

class Number {

Figure: Flow graph of Number

(v0, !)!!"(v1, !)

!!"(v2, !)

even call odd!!!!!!!!"(v5, v3)

!!"(v6, v3)

!!"

(v8, v3)odd ret even!!!!!!!"(v3, !)


return true; else return odd(n 1); }


else return even(n 1);

}

return false;

}

v5

v6

v7

v1

v3 v9

v0

v2

v4 v8

even

even

even

odd

odd

odd

even


odd

class Number {



Flow Graph:

Example Run:


v5

v6

v7

v1

v3 v9

v0

v2

v4 v8

!

!

!

!

!

!

even

even

even

odd

odd

odd

even


odd





}}

return false;

class Number {


(v0, !)!!"(v1, !)

!!"(v2, !)


!!"(v6, v3)

!!"

(v8, v3)odd ret even!!!!!!!"(v3, !)





}

return false;

}

v5

v6

v7

v1

v3 v9

v0

v2

v4 v8

even

even

even

odd

odd

odd

even


odd

class Number {



Flow Graph:

Example Run:


v5

v6

v7

v1

v3 v9

v0

v2

v4 v8

!

!

!

!

!

!

even

even

even

odd

odd

odd

even


odd





}}

return false;

class Number {


(v0, !)!!"(v1, !)

!!"(v2, !)


!!"(v6, v3)

!!"

(v8, v3)odd ret even!!!!!!!"(v3, !)





}

return false;

}

v5

v6

v7

v1

v3 v9

v0

v2

v4 v8

even

even

even

odd

odd

odd

even


odd

class Number {



Flow Graph:

Example Run:


v5

v6

v7

v1

v3 v9

v0

v2

v4 v8

!

!

!

!

!

!

even

even

even

odd

odd

odd

even


odd





}}

return false;

class Number {


(v0, !)!!"(v1, !)

!!"(v2, !)


!!"(v6, v3)

!!"

(v8, v3)odd ret even!!!!!!!"(v3, !)





}

return false;

}

v5

v6

v7

v1

v3 v9

v0

v2

v4 v8

even

even

even

odd

odd

odd

even


odd

class Number {



Flow Graph:

Example Run:


v5

v6

v7

v1

v3 v9

v0

v2

v4 v8

!

!

!

!

!

!

even

even

even

odd

odd

odd

even


odd





}}

return false;

class Number {


(v0, !)!!"(v1, !)

!!"(v2, !)


!!"(v6, v3)

!!"

(v8, v3)odd ret even!!!!!!!"(v3, !)





}

return false;

}

v5

v6

v7

v1

v3 v9

v0

v2

v4 v8

even

even

even

odd

odd

odd

even


odd

class Number {



Flow Graph:

Example Run:


v5

v6

v7

v1

v3 v9

v0

v2

v4 v8

!

!

!

!

!

!

even

even

even

odd

odd

odd

even


odd





}}

return false;

class Number {


(v0, !)!!"(v1, !)

!!"(v2, !)


!!"(v6, v3)

!!"

(v8, v3)odd ret even!!!!!!!"(v3, !)





}

return false;

}

v5

v6

v7

v1

v3 v9

v0

v2

v4 v8

even

even

even

odd

odd

odd

even


odd

class Number {



Flow Graph:

Example Run:


v5

v6

v7

v1

v3 v9

v0

v2

v4 v8

!

!

!

!

!

!

even

even

even

odd

odd

odd

even


odd





}}

return false;

class Number {


(v0, !)!!"(v1, !)

!!"(v2, !)


!!"(v6, v3)

!!"

(v8, v3)odd ret even!!!!!!!"(v3, !)





}

return false;

}

v5

v6

v7

v1

v3 v9

v0

v2

v4 v8

even

even

even

odd

odd

odd

even


odd

class Number {


CVPP -- Maximal Models

Local Specification for method even:

method even can only call method odd, and after returning from the call, no other method can be called





!

v0 v1 even

even

odd

!

!even,r

odd

v2v3 even,r

!





!

v0 v1 even

even

odd

!

!even,r

odd

v2v3 even,r

!





!

v0 v1 even

even

odd

!

!even,r

odd

v2v3 even,r

!





!

v0 v1 even

even

odd

!

!even,r

odd

v2v3 even,r

!


Contributions


Contributions• Full automation of the usage of CVPP

- ProMoVer: procedure-modular verification

- Annotation language

• Enhancing the usability

- Different specification languages

- Specification extraction

- Proof storage and reuse


Contributions• Evaluating and identifying application areas

- Experiments with product families

• Extending the class of properties

- Encoding data from finite domains through control


Papers• ProMoVer

- Siavash Soleimanifard, Dilian Gurov, and Marieke Huisman. Procedure-modular verification of control flow safety properties. In FTfJP ’10

- Siavash Soleimanifard, Dilian Gurov, and Marieke Huisman. ProMoVer: Modular verification of temporal safety properties. In SEFM ’11

- Siavash Soleimanifard, Dilian Gurov, and Marieke Huisman. Procedure-modular specification and verification of temporal safety properties. Submitted to the SoSyM special issue on SEFM 2011.

• Product Families

- Ina Schaefer, Dilian Gurov, and Siavash Soleimanifard. Compositional algorithmic verification of software product lines. In FMCO ’10


ProMoVer


ProMoVer -- Usage

/ * * * @ g l o b a l _ l t l _ p r o p : * e v e n - > X ( ( e v e n & & ! e n t r y ) W o d d ) * /p u b l i c c l a s s N u m b e r { / * * @ l o c a l _ i n t e r f a c e : r e q u i r e d o d d * @ l o c a l _ s l _ p r o p : * n u X 1 . ( ( [ e v e n c a l l e v e n ] f f ) / \ ( [ t a u ] X 1 ) / \ [ e v e n c a r e t o d d ] * n u X 2 . ( ( [ e v e n c a l l e v e n ] f f ) / \ ( [ e v e n c a r e t o d d ] f f ) / \ ( [ t a u ] X 2 ) ) ) * @ l o c a l _ l t l _ p r o p : * G ( X ( ! e v e n | | ! e n t r y ) & & ( o d d - > X G e v e n ) ) * / p u b l i c b o o l e a n e v e n ( i n t n ) { i f ( n = = 0 ) r e t u r n t r u e ; e l s e r e t u r n o d d ( n - 1 ) ; } / * * @ l o c a l _ i n t e r f a c e : r e q u i r e d e v e n * @ l o c a l _ s l _ p r o p : * n u X 1 . ( ( [ o d d c a l l o d d ] f f ) / \ ( [ t a u ] X 1 ) / \ [ o d d c a r e t e v e n ] * n u X 2 . ( ( [ o d d c a l l o d d ] f f ) / \ ( [ o d d c a r e t e v e n ] f f ) / \ ( [ t a u ] X 2 ) ) ) * @ l o c a l _ l t l _ p r o p : * G ( X ( ! o d d | | ! e n t r y ) & & ( e v e n - > X G o d d ) ) * / p u b l i c b o o l e a n o d d ( i n t n ) { i f ( n = = 0 ) r e t u r n f a l s e ; e l s e r e t u r n e v e n ( n - 1 ) ; }}


ProMoVer -- Usage




ProMoVer -- Usage/ * * * @ g l o b a l _ l t l _ p r o p : * e v e n - > X ( ( e v e n & & ! e n t r y ) W o d d ) * /p u b l i c c l a s s N u m b e r { / * * @ l o c a l _ i n t e r f a c e : r e q u i r e d o d d * @ l o c a l _ s l _ p r o p : * n u X 1 . ( ( [ e v e n c a l l e v e n ] f f ) / \ ( [ t a u ] X 1 ) / \ [ e v e n c a r e t o d d ] * n u X 2 . ( ( [ e v e n c a l l e v e n ] f f ) / \ ( [ e v e n c a r e t o d d ] f f ) / \ ( [ t a u ] X 2 ) ) ) * @ l o c a l _ l t l _ p r o p : * G ( X ( ! e v e n | | ! e n t r y ) & & ( o d d - > X G e v e n ) ) * / p u b l i c b o o l e a n e v e n ( i n t n ) { i f ( n = = 0 ) r e t u r n t r u e ; e l s e r e t u r n o d d ( n - 1 ) ; } / * * @ l o c a l _ i n t e r f a c e : r e q u i r e d e v e n * @ l o c a l _ s l _ p r o p : * n u X 1 . ( ( [ o d d c a l l o d d ] f f ) / \ ( [ t a u ] X 1 ) / \ [ o d d c a r e t e v e n ] * n u X 2 . ( ( [ o d d c a l l o d d ] f f ) / \ ( [ o d d c a r e t e v e n ] f f ) / \ ( [ t a u ] X 2 ) ) ) * @ l o c a l _ l t l _ p r o p : * G ( X ( ! o d d | | ! e n t r y ) & & ( e v e n - > X G o d d ) ) * / p u b l i c b o o l e a n o d d ( i n t n ) { i f ( n = = 0 ) r e t u r n f a l s e ; e l s e r e t u r n e v e n ( n - 1 ) ; }}


method odd can only call method even, and after returning from the call, no other method can be called


ProMoVer -- Usage



method odd can only call method even, and after returning from the call, no other method can be called

in every program execution starting in method even, the first call is not to method even itself


ProMoVer -- Usage



ProMoVer -- Usage


Verification Result:YES


ProMoVer -- Usage


in every program execution starting in method even, the first call IS to method even itself


ProMoVer -- Usage


in every program execution starting in method even, the first call IS to method even itself

Verification Result:No

(even, ε) even call odd−−−−−−−−→(odd, even) odd ret even−−−−−−−→(even, ε)


ProMoVer

(i)

Method name

Graph Tool

CWB

YES/NO+

Lo

cal

Pro

per

ties

ProMoVer

Analyzer(ii)

Counter exampleYES/NO+

YES/NO+Method name orModal equation system

Annotated Java Program

Glo

bal

Pro

per

ties

YES/NO+Counter ex. or

Max. Model

Graph Tool

Moped

Post!Processor

Pre!Processor


ProMoVer

Local Verification

(i)

Method name

Graph Tool

CWB

YES/NO+

Lo

cal

Pro

per

ties

ProMoVer

Analyzer(ii)




Glo

bal

Pro

per

ties


Max. Model

Graph Tool

Moped

Post!Processor

Pre!Processor


ProMoVer

Local Verification

Global Entailment

(i)

Method name

Graph Tool

CWB

YES/NO+

Lo

cal

Pro

per

ties

ProMoVer

Analyzer(ii)




Glo

bal

Pro

per

ties


Max. Model

Graph Tool

Moped

Post!Processor

Pre!Processor


ProMoVer•Different specification languages

- Safety fragment of modal mu-calculus

- Modal equation systems

- Safety LTL

- Safety automata

• Specification extractor

• Proof storage and reuse mechanism


ProMoVer

Local Verification

Global Entailment

(i)

Method name

Graph Tool

CWB

YES/NO+

Lo

cal

Pro

per

ties

ProMoVer

Analyzer(ii)




Glo

bal

Pro

per

ties


Max. Model

Graph Tool

Moped

Post!Processor

Pre!Processor


ProMoVer

Store(i)

Method name

Graph Tool

CWB

YES/NO+

Loca

l P

roper

ties

ProMoVer

Analyzer(ii)


Modal equation

StoreStore

Store

Retrieve Retrieve



Glo

bal

Pro

per

ties

system


Spec. Extractor

Max. Model

Graph Tool

Moped

StorageGraph & Proof

Post!Processor

Pre!Processor

Local Verification

Global Entailment


Case Studies

Evaluating ProMoVer with three Java-Card applications


Case Studies

Evaluating ProMoVer with three Java-Card applications Global Property

No non-atomic operation within a transaction


Case Studies

ApplicationLines

of Code

Local Model Check

Maximal Model Cons.

Global ModelCheck

Total Time

AccountAccessor 190 0.5 sec 0.7 sec 0.9 sec 8.7 sec

TransitApplet 918 0.5 sec 0.9 sec 0.9 sec 13.2 sec

JavaPurse 884 0.5 sec 13.0 sec 1.1 sec 22.5 sec




Case Studies

ApplicationLines

of Code

Local Model Check

Maximal Model Cons.

Global ModelCheck

Total Time

AccountAccessor 190 0.5 sec 0.7 sec 0.9 sec 8.7 sec

TransitApplet 918 0.5 sec 0.9 sec 0.9 sec 13.2 sec

JavaPurse 884 0.5 sec 13.0 sec 1.1 sec 22.5 sec



CodeChangeTT%

Spec.ChangeTT%

66 52

44 37

40 24


Product Families


Product Families• Set of products with well-defined

commonalities and variabilities

Comonalities

Artifact 1 Artifact 2 Artifact 4Artifact 3




Comonalities





Comonalities





Compostional Verification of Software Product FamiliesSiavash Soleimanifard

Teoretical Computer Science DepartmentKTH Royal Institute of Technology

Stockholm, SWEDEN

Background

� Product Families Definition: Set of products with well-defined commonalities andvariabilities

� It is an industrial design approach for reuse and quality improvement in softwareengineering and it is proven to be commercially successful

� Generates exponential number of products� verification is hard, time consuming, most cases infeasible

P1

P3

P2

P4

Existing Modeling Approaches

� Annotative: a model is for representing all products;� Compositional: an association between product fragments, features;� Transformation: variability is represented through a set of rules: what have to be

replaced for each particular product model.

Existing Verification Approaches

Model Checking

� A. Fantechi et al., modal transition systems are extracted by the variability operators:requires/possible;

� A. Classen et al., a labeled transition system is constructed from product family andfeatures appear as the labels in a way that state reachability on a set of features canbe computed;

� A. Gruler et al., proposes an extension of CCS process calculus by variant operatorsto model a family of processes;

� K. Lauenroth, transitions on I/O–automata are related to variants.

Compositional Verification

� Blundell et al. in [1] and Liu et al. in [2]� each feature is represented as a state machine� other features can be attached to the extracted transition system via a particular

type of states (interface)

Motivation

Non-Compositional Verification

� Not Scalable because of the exponential number of productsCurrent Compositional Verification

� Restricted� Not Scalable

For an analysis technique to work for software product lines, it has to be compositional,

easily adaptable with the current systems and not restricted.

Compositional Verification with CVPP

Modular

� Verify each module locally, independently� Global correctness is relativized on the composition of local correctness� Modules are methods, e.g., Hoare logic

Algorithmic

� Accepts annotated Java programs� Fully automatic approach

� push-button tool support� PROMOVER: many optimizations, easy to use [4]

Abstraction

� Complete data abstraction� Flow Graphs

Properties

� Safety temporal properties of the control flow� Legal sequences of method invocations

Suitable Software Family Modeling for Using CVPP

Simple Hierarchical Variability Model (SHVM)

@VP1

Product Family

V21

@VP2

Core

V22V11 V12

Variation Point

Variant

Non-Compositional Verification

� Verification tasks bound by (#variants)(#VP)ND

Compositional Verification

� Verification tasks bound by (#variants ×#VP)ND

Compositional Verification of Software Families by CVPP

� Relativize Product Properties towards Variation Points� Apply Compositional Analysis Technique

Compositional Verification Procedure

For each SHVM node recursively do,1. locally verify the core methods and variation points, and2. globally relativize the correctness of the SHVM node on the composition of variation

points and core methods.Soundness

� If the above verification procedure succeeds for SHVM S and property φ, thenproperty φ holds for all products of S [3].

Experimental Results

Cash Desk Example

CashDesk

Keyboard Scanner Cash Card

@EnterProducts @Payment

cardPay()enterCard()cashPay()

enterProd()

useKeyboard() useScanner()

writeReceipt()updateStock()

sale()

payment()payment()enterProd()

� CD - Simple Cash Desks� CD/CH - Cash Desk with Coupon Handling� CD/CT - Cash Desk with Credit Cards� CD/CT/CH - Cash Desk with Credit Cards and Coupon Handling

ProductLine

Depth # Modules # Products tnon−comp tcomp

CD 1 7 9 79 9CD/CH 1 9 18 177 10CD/CT 2 15 27 278 11CD/CH/CT 2 17 54 652 12

Conclusion

� Compositional analysis of product families defined by SHVM� Verification of control flow safety properties for SHVM by PROMOVER

� Evaluations show a dramatic gain in performance

References

C. Blundell, K. Fisler, S. Krishnamurthi, and P. van Hentenryck.Parameterized Interfaces for Open System Verification of Product Lines.In Automated Software Engineering (ASE ’04), pages 258–267. IEEE, 2004.

J. Liu, S. Basu, and R. R. Lutz.Compositional model checking of software product lines using variation pointobligations.Automatic Software Engineering, 18(1):39–76, 2011.

I. Schaefer, D. Gurov, and S. Soleimanifard.Compositional algorithmic verification of software product lines.In Formal Methods for Components and Objects, volume 6957 of Lecture Notes in

Computer Science, pages 184–203. Springer, 2010.

S. Soleimanifard, D. Gurov, and M. Huisman.Promover: Modular verification of temporal safety properties.In Software Engineering and Formal Methods, volume 7041 of Lecture Notes in

Computer Science, pages 366–381. Springer, 2010.

Theoretical Computer Science, CSC - School of Computer Science and Communication, KTH Royal Institute of Technology, SE-100 44, Stockholm, SWEDEN Mail: [email protected] WWW: http://www.csc.kth.se/˜siavashs

Comonalities



Hierarchical Variability

Product Family

@VP1

V11 V12

@VP2

V21 V22

Variation Point

Variant

Core

: θ



Product Family

@VP1

V11 V12

@VP2

V21 V22

Variation Point

Variant

Core

: θ

φ2

φ1

φ3 φ4 φ5

ψV P1 ψV P2



Product Family

@VP1

V11 V12

@VP2

V21 V22

Variation Point

Variant

Core

: θ

φ2

φ1

φ3 φ4 φ5

ψV P1 ψV P2

ψV P2 ψV P2ψV P1ψV P1



Product Family

@VP1

V11 V12

@VP2

V21 V22

Variation Point

Variant

Core

: θ

φ2

φ1

φ3 φ4 φ5

ψV P1 ψV P2




Product Family

@VP1

V11 V12

@VP2

V21 V22

Variation Point

Variant

Core

: θ

φ2

φ1

φ3 φ4 φ5

ψV P1 ψV P2




Product Family

@VP1

V11 V12

@VP2

V21 V22

Variation Point

Variant

Core

: θ

φ2

φ1

φ3 φ4 φ5

ψV P1 ψV P2




Product Family

@VP1

V11 V12

@VP2

V21 V22

Variation Point

Variant

Core

: θ

φ2

φ1

φ3 φ4 φ5

ψV P1 ψV P2




Product Family

@VP1

V11 V12

@VP2

V21 V22

Variation Point

Variant

Core

: θ

φ2

φ1

φ3 φ4 φ5

ψV P1 ψV P2




Product Family

@VP1

V11 V12

@VP2

V21 V22

Variation Point

Variant

Core

: θ

φ2

φ1

φ3 φ4 φ5

ψV P1 ψV P2




Product Family

@VP1

V11 V12

@VP2

V21 V22

Variation Point

Variant

Core

: θ

φ2

φ1

φ3 φ4 φ5

ψV P1 ψV P2

Problem with loops



Product Family

@VP1

V11 V12

@VP2

V21 V22

Variation Point

Variant

Core

: θ

φ2

φ1

φ3 φ4 φ5

ψV P1 ψV P2

Problem with loops

Soundness proof



Product Family

@VP1

V11 V12

@VP2

V21 V22

Variation Point

Variant

Core

: θ

φ2

φ1

φ3 φ4 φ5

ψV P1 ψV P2

Problem with loops

Soundness proof

Automation, ProMoVer



Product Family

@VP1

V11 V12

@VP2

V21 V22

Variation Point

Variant

Core

: θ

φ2

φ1

φ3 φ4 φ5

ψV P1 ψV P2

Problem with loops

Soundness proof

Annotation language




Product Family

@VP1

V11 V12

@VP2

V21 V22

Variation Point

Variant

Core

: θ

φ2

φ1

φ3 φ4 φ5

ψV P1 ψV P2

Problem with loops

Soundness proof

Annotation language


Case study


Case Studies


Case Studies

Application Depth Modules Productsnon-comp.

Timecomp.Time

Cash Desk 1 7 9 79 sec 9 secCash Desk with

Coupons 1 9 18 117 sec 10 sec

Cash Desk with Cards 2 15 27 278 sec 11 sec

Cash Desk with Cards & Coupon

2 17 54 652 sec 12 sec


Boolean Flow Graph


Boolean Flow Graphs• Flow Graphs

- encoding data through control

‣ reuse the CVPP machinery

‣ no direct correspondence with the code

• Behaviour extended by passing and returning values

•Maximal model construction with data

• Evaluated by some examples


Boolean Flow Graphs


}


return true; else



if (n == 0)

else

return even(n−1);

}

return false;

v5

v6

v7

v1

v3 v9

v0

v2

v4 v8

!

!

!

!

!

!

even

even

even

odd

odd

odd

even


odd

Example Run:

(v0, !)"!"b (v1, !)

"!"b (v2, !)


"!"b (v6, v3)

"!"b


"!"b (v1, v9 · v3)

"!"b





Boolean Flow Graphs


}


return true; else



if (n == 0)

else

return even(n−1);

}

return false;

v5

v6

v7

v1

v3 v9

v0

v2

v4 v8

!

!

!

!

!

!

even

even

even

odd

odd

odd

even


odd

Example Run:

(v0, !)"!"b (v1, !)

"!"b (v2, !)


"!"b (v6, v3)

"!"b


"!"b (v1, v9 · v3)

"!"b





Boolean Flow Graphs


}


return true; else



if (n == 0)

else

return even(n−1);

}

return false;

v5

v6

v7

v1

v3 v9

v0

v2

v4 v8

!

!

!

!

!

!

even

even

even

odd

odd

odd

even


odd

Example Run:

(v0, !)"!"b (v1, !)

"!"b (v2, !)


"!"b (v6, v3)

"!"b


"!"b (v1, v9 · v3)

"!"b





Boolean Flow Graphs


}


return true; else



if (n == 0)

else

return even(n−1);

}

return false;

v5

v6

v7

v1

v3 v9

v0

v2

v4 v8

!

!

!

!

!

!

even

even

even

odd

odd

odd

even


odd

Example Run:

(v0, !)"!"b (v1, !)

"!"b (v2, !)


"!"b (v6, v3)

"!"b


"!"b (v1, v9 · v3)

"!"b




(false)even

(false)even

v0

v1

v2

v3

v4

v5

v6

v7

v8

v9

v10

v11

v12

v13

even,n

even, even,

even,

n

even,n,ret,

n,ret

! ! ! !

even

even,ret,

! !

odd

odd,

odd,

odd,

odd,

odd,

odd,n,n, ret,

n,retn

n

nn, r r r r

r r

odd(false)odd(false)

else return even(!n);

if (!n) then

fiend

return F;

bool odd(n) begin

begin

return T; else return odd(!n);

bool even(n)

if (!n) then

fiend


Boolean Flow Graphs


}


return true; else



if (n == 0)

else

return even(n−1);

}

return false;

v5

v6

v7

v1

v3 v9

v0

v2

v4 v8

!

!

!

!

!

!

even

even

even

odd

odd

odd

even


odd

Example Run:

(v0, !)"!"b (v1, !)

"!"b (v2, !)


"!"b (v6, v3)

"!"b


"!"b (v1, v9 · v3)

"!"b




(false)even

(false)even

v0

v1

v2

v3

v4

v5

v6

v7

v8

v9

v10

v11

v12

v13

even,n

even, even,

even,

n

even,n,ret,

n,ret

! ! ! !

even

even,ret,

! !

odd

odd,

odd,

odd,

odd,

odd,

odd,n,n, ret,

n,retn

n

nn, r r r r

r r



if (!n) then

fiend

return F;

bool odd(n) begin

begin


bool even(n)

if (!n) then

fiend


Boolean Flow Graphs


}


return true; else



if (n == 0)

else

return even(n−1);

}

return false;

v5

v6

v7

v1

v3 v9

v0

v2

v4 v8

!

!

!

!

!

!

even

even

even

odd

odd

odd

even


odd

Example Run:

(v0, !)"!"b (v1, !)

"!"b (v2, !)


"!"b (v6, v3)

"!"b


"!"b (v1, v9 · v3)

"!"b




(false)even

(false)even

v0

v1

v2

v3

v4

v5

v6

v7

v8

v9

v10

v11

v12

v13

even,n

even, even,

even,

n

even,n,ret,

n,ret

! ! ! !

even

even,ret,

! !

odd

odd,

odd,

odd,

odd,

odd,

odd,n,n, ret,

n,retn

n

nn, r r r r

r r



if (!n) then

fiend

return F;

bool odd(n) begin

begin


bool even(n)

if (!n) then

fiend


Conclusion• ProMoVer: a completely automated tool for

procedure-modular verification

- algorithmic

- light weight

‣ Spec. extractor

‣ proof storage & reuse

- modular : support open systems, variability

- temporal safety properties

‣ meaningful abstraction at procedure level Wednesday, May 23, 2012

Conclusion• modular verification of product families

- hierarchical model

- compositional verification

• Boolean flow graphs

- encoding finite data through control

- state-space blow up


Future Work• ProMoVer

- support more specification languages

• Product families

- richer model

- case study: compare to other approaches

• CVPP framework

- extend the class of properties by:

‣ symbolic data, e.g., Boolean and object references


Future Work -- BOP

decl ref x , y ;

void main ( )begin

x := new ;y := new ;i f ( x = y) then y := P(x ) ;

else x := P(y ) ;f idel ( x ) ;del ( y ) ;

end

ref P( ref a )begin

decl ref l ;l := a ;i f ( l = a ) then return l ;

else return a ;f i

end

Fig. 1: A BOP program

The reachable part of an initialized model S = (M, E) is defined by R(S) =(M�, E), where M� is obtained from M by deleting all states and transitions

not reachable from any entry state in E.we need it later

The definition of simulation is standard.

Definition 2 (Simulation). A simulation is a binary relation R on S suchthat whenever (s, t) ∈ R then λ(s) = λ(t), and whenever s

a−→s� then there issome t� ∈ S such that t

a−→t� and (s�, t�) ∈ R. We say that t simulates s, writtens � t, if there is a simulation R such that (s, t) ∈ R.

Simulation on two models M1 and M2 is defined as simulation on their dis-

joint union M1�M2. The transitions of M1�M2 are defined by ini(s)a−→ini(s�)

if sa−→s� in Mi and its valuation by λ(ini(S)) = λi(S), where ini (for i ∈ {1, 2})

injects Si into S1 �S2. Simulation is extended to initialized models (M1, E1) by

defining (M1, E1) � (M2, E2) if there is a simulation R on M1 �M2 such that

for each s ∈ E1 there is some t ∈ E2 with (in1(s), in2(t)) ∈ R. Initialized model

S1 is simulation equivalent to S2, written S1 � S2 if S1 � S2 and S2 � S1.

We extend disjoint union to initialized models (by (M1, E1) � (M2, E2) =

(M1 �M2, E1 � E2)) and show that simulation is preserved by disjoint union.

Theorem 1 (Composition). If S1 � T1 and S2 � T2 then S1 � S2 � T1 � T2.

Proof. For the proof we refer the readers to [1].

6


Future Work -- BOP

decl ref x , y ;

void main ( )begin



end

ref P( ref a )begin


else return a ;f i

end



















6


Future Work -- BOPdecl ref x , y ;

void main ( )begin



end

ref P( ref a )begin


else return a ;f i

end



















6



void main ( )begin



end

ref P( ref a )begin


else return a ;f i

end



















6

Abstract



void main ( )begin



end

ref P( ref a )begin


else return a ;f i

end



















6

Abstract

Conditional calls



void main ( )begin



end

ref P( ref a )begin


else return a ;f i

end



















6

Abstract

Conditional calls

Problem with loops


Thanks for listening!


Date post:	15-May-2018
Category:	Documents
Upload:	dinhquynh
View:	216 times
Download:	1 times

Procedure-Modular Veriﬁcation of Temporal Safety Propertiessiavashs/lic-presentation.pdf ·...

Documents