Analysis! Some Examples of Relations!

Transcription

1 Analysis! Testing and Analysis! Verification and Validation (V&V)! Reasoning! Relations and Analysis! A software product consists of! A collection of (types of) artifacts! Related to each other by myriad Relations! The relations are essentially desiderata! At least initially! Before the product can be trusted, the relations need to be verified/confirmed! That is the role of analysis! Does the software do what it is supposed to do! What are its capabilities and its strengths! What is the nature of the artifact(s) that have been built! What can I count on! What should I worry about! Requirements Spec.! Design! Hi Level! consistent! views! Low! level! Some Examples of Relations! Executing this code must meet this requirement! This code must conform to that design element! This compiled code came from this compiler! This design element addresses those requirements! These lower level requirements are elaborations of these higher level requirements! This is the date by which that test must be passed! Component invocations conform to component abstract interface specifications! Documentation describes the actual system! ETC..! Test Plan! Code! Much of the rest of the course will examine the ways in which consistency is defined and determined through the use of relation specifications! Requirements Spec.!!!!! Test Plan! Design! Hi Level!! Low! level! Code!

2 Relation verification should take place continuously through development! Analysis should occur continuously from the start:! requirements validated against user needs! requirements shown internally consistent! validate current artifacts against user needs! use information from previous analyses to verify current artifacts! Test plans should begin with requirements and be reviewed and refined with each phase! test plans should be executed as early as possible! More details coming up soon Requirements Spec.! Characteristics of! System to be! built must! match required! characteristics! Test Results must! match required behavior! Hi level design must! show HOW requirements! can be met! Test Plan! Test plan! exercises! this code! Design! Hi Level! consistent! views! Low! level! Code must! implement! design! Code! Requirements! Requirements! Functional" Safety" Functional" Safety" Performance" Robustness" Accuracy" Performance" Robustness" Accuracy" Test input/output! behavior must! match functional! requirements! Timing" Inputs" Outputs" Setup" Knockdown" Testplan! Timing limit! must meet! performance! requirement! Timing" Inputs" Outputs" Setup" Knockdown" Testplan! Functional" Test input/output! behavior must! match functional! requirements! and these are! the specific! timing (accuracy)! functional,...)! requirements! Timing limit! must meet! performance! requirement! Inputs" Outputs"

3 Requirements Spec.! Requirements Spec.! These are the test cases! that are used to test! for satisfaction of this! requirement! These are the test cases! that are used to test! for satisfaction of this! requirement! Test Plan! Test Plan! Basic Notions and Definitions! What are V and V! Consistency determination is fundamental! Specific relations start out as statements of intent! Product "has" these qualities if its behavior is consistent with (satisfies) statements of intent! Basic Definitions:! failure: inconsistency between actual behavior of software and specification of intent! fault: software flaw whose execution caused the failure! error: human action that results in software containing a fault! Informal Requirements! Formal Specifications! Software Implementation! Verification! Validation! More Definitions! More Definitions! Testing: The systematic () search of a program's execution! space for the occurrence of a failure! Testing: The systematic () search of a program's execution! space for the occurrence of a failure! Debugging: Searching for the fault that caused an!!observed failure!

4 More Definitions! More Definitions! Testing: The systematic () search of a program's execution! space for the occurrence of a failure! Debugging: Searching for the fault that caused an!!observed failure! Analysis: The static examination of a program's textual! representation for the purpose of inferring characteristics! Testing: The systematic () search of a program's execution! space for the occurrence of a failure! Debugging: Searching for the fault that caused an!!observed failure! Analysis: The static examination of a program's textual! representation for the purpose of inferring characteristics! Verification: Using analytic inferences to formally prove that! all executions of a program must be consistent with intent! The Essence of Analysis! COMPARISON of BEHAVIOR to INTENT! INTENT! - Originates with requirements! - Different types of intent (requirements)! BEHAVIOR! - Can be observed as software executes! - Can be inferred from execution model! - Different models support different inferences! COMPARISON! - Can be informal--done by human eyeballs! - Can be done by computers (comparing text strings)! - Can be done by formal machines (eg. FSM's)! - Can be done by rigorous mathematical reasoning! Results obtained will vary as a function of the above! Specification of " Intended Behavior " The Framework! Development" (Synthesis)" Process" Evaluation" (Analysis) " Process" Comparison of Behavior to Intent (relation checking)" Specification of " Actual Behavior" Testing/Analysis Results" (Dynamic) Testing! Dynamic Testing! Behavior determined by examining test execution results! Intent derived (somehow) from (various) specifications! Comparison usually done by textual examination! Testing should select test cases likely to reveal failures! Two basic types of testing! functional testing is based on the functional specification (black box testing)! structural testing is based on the software structure (white box testing)! Specification of! Intended Behavior! Required" Outputs" Test " Specification of Actual Execution" Behavior! Results" Result " Comparator" Failure" (Human or" Reporting" Machine)" Comparison of Behavior to Intent!

5 Testing is too long and hard to do all at once at the end of development! Divide the job into subtasks! Do some activities during development! Can do test planning during development! And should do so! Phase testing at the end! Using test plans previously developed! Testing Phases! Unit/Module! Comparing a code unit or module with design specifications.! planned during coding: done after coding! Integration! Systematic combination of software components and modules! planned during design: done after unit/module V&V! Software System! Comparing entire software system with requirements! planned during requirements: done after integration! System! Comparing integrated hardware/software system to requirements! planned during informal requirements: after SW System! Requirements! Specification! System Test! Plan! System! Testing! DEVELOPMENT PHASES! Architecting! Implementation! Designing! Software Sys.! Integration! Test Plan! Test Plan! TEST PLANNING! Software! Sys Testing! Integration! Testing! Unit! Test! Plan! Coding! Unit Testing! Reasoning during development! Should be incremental! After each phase! During each phase! Testing not possible! As usually construed! What can be done! TESTING PHASES! Flow of control edge (the ImmFol relation) Data Flow edge (artifacts flow from tail to head) DEVELOPMENT PHASES! Requirements! Specification! Requirements! Specification! System Test! Plan! System Test! Plan! System! Testing! System! Testing! Analysis of requirements happens here TESTING PHASES!

6 DEVELOPMENT PHASES! DEVELOPMENT PHASES! Requirements! Specification! Architecting! Requirements! Specification! Architecting! Implementation! Designing! System Test! Plan! Software Sys.! Test Plan! System Test! Plan! Software Sys.! Test Plan! Integration! Test Plan! System! Testing! Software! Sys Testing! System! Testing! Software! Sys Testing! Integration! Testing! TESTING PHASES! TESTING PHASES! DEVELOPMENT PHASES! DEVELOPMENT PHASES! Requirements! Specification! Architecting! Implementation! Designing! Coding! Requirements! Specification! Architecting! Implementation! Designing! Coding! System Test! Plan! Software Sys.! Test Plan! Integration! Test Plan! Unit! Test! Plan! System Test! Plan! Software Sys.! Integration! Test Plan! Test Plan! TEST PLANNING! Unit! Test! Plan! System! Testing! Software! Sys Testing! Integration! Testing! Unit Testing! System! Testing! Software! Sys Testing! Integration! Testing! Unit Testing! TESTING PHASES! TESTING PHASES! Examples of Goals for Testing! Black Box vs. White Box Testing! Does the software do what it is supposed to do! When might it fail! How fast does it run! How accurate are the results! What are its failure modes and characteristics! What can I count on! What should I worry about! What are its strengths and weaknesses! SELECTED INPUTS SELECTED INPUTS RESULTANT OUTPUTS BLACK BOX TESTING RESULTANT OUTPUTS INTERNAL BEHAVIOR DESIRED OUTPUT DESIRED OUTPUT SOFTWARE DESIGN WHITE BOX TESTING (CLEAR BOX TESTING)!

7 Input Space" Black Box Testing! Program " Testing is Sampling the Input Space! Key problem: What is the input space! What is the software intended to do! Subproblem: The input space is large! One dimension for each program input! Each dimension can have as many elements as there are legal inputs (eg. 2**32 different integers)! Each input really is different! How different Which difference matter! Key Problem: How to sample from it! Output Space" What is the input space! Computing the Input Space! Specification" sum_of_roots takes an arbitrarily long sequence of real numbers, and computes the sum of their square roots. The real number sequence must be ended with the number Implementation Program sum_of_roots; Real sum, x, r; sum := 0; Do forever input x; if x = then exit else r := sqrt(x); sum := sum + r; end do; print sum; end; There are ~2**32 possible different values for each input! If n values are read in, then there are (2**32)**n different points in the input space! The number of different input values read in is unlimited! There is no limit (theoretically) to the size of the input space! Some observations about the example program input space! There is no real need to test every possible combination of input values! Most executions behave the same! But some input combinations are different! Negative values will produce a failure! There is a virtually limitless number of inputs that donʼt cause the negative square root failure! A sufficiently large sequence of input values will cause an overflow failure! Effective selection of test cases requires thought and care" The Testcase Selection Problem! Testing (especially assertion-based) lets you put your program under a microscope! Can examine minutiae! But only for current execution! To find faults you need to select test data to cause failures! Testing can demonstrate the presence of faults (when suitable test cases are selected)! But demonstrating the absence of faults requires knowing the behaviors of all executions! But there are (virtually) infinitely many possible executions! So how to sample the inputs representatively!

8 Partitioning the Input Space! Rationale: All points in the same subdomain are processed equivalently by the program! But:! How to determine the partition! How to know how far the equivalence holds! How to select the point(s) within each domain to use as the actual input(s)! Active research in the 1970ʼs (eg. White and Cohen)! The manual and/or requirements specification can help! Equivalence Partitioning! The typical approach! A test of any value in a given class is equivalent to a test of any other value in that class! If a test case in a class reveals a failure, then any other test case in that class should reveal the failure! Some approaches limit conclusions to some chosen class of faults and/or failures! Input Space Partitioning! Input Space Divided into Domains" Program " Structural (White Box) Testing! Testcase choices driven by program structure! Flowgraph is most commonly used structure:! Represent statements by nodes! If a statement can execute immediately after another, connect the nodes representing them by an edge! Every program execution sequence is a path! Criteria based on coverage of program constructs (Howden and Miller in the early 1970ʼs)! All statements (node coverage)! All control transitions (edge coverage)! All possible paths, loop iterations (path, loop coverage)! How to generate input data to do this! What exact data sets are used to force these coverages! It matters! Rigorously defined Flowgraph helps! Functional Testing! totalpay := 0.0;! for i = 1 to last_employee! if salary[i] < ! then salary[i] := salary[i] * 1.05;! else salary[i] := salary[i] * 1.10;! totalpay := totalpay + salary[i];! end loop;! print totalpay;! Different paths partition the execution space totalpay := 0.0;! for i = 1 to last_employee! salary[i] := salary[i] * 1.05! if salary[i] < ! totalpay := totalpay + salary[i]! end loop! print totalpay! salary[i] := salary[i] * 1.10! Specification of Intent:! Expressed explicitly! Increasingly completely!» Functionality, timing, accuracy, robustness,...! Increasingly rigorously!» Mathematics, FSAʼs! Ideally arise directly from requirements and design specifications! Comparison! With automatic comparators! Specification of Behavior! Tools to capture test outputs (inputs too)!

9 Examples of Non-Structural Testing Goals! Does the software do what it is supposed to do! When might it fail! How fast does it run! How accurate are the results! What are its failure modes and characteristics! What can I count on! What should I worry about! What are its strengths and weaknesses! Functional (Black Box) Testing Guidelines! Result in many test cases! Some test cases may satisfy many heuristics! Keep track of the goal of each test case! Changes in specification will cause changes in functional test cases! Need a way to organize, use, reuse, and monitor functional testing! NOTE: many of the functional testing guidelines can also be applied in structural testing (at a more detailed and formal level)! Assertion-Based Testing! Zoom in on internal workings of the program! Examine behaviors at internal program locations while the program is executing! Augments examining only final outputs! Assertions: Specifications of intended relations among the values of program variables! Development of increasingly elaborate assertion languages (eg. Anna) in the ʻ70ʼs and ʻ80ʼs! Often: Checking relations between code and design! Comparison: Runtime evaluation of assertions! Facilities for programming reactions to violations! Also useful as a debugging aid! Inserted by" Tester" <code sequence>" X := Y;" Time := Y * 2.0 * T;" ASSERT Time > 0.0;" <rest of code>" Automatically " processed" into" if ~(Time > 0.0) Then" "Assertion_violation_handler;" Assertion-Based Dynamic Testing! Specification of " Intended Behavior " Functional" Behavior" Assertions" Runtime " Assertion" Checking" Comparison of Behavior to Intent" Specification of " Actual Behavior" Intermediate" Execution " Results " Reports on" Internal Failures" Functional vs. Structural Testing! Cannot determine if software does what it is supposed to do without considering the intent! a special case not handled by the implementation will not be tested unless the specification/ requirements are considered! Cannot ignore what is actually done by the software! program may treat one element in domain differently than stated in the specification! implementation often employs use an algorithmic technique with special characteristics that are not highlighted in the specification! Both functional and structural testing must be done! Should use all available information in testing!

10 How much testing is enough! How much testing is enough! Test programs by running data through them! Does the program select correct answers! Reject incorrect ones! Mutation Testing! How much testing is enough! Test programs by running data through them! Does the program select correct answers! Reject incorrect ones! Test test datasets by running progams through them! Can the testsets separate the correct programs from the MUTANTS! Determines the adequacy of sets of testcases! Theory! Testsets should be sufficient to pick up all faults! In order for a testset to be adequate one of its testcases must differentiate between correct code and code with a fault! Mutation Testing Approach! Produce a family of mutants of the original program! Use it to test the adequacy of the programʼs testcase set:! Run mutants and original program over the set! Make sure some testcase produces different results! If not, make sure mutants didnʼt really change the program! If it did, then add a new testcase that forces different results! original Start with program to be tested!

11 How to build the set of mutants! original mutants The competent programmer assumption! Mutants are simple coding errors! Change each integer to another! Change each loop iteration count (by 1)! Misspell each variable name! Change each arithmetic operator! Etc.! More complicated mutants seem unnecessary! Multiple mutants seem unnecessary! Create mutants * Change x := a + b To x := a - b * original mutants original mutants Create a mutan Create a mutan So, how does this original # = +, mutants - * Create mutants

12 testcases original mutants original mutants Start with all muta Consider a set Copyright of testcases! L. Osterweil, all rights reserved testcases testcases original mutants original mutants Run each testcase CS through all mutants! comparator Compare mutant output to original output! 620 Spring 2009 Univ. of Massachusetts testcases Note, for example: a test set where b = 0 will not kill the mutant created by replacing x := a + b with x := a - b original & mutants ~ = comparator If results differ then kill the mutant!

13 testcases testcases original mutants original Continue for all testcases! A good set of testcases kills all mutants! Mutation testing! A fun idea! Lots of interest in this over the decades! Still not a particularly practical idea! So what do we do instead! Summary of Problems in Doing Testing Effectively! Hard to cover program execution space effectively! Hard to select test data effectively! Hard to tell if test results are right or wrong! --if program computes complex function(s)! --if the number of test cases gets large! Best to detect errors early--before they become faults! Testing comes at the end of the lifecycle, when time and! budget tend to be short! What do you know when testing is done! What relations have been checked!!how thoroughly!!to whose satisfaction! Summary of Dynamic Testing! Strengths:! Microscopic examination of execution details! Evaluation in actual runtime environment! Oldest approach, most familiar! Weaknesses:! Cannot demonstrate absence of faults! Hard to generate test data! Hard to know when testsets are adequate! Testing aids (eg. assertion checkers) alter execution! Static Analysis! Technique for demonstrating the absence of faults without the need for execution! Specification of Intent: derived from requirements! Specification of Behavior: derived from model(s)! Comparison: Done analytically and mathematically! Results: Theorems about the program (eg. proofs that certain behaviors are impossible--or mandatory)!

14 Specification of " Intended Behavior " Inspection! Specification of " Actual Behavior" Early Static Analyzers! Informal" Specification" Human" Inspector" Comparison of Behavior to Intent" Source" Text" Informal" Error" Findings" Syntax checker: Proves that all executions are syntactically correct! Static semantics checkers: Demonstrate adherence to certain semantic rules and conditions! Line at a time checks! Combinational checks!» Type mismatches!» Argument/Parameter list mismatches! Syntax Checker! Static Semantic Analyzer! Specification of " Intended Behavior " Specification of " Actual Behavior" Specification of " Intended Behavior " Specification of " Actual Behavior" Syntax" Specification" Source" Text" Semantic" Specification" Source" Text" Parser" Syntax " Faults" Semantic" Analyzer" Static" Semantic" Faults" Comparison of Behavior to Intent" Comparison of Behavior to Intent" Dataflow Analysis! Specification of Intent: Sequence of events! Specification of Behavior: Derived from flowgraph model! Nodes annotated with events of interest! All possible executions modeled as all sequences of events along all flowgraph paths! Comparison: Analytic process! Are all possible event sequences the desired one(s)! Result: Theorems demonstrating absence of event sequence errors! Examples:! No variable referenced before definition! No file read before it is opened! Elevator doesnʼt move until doors are shut! Rocket wonʼt try to fire thrusters after fuel is exhausted! Use of the Flow Graph (ImmFol Relation) to Determine Actual Behavior! Determine local information by looking at local behavior! Which artifacts are created, used,! Infer global information! By looking at local information! And tracing flow graph edges to find relevant information at other nodes!

15 Documenting Local Behavior! First, determine local information that is true at each node in the CFG! e.g., What variables are defined! What variables are referenced! Usually stored in sets!» e.g.,ref(n) is the set of variables referenced at node n! This same type of information available for precode artifacts! Interface specifications for modules! Input and output specifications of requirements elements! Inferring Global Behavior Example: Reaching Definitions! Definition reaches a node if there is a def clear path from the definition to that node! Do this by tracing paths between nodes! Definition of x at node 1 reaches nodes 2,3,4,5 but not 6! Originally used to determine data dependencies, for debugging, data flow testing, etc. " :=x Inferring Global Behavior Example: Reaching Definitions! Definition reaches a node if there is a def clear path from the definition to that node! Do this by tracing paths between nodes! Definition of x at node 1 reaches nodes 2,3,4,5 but not 6! Originally used to determine data dependencies, for debugging, data flow testing, etc. " :=x Some types of reaching definitions behavior! Definitions that might reach a node reaching_def={x i } 1 2 reaching_def={y j } 3 reaching_def= {x i,y j } Definitions that must reach a node reaching_def={x i,y j } 1 2 reaching_def={y j } No need to use this only on models of code. Apply to rqts., design, etc. " 3 reaching_def={y j } Another Example: Live Variables! Another Example: Live Variables! a variable, x, is live at node p if there exists a def-clear path for x from node p to a use of x! x is live at 2, 3, 4, but not! at node 5! 1 2 a variable, x, is live at node p if there exists a def-clear path for x from node p to a use of x! x is live at 2, 3, 4, but not! at node 5! 1 2 Originally used to determine what variables to keep in a register after executing a line of code! 3 5 Originally used to determine what variables to keep in a register after executing a line of code! 3 5 This is best done by tracing backwards! 4 :=x 6 This is best done by tracing backwards! Applicable to models of pre-code artifacts too! 4 :=x 6

16 Computing global behavior - live variables! Possible live variables Different Global Behavior Problems Require Different Propagation Rules! live={x,y} live={x} live={y} Definite live variables 1 2 live={x} Some use forward tracing! Some use backward tracing! Some require ANDing! Some require Oring! Some compute ALL results! Some compute SOME results! Some compute NONE results! And various combinations of the above! live={x} 3 4 live={x, y} Standard Propagation Rules! Need to propagate information from IMMFOL neighbors! Backwards or forwards! Must take branching into account! Must add in local information! What is happening at this node! Finite State Verification: Using Data Flow Analysis to Verify Properties! Data flow analysis used to infer behavior! Requires use of propagation among nodes! Multiple propagations may be needed! Inferred behavior can then be compared to desired! Often comes from Requirements spec.!» E.g. robustness specs.! Finite State Verification (FSV)! Data Flow Propagation: An Example! Forward flow Verifies properties about system behavior using data-flow analysis! Works on a Control flow graph! Has been successfully used to prove a variety of properties of systems! No reason to restrict this to code! Apply to designs, architectures, etc.! :=x y:= In(n)=U K pred of n Out(k) Out(n) = (In (n)-kill (n) )U Gen(n) For reaching definitions, a definition of a variable at node n would kill any reaching definitions of that variable from other nodes, and gen a definition of that variable at node n"

17 Data Flow Propagation: An Example! Forward flow Data Flow Propagation: An Example! Forward flow :=x y:= In(n)=U K pred of n Out(k) Out(n) = (In (n)-kill (n) )U Gen(n) in := x in := x :=x 2 in := x 5 in := x 6 in := x y:= In(n)=U K pred of n Out(k) Out(n) = (In (n)-kill (n) )U Gen(n) For reaching definitions, a definition of a variable at node n would kill any reaching definitions of that variable from other nodes, and gen a definition of that variable at node n" For reaching definitions, a definition of a variable at node n would kill any reaching definitions of that variable from other nodes, and gen a definition of that variable at node n" Data Flow Propagation: An Example! Forward flow Data Flow Propagation: An Example! Forward flow in := x in := x :=x 2 in := x 5 in := x 6 in := x y:= In(n)=U K pred of n Out(k) Out(n) = (In (n)-kill (n) )U Gen(n) :=x y:= In(n)=U K pred of n Out(k) Out(n) = (In (n)-kill (n) )U Gen(n) For reaching definitions, a definition of a variable at node n would kill any reaching definitions of that variable from other nodes, and gen a definition of that variable at node n" For reaching definitions, a definition of a variable at node n would kill any reaching definitions of that variable from other nodes, and gen a definition of that variable at node n" Data Flow Propagation: An Example! Forward flow Data Flow Propagation: An Example! Forward flow :=x y:= In(n)=U K pred of n Out(k) Out(n) = (In (n)-kill (n) )U Gen(n) 1 in := { } out:= { } 3 in := { } out:= { } 4 in := { } out:= { } :=x 2 in := { } out:= { } 5 in := { } 6 in := x y:= In(n)=U K pred of n Out(k) Out(n) = (In (n)-kill (n) )U Gen(n) For reaching definitions, a definition of a variable at node n would kill any reaching definitions of that variable from other nodes, and gen a definition of that variable at node n" For reaching definitions, a definition of a variable at node n would kill any reaching definitions of that variable from other nodes, and gen a definition of that variable at node n"

18 Finite State Verification (FSV)! Verifies properties about system behavior using data-flow analysis! Works on a Control flow graph! Has been successfully used to prove a variety of properties of systems! No reason to restrict this to code! Apply to designs, architectures, etc.! Examples of Properties! Language specific! No undefined references! Canʼt write to a file until it is opened! Specific to a system! Canʼt get money until pwd is OK! Canʼt move elevator with doors open! Etc.! Examples of Properties! Language specific! No undefined references! Canʼt write to a file until it is opened! Specific to a system! Canʼt get money until pwd is OK! Canʼt move elevator with doors open! Etc.! Some properties are much more complicated.! Longer sequences of events! Verifying harder properties! Represent Event Sequence Properties of Systems! Create an event flow model of the system! Specify properties as FSAs! Verify that all the possible traces through the CFG of the system are consistent with the property specified by the FSA! Associates the states in the property with the nodes in the CFG! Note: Specify robustness requirements with an FSA()! Elevator Property! The elevator does not move! while its doors are open.! L(P) is the set of all strings! accepted by property P! All traces through the system should satisfy this property! Events: open, close, move Events! Recognizable events! Method calls!» Can reason about sequences of method calls!» E.g., Push must be called before Pop! Thread interactions!» Join or Fork! Arbitrary operations!» a+b=> Add AB event! Need to be able to treat events as indivisible actions! E.g., can treat pop and push as atomic as long as they do not contain any events of concern!!

19 All or None Properties! An all property is a behavior that must always happen on all possible executions! A none property is a behavior that must never happen The elevator never moves while the doors are open! This FSA is a none property--note that the! accepting state is the! complement of the! accepting states of the ALL property! The None Property! close open move close move open close, open,move Using Quantified Regular Expressions! Alphabet, quantification, regular expression For the events {open, close, move}!!show that for all paths!! Annotated CFG! A CFG G is <N, n initial, n final, E>! Use annotation relation to associate events with nodes! Σ G is the alphabet of G! Events must be indivisible wrt other events in the property! L(G) is the language of G! The set of all strings in (Σ G ) * that occur on paths from the initial node to the final node! CFG is alphabet refined! Remove nodes that do not affect the property being verified! ((close v move)*, (open +, close)*)*, open*! Static Dataflow Analysis! Specification of " Intended Behavior " Specification of " Actual Behavior" Architecture of the DFA verifier! Event" Sequences" Possible" Execution" Sequences" Event alphabet Property! Property! Translator! Dataflow " Propagation" Algorithms" Comparison of Behavior to Intent" Proofs of the" Presence or" Absence of" Faults" System! Ada, Java, C++, Jovial System! Annotated CFG! Translator! FSA Reasoning Engine! Consistent! Inconsistent + counter example!

20 Reasoning Engine: State Propagation! States of the property are propagated through the CFG! For each node of the CFG, indicate the states of the property that the program could be in at that point in the program! Need to show L(G) L(P)! The property is proved if only accepting (nonaccepting) states are contained in the final node of the CFG! Uses Data Flow Analysis! Forward Flow, Any Path Problem! IN and OUT are sets of FSA states! IN(n) = OUT(m)! m in pred(n) OUT(n) = δ(s, n) s in IN(n) δ is the FSA transition function In Out Result: Let f be the final node of the TFG! All property: Want OUT(f) Accept(P)! None property: Want OUT(f) Accept(P) =! Where Accept(P) is the set of accepting states of a property, P! Worst-case cost is O((N G ) 2 S P )! Simple Example! State Propagation! State Propagation! State Propagation! 1: if 1 2: open 3: if 3 5: move 3

21 State Propagation! Fixed Example! 1: if 2: open 3: if 5: move State Propagation! State Propagation! 1 System! Ada, Java, C++, Jovial Architecture of the DFA verifier! Event alphabet System! Annotated CFG! Translator! Property! FSA Property! Translator! Reasoning Engine! Consistent! Inconsistent + counter example! State Propagation: Strengths! Relatively efficient approach for proving properties of a system! Requires limited manual intervention! Techniques being developed to automatically determine constraints or system model! Actually proves that the property is true for all possible executions! or! provides a counter example!

22 State Propagation: Weaknesses! Difficult to state the properties precisely! Program, property, or both could be wrong! Must look at each counter example to determine if it corresponds to an executable path! Can only reason about static models of the system! Still a sampling technique! Must decide what properties to verify! Concurrent and Distributed Systems! Extremely difficult to develop and test such systems! Non-determinism means that! the same inputs might produce different outputs on different executions! When reasoning about a system there are numerous different alternatives to consider!» Usually more than a programmer can reasonably consider! In addition to the problems that can arise with sequential programs, have problems that are unique to concurrent systems! Data access problems! Synchronization problems! Recent and Future Work! Specifying properties (Propel) (ICSE2002, ISSTA2006)! Heuristics for constraint selection (FSE2003)! Heuristics for counterexample selection (FSE2004)! Design-time verification applied to architectural description languages (CBSE 2006)! Integrating Testing and FSV techniques! Verification of process descriptions! Scientific processes! Medical processes!» To improve safety and efficiency! ecommerce and egovernment processes!» To assure security and privacy! Conclusions! Finite state verification approaches are improving! Being used in industry for hardware systems! With the increasing interest in software security and quality, becoming more widely used for software systems! FLAVERS provides a demonstration of its potential effectiveness! Evaluation of Static Analysis! Strengths:! Can demonstrate the absence of faults! Proofs can be automatically generated and proven! Algorithms are fast (low-order polynomial)! No need to generate test data! You know when you are done! Weaknesses! Behavior specification is a model with inaccuracies!» Not all paths are executable! Only certain classes of faults analyzable!» Mostly sequence specific!» Weak on functionality! Symbolic Execution! Specification of Intent: Formulae, functions! Specification of Behavior: Functions derived from annotated flowgraph, symbol table! Annotate nodes with function(s) computed there! Specify path to be studied! Compute function(s) computed as composition(s) of functions at path nodes, constraints of path edges! Comparison: Solving simultaneous constraints; symbolic algebra! Results: Demonstrations that given paths computed the right function(s)!

23 Symbolic Execution! Specification of " Intended Behavior " Function" to be" Computed" Functional" Equivalence" Theorem Prover" Comparison of Behavior to Intent" Specification of " Actual Behavior" Formula" Inferred from" Actual Code" Proofs of" Functional" Correctness" Example Symbolic Representation! 1: input A,B 2: A>0 3: C :=0 4: C := A*B 5: B>0 6: X := C*(A+2*A) 7: X := A+B 8: output X P1: (1,2,4,5,6,8)!! n: path values path condition!!1: A=a, B=b true!! 2: a 0!! 4: C=a*b!! 5: a 0 b>0!! 6: X = a*b*(a+2*a)!! 8: out 3*a**2*b! Path condition: a 0 b>0! Variable values! A: a! B: b! C: a*b! X: 3*a**2*b! Example Symbolic Representation! 1: input A,B 2: A>0 3: C :=0 4: C := A*B 5: B>0 6: X := C*(A+2*A) 7: X := A+B 8: output X P2: (1,2,4,5,7,8)!! n: path values path condition!!1: A=a, B=b true!! 2: a 0!! 4: C=a*b!! 5: a 0 b 0!! 7: X = a+b!! 8: out a+b! Path condition: a 0 b 0! Variable values! A: a! B: b! C: a*b! X: a+b! Example Symbolic Representation! 1: input A,B 2: A>0 3: C :=0 4: C := A*B 5: B>0 6: X := C*(A+2*A) 7: X := A+B 8: output X P1: (1,2,3,5,7,8)!! n: path values path condition!!1: A=a, B=b true!! 2: a>0!! 3: C= 0!! 5: a>0 b 0!! 7: X = a+b!! 8: out a+b! Path condition: a>0 b 0! Variable values! A: a! B: b! C: 0! X: a+b! Applications of Symbolic Evaluation! Symbolic Testing! examination of path domain and computation for detecting failures! especially useful for scientific applications! Path and Test Data Selection! select paths to cover structure and determine feasibility of condition! select data to satisfy path condition or revealing condition! Debugging! examine symbolic representation for faulty data manipulation! Verification! prove consistency of specification assertions! inductive assertion method for proving correctness!...!» {I} S {O}...! xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx! xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx! Proof of Correctness! Formal Verification! INTENT:! o Usually specification of functionality! --What function(s) does the software compute! o Sometimes accuracy, timing,...! BEHAVIOR:! o Inferred from semantically rich program model! o Generally requires most of semantics of programming!! language! o Generally uses symbolic execution! COMPARISON:! o Use of formal mathematics (eg. predicate logic)! o Probably source of misleading name: PROOF of!!correctness! --Proof is probably OK! --Correctness is dangerously misleading!

24 Specification of " Intended Behavior " Formal Verification! Specification of " Actual Behavior" Floyd Method of Inductive Assertions! Final and" Intermediate" 1st-Order Logic" Assertions" Symbolic" Execution " of Path" Segments" Show that each program fragment behaves as intended! Use induction to prove that all sequences of executable fragments behave as intended! Show that the program must terminate! First-Order Logic" Theorems and" Proofs" Comparison of Behavior to Intent" Proof of the" Absence of" All Functional" Faults" Use of Assertions! Assertion: Specification of a condition that is intended to! be true at a specific given site in the program text! In Floyd's Method, assertions are written in Predicate Logic! In Floyd's Method there are three types of assertions:! o Initial, As: Sited at the program initial statement! o Final, AF: Sited at the program final statement! o Intermediate Ai: Often called a "loop invariants"! Sited at various internal program locations subject!! to the rule:! EVERY LOOP ITERATION (CFG CYCLE) SHALL PASS THRU! THE SITE OF AT LEAST ONE INTERMEDIATE ASSERTION! Net Effect: Every program execution sequence is divided! into a finite number of segments of non-looping code! bounded on each end by a predicate logic assertion! Mathematical Induction! Goal: prove that a given property holds for all elements of a set! Approach:! (initial step) show property holds for "first" element! (induction step) show that if property holds for element i, then it must also hold for element i + i! Often used when direct analytic techniques are too hard or complex! Example: How many edges in C n! Initial Step! Theorem:! let C n = (V n, E n ) be a complete, unordered graph on n nodes,!!!!then E n = n * (n-1)/2! show the property is true for C1:! graph has one node, 0 edges! E1 = n(n-1)/2 = 1(0)/2 = 0!

25 Induction Step! assume true for Cn: En = n(n-1)/2! graph Cn+1 has one more node, but n more edges (one from the new node to each of the n old nodes)! so, En+1 = n(n-1)/2 + n! = n(n-1)/2 +2n/2 = (n(n-1)+2n)/2! = (n(n-1+2))/2 = n(n+1)/2! = (n+1) ((n+1)-1)/2! = (n+1)(n)/2! Floydʼs Method of inductive assertions (informal description)! Place assertions at the start, final, and intermediate points in the code.! Any path is composed of sequences of program fragments all of which:! start with an assertion! are followed by some assertion free code! and end with an assertion eg. (As =) A0, C1, A1, C2, A2, An-1, Cn-1, An, Cn, An+1(=Af)! Show that for any executable path, if Ai is assumed true for any Ai and code Ci is executed, then Ai+1 must always be true! Pictorially! Must be sure:! intermediate assertions assuming A i, then executing Code C i,! necessarily A i+1! by forward substitution! initial assertion A i! C i! STRAIGHT-LINE CODE! A i+1! A i! A i+1! final assertion C i! STRAIGHT-LINE CODE! Why does this work! suppose P = arbitrary path through the program! can denote it by! P = A s C 1 A 1 C 2 A 2...C n A F! where! A s -!Initial assertion! A F -!Final assertion! A i -!Intermediate assertions! C i -!Loop free, uninterrupted,!!!straight-line code! If it has been shown that! i, 1 i < n: A i C i A i+1! Then, by induction! Loop Invariants (Loop Breakers)! Problem: infinite number of paths! Must find a way to deal with loops! Solution: Assertion, Ai, that is! True for any number of loop iterations! connects up to adjacent assertions! Such an assertion:! Is invariant with respect to loop iterations! Must be embedded in (break) every loop! A loop invariant must capture the essence! Of the work that the loop is to perform! A s... A f!

26 Schematic Example of a Loop Invariant! Ai is a loop invariant because of its relation to other assertions:!!!note THAT:! A I, false branch, => A I! A I, true branch, => A I!! BUT ALSO:! Initial assertion A s to A I => A I! A I, false branch, => final assertion A F! A I, true branch, => final assertion A F! A s " A F! A I " false! true! Floydʼs Method (carefully stated)! Specify initial, final assertions to capture intent! Intermediate assertions "cut" every program loop! For each pair of assertions with an executable (assertionfree) path from the first to the second,! Assume that the first assertion is true! Show that for all (assertion-free, executable) paths from the first assertion to the second, that the second assertion is true! This establishes partial correctness! Show that the program terminates! This establishes total correctness! Floyd-Hoare axiomatic proof method! Floyd-Hoare axiomatic proof method! Assertions are preconditions and postconditions on some statement or sequence of statements! Goal: For all adjacent assertion pairs, P and Q, If P (the precondition) is true before S is executed, and then S is executed, then Q (the postcondition) must be true Notation: P{S}Q As in Floyd's inductive assertion method, we construct a sequence of assertions, each of which can be inferred from previously proved assertions and the rules and axioms about the statements and operations of the program To prove P{S}Q, we need some axioms and rules about the programming language! Hoare axioms and proof rules! Take a simple programming language that deals only with integers and has the following types of constructs:! assignment statement!!!! f! composition of a sequence of statements!!! S1, S2! conditional (alternative statements)!!!!if B then S1 else S2! iteration!!!!while B do S! Axioms and proof rules! axiom of assignment! P {f} Q,! where Q is obtained from P by substituting f for all occurences of x in P (symbolic execution)!! rule of composition! P {S1, S2 } Q => P{S1}P1 P1{S2}Q! Using Hoare's notation, this is written as! P{S1}P1, P1{S2}Q! P {S1,S2} Q!

27 Proof Rules (continued)! rule for the alternative statement! P{if B then S1 else S2 }Q!!!!!!P{B S1}Q P{~B S2}Q! Hoare's notation!! P{B S1}Q, P{~B S2}Q! P{if B then S1 else S2 }Q! Proof rules (continued}! rules of consequence! [P {S} Q Q R] P {S} R! [P {S} Q R P] R {S} Q! Hoare's notation! P {S} R, R Q! P {S} Q! P R, R {S} Q! P {S} Q! An Example: Wensley's Algorithm! Procedure Wensley (P: input, Q: input, E: input, Y: output); --assume 0 P<Q, 0< E! Declare P, Q, E, Y, A, B, D real;! A :=0.0; B :=Q / 2.0; D :=1.0; Y := 0.0;! Do_While (D>=E)! If (P - A - B >= 0.0) then {Y := Y+(D / 2.0); A := A+B};! B :=B / 2.0; D := D / 2.0;! Wensleyʼs Algorithm! Input P, Q, E A 0.0 B Q/2 D 1.0 Y 0.0 D E P-A-B 0.0 A0! AI! AF! Y Y+(D/2.0) A A+B End_do;! End Wensley;! B B/2.0 D D/2.0 What does Wensley's algorithm do! What does Wensley's algorithm do! Approximating P/Q (=Y) with error E! On the kth iteration of the loop! A k = a 1 Q2-1 + a 2 Q a k Q2 -k a i {0,1}! B k = Q2 -k! D k = 2 -k! Y k = a a a k 2 -k a i {0,1}! Input P, Q, E A 0.0 B Q/2 D 1.0 Y 0.0 D E A0! AI! AF! since 0 P/Q<1, then P/Q can be estimated as a sum of the series a a a k 2 -k!!a i {0,1}! therefore! Y k is the computed value of the quotient! given Y k, A k is the computed dividend P! D k is the computed error! P-(A k + B k ) says when to add 2 -(k+1) to Y k+1 (a k+1 = 1)! P-A-B 0.0 Y Y+(D/2.0) A A+B B B/2.0 D D/2.0 B k = 2 -(k+1) * Q!

28 Initial: Final: Assertions!!A 0 : {(0 P<Q) (0< E)}!!A F : {((P/Q-E)<Y (P/Q))}! computed quotient! Intermediate:!!!A I : {(A=Q*Y) (B=Q*(D/2))!! (k 0, k integer D=2 -k )!!! ((P/Q)-D)<Y (P/Q)}! computed error! Summary of Four Lemmas Needed! I.!Initial assertion, A0, to AI! II.!AI, false branch, to AI! III.! AI, true branch, to AI! IV.! AI, to AF, final assertion! Input P, Q, E A 0.0 B Q/2 D 1.0 Y 0.0 D E P-A-B 0.0 B B/2.0 D D/2.0 A0! AI! AF! Y Y+(D/2.0) A A+B Y is within the computed error D of P/Q! Lemmas called verification conditions A 0 : Initial Assertion! (0 P < Q) (0 < E)! { Input P, Q, E! A 0;! code B Q/2;! D 1;! Y 0;! A I :! A = Q * Y! B = Q * D/2! D = 2 -k, k = 0! P/Q - D < Y P/Q! Lemma I: A 0 to A I! Input P, Q, E A 0.0 B Q/2 D 1.0 Y 0.0 A0" A" 1" A 0 : Initial Assertion! (0 P < Q) Λ (0 < E) { Input P, Q, E! code A 0;! B Q/2;! D 1;! Y 0; A 1 :! A = Q * Y! B = Q * D/2! D = 2 -k,k=0! P/Q - D < Y P/Q! Lemma I: A 0 to A I! Proof: 1) A = 0; Q *Y = Q * 0 = 0 A = Q *Y 2) B = Q/2 = Q * 1/2 = Q*D/2 3) D = 1 = 2-0 4) P/Q - 1 < Y = 0 P/Q because 0 P/Q < 1 given by input assertion Lemma II: A I, false branch, A I A I :! A = Q * Y! B = Q * D/2! D = 2 -k for some integer k! P/Q - D < Y P/Q! } D E [constraint]! P - A - B < 0 [constraint]!!b B/2! code!d D/2! AI: A = Q * Y!!B = Q * D/2!!D = 2 -(k+1)! P/Q - D < Y P/Q! D E A" I" P-A-B 0.0 B B/2.0 D D/2.0 Proof of lemma II! Need to establish that A1 is a correct relation among variable values after loop execution, based on assumption that A1 was correct among variable values before loop execution! Notation:! A, B, D, Y are original values of variables" A" I" Aʼ, Bʼ, Dʼ, Yʼ are values " "after loop execution" D E Symbolic execution gives:! Aʼ = A, Bʼ= B/2; Dʼ = D/2; Yʼ = Y" P-A-B 0.0 B B/2.0 D D/2.0

29 A = Q * Y! B = Q * D/2! D = 2 -k for some integer k! P/Q - D < Y P/Q! } D E [constraint]! P - A - B < 0 [constraint]!!b B/2!!D D/2! Aʼ = Q * Yʼ!!Bʼ = Q * Dʼ/2!!Dʼ = 2 -(k+1) for some integer k!!p/q - Dʼ < Yʼ P/Q! Proof of Lemma II! (Symbolic execution shows A = A, B = B/2; D = D/2; Y = Y) Proof: 1) A = A = Q * Y = Q * Y 2) B = B/2= (Q * D/2)/2 =(Q * 2D /2)/2 = Q*D /2 3) D = D/2= 2 -k /2 = 2 -k-1 =2 -(k+1) 4) a)p-a-b < 0 (constraint ) P - Q * Y - Q * D/2 < 0 P/Q - Y - D/2 < 0 (uses Q > 0) P/Q - D/2 < Y but D = D/2 P/Q - D < Y b)y P/Q => Y P/Q Lemma III: AI; True branch; AI! AI: A = Q * Y! B = Q * D/2! D = 2 -k for some integer k! P/Q - D < Y P/Q! D E [constraint]! P - A - B 0 [constraint]!!y Y+(D/2.0)!!A A+B!!B B/2!!D D/2! AI: Aʼʼ = Q * Yʼʼ!!Bʼʼ = Q * Dʼʼ/2!!Dʼʼ = 2 -(k+1) for some integer k!!p/q - Dʼʼ < Yʼʼ P/Q! D E P-A-B 0.0 B B/2.0 D D/2.0 A" 1" A" F" Y Y+(D/2.0) A A+B From symbolic execution we know:! Aʼʼ = A + B; Bʼʼ = B / 2; Dʼʼ = D / 2; Yʼʼ = Y + D / 2;! We also know: P - A - B 0 and D E! Proof Lemma III! Lemma IV AI,AF AI: A = Q * Y! B = Q * D/2! D = 2 -k for some integer k! P/Q - D < Y P/Q! D E [constraint]! P - A - B 0 [constraint]!!y Y+(D/2.0)!!A A+B!!B B/2!!D D/2! AI: Aʼʼ = Q * Yʼʼ!!Bʼʼ = Q * Dʼʼ/2!!Dʼʼ = 2 -(k+1) for some integer k!!p/q - Dʼʼ < Yʼʼ P/Q! From symbolic execution we know: A = A + B; B = B / 2; D = D / 2; Y = Y + D / 2; We also know: P - A - B 0 and D E Proof: 1) A = A + B = Q*Y + Q*(D/2) = Q(Y + D/2) =Q * Y 2) B = B/2 = Q * D/2/2 = Q * D /2 3) D = D/2 = 2 (-K-1) = 2 -(k+1) 4) a) P - A - B 0 P - Q *Y - Q * (D/2) 0 P/Q - D/2 Y P/Q - D/2 Y - D/2 P/Q Y b) P/Q - D < Y P/Q - D < Y - D/2 P/Q - D/2 < Y P/Q - D <Y AI, false, AF! D E AI" AF" Lemma IV! A I : (A=Q*Y) (B=Q*(D/2)) (k 0, k integer D=2 -k )!!! ((P/Q)-D)<Y (P/Q)! D < E ] code! A F: ((P/Q-E)<Y (P/Q))! Proof:! Given ((P/Q)-D)<Y (P/Q) and (D < E)! ((P/Q)-E)<((P/Q)-D)<Y (P/Q) A F! This is only partial correctness! Must also prove termination! In general, can not prove termination! For most programs, can usually do it by showing that each loop must terminate For our example: given that (E>0) observe that D decreases on each iteration and E does not change Thus, eventually D<E and the loop terminates! Input P, Q, E A 0.0 B Q/2 D 1.0 Y 0.0 D E P-A-B 0.0 A0! AI! AF! Y Y+(D/2.0) A A+B B B/2.0 D D/2.0

30 Observations! Proofs are long, tedious & often hard! Assertions are hard to get right! Invariants are difficult to get right.! need to be invariant, but also need to support overall proof strategy! Proofs themselves often require deep program insight! Often require axioms about the domain! Deeper Issues! Unsuccessful proof attempt! incorrect software! incorrect assertions! incorrect placement of assertions! inept prover! any combination (or all) of the above! Although failed proofs often indicate which of the above is likely to be the problem (especially to an astute prover)! Deeper Issues! Undecidability of Predicate calculus -- no way to be sure when you have a false theorem! There is no sure way to know when you should quit trying to prove a theorem (and change something)! Proofs are generally much longer than the software being verified! Suggests that errors in the proof are more likely than errors in the software being verified! Mathematics as a "social process"! Belief in a proof is a social process! Informally describe proof! Distribute an informal write-up to colleagues! Formal write-up is refereed! Accepted paper gets read by wider audience! Proof/Theorem is used! Increases confidence! Despite this, mathematical proofs are often wrong! Specification Problem! Real programs are not captured by simple mathematical algorithms! E.g. This software correctly identifies faces! Error processing issues! User interface issues! Resulting specifications are! Large! Mathematically unappealing! Probably not complete! Hard to capture intent! Specification Problem! Specification & program are not independent representations! Proof not 'mathematically' sound! Very labor intensive! Loop invariants - usually manual! Input and output assertions - manual! Verification conditions - can be automated!

31 Software Tools Can Help! Proof Checkers:! Scrutinize the steps of a proof and determine if they are sound! Identify the rule(s) of inference, axiom(s), etc. needed to justify each step! How to know if the proof checker is right (verify it with what...)! Software Tools Can Help! Verification Assistants! Facilitate precise expression of assertions! Accept rules of inference! Accept axioms! Construct statements of needed lemmas! Check proofs! Assist in construction of proofs (theorem provers)! Human/computer collaboration! Most successful -- human/computer collaboration!» Human architects the proof!» Computer attempts the proof (generally by exhaustive search of space of possible axioms and inferences at each step)!» Human intervention after computer has tried for a while! Current Status:! Have verified some non-trivial programs or important parts of programs! e.g., protocol verification! Improved theorem provers! Improved specification languages! Verification and testing/analysis research now viewed more as a continuum testing--> finite state verification--> verifications! Summary! Verification has had a very positive impact on software engineering! major argument for structured programming!» Dijkstra's "goto's considered harmful" letter!» one-in one-out structures easier to reason about! major impetus for abstract data types!» centralized all changes to a data structures!» input/output assertions for all operations! Formal Development! Start with assertions, develop software artifacts to fulfill them! A top-down approach! Very popular in Europe: A hard sell in the U.S.! Need to prove lemmas in higher level software dictates the functional requirements (eg. input/output assertion) pairs of lower level software artifacts.! Also suggests the use of libraries of reusable verified software artifacts for commonly needed utilities! This is Component-based software development!