System Correctness. EEC 421/521: Software Engineering. System Correctness. The Problem at Hand. A system is correct when it meets its requirements

Transcription

1 System Correctness EEC 421/521: Software Engineering A Whirlwind Intro to Software Model Checking A system is correct when it meets its requirements a design without requirements cannot be right or wrong, it can only be surprising Verification must always start with the identification and formalization of all relevant correctness requirements 4/24/08 EEC 421/521: Software Engineering 1 4/24/08 EEC 421/521: Software Engineering 3 The Problem at Hand Finding defects in programs is hard This is especially true in large systems Concurrency only worsens the problem If only there were a way to see into the future and determine what a program is going to do System Correctness A well-designed system is provably correct reverse burden of proof: it is best to assume that the system is incorrect until the opposite can be shown sometimes we have to keep the design simpler than we would like, to be able to prove its properties reason: common sense can be misleading, especially in distributed systems design 4/24/08 EEC 421/521: Software Engineering 2 4/24/08 EEC 421/521: Software Engineering 4

2 System Correctness Cannot prove a system correct in absolute sense you can only prove that a system does or does not have certain specific properties It requires human judgment to conclude whether having or not having those properties constitutes correctness getting the properties (requirements) right is as important as getting the (model of the) system right There is no magic wand, no blind test that could automagically prove an arbitrary given system correct 4/24/08 EEC 421/521: Software Engineering 5 Goal of System Verification We are interested in determining whether design requirements could possibly be violated Testing is concerned with making sure that the probability of violations is minimized Logical correctness is concerned with possibilities, not probabilities Impossibility >> Low Probability 4/24/08 EEC 421/521: Software Engineering 7 Correctness Requirements Decidability Some requirements are standard: A system (e.g., an OS) should not be able to deadlock No process should be able to starve another No explicitly stated assertion inside a process should ever fail The most important requirements are application-specific: System invariants, process assertions Effective progress requirements Proper termination General causal and temporal relations on states e.g., when a request is issued eventually a reply is returned Fairness assumptions e.g., about process scheduling 4/24/08 EEC 421/521: Software Engineering 6 A problem is decidable, if it has a solution, and the solution can be found in a finite amount of time Otherwise the problem is undecidable 4/24/08 EEC 421/521: Software Engineering 8

3 Gödel's Incompleteness Theorem For any consistent formal theory that proves basic arithmetical truths, an arithmetical statement that is true but not provable in the theory can be constructed. That is, any theory capable of expressing elementary arithmetic cannot be both consistent and complete. Turing s Proposition There must be problems that are undecidable Example: The Halting Problem (HP) Given a program and an input to the program, determine if the program will eventually stop when it is given that input. Simply running the program with the given input is not a valid approach. Why? 4/24/08 EEC 421/521: Software Engineering 9 4/24/08 EEC 421/521: Software Engineering 11 Gödel's Theorem: Proof Consider statement G! G cannot be proven to be true If G is proven to be true, there is a contradiction The theory is inconsistent If G cannot be proven, there is at least one statement that cannot be proven The theory is incomplete HP is Undecidable [Turing, 1936] Suppose that there is a solution, called H Program P Input I H Program P is just a string of characters, and so P can be provided as input to H Program P Program P H Halts or Loops Halts or Loops 4/24/08 EEC 421/521: Software Engineering 10 4/24/08 EEC 421/521: Software Engineering 12

4 HP is undecidable Construct a new program K: if H outputs loops, then halt Else loop forever K does the opposite of H Model Checking Technology to verify requirements and design for a variety of real-time embedded and safetycritical systems Program P H Loop? K loop 4/24/08 EEC 421/521: Software Engineering 13 4/24/08 EEC 421/521: Software Engineering 15 HP is Undecidable Since K is a program, we can provide K as input to itself If H says K halts, then K itself would loop If H says K loops, then K will halt In either case, H gives the wrong answer for K Thus, H cannot work for all cases! The Basic Idea Model Checking is an automated and exhaustive correctness verification technique for finite state concurrent systems User does not need to be a formal methods expert Unlike testing, model checking can show absence of errors If the property cannot be verified then a counterexample path is provided 4/24/08 EEC 421/521: Software Engineering 14 4/24/08 EEC 421/521: Software Engineering 16

5 Model Checking Characteristics Model (system requirements) Model Checker Answer Yes, if model satisfies Spec Counterexample, if not Characteristics of system models which favor model checking over other verification techniques Ongoing input/output behavior (not: single input, single result) Concurrency (not: single control flow) Specification (system property) Control intensive (not: lots of data manipulation) 4/24/08 EEC 421/521: Software Engineering 17 4/24/08 EEC 421/521: Software Engineering 19 How a Model Checker Works Enumerate all possible execution traces that a system could take Evaluate the specification in each of the traces to see if it holds Implementation (system model) M = S satisfies, implements, refines Specification (system property) 4/24/08 EEC 421/521: Software Engineering 18 Example Systems Control logic of hardware designs Communication protocols Device drivers 4/24/08 EEC 421/521: Software Engineering 20

6 Describing System Model While the choice of system model is important for ease of modeling in a given situation, the only thing that is important for model checking is that the system model can be translated into some form of state-transition graph State Explosion Translation from system description to a state Diagram usually involves exponential blow-up Example: n Boolean variables ==> 2 n states! Solution: Use Kripke structures 4/24/08 EEC 421/521: Software Engineering 21 4/24/08 EEC 421/521: Software Engineering 23 State-Transition Graph System Properties q 1 a Safety Nothing bad happens a, b b Liveness Something good happens eventually (but we don t know when) q3 q 2 4/24/08 EEC 421/521: Software Engineering 22 4/24/08 EEC 421/521: Software Engineering 24

7 Safety and Liveness Temporal Logic Safety: those properties whose violation always has a finite witness ( if something bad happens on an infinite run, then it happens already on some finite prefix ) Liveness: those properties whose violation never has a finite witness ( no matter what happens along a finite run, something good could still happen later ) A formalism for describing ordering of states/events Input/output pairs are good for transformational systems Temporal logic is good for reactive systems, which continuously interact with the environment 4/24/08 EEC 421/521: Software Engineering 25 4/24/08 EEC 421/521: Software Engineering 27 Expressing Properties Temporal Logic Temporal Logic Example properties for an ATM Basic Operators Always asks for the password! - Always (G) " - Eventually (F)! - Exists (E) " - Forall (A) # - Next (X) EF g AF g If withdrawal is selected and there is enough money then eventually the requested amount is delivered Deposit is not complete until the envelope is inserted EG g AG g 4/24/08 EEC 421/521: Software Engineering 26 4/24/08 EEC 421/521: Software Engineering 28

8 Temporal Logics Symbolic Model Checking Linear Temporal Logic (LTL) The property must be satisfied by each path of the transition system Computation Tree Logic (CTL) System computation is perceived as a tree and the computation tree should obey the branching dictated by the property The two are not comparable There are CTL formulas that are inexpressible in LTL and vice versa 4/24/08 EEC 421/521: Software Engineering 29 Program or High-level Design Correctness Property (S: state space, I : initial states, R: transition relation) Are all initial states in S P, the set of states that satisfy p? P: temporal logic formula Model Checker 4/24/08 EEC 421/521: Software Engineering 31 Yes! No! Correct! Not correct! And here is why: State1 (initial) State2 State3 Bad state Explicit-State Model Checking Program or High-level Design Correctness Property A 1 A 2 Is the bad state reachable in A 1 A 2? Model Checker Correct! Not correct! And here is why: State1 (initial) State2 State3 Bad state 4/24/08 EEC 421/521: Software Engineering 30 No! Yes! Some Tools Explicit-state model checkers Spin (Bell Labs) Java Pathfinder (NASA Ames) Verisoft (Bell Labs) Symbolic model checkers SMV, nusmv (CMU) ALV (UC Santa Barbara) 4/24/08 EEC 421/521: Software Engineering 32