1. Integration of Model Checking into Software Development Processes Fei Xie

2. 2 Outline Problem Dissertation research overview Focus: Integration of model checking into CBD Conclusion and future work

3. 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. 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. 5 Research Goal and Problem Goal: Seamlessly integrate MC into software development processes Problem: Address two major challenges –Applicability –State space explosion

6. 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. 7 Challenge II: State Space Explosion 5 components, 1000 states/component5 components, 1000 states/component Worst case: 1000 trillion statesWorst case: 1000 trillion states

8. 8 Overview of My Research Model-Driven Development (MDD) Model Checking Component-Based Development (CBD) Model Checking +

9. 9 Model-Driven Development Requirement Analysis and Design Executable Design Model Design Validation Validated Executable Design Code Generation Predefined Templates Code (C/C++, Java) Increasingly popular for Embedded Systems and Web-Based Systems

10. 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. 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. 12 The ObjectCheck Toolkit Property Specification InterfacexUML IDEError Visualizer xUML-to-S/R TranslatorError Report Generator COSPAN Model Checker S/R ModelS/R Query Error ReportError TrackDesigner xUML Model Property

13. 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. 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. 15 Integrated State Space Reduction Framework xUML-to-S/R Translation S/R ModelS/R Level Query Model Checking with COSPAN Success Report / Error Track xUML Model xUML Level Query Reduced xUML Model Reduced xUML Level Query User-Driven State Space Reduction Verification TaskVerification Subtasks Basic Model Checking Process Compositional Reasoning Abstraction Symmetry Reduction Symbolic Verification Localization Reduction Partial Order Reduction

16. 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. 17 Rule Establishment and Proof Software Semantics Formal Semantics (1)Establish a compositional reasoning rule (4) Prove the rule based on the 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. 18 Rule Implementation and Application Software System Formal Representation (1)Formulation of premises for applying the rule (2) Translation of the premises. (4) Establishment of conclusion according to the proven rule. (3) Discharge of the premises

19. 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. 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. 21 Integration of MC into CBD Motivation Overview Component Model for Verification Case Study: TinyOS Verification of Components

22. 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. 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. 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. 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. 26 Integration of MC into CBD Motivation Overview Component Model for Verification Case Study: TinyOS Verification of Components

27. 27 Our Approach Verified Properties Verified Properties Verification of a property on a composite component –Reuses verified properties of its sub-components –Is based on compositional reasoning –Follows an abstraction-refinement paradigm + Verified Properties Verified Properties = Verified Properties Verified Properties

28. 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. 29 Integration of MC into CBD Motivations Overview Component Model for Verification Case Study: TinyOS Verification of Components

30. 30 Component Executable Representation (Design Models or Sources) Functional Interface External Visible Variables Verified Temporal Properties

31. 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. C p A(p) A(p)  p holds on C Assumptions = Assumed Properties

32. 32 Component Composition Executable of C 1 Executable of C n Executable of C Connect via interfaces … Properties of C 1 Properties of C n Properties of C ? … Interface of C 1 Interface of C n Interface of C Selectively merge … (Visible variable sets are treated in the same way.)

33. 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. 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 Messaging Interface External Visible Variables Verified Temporal Properties

35. 35 Integration of MC into CBD Motivation Overview Component Model for Verification Case Study: TinyOS Verification of Components

36. 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. 37 Integration of MC into CBD Motivation Overview Component Model for Verification Case Study: TinyOS Verification of Components

38. 38 Background: Verification of Closed AIM System Property Specification InterfacexUML IDEError Visualizer xUML-to-S/R TranslatorError Report Generator COSPAN Model Checker S/R ModelS/R Query Error ReportError TrackDesigner xUML Model Property

39. 39 Verification of Primitive Components Primitive Component Assumptions in A(p) 2. Constrain the closed system Env (AIM Process) … 1. Create a closed system With 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. 40 Sensor Component Output Message Type Input Message Type Component Boundary AIM Process

41. 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. 42 Verification of Sensor Component Sensor Component Assumptions Env Output Output_Ack Done Done_Ack …

43. 43 Network Component

44. 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. 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. 46 Abstraction-Refinement Paradigm Component Abstraction Refined Abstraction Refine through adding details What is the abstraction? Verified properties of sub-components … Good Enough Abstraction

47. 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. 48 Sensor-to-Network Component

49. 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. 50 Abstraction SP (Sensor) NP (Network) Env (Environment) Verified Properties Assumptions Non-deterministic AIM Processes

51. 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. 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. 53 Verification Time Usage

54. 54 Verification Memory Usage

55. 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. 56 Refinement Example SensorNetwork 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. 57 Refinement Example (cont.) SensorNetwork 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. P3P2 Inclusion of P2 and P3 into the abstraction  P1 P1

58. 58 Verification Time Usage

59. 59 Verification Memory Usage

60. 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. 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. 62 Immediate Future Research Scalable Verification of Component-Based Systems Security Guarantee through Formal Verification Hardware/Software Co-design and Co-verification Knowledge Driven Adaptive Model Checking System Interactions SoftwareSafety SecurityReliability

63. 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. 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. 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. 66 For More Information Useful links http://www.cs.utexas.edu/users/feixie http://www.cs.utexas.edu/users/ObjectCheck Email: feixie@cs.utexas.edu Questions?

67. 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 Checker Exhaustive and intelligent search over the state space of the system model

68. 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. 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, P 0 : After Request (i) Eventually TicketHeld(i) or TryLater (i) or SoldOut(i)

70. 70 Reduction Steps for Checking P 0 Customers, Dispatcher Agents, Ticket Sever Step 1: Symmetry Reduction Step 2: Decomposition Step 3: Symmetry ReductionStep 4: DecompositionStep 5: Case Splitting Step 6: Symmetry Reduction P0P0 Customers, Dispatcher Agents, Ticket Sever P1P1 CustomersDispatcherAgents, Ticket Server P 21, P 22 P 31, P 32 P 33, P 23 Agents, Ticket Server P 41, P 42 P 43, P 44 Ticket Server Agents P 41, P 42 P 43, P 44 P5P5 Ticket ServerP6P6 Agent P 41, P 42 P 43, P 44

71. 71 Evaluation of User-driven State Space Reduction Directly model checking P 0 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 P 21 P 22 P 41 P 42 P 43 P 44 P6P6 Memory0.30M0.95M0.28M0.29M0.28M0.29M0.35M Time0.02S1.81S0.01S0.04S0.01S0.04S0.63S

72. 72 Translation Context Semantics Conformance Semantics Conformance AIM Semantics  -automaton Semantics Semantics Translation xUMLS/R xUML-to-S/R Translation xUML: An executable dialect of UML S/R: Input language of COSPAN model checker

73. 73 Rule AENT [Amla, Emerson, Namjoshi, and Trefler 01] Has been adapted to AIM semantics To show P 1 //P 2 |= Q, find Q 1 and Q 2 that satisfy: C1: P 1 //Q 2 |= Q 1 and P 2 //Q 1 |= Q 2 {Verifying component properties assuming properties of other components hold} C2: Q 1 //Q 2 |= Q {Deriving system property from component properties} C3: Either P 1 //CL(Q) |= (Q + Q 1 + Q 2 ) Or P 2 //CL(Q) |= (Q + Q 1 + Q 2 ) {Validating circular dependencies among component properties} Conclusion Premises

74. 74 Translation from AIM Semantics to  -automaton semantics AIM Semantics  -automaton Semantics I/O-automaton Semantics

75. 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. 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 P 1 //P 2 |= Q holds –By Theorem 3, P 1 //P 2 |= Q holds

77. 77 Why validate circular dependencies among component properties? Eventually (A)Eventually (B) Eventually (A) and Eventually (B) ? C1C2 XX A = FALSE B = FALSE Eventually (B)  Eventually (A) Eventually (A)  Eventually (B) Think about Deadlocks. A: C1 releases Lock A. B: C2 releases Lock B.

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