integration of model checking into software development processes fei xie
TRANSCRIPT
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:[email protected]
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