integration of model checking into software development processes fei xie

Integration of Model Checking into Software Development

Processes

Fei Xie

2

Outline

• Problem• Dissertation research overview• Focus: Integration of model checking into

CBD • Conclusion and future work

3

Validation of Software

• Testing is the most commonly used technique • Software complexity has overwhelmed

conventional testing methods– Test case coverage– Lack of automation– Concurrency makes testing even harder

• Software must be validated

• Advanced validation techniques are needed

4

Model Checking (MC)

• A formal verification method• Able to explore all possible states (or

execution paths) of a system• Enjoys substantial automation support• Has been quite successful for hardware

[Clarke and Emerson 81, Queille and Sifakis 82]

5

Research Goal and Problem

• Goal: Seamlessly integrate MC into software development processes

• Problem: Address two major challenges– Applicability– State space explosion

6

Challenge I: Applicability

• Syntax and semantics gaps between– Software specification languages– Input languages of model checkers

• Often specify finite-state systems

• Difficulties in property specification– For instance, software engineers are

not familiar with temporal logics

7

Challenge II: State Space Explosion

• 5 components, 1000 5 components, 1000 states/componentstates/component

• Worst caseWorst case: 1000 trillion states: 1000 trillion states

8

Overview of My Research

Model-Driven Development (MDD)

Model Checking Component-Based Development (CBD)

Model Checking

+

9

Model-Driven Development

RequirementAnalysis

and Design

ExecutableDesign Model

DesignValidation

ValidatedExecutable

DesignCode

Generation

PredefinedTemplates

Code(C/C++, Java)

Increasingly popular for Embedded Systems and Web-Based Systems

10

Executable UML (xUML)

• Has well-defined Execution Semantics

• Utilizes UML Action Semantics recently adopted by OMG

• Can be compiled to procedural codes

• Tools provided by:– Project Technologies– Kennedy Carter– Hyperformix (SES)– …

11

Integration of MC into MDD

• Executable design-level models are key to MDD– Executable: amenable to model checking– Design-level: lower complexities

• Model Checking Software Designs via Translation[FASE’04, FASE’02a, ASE’01] – Translate designs into model-checkable languages– Reuse state-of-the-art model checkers– Support design-level property formulation

How to address applicability?

12

The ObjectCheck Toolkit

Property Specification Interface xUML IDE Error Visualizer

xUML-to-S/R Translator Error Report Generator

COSPAN Model Checker

S/R ModelS/R Query

Error Report

Error Track

Designer

xUML ModelProperty

13

COSPAN [Hardin, Har’El, and Kurshan 96]

• Automata-theoretical approach to model checking [Kurshan 94] – Model a system and its property as -automata, P and T– Check the language containment, L(P) L(T)

• Many state space search and reduction algorithms– Explicit state enumeration– Symbolic model checking – Localization reduction– Homomorphism reduction– (and more)

14

Integration of MC into MDD (cont.)

• Model Checking Software Designs via Translation [FASE’04, FASE’02a, ASE’01]

– Many reduction algorithms applied in translation

• Integrated State Space Reduction [FASE’02b]

– Reduction algorithms applied in an integrated way• Translation-Based Compositional Reasoning

[FME’03]

– Application of CR in model checking via translation

How to reduce state spaces?

15

Integrated State Space Reduction Framework

xUML-to-S/R Translation

S/R Model S/R Level Query

Model Checking with COSPAN

Success Report / Error Track

xUML Model xUML Level Query

ReducedxUML Model

Reduced xUML Level Query

User-Driven State Space Reduction

Verification Task

Verification Subtasks

Basic Model Checking Process

Compositional ReasoningAbstractionSymmetry Reduction

Symbolic VerificationLocalization Reduction

Partial Order Reduction

16

Translation-Based Compositional Reasoning

• Compositional Reasoning (CR) [Misra and Chandy 81, …]– Decompose a system into modules– Verify module properties– Derive system properties from module properties

• To apply CR, what need be done– Establish a compositional reasoning rule– Prove the correctness of the rule– Implement the rule

• How to apply CR in model checking via translation?

17

Rule Establishment and Proof

Software Semantics

Formal Semantics

(1) Establish a compositional reasoning rule

(4) Prove the rule based onthe mapping and proof of the corresponding rule in formal semantics

(3) Prove the corresponding rule or reuse existing proof

(2) Map the rule to its corresponding rule in the formal semantics

Semantics Translation

18

Rule Implementation and Application

Software System

Formal Representation

(1) Formulation of premises for applying the rule

(2) Translation of the premises.

(4) Establishmentof conclusion according tothe proven rule.

(3) Discharge of the premises

19

Real-World Systems Verified

• The control subsystem of a NASA robotics system [FMSD’03]

– Code size 45,000 lines of C++– 22 properties checked: safety and liveness– 6 bugs found

• Instances of TinyOS run-time system for networked sensors [ESEC/SIGSOFT FSE’03]

20

Today’s Focus:Integration of MC into CBD

How are Applicability and State Space Explosion addressed?

Verified Systems by Composition from Verified Components [ESEC/SIGSOFT FSE’03]

Component-Based Development (CBD)

Model Checking

21

Integration of MC into CBD

• Motivation• Overview• Component Model for Verification• Case Study: TinyOS• Verification of Components

22

What is CBD?

• Compose systems via component assembly

• Pre-fabricate many components• Reuse components as much as possible

• Increasingly popular for– Embedded systems– Web-based systems

• Analogies: Automotive and Avionics

23

Research Goal

• Goal:– To construct safe, secure, and reliable

systems from safe, secure, and reliable components

• Framework:– Composition of verified systems from

verified components

24

Research Challenges

• How to verify primitive components?– How to represent the environment?– How to conduct the verification?

• How to compose verified components to build larger verified components effectively?– How to verify the larger components?– How to reuse verified properties? Both applicability and state space management

25

Synergy between CBD and MC

• Component-based development – Introduces compositional structures to

software– Helps minimize state spaces to be

explored

• Model checking– Provides exhaustive state space coverage– Strong at detection of composition errors

Explore this synergy to address these challenges

26

Integration of MC into CBD

• Motivation• Overview• Component Model for Verification• Case Study: TinyOS• Verification of Components

27

Our Approach

VerifiedProperties

VerifiedPropertiesVerification of a property on a composite component – Reuses verified properties of its sub-

components– Is based on compositional reasoning– Follows an abstraction-refinement paradigm

+

VerifiedProperties

VerifiedProperties

=

VerifiedProperties

VerifiedProperties

28

Compositional Reasoning

To model check a property on a software system• Step 1: Decompose the system into modules

and model-check module properties• Step 2: Derive the system property from the

verified module properties

Assume-guarantee style of compositional reasoning[Misra and Chandy 81, Abadi and Lamport 93, Alur and Henzinger 99, McMillan 99, Amla, Emerson, Namjoshi and Trefler 01, …]

• Model check properties of a module assuming properties of other modules hold

29

Integration of MC into CBD

• Motivations• Overview• Component Model for Verification• Case Study: TinyOS• Verification of Components

30

Component

Executable Representation (Design Models or Sources)

FunctionalInterface

External VisibleVariables

Verified TemporalProperties

31

Environment of C(Components interacting with

C )

Component Property

• A property of C is a pair (p, A(p))– p is a temporal property– A(p) is a set of assumptions on environment

of C– p is verified assuming A(p) holds.

Cp

A(p)

A(p) p holds on C

Assumptions = Assumed Properties

32

Component Composition

Executable of C1

Executable of Cn

Executable of CConnect via interfaces…

Properties of C1

Properties of Cn

Properties of C?…

Interface of C1

Interface of Cn

Interface of CSelectively merge…

(Visible variable sets are treated in the same way.)

33

Instantiation of Component Model on AIM Computation

Model• Asynchronous Interleaving Message-

passing– A system consists of a finite set of processes– Processes execute asynchronously – At any moment, only one process executes – Interactions via asynchronous message-

passing

• Semantics of xUML conforms to the AIM model.

34

Instantiation of Component Model on AIM Computation

Model (cont.)

• Compose components by establishing mappings among their input and output message types

Design models in xUML

MessagingInterface

External VisibleVariables

Verified TemporalProperties

35

Integration of MC into CBD

• Motivation• Overview• Component Model for Verification• Case Study: TinyOS• Verification of Components

36

TinyOS [Hill, et al., 00]

• A run-time system for networked sensors from UC Berkeley

• Component-based– Different requirements of sensors – Physical limitations of sensors

• High reliability required – Concurrency-intensive operations– Installation to many sensors

37

Integration of MC into CBD

• Motivation• Overview• Component Model for Verification• Case Study: TinyOS• Verification of Components

38

Background:Verification of Closed AIM

System

Property Specification Interface xUML IDE Error Visualizer

xUML-to-S/R Translator Error Report Generator

COSPAN Model Checker

S/R ModelS/R Query

Error Report

Error Track

Designer

xUML ModelProperty

39

Verification of Primitive Components

PrimitiveComponent

Assumptions in A(p)

2. Constrain the closed system

Env(AIM Process)

…

1. Create a closed systemWith a matching interface,

but non-deterministic

To check a property (p, A(p)) :

3. Check p on the constrained system

p

Addressing both applicability and state

space explosion in model checking primitive

components

Step 1 of Compositional Reasoning: Verification of Module Property

40

Sensor Component

Output MessageType

Input MessageType

ComponentBoundary

AIMProcess

41

Sensor Component (cont.)Properties:

(Output repeatedly and handle output handshakes correctly.) Repeatedly (Output);After (Output) Never (Output) UntilAfter (OP_Ack);After (Done) Eventually (Done_Ack);Never (Done_Ack) UntilAfter (Done);After (Done_Ack) Never (Done_Ack) UntilAfter(Done);

Assumptions: (Output handshakes are correctly ack-ed.)After (Output) Eventually (OP_Ack);Never (OP_Ack) UntilAfter (Output);After (OP_Ack) Never (OP_Ack) UntilAfter (Output);After (Done) Never (Done) UntilAfter (Done_Ack);

42

Verification of Sensor Component

Sensor Component

Assumptions

Env

OutputOutput_Ack

DoneDone_Ack…

43

Network Component

44

Network Component (cont.)

Properties:(Transmit repeatedly if input repeatedly, and handle input handshakes correctly.)IfRepeatedly (Data) Repeatedly (RFM.Pending);IfRepeatedly (Data) Repeatedly (Not RFM.Pending);After (Data) Eventually (Data_Ack); Never (Data_Ack) UntilAfter (Data);After (Data_Ack) Never (Data_Ack) UntilAfter (Data);After (Sent) Never (Sent) UntilAfter (Sent_Ack);

Assumptions: (Input handshakes are correctly ack-ed.)After (Data) Never (Data) UntilAfter (Data_Ack);After (Sent) Eventually (Sent_Ack); Never (Sent_Ack) UntilAfter (Sent);After (Sent_Ack) Never (Sent_Ack) UntilAfter (Sent);

45

Verification of Composite Components

(1) Abstraction

(2) Verification(3) Refinement

To model check a property on a composite component: Addressing both applicability and state

space explosion in model checking composite

components

46

Abstraction-Refinement Paradigm

Component

Abstraction

Refined Abstraction

Refine throughadding details

What is the abstraction?Verified propertiesof sub-components

…

Good Enough Abstraction

47

Verified Properties as Abstraction

A property = a behavior of a component

Sensor Component

Property 1: Outputs repeatedly Property 2: Handles output handshakes correctly

The component can be represented by the property if only the behavior is of

interest.

48

Sensor-to-Network Component

49

Sensor-to-Network Component

Properties:(Transmit repeatedly on physical network.)Repeatedly (RFM.Pending); Repeatedly (Not RFM.Pending);

Assumptions:(Assumptions on hardware platform are ignored. )

50

Abstraction

SP(Sensor)

NP(Network)

Env(Environment)

Verified Properties Verified Properties

Assumptions

Non-deterministicAIM Processes

51

Abstraction (cont.)

• A sub-component property is included if it is – Related by dependencies– Not involved in invalid circular

dependencies– Enabled: Its environment assumptions hold

on • Other sub-components in the composition• Environment of the composition

Verified properties of Sensor and Network are included in the abstraction of Sensor-

to-Network.

52

Abstraction Verification

• The properties of Sensor-to-Network:

Transmit repeatedly on physical network

were successfully verified on the abstraction

Step 2 of Compositional Reasoning: Derivation of System Property

• Conclusion: Sensor-to-network has the properties

Step 1 of Compositional Reasoning: Verification of Module Property

53

Verification Time Usage

5355.5

641

18 0.1

0

1000

2000

3000

4000

5000

6000

Sensor-to-Network

Sensor Network AbstractionTime (Sec.)

54

Verification Memory Usage

208.48

33.67

6.82 0.16

0

50

100

150

200

250

Sensor-to-Network

Sensor Network Abstraction

Memory (MB)

55

Abstraction Refinement

• An abstraction can be refined by – (Introducing, verifying, and) enabling

additional sub-component properties

• A property can be enabled by – Enabling its assumptions on other

components

• Currently requires user interactions

56

Refinement Example

Sensor Network

Sensor-to-Network

To verify a new property, P1, on Sensor-to-Network (SN): Property P1: SN transmits any sensor reading exactly once

Property P2: Network transmits any input exactly once. Assumption: A new input arrives only after Network acks the last input with a Sent message

57

Refinement Example (cont.)

Sensor Network

Sensor-to-Network

• A real bug was found in Sensor and fixed. Property P3 was verified on the revised Sensor

Property P3: Sensor outputs any sensor reading exactly once;

After an output, Sensor will not output until a Done message is received.

P3 P2

• Inclusion of P2 and P3 into the abstraction P1

P1

58

Verification Time Usage

206.6

96

6.6 0.1

0

50

100

150

200

250

Sensor-to-Network

Sensor Network AbstractionTime (Sec.)

59

Verification Memory Usage

54.89

19.5

3.830.18

0

10

20

30

40

50

60

Sensor-to-Network

Sensor Network Abstraction

Memory (MB)

60

Related Work to Component Verification

• Compositional Reasoning– Previous work: in top-down system decomposition

– Our approach: in bottom-up component composition

• The Inscape Environment [Perry 89] – Consistency checking in software composition models

• Compositional Reachability Analysis (CRA)[Graf and Steffen 90, Yeh and Young 91, Cheung and Kramer 93] – Composition and minimization of Label Transition Systems

• Modular Feature Verification [Fisler and Krishnamurthi 01]

– Verification of layered composition of features

61

Contributions of My Research

• Seamless integration of MC into MDD– Verification of real-world systems of significant size

• Seamless integration of MC into CBD – Verification of real-world component-based systems

• Addresses of both challenges in software MC – Applicability– State space explosion

• Synergistic combination of the two integrations– Further alleviation of state space explosion

62

Immediate Future Research

Scalable Verification

of Component-Based

SystemsSecurity

Guaranteethrough Formal

VerificationHardware/Software

Co-design andCo-verification

Knowledge Driven

Adaptive ModelChecking System

Interactions

Software Safety

Security

Reliability

63

Conclusions

• Software must be safe, secure, and reliable• Advanced validation methods are needed• My research integrates MC into MDD and

CBD • Systems of significant size have been

verified• Many challenging problems are still ahead

64

Publications

• Fei Xie, Vladimir Levin, Robert P. Kurshan, and James C. Browne. Translating Software Designs for Model Checking. In Proc. of FASE, to appear, 2004.

• Thomas Ball, Vladimir Levin, and Fei Xie. Automatic Creation of Environment Models via Training. In Proc. of TACAS, to appear, 2004.

• Fei Xie and James C. Browne. Verified Systems by Composition from Verified Components.  In Proc. of ESEC/FSE, 2003. 

• Fei Xie, James C. Browne, and Robert P. Kurshan. Translation-Based Compositional Reasoning for Software Systems. In Proc. of FME, 2003. 

65

Publications (cont.)

• Natasha Sharygina, James C. Browne, Fei Xie, Robert Kurshan, and Vladimir Levin. Lessons Learned from Model Checking a NASA Robot Controller. Journal of FMSD, 2003.

• Fei Xie and James C. Browne. Integrated State Space Reduction for Model Checking Executable Object-oriented Software System Designs, In Proc. of FASE, 2002. 

• Fei Xie, Vladimir Levin, and James C. Browne. ObjectCheck: A Model Checking Tool for Executable Object-oriented Software System Designs, In Proc. of FASE, 2002. 

• Fei Xie, Vladimir Levin, and James C. Browne. Model Checking for an Model Checking for an Executable Subset of UML. In Proc. of ASE, 2001.

66

For More Information

• Useful linkshttp://www.cs.utexas.edu/users/feixiehttp://www.cs.utexas.edu/users/ObjectCheck

• Email:feixie@cs.utexas.edu

Questions?

67

How MC works?

System Model

This is great. Let’s model-check software

systems.Farewell, bugs

Temporal Property

Example temporal properties:Buffer A will never overflow;System outputs repeatedly

Model CheckerExhaustive and

intelligent search over the state space of the

system model

68

Case Study: An Online Ticket Sale System (OTSS)

Customer (C) Dispatcher (D) Agent (A) Ticket_Server (TS)

TryLater Assignment

Hold

Request

Held/Later/Out

TicketHeld/TryLater/SoldOut

Payment

Ticket

Reset

Buy/Release

Branching Point 1

Branching Point 4

Branching Point 2

Branching Point 3

69

Property to be Checked on OTSS

• In English, After a Request message from a customer is

processed by the dispatcher, eventually the system will reply the customer with a TicketHeld message, or a TryLater message, or a SoldOut message

• In the xUML level query specification logic,

P0 : After Request (i) Eventually TicketHeld(i) or TryLater (i) or SoldOut(i)

70

Reduction Steps for Checking P0

Customers, DispatcherAgents, Ticket Sever

Step 1: Symmetry Reduction

Step 2: Decomposition

Step 3: Symmetry Reduction

Step 4: Decomposition

Step 5: Case SplittingStep 6: Symmetry Reduction

P0

Customers, DispatcherAgents, Ticket Sever

P1

Customers Dispatcher Agents, Ticket ServerP21 , P22 P31 , P32

P33 , P23

Agents, Ticket ServerP41 , P42

P43 , P44

Ticket Server AgentsP41 , P42

P43 , P44

P5

Ticket ServerP6 AgentP41 , P42

P43 , P44

71

Evaluation of User-driven State Space Reduction

• Directly model checking P0 on OTSS – Two customer instances and two agent instances– SPOR and SMC are both applied– Memory usage: 152.79M– Time usage: 16273.7S

• Memory and time usages for discharging subtasks at the leaf nodes of the reduction tree P21 P22 P41 P42 P43 P44 P6

Memory

0.30M 0.95M

0.28M 0.29M 0.28M 0.29M 0.35M

Time 0.02S 1.81S 0.01S 0.04S 0.01S 0.04S 0.63S

72

Translation Context

SemanticsConformance

SemanticsConformance

AIMSemantics

-automatonSemantics

Semantics Translation

xUML S/RxUML-to-S/R Translation

xUML: An executable dialect of UMLS/R: Input language of COSPAN model checker

73

Rule AENT [Amla, Emerson, Namjoshi, and Trefler

01] • Has been adapted to AIM semantics

To show P1//P2 |= Q, find Q1 and Q2 that satisfy:C1: P1//Q2 |= Q1 and P2 //Q1 |= Q2

{Verifying component properties assuming properties of other components hold}

C2: Q1//Q2 |= Q

{Deriving system property from component properties}C3: Either P1//CL(Q) |= (Q + Q1 + Q2)

Or P2//CL(Q) |= (Q + Q1 + Q2)

{Validating circular dependencies among component properties}

Conclusion

Premises

74

Translation from AIM Semantics to -automaton

semanticsAIM Semantics

-automaton Semantics

I/O-automaton Semantics

75

Preservation of Language Containment

• L(A) L(B) iff L(Trans(A)) L(Trans(B))• Theorem 1:

– Translation from AIM semantics to I/O-automaton semantics preserves language containment

• Theorem 2: – Translation from I/O-automaton semantic to

-automaton semantics preserves language containment

• Theorem 3: – Translation from AIM Semantic to -automaton

semantics preserves language containment

76

Proof via Semantics Translation

• Proof sketch for Rule AENT:– Assume that C1, C2, and C3 hold– By Theorem 3, -automaton translations of

C1, C2, C3 hold– By -automaton counterpart of Rule AENT,

-automaton translation of P1//P2 |= Q holds

– By Theorem 3, P1//P2 |= Q holds

77

Why validate circular dependencies

among component properties?

Eventually (A) Eventually (B)

Eventually (A) and Eventually (B)?

C1 C2

X X A = FALSEB = FALSE

Eventually (B) Eventually (A) Eventually (A) Eventually (B)

Think about Deadlocks.A: C1 releases Lock A.B: C2 releases Lock B.

78

Property and Assumption Formulation

• Properties– Currently manually guided– Derived from component specifications– Added incrementally in component reuses

• Assumptions– Manual formulation– Automatic generation

• Often lead to complex assumptions

• Automatic generation heuristics in progress

79

Immediate Future Directions

• Scalable verification of component-based systems– Large-scale components conforming to CORBA, .NET,

or other platforms– Systems involving multiple component paradigms

• Software security guarantee via formal verification– Integration of security policies into design models– Formulation of security properties, e.g., information flow– Effective verification of security properties

80

Immediate Future Directions (cont.)

• Domain knowledge driven state space reduction– Extending integrated state space reduction

framework– Exploring domain knowledge– Developing adaptive model checking systems

• Hardware/software co-verification– Translating both software and hardware into a

model checkable language– Or modeling hardware as transaction models

81

Long-Term Research Plan

• Goal: methods and tools– For development of safe, secure, and reliable

software systems of increasing complexity– Integrated into routine development efforts

• Approach: synergistic integration of – Testing– Formal Verification– Static Analysis– Run-Time Monitoring