1 / 24

The Quest for Correctness

The Quest for Correctness. Joseph Sifakis VERIMAG Laboratory. 2nd Sogeti Testing Academy April 29th 2009. Correctness by checking vs. Correctness by construction.

vine
Télécharger la présentation

The Quest for Correctness

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. The Quest for Correctness Joseph Sifakis VERIMAG Laboratory 2nd Sogeti Testing Academy April 29th 2009

  2. Correctness by checking vs. Correctness by construction • Building systems which are correct with respect to given requirementsis the main challenge for all engineering disciplines • Correctness can be achieved: • Either by checkingthat a system or a model of a system meets given requirements • Or by constructionby using results such as algorithms, protocols, architectures e.g. token ring protocol, time triggered architecture • A big difference between Computing Systems Engineering and disciplines based on Physics is the importance of a posteriori verification for achieving correctness

  3. O V E R V I E W • Current status • Work directions • Conclusion 3

  4. Ad hoc models e.g. SystemC simulation • Formal models (well-defined notion of state and transition) Approaches for checking correctness • Checking correctness • Physical prototypese.g. testing • Models (Virtual SW Prototypes) • Verification • Algorithmic Verification e.g. Model checking • Deductive Verification Exhaustivity

  5. Verification: Three essential ingredients • Should be: • faithfule.g. whatever property is satisfied for the model holds for the real system • generated automatically from system descriptions • Should be: • consistente.g. there exists some model satisfying them • complete e.g. they tightly characterize the system’s behavior • As a rule, for infinite state models all non trivial properties are undecidable e.g. bounded memory • Intrinsically high complexity for finite state models (state explosion problem) System Model Requirements Verification Method YES, NO, DON’TKNOW

  6. Requirements specification (1/3) Property-based State-based Using formulas, in particular temporal logic, to characterize a set of execution structures e.g. traces, execution trees Using a machine (monitor) to specify observable behavior always( inev ( enable( send ) ) ) always( inev ( enable( receive) ) ) send receive Good for expressing global properties such as mutual exclusion, termination, fairness Good for characterizing causal dependencies e.g. sequences of actions We need a combination of both property-based and state-based styles

  7. Requirements specification (2/3) • Temporal logic was a breakthrough in understanding and formalizing requirements for concurrent systems e.g. mutex, fairness • Nonetheless, the declarative style is not always easy to master and understand - Moving towards a “less declarative” style e.g. MSC, modal automata f2 f1 f3 • We need requirement specification languages for engineers e.g. PSL/Sugar • Much to be done for extra-functional requirements characterizing: • security (e.g. privacy properties, electronic voting) • reconfigurability (e.g. non interference of features) • quality of service (e.g. degree of jitter).

  8. semantics Building models (1/3) For hardware, it is easy to get faithful logical finite state models represented as systems of boolean equations HW MODEL v v= … u= .. x= … y= … z=xy x z y u

  9. semantics abstraction Building models (2/3) For software this may be much harder …. valid if…. while valid do if x<0 then z=x else z=-x; while … SEMANTIC MODEL PROGRAM x<0 z:=x x>=0 z:=-x valid  valid ABSTRACT MODEL  b z:=  b b z:=b valid

  10. CommandHandlers EventHandlers Tasks APPLICATION SW EXECUTION PLATFORM TaskScheduler EventScheduler Sensors Timers Antenna Building models (3/3) • For mixed Software / Hardware systems: • there are no faithful modeling techniques as we have a poor understanding of how software and the underlying platform interact • validation by testing physical prototypes or by simulation of ad hoc models

  11. 2Q A Algorithmic Verification: Using Abstraction (1/2) • SA satisfies fA implies S satisfies f • where SA =(QA,RA) is an abstraction of S=(Q,R) • for formulas f involving only universal quantification over execution paths [Cousot&Cousot 79] Abstract interpretation, a general framework for computing abstractions based on the use of Galois connections Q aFg F QA g • a,g are monotonic • Id ga • ag  Id 2Q a   aFg is the best approximation of F in the abstract state space

  12. Algorithmic Verification: Using Abstraction (2/2) Model checking Abstract interpretation • Initially, focused on finite state systems (hardware, control intensive reactive systems). • Later, it addressed verification of infinite state systems by using abstractions. • Used to check general properties specified by temporal logics. • Driven by the concern for finding adequate abstract domains for efficient verification of program properties, in particular properties related to program execution. • Focuses on forward or backward reachability analysis for specific abstract domains. Significant results can still be obtained by combining these two approaches e.g. by using libraries of abstract domains in model checking algorithms.

  13. O V E R V I E W • Current status • Work directions • Conclusion 13

  14. Work Directions: Component-based Modeling Build complex systems by composing components (simpler systems). This confers numerous advantages such as productivity and correctness • SW Component frameworks: • Coordination languages extensions of programming languages e.g. BPEL, Javaspaces, TSpaces, Concurrent Fortran, NesC • Middleware e.g. Corba, Javabeans, .NET • Software development environments: PCTE, SWbus, Softbench, Eclipse • System modeling languages: Statecharts, SysML, Matlab/Simulink, AADL, Ptolemy • Hardware description languages: Verilog, VHDL, SystemC Heterogeneity: Embedded systems are built from components with different characteristics • Execution: synchronous and asynchronous components • Interaction: function call, broadcast, rendezvous, monitors • Abstraction levels: hardware, execution platform, application software

  15. Work Directions: Component-based Modeling Actor-based programming Thread-based programming Software Engineering Systems Engineering

  16. c2 c’2 c1 c’1 Work Directions: Component-based Modeling • Build a component C satisfying given requirements f, from • C0 a set of atomic components described by their behavior • GL ={gl1, …, gli, …} a set of glue operators on components gl12 satisfiesf gl1 gl2 • Move from single low-level composition operators e.g. automata-based to families of high-level composition operators e.g. protocols, controllers • We need a unified composition paradigm for describing and analyzing the coordination between components to formulate system designs in terms of tangible, well-founded and organized concepts

  17. Work Directions: Constructivity • Today, a posteriori verificationat high development costs limited to medium complexity systems • Tomorrow, correct-by-construction results should advantageously take into account architectures and their features. There is a large space to be explored, between full constructivity and a posteriori verification. Develop correct-by-constructionresults • For particular • architectures (e.g. client-server, star-like, time triggered) • programming models (e.g. synchronous, data-flow) • execution models (e.g. event triggered preemptable tasks) • For specific classes of properties such as deadlock-freedom, mutual exclusion, timeliness 17

  18. ~ ~ gl sat Pi satgl(P1, ..,Pn) implies gl gl ci cn c1 Work Directions: Constructivity – Compositionality Build correct systems from correct components: rules for proving global properties from properties of individual components  gl   We need compositionality results for the preservation of progress properties such as deadlock-freedom and liveness as well as extra-functional properties

  19. gl gl’ sat P’ sat P and c1 cn c1 cn gl  gl’ sat PP’ implies c1 cn Work Directions: Constructivity – Composability X Essential properties of components are preserved when they are integrated gl   gl   • Property stability phenomena are poorly understood. We need composability results e.g. non interaction of features in middleware, composability of scheduling algorithms, of Web services, of aspects

  20. Work Directions: Constructivity - Example Checking global deadlock-freedom of a system built from deadlock-free components, by separately analyzing the components and the architecture. p1 p2 p1 p2 S1 S2 S1 S2 q1 q2 Potential deadlock D = en(p1)  en(p2) en(q2) en(q1) p1 p2 S1 S2 r1 Potential deadlock D = en(p1)  en(p2)  en(q2)   en(q3)  en(r3)   en(r1) q2 S3 r3 q3

  21. Work Directions: Constructivity - Example

  22. O V E R V I E W • Current status • Work directions • Conclusion 22

  23. From a posteriori verification to constructivity at design time • Verification is not the only way for guaranteeing correctness. • In contrast to Physics, Computer Science deals with an infinite number of possibly created universes • Limiting the focus on particular tractable universes of systems can help overcome current limitations • We should concentrate on compositional modeling and verification for sub-classes of systems and properties which are operationally relevant and technically successful

  24. Thank You

More Related