WSO2Con USA 2015: Building Web Apps with Reusable UI Components and Composition
Verified Systems by Composition from Verified Components
description
Transcript of Verified Systems by Composition from Verified Components
Verified Systems by Composition from Verified Components
Fei Xie and James C. Browne
2
Research Goal
• Goal:– Construction of reliable and secure software
systems from reliable and secure components;• Framework:
– Composition of verified systems from verified components.
3
Research Challenges
• How to verify components?• How to compose verified components to
build larger verified components effectively?
4
Synergism between CBD and MC
• Component-Based Development (CBD) – Introduces compositional structures to software;– Helps minimizing state spaces to be explored.
• Model Checking (MC)– Provides exhaustive state space coverage;– Strong at detection of composition errors.
5
Agenda
• Motivations• Our Approach• Component Model for Verification• Case Study: TinyOS• Verification of Components• Related Work• Conclusions and Future Work
6
Highlights of Our Approach
• Temporal properties are specified, verified, and packaged with components.
• Larger components are composed incrementally. • Component reuse considers component properties. • Verification of a property of a composed component
– Reuses verified properties of its sub-components; – Follows abstraction-refinement paradigm;– Is based on compositional reasoning.
7
Compositional Reasoning
• To verify a property on a software system
• Step 1: Verification of component properties;• Step 2: Validation of circular dependencies;• Step 3: Derivation of the system property from
component properties.
• Previous work: in top-down system decomposition; • Our approach: in bottom-up component composition.
8
Why validate circular dependenciesbetween component properties?
Eventually (A) Eventually (B)
Eventually (A) and Eventually (B)?
C1 C2
X X A = FALSEB = FALSE
9
Agenda
• Motivations• Our Approach• Component Model for Verification• Case Study: TinyOS• Verification of Components• Related Work• Conclusions and Future Work
10
Component
• A component, C, has four parts:– Executable representation (models or sources);– Interface (procedural, messaging, …); – A set of externally visible variables;– A set of verified temporal properties of C.
11
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) hold.
• The environment of C– is the set of components that C interacts with;– varies in different compositions.
12
Component Composition
• Connect executable representations of sub-components through their interfaces;
• Selectively merge interfaces and visible variable sets of sub-components;
• Verify properties of composed component by reusing properties of sub-components.
13
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.
14
Instantiation of Component model on AIM Computation Model (cont.)• Component
– Represented in Executable UML (xUML); – Messaging interface;
• Composition – Establishing mappings among input and output
message types of sub-components.
15
Agenda
• Motivations• Our Approach• Component Model for Verification• Case Study: TinyOS• Verification of Components• Related Work• Conclusions and Future Work
16
TinyOS [Hill, et. al, `00]
• A run-time system for network sensors from UC Berkeley;
• Component-based– Different requirements of sensors; – Physical limitations of sensors;
• High reliability required – Concurrency-intensive operations;– Installation to many sensors.
17
Agenda
• Motivations• Our Approach• Component Model for Verification• Case Study: TinyOS• Verification of Components• Related Work• Conclusions and Future Work
18
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
19
Verification of Primitive Components
• Given a component and a property:– Create a closed system from the component and
an environment process, env;– Constrain env with assumptions of the property;– Verify the property on the constrained system.
Compositional Reasoning: Step 1
20
Sensor Component
Output messageType
Input messageType
ComponentBoundary
AIMProcess
21
Sensor Component (cont.)Properties:
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: 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);Repeatedly (C_Intr);After (C_Intr) Never (C_Intr + A_Intr + S_Schd) UntilAfter (C_Ret);After (ADC.Pending) Eventually (A_Intr);After (A_Intr) Never (C_Intr + A_Intr + S_Schd) UntilAfter (A_Ret);After (STQ.Empty = FALSE) Eventually (S_Schd);After (S_Schd) Never (C_Intr + A_Intr + S_Schd) UntilAfter (S_Ret);
22
Verification of Sensor Component
Sensor Component
Assumptions
Env
OutputOutput_Ack
DoneDone_Ack…
23
Network Component
24
Network Component (cont.)Properties:
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: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);After (NTQ.Empty = FALSE) Eventually (N_Schd);After (N_Schd) Never (N_Schd +R_Intr) UntilAfter (N_Ret);After (RFM.Pending) Eventually (R_Intr);After (R_Intr) Never (N_Schd +R_Intr) UntilAfter (R_Ret);
25
Verification of Composed Components
(1) Abstraction
(2) Verification(3) Refinement
26
Abstraction-Refinement Paradigm
Component
…
AbstractionAbstract throughremoving details
Refined Abstraction
Refine throughadding details
What is it?How to create it?How to refine it?
27
Sensor-to-Network Component
28
Sensor-to-Network ComponentProperties:
Repeatedly (RFM.Pending); Repeatedly (Not RFM.Pending);
Assumptions:Repeatedly (C_Intr);After (C_Intr) Never (C_Intr+A_Intr+S_Schd+N_Schd+R_Intr) UntilAfter (C_Ret);After (ADC.Pending) Eventually (A_Intr);After (A_Intr) Never (C_Intr+A_Intr+S_Schd+N_Schd+R_Intr) UntilAfter (A_Ret);After (STQ.Empty = FALSE) Eventually (S_Schd);After (S_Schd) Never (C_Intr+A_Intr+S_Schd+N_Schd+R_Intr) UntilAfter (S_Ret);After (NTQ.Empty = FALSE) Eventually (N_Schd);After (N_Schd) Never (C_Intr+A_Intr+S_Schd+N_Schd+R_Intr) UntilAfter (N_Ret);After (RFM.Pending) Eventually (R_Intr);After (R_Intr) Never (C_Intr+A_Intr+S_Schd+N_Schd+R_Intr) UntilAfter (R_Ret);
29
Abstraction
SP(Sensor)
NP(Network)
Env(Environment)
Verified Properties Verified Properties
Assumptions
AIM Processes
30
Abstraction (cont.)
• A sub-component property is included if it is – In the cone-of-influence;– Not involved in invalid circular dependencies;
– Enabled: Its environment assumptions hold on • Other components in the composition;• Environment of the composition.
Compositional Reasoning: Step 2
31
Verification and Complexity
Component Time Memory1 Sensor-to-Network 89m15.45s 208.48M2 Sensor 10m41.01s 33.673M3 Network 18.0S 6.8239M4 Abstraction 0.1s 0.1638M
• Check the property of SN on the abstraction.
Compositional Reasoning: Step 3 and Step 1
32
Abstraction Refinement
• An abstraction can 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.
33
Refinement Example
• To check Property P1 on Sensor-to-NetworkSN transmits any sensor reading exactly once.
• Property P2 has been verified on Network. Network transmits any input exactly once. Assumption: A new input arrives only after Network acks the last input with a Sent message.
• P2 is not enabled in the composition of SN.
34
Refinement Example (cont.)
• To enable P2, introduce and check Property P3 on Sensor:
Sensor outputs any sensor reading exactly once;After an output, Sensor will not output again until a done message is received.
• A bug was found in Sensor and fixed. P3 was verified on the revised Sensor.
• Inclusion of P2 and P3 into the abstraction leads to verification of P1.
35
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.
36
Agenda
• Motivations• Our Approach• Component Model for Verification• Case Study: TinyOS• Verification of Components• Related Work• Conclusions and Future Work
37
Related Work
• Compositional Reachability Analysis (CRA)[Graf and Steffen, Yeh and Young, Cheung and Kramer] – Compose and minimize the LTS of a software
system from LTSs of its components.• Modular Feature Verification
[Fisler and Krishnamurthi]– Verification of layered composition of features.
38
Conclusions and Future Work
• An important step towards composition of verified systems from verified components.
• Results are promising: – Detection of composition errors;– Significant reduction on verification complexity.
• Future work – Automatic property and assumption generation;– Extended case studies.