Coding and Testing. The Coding Phase. Coding Goal: Create code that can be executed on a computer! What makes a programming language good?
|
|
- Emory Martin
- 5 years ago
- Views:
Transcription
1 Requirements Spec.! Design! Coding and Testing Computer Science 320! Fall 2010! Prof. Leon Osterweil! 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! exercises! this code! Hi Level! consistent! views! Low! level! Code must! implement! design! Test Plan! Code! The Coding Phase relations to! test cases! Code-related artifacts executables! parse trees! Object! Source! relations! to low! level! design! Goal: Produce executable code in a coding language! Gets down to very specific details:! --Procedures/algorithms! --Data structures! --The interactions between them! --THE DEVIL IS IN THE DETAILS! Coding is usually 10-15% of the effort on a software!!development project: We will spend little time on it in!!this course! instrumented! source! Coding should follow closely the specifications resulting! from the final phases of design! --Modular structure of the code! --Object specifications (data modules) (Data abstractions)! Coding Goal: Create code that can be executed on a computer! Developer writes source code! Object code emitted from a compiler!!so, is code really just another model?! Executable results from loading object code with libraries,! utilities, etc.! What makes a programming language good? Important to keep all of these straight! Some designed to support specific design methodologies! Some are special-purpose, well adapted to application!!domains!
2 A good language is one that meets the needs of its stakeholders What makes a programming language good? If it meets the needs of its stakeholders Different kinds of projects Quality is super-important Rapid deployment is key Evolvability is paramount Emphasis on user interface Etc. Suggest languages with strengths like Readability Expressive power Low level (close to the machine) Dynamism and late binding Etc. On Languages Bad code can be written in any language But some languages encourage bad practices Good code can be written in any language But some languages encourage it/make it easier And discourage bad practices Most modern languages try to encourage good practices Like those we have been advocating (in discussing design) Modularity Information hiding Data abstraction Incorporation of design and requirements specification into code Support for testing and analysis Information Hiding in Implementation Implementation units should hide internal details as specified by a Modular design Superior procedure semantics support this better Implementation units should communicate through welldefined interfaces (not global variables). Some languages make global data easier than others Some languages make it hard to inspect internals of Modules. Others make it easier Different decisions are harder or easier to hide Algorithm Data representation Lower-level modules Policy Data Abstractions User's (client's)-eye view of the data types to be used! Essentially the same as Parnas notion of a "data module"! --and the notion of an "object"! Cluster of "accessing primitives" / "methods" whose! purpose is to provide the only mechanisms for! manipulating data of a given type! Problem: How to specify the semantics of these types! --without specifying their implementation! Being rigorous help separate (even slightly) different! notions of an ADT from each other! Assertion Languages Assert statements to define assertions Assertions defined by programmer Locations identified by programmer Reactions to violations defined by programmer Different assertion language semantics Usually Boolean logic Sometimes private data space
3 Tool Suites Better tools make languages more useful Better editors Better diagnostics Better testing aids More powerful libraries Etc. Ada Early language that supported information hiding Use of External and Internal part dichotomy Strict encapsulation Support for data abstraction Packages Very wordy Support for disciplined concurrency No type hierarchy Very static language C C++ Gets you down close to the machine Little restriction on use of pointers Little restriction (help with) dynamic storage allocation Little support for encapsulation Adds support for objects to C Thus, support for objects (encapsulation) Type hierarchies Still little discipline over pointers, storage allocation Java Lisp Early language with special attention paid to dynamism and the web Designed to facilitate distributed applications Host readily on various machines (across the web) Support by lots of tools Highly dynamic language Various sorts of late binding But more discipline than C (eg. over use of pointers) Very dynamic language Very little compilation done Mostly interpretation Create code on the fly and interpret it Excellent vehicle for rapid prototyping Virtually no concept of types Types with Lisp extensions Primitive flow of control structures Very hard to encapsulate
4 Ruby/Python/Perl Prolog Highly dynamic Interpreted, not compiled Sometimes used as a scripting language, sometimes as general-purpose programming language Object-orientedness varies Extensive libraries Supporting frameworks RoR for web applications Rule-based language No real procedural flow of control Emphasis on reaction Favorite language for trying to capture human knowledge Data is subordinated Structuring, modularization are difficult Patterns Higher level implementation constructs Idioms (Rich and Waters, ~1985) The Gang of Four book Inspiration from real architects (C. Alexander) Idioms in common use Suggest ways that humans think/human esthetics Transcend specific languages Some finding more direct support in newer languages Coding closely tied up with Testing The essence is dealing with Faults They manifest themselves as Failures 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 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 More Definitions Testing: The systematic (?) search of a program's execution! space for the occurance 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!
5 Validation and Verification (V&V) Informal Requirements! Formal Requirements! Software Implementation! Verification! Validation! Other Quality/Reliability Improvement Approaches Fault avoidance: software development techniques that reduce the incidence of faults (e.g., design principles and methods, formal specification, prototyping)! Fault elimination: software analysis techniques that detect and remove faults (e.g., reviews and inspections, static analysis, testing, formal verification)! Fault prediction: software analysis techniques that predict the occurence of faults and direct further efforts (e.g., reliability assessment, metrics)! Fault tolerance: software execution techniques that detect and correct errors before a failure occurs!(e.g., self-checking assertions, recovery blocks, n- version programming)! The Basic Fault Elimination Approach COMPARISON of! BEHAVIOR to! INTENT! INTENT:! - Originates with requirements! - Different types of intent (requirements)! - Each type relatively better captured with different set of! formalisms! BEHAVIOR! - Can be observed as software executes! - Can be inferred from execution model! - Different models support different sorts of inferences! Specification of " Intended Behavior " A Unifying Framework Development" (Synthesis)" Process" Evaluation" (Analysis) " Process" Specification of " Actual Behavior" COMPARISON! - Can be informal--done by human eyeballs! - Can be done by computers--eg. 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! Comparison of Behavior to Intent (constraint evaluation)" Testing/Analysis Results" Testing Behavior determined by examining test execution results! Intent derived (somehow) from (various) specifications! Comparison is done by textual examination! Testing must select test cases likely to reveal failures! Equivalence partitioning is 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! 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)! Black box vs. white box testing White box testing (vs. Black box testing) Black Box testing No knowledge of internals Testing relies on observing external behavior Driven by users, customers, etc. White Box testing Uses knowledge of program structure Uses monitoring of program internals Often driven by developers, based on implementation issues Complementary approaches Each produces results that stimulate the other
6 Black Box vs. White Box Testing Dynamic Testing SELECTED INPUTS RESULTANT OUTPUTS DESIRED OUTPUT Specification of! Intended Behavior! Required" Outputs" Test " Specification of Actual Execution" Behavior! Results" BLACK BOX TESTING SELECTED INPUTS RESULTANT OUTPUTS INTERNAL BEHAVIOR WHITE BOX TESTING (CLEAR BOX TESTING)! DESIRED OUTPUT SOFTWARE DESIGN Result " Comparator" (Human or" Machine)" Comparison of Behavior to Intent! Failure" Reporting" Testing Aims to Answer Jalote Chapter 10, starting on Page 465 covers this subject 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? A Simplistic View A More Realistic View Input Space" Program " Program " Input Space Divided into Domains" Output Space"
7 Partitioning the Input Space Rationale: Test the program one function at a time The requirements specification is used to enumerate the functions Then test the different functions And the non-functional requirements Do this by sampling from the different partitions 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 differences matter? Key Problem: How to sample from the input 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; 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 Summary of Some Difficulties 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! Hard to tell when you are done with testing! --Is it good or bad to keep finding faults?! Effective selection of test cases requires thought and care"
8 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 unit or module with design specifications. Integration Systematic combination of software components and modules to insure consistency of component interfaces and adherence to design specification Software System Comparing an integrated software system with software system requirements System Acceptance evaluation of an integrated hardware and software system Requirements! Specification! System! Testing! Development Phases! Architecting! Designing! Coding! Software! Sys Testing! Integration! Testing! Testing Phases! Unit Testing! Create Test Plans As Early as Possible No need to wait until after development to create test plan Desired behaviors specified in requirements Tests are run after development Test plans built beforehand Good reasons to plan early Testing may require developing test harnesses May help identify untestable requirements Or vague, poorly thought out requirements We can do this at first Then later. Requirements! Specification! Requirements! Specification! Architecting! System Test! Plan! System Test! Plan! Software Sys.! Test Plan! System! Testing! System! Testing! Software! Sys Testing!
9 And later still. DEVELOPMENT PHASES! Requirements! Specification! Architecting! Implementation! Designing! Requirements! Specification! Architecting! Implementation! Designing! Coding! System Test! Plan! Software Sys.! Test Plan! Integration! Test Plan! System Test! Plan! Software Sys.! Test Plan! TEST PLANNING! Integration! Test Plan! Unit! Test! Plan! System! Testing! Software! Sys Testing! Integration! Testing! System! Testing! Software! Sys Testing! Integration! Testing! Unit Testing! TESTING PHASES! Summary of Dynamic Testing Testing is Buying Knowledge The testing costs resources It should result in knowledge that is worth the cost? The value of the knowledge is up to the buyer The cost of the knowledge is something that software engineers should be able to estimate 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 Hard to decide when enough testing has been done Testing aids can alter execution Analysis Testing can only prove the presence of faults, not their absence Static analysis doesn t require execution Build mathematical model of software Do reasoning, prove theorems Can show the absence of errors Responds to testing weaknesses No need to select input data No need to examine output results No problem knowing when you are done Limitations Only some theorems can be proven Some of them are very hard 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)!
10 Many Static Analysis Approaches Inspection Syntax Checking Semantic Checking Flow Analysis Formal Verification Specification of! Intended Behavior! Informal" Specification" Inspection Human" Inspector" Specification of! Actual Behavior! Source" Text" Informal" Error" Findings" Comparison of Behavior to Intent! 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! Early Static Analyzers Example Semantic Checks 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! Division by 0 Parameter/argument mismatches??
11 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! Static Dataflow Analysis Specification of! Intended Behavior! Event" Sequences" Dataflow " Propagation" Algorithms" Specification of! Actual Behavior! Possible" Execution" Sequences" Comparison of Behavior to Intent! Proofs of the" Presence or" Absence of" Faults" 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;! Example Flowgraph totalpay := 0.0;! for i = 1 to last_employee! salary[i] := salary[i] * 1.05! if salary[i] < ! salary[i] := salary[i] * 1.10! Skeleton Flowgraph Do If 7 totalpay := totalpay + salary[i]! 8 9 end loop! 10 print totalpay! 11 Annotated Flowgraph X := Do X := Something Wrong Here Do := X X := If 7 If
12 Better := X Do 2 3 X := Tougher Situation Do If 7 If X := 8 9 := X More Serious Issue Here Open Door Move Elevator Do 2 3 Close Door 4 If 7 A Problem 6 5 Do 2 If Open Door Move Elevator 8 9 Close Door Another Problem? Close Door Move Elevator 6 5 Do 2 If Open Door Static Analysis of Pre-code Artifacts Flowgraphs of designs are possible Apply analyses to the graphs There are other graphs too Data flow graphs Finite State Machines Petri Nets This is what should happen at the end of design, and other pre-code phases.
13 What about analysis of functionality Preceding suggests analysis for non-functional behaviors Especially robustness Major interest in analysis for functional correctness How to keep control of software? We need a way to prevent runaways and other forms of bad behavior Analogous to Heat sink (thermodynamics) Electrical ground (electrical engineering) Containment Vessel (nuclear energy) What do we have???? Why should we care? A Story from the Past: The Story of Bob G. The position of software in society The infrastructure in the infrastructure Banks Telephones Computer Networks Roads Air Travel Software is in all of them In the most critical positions
14 Old software never dies What are our obligations when we produce software? And doesn t fade away either Other Moral Dilemmas (for later) Whistle-blowing Trap doors Theft of Intellectual Property (IP) Worms, Viruses, etc. 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! Specification of " Intended Behavior " Formal Verification Final and" Intermediate" 1st-Order Logic" Assertions" First-Order Logic" Theorems and" Proofs" Comparison of Behavior to Intent" Specification of " Actual Behavior" Symbolic" Execution " of Path" Segments" Proof of the" Absence of" All Functional" Faults" Floyd Method of Inductive Assertions 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
15 Loop Invariants Should be able to identify loop invariant for every loop that you write Should be able to state initial and final assertions too Maybe not in formal mathematics Should be able to reason about how they support overall program logic 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 + 1 Often used when direct analytic techniques are too hard or complex Example: How many edges in C n Theorem: let C n = (V n, E n ) be a complete, unordered graph on n nodes, then E n = n * (n-1)/2 Initial Step Induction Step show the property is true for C1: graph has one node, 0 edges E1 = n(n-1)/2 = 1(0)/2 = 0 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
16 Sort Example procedure sort(values, size); declare values real array[1000], temp real, i, j, size integer; ASSERT INITIAL do for i = 1 to size-1 do for j = i+1 to size if values[j] > values[i] then temp := values[i]; values[i] := values[j]; values[j] := temp; ASSERT INNER ASSERT OUTER ASSERT FINAL end sort; A Harder 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;! End_do;! End Wensley;! Wensley s Algorithm Input P, Q, E A 0.0 B Q/2 D 1.0 Y 0.0 A0! AI! AF! Initial: Final: Assertions A 0 : {(0 P<Q) (0< E)}!A F : {((P/Q-E)<Y (P/Q))}! computed quotient! D E P-A-B 0.0 B B/2.0 D D/2.0 Y Y+(D/2.0) A A+B computed error! Intermediate:!!!A I : {(A=Q*Y) (B=Q*(D/2))!! (k 0, k integer D=2 -k )!!! ((P/Q)-D)<Y (P/Q)}! Y is within the computed error D of P/Q! Floyd s Method of inductive assertions (informal description) Pictorially intermediate assertions 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 initial assertion A i! C i! STRAIGHT-LINE CODE! A i+1! final assertion
17 Must be sure: assuming A i, then executing Code C i, necessarily A i+1 A i! C i! STRAIGHT-LINE CODE! A i+1! 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! A s... A f! 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! 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 true! A s " A F! A I " false! 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 (assertion-free) 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 Sort Example procedure sort(values, size); declare values real array[1000], temp real, i, j, size integer; ASSERT INITIAL do for i = 1 to size-1 do for j = i+1 to size if values[j] > values[i] then temp := values[i]; values[i] := values[j]; values[j] := temp; ASSERT INNER ASSERT OUTER ASSERT FINAL end sort;
18 Sort Example procedure sort(values, size); declare values real array[1000], temp real, i, j, size integer; ASSERT INITIAL do for i = 1 to size-1 do for j = i+1 to size if values[j] > values[i] then temp := values[i]; values[i] := values[j]; values[j] := temp; ASSERT INNER ASSERT OUTER ASSERT FINAL end sort; ASSERT OUTER values[i] is > values[j] for all j, where i < j < size Sort Example procedure sort(values, size); declare values real array[1000], temp real, i, j, size integer; ASSERT INITIAL do for i = 1 to size-1 do for j = i+1 to size if values[j] > values[i] then temp := values[i]; values[i] := values[j]; values[j] := temp; ASSERT INNER ASSERT OUTER ASSERT FINAL end sort; ASSERT INNER values[i] > values[k] for all i < k < j Sort Example procedure sort(values, size); declare values real array[1000], temp real, i, j, size integer; ASSERT INITIAL do for i = 1 to size-1 do for j = i+1 to size if values[j] > values[i] then temp := values[i]; values[i] := values[j]; values[j] := temp; ASSERT INNER ASSERT OUTER ASSERT FINAL end sort; ASSERT FINAL For all i, j < size values[i] > values [j]
19 Sort Example procedure sort(values, size); declare values real array[1000], temp real, i, j, size integer; ASSERT INITIAL do for i = 1 to size-1 do for j = i+1 to size if values[j] > values[i] then temp := values[i]; values[i] := values[j]; values[j] := temp; ASSERT INNER ASSERT OUTER ASSERT FINAL end sort; size > 0 and size < 1000 ASSERT INITIAL Loop Invariants A Harder Example: Wensley's Algorithm Should be able to identify loop invariant for every loop that you write Should be able to state initial and final assertions too Maybe not in formal mathematics Should be able to reason about how they support overall program logic 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;! End_do;! End Wensley;! 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 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! B B/2.0 D D/2.0 P-A-B 0.0 B B/2.0 D D/2.0 Y Y+(D/2.0) A A+B
20 What does Wensley's algorithm do? 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) B k = 2 -(k+1) * Q! Initial: Final: Assertions A 0 : {(0 P<Q) (0< E)}!A F : {((P/Q-E)<Y (P/Q))}! computed quotient! computed error! Intermediate:!!!A I : {(A=Q*Y) (B=Q*(D/2))!! (k 0, k integer D=2 -k )!!! ((P/Q)-D)<Y (P/Q)}! Y is within the computed error D of P/Q! Summary of Four Lemmas Needed I. Initial assertion, A0, to AI II. AI, false branch, to AI III. IV. AI, true branch, to AI 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 Lemmas called verification conditions A0! AI! AF! Y Y+(D/2.0) A A+B 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 B B/2.0 D D/2.0 A0! AI! AF! Y Y+(D/2.0) A A+B 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 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?...)
21 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 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 testing--> finite state verification--> verifications 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 Integration of Testing Analysis and Formal Methods Testing! --Is dynamic in nature, entailing execution of the program! --Requires skillful selection of test data to assure good! exercising of the program! --Can show program executing in usage environment! --Can support arbitrarily detailed examination of virtually! any program characteristics and behavior! --Is generally not suitable for showing absence of faults! Analysis! --Is static, operating on abstract program representations! --Supports definitive demonstration of absence of faults! --Generally only for certain selected classes of faults! Formal Methods! --Most through, rigorous, mathematical! --Apply primarily to checking functional characteristics! --Most human and cost intensive! The types of capabilities are complementary; suggests need for skillful integration!
22 DEVOLOP! CODE! CODE! STATIC! ANALYSIS FOR! CODE FLAWS! PATHS WITH FLAWS! SYMBOLIC! EXECUTION! ERRORS! ERROR FEEDBACK (FIX ERRORS)! ERRORS! FOUND! NO! ERRORS! FOUND! CODE! ERRORS! ERRORS! FULLY! INSTRUMENTED! CODE! DYNAMIC! TESTING! DEVELOP! ASSERTIONS! INSERT! TEST! PROBES! STATIC! ANALYSIS FOR! PROBE REMOVAL! SYMBOLIC! EXECUTION! CONSTRAINT! SOLUTION! CODE WITH! SOME PROBES! REMOVED! PATH! SELECTION! PATHS! THROUGH! PROBES! VERIFICATION FEEDBACK (GET MORE COMPLETE ASSERTIONS)! Testing & Analysis Process Architecture
Coding and Testing. Class Schedule rest of semester
Coding and Testing Computer Science 320 Fall 2012 Prof. Leon Osterweil Class Schedule rest of semester Wednesday, Dec. 5: Unit test demos Thursday, Dec. 6: Integrative Experience papers due: Email to ljo@cs.umass.edu
More informationCoding and Unit Testing! The Coding Phase! Coding vs. Code! Coding! Overall Coding Language Trends!
Requirements Spec. Design Coding and Unit Testing Characteristics of System to be built must match required characteristics (high level) Architecture consistent views Software Engineering Computer Science
More informationFormal Verification! Prof. Leon Osterweil! Computer Science 520/620! Spring 2012!
Formal Verification Prof. Leon Osterweil Computer Science 520/620 Spring 2012 Relations and Analysis A software product consists of A collection of (types of) artifacts Related to each other by myriad
More informationTesting! Prof. Leon Osterweil! CS 520/620! Spring 2013!
Testing Prof. Leon Osterweil CS 520/620 Spring 2013 Relations and Analysis A software product consists of A collection of (types of) artifacts Related to each other by myriad Relations The relations are
More informationFormal Verification! Prof. Leon Osterweil! Computer Science 520/620! Spring 2011!
Formal Verification! Prof. Leon Osterweil! Computer Science 520/620! Spring 2011! Relations and Analysis! A software product consists of! A collection of (types of) artifacts! Related to each other by
More informationStatic Analysis! Prof. Leon J. Osterweil! CS 520/620! Fall 2012! Characteristics of! System to be! built must! match required! characteristics!
Static Analysis! Prof. Leon J. Osterweil! CS 520/620! Fall 2012! Requirements Spec.! Design! Test Results must! match required behavior! Characteristics of! System to be! built must! match required! characteristics!
More informationAnalysis! Some Examples of Relations!
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
More informationBasic Verification Strategy
ormal Verification Basic Verification Strategy compare behavior to intent System Model of system behavior intent Verifier results Intent Usually, originates with requirements, refined through design and
More informationPart 5. Verification and Validation
Software Engineering Part 5. Verification and Validation - Verification and Validation - Software Testing Ver. 1.7 This lecture note is based on materials from Ian Sommerville 2006. Anyone can use this
More informationSoftware Testing. Software Testing
Software Testing Software Testing Error: mistake made by the programmer/ developer Fault: a incorrect piece of code/document (i.e., bug) Failure: result of a fault Goal of software testing: Cause failures
More informationChapter 1: Principles of Programming and Software Engineering
Chapter 1: Principles of Programming and Software Engineering Data Abstraction & Problem Solving with C++ Fifth Edition by Frank M. Carrano Software Engineering and Object-Oriented Design Coding without
More informationVerification and Validation. Verification and validation
Verification and Validation Verification and validation Verification and Validation (V&V) is a whole life-cycle process. V&V has two objectives: Discovery of defects, Assessment of whether or not the system
More informationReading assignment: Reviews and Inspections
Foundations for SE Analysis Reading assignment: Reviews and Inspections M. E. Fagan, "Design and code inspections to reduce error in program development, IBM Systems Journal, 38 (2&3), 1999, pp. 258-287.
More informationChapter 11, Testing. Using UML, Patterns, and Java. Object-Oriented Software Engineering
Chapter 11, Testing Using UML, Patterns, and Java Object-Oriented Software Engineering Outline Terminology Types of errors Dealing with errors Quality assurance vs Testing Component Testing! Unit testing!
More informationPage 1. Reading assignment: Reviews and Inspections. Foundations for SE Analysis. Ideally want general models. Formal models
Reading assignment: Reviews and Inspections Foundations for SE Analysis M. E. Fagan, "Design and code inspections to reduce error in program development, IBM Systems Journal, 38 (2&3), 999, pp. 258-28.
More informationTerminology. There are many different types of errors and different ways how we can deal with them.
Testing Terminology Reliability: The measure of success with which the observed behavior of a system confirms to some specification of its behavior. Failure: Any deviation of the observed behavior from
More informationIntroduction to Formal Methods
2008 Spring Software Special Development 1 Introduction to Formal Methods Part I : Formal Specification i JUNBEOM YOO jbyoo@knokuk.ac.kr Reference AS Specifier s Introduction to Formal lmethods Jeannette
More informationCOS 320. Compiling Techniques
Topic 5: Types COS 320 Compiling Techniques Princeton University Spring 2016 Lennart Beringer 1 Types: potential benefits (I) 2 For programmers: help to eliminate common programming mistakes, particularly
More informationBlack Box Testing. EEC 521: Software Engineering. Specification-Based Testing. No Source Code. Software Testing
Black Box Testing EEC 521: Software Engineering Software Testing Black-Box Testing Test-Driven Development Also known as specification-based testing Tester has access only to running code and the specification
More informationProgramming Languages Third Edition
Programming Languages Third Edition Chapter 12 Formal Semantics Objectives Become familiar with a sample small language for the purpose of semantic specification Understand operational semantics Understand
More informationMONIKA HEINER.
LESSON 1 testing, intro 1 / 25 SOFTWARE TESTING - STATE OF THE ART, METHODS, AND LIMITATIONS MONIKA HEINER monika.heiner@b-tu.de http://www.informatik.tu-cottbus.de PRELIMINARIES testing, intro 2 / 25
More informationNo Source Code. EEC 521: Software Engineering. Specification-Based Testing. Advantages
No Source Code : Software Testing Black-Box Testing Test-Driven Development No access to source code So test cases don t worry about structure Emphasis is only on ensuring that the contract is met Specification-Based
More informationLecture Notes on Contracts
Lecture Notes on Contracts 15-122: Principles of Imperative Computation Frank Pfenning Lecture 2 August 30, 2012 1 Introduction For an overview the course goals and the mechanics and schedule of the course,
More informationWhy testing and analysis. Software Testing. A framework for software testing. Outline. Software Qualities. Dependability Properties
Why testing and analysis Software Testing Adapted from FSE 98 Tutorial by Michal Young and Mauro Pezze Software is never correct no matter what developing testing technique is used All software must be
More informationTesting. ECE/CS 5780/6780: Embedded System Design. Why is testing so hard? Why do testing?
Testing ECE/CS 5780/6780: Embedded System Design Scott R. Little Lecture 24: Introduction to Software Testing and Verification What is software testing? Running a program in order to find bugs (faults,
More informationLectures 20, 21: Axiomatic Semantics
Lectures 20, 21: Axiomatic Semantics Polyvios Pratikakis Computer Science Department, University of Crete Type Systems and Static Analysis Based on slides by George Necula Pratikakis (CSD) Axiomatic Semantics
More informationVerification and Validation. Assuring that a software system meets a user s needs. Verification vs Validation. The V & V Process
Verification and Validation Assuring that a software system meets a user s needs Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 19,20 Slide 1
More informationVerification and Validation
Verification and Validation Assuring that a software system meets a user's needs Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 19 Slide 1 Objectives To introduce software verification
More informationAerospace Software Engineering
16.35 Aerospace Software Engineering Verification & Validation Prof. Kristina Lundqvist Dept. of Aero/Astro, MIT Would You...... trust a completely-automated nuclear power plant?... trust a completely-automated
More informationIan Sommerville 2006 Software Engineering, 8th edition. Chapter 22 Slide 1
Verification and Validation Slide 1 Objectives To introduce software verification and validation and to discuss the distinction between them To describe the program inspection process and its role in V
More informationDistributed Systems Programming (F21DS1) Formal Verification
Distributed Systems Programming (F21DS1) Formal Verification Andrew Ireland Department of Computer Science School of Mathematical and Computer Sciences Heriot-Watt University Edinburgh Overview Focus on
More informationLecture Notes for Chapter 2: Getting Started
Instant download and all chapters Instructor's Manual Introduction To Algorithms 2nd Edition Thomas H. Cormen, Clara Lee, Erica Lin https://testbankdata.com/download/instructors-manual-introduction-algorithms-2ndedition-thomas-h-cormen-clara-lee-erica-lin/
More informationStatic Analysis! Summary of Dynamic Testing! Some References for Testing! Prof. Leon J. Osterweil! CS 520/620! Spring 2013! DEVELOPMENT PHASES!
Requirements Spec. Design Static Analysis Prof. Leon J. Osterweil CS 50/60 Spring 0 Characteristics of System to be built must match required characteristics Test Results must match required behavior Hi
More informationObject-Oriented and Classical Software Engineering
Slide 6.1 Object-Oriented and Classical Software Engineering Seventh Edition, WCB/McGraw-Hill, 2007 Stephen R. Schach srs@vuse.vanderbilt.edu CHAPTER 6 Slide 6.2 TESTING 1 Overview Slide 6.3 Quality issues
More informationObject-Oriented and Classical Software Engineering
Slide 6.1 Object-Oriented and Classical Software Engineering Seventh Edition, WCB/McGraw-Hill, 2007 Stephen R. Schach srs@vuse.vanderbilt.edu CHAPTER 6 Slide 6.2 TESTING Overview Slide 6.3 Quality issues
More informationStatic Analysis! Prof. Leon J. Osterweil! CS 520/620! Spring 2013! Characteristics of! System to be! built must! match required! characteristics!
Static Analysis! Prof. Leon J. Osterweil! CS 50/60! Spring 01! Requirements Spec.! Design! Test Results must! match required behavior! Characteristics of! System to be! built must! match required! characteristics!
More informationTesting & Continuous Integration. Kenneth M. Anderson University of Colorado, Boulder CSCI 5828 Lecture 20 03/19/2010
esting & Continuous Integration Kenneth M. Anderson University of Colorado, Boulder CSCI 5828 Lecture 20 03/1/20 University of Colorado, 20 1 Goals 2 Review material from Chapter of Pilone & Miles esting
More informationChapter 8. Achmad Benny Mutiara
Chapter 8 SOFTWARE-TESTING STRATEGIES Achmad Benny Mutiara amutiara@staff.gunadarma.ac.id 8.1 STATIC-TESTING STRATEGIES Static testing is the systematic examination of a program structure for the purpose
More informationWhen Brunel s ship the SS Great Britain was launched into the River Thames, it made such a splash that several spectators on the opposite bank were
C. A. R. Hoare Emeritus Professor of Computing at the University of Oxford and is now a senior researcher at Microsoft Research in Cambridge, England. He received the 1980 ACM Turing Award for his fundamental
More informationSystem Correctness. EEC 421/521: Software Engineering. System Correctness. The Problem at Hand. A system is correct when it meets its requirements
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,
More informationCS 161 Computer Security
Wagner Spring 2014 CS 161 Computer Security 1/27 Reasoning About Code Often functions make certain assumptions about their arguments, and it is the caller s responsibility to make sure those assumptions
More informationSymbolic Evaluation/Execution
Symbolic Evaluation/Execution Reading Assignment *R.W. Floyd, "Assigning Meaning to Programs, Symposium on Applied Mathematics, 1967, pp. 19-32 (Appeared as volume 19 of Mathematical Aspects of Computer
More information1. true / false By a compiler we mean a program that translates to code that will run natively on some machine.
1. true / false By a compiler we mean a program that translates to code that will run natively on some machine. 2. true / false ML can be compiled. 3. true / false FORTRAN can reasonably be considered
More informationTesting: Coverage and Structural Coverage
Testing: Coverage and Structural Coverage Testing, Quality Assurance, and Maintenance Winter 2017 Prof. Arie Gurfinkel based on slides by Prof. Marsha Chechik and Prof. Lin Tan How would you test this
More informationAXIOMS OF AN IMPERATIVE LANGUAGE PARTIAL CORRECTNESS WEAK AND STRONG CONDITIONS. THE AXIOM FOR nop
AXIOMS OF AN IMPERATIVE LANGUAGE We will use the same language, with the same abstract syntax that we used for operational semantics. However, we will only be concerned with the commands, since the language
More informationChapter 3 (part 3) Describing Syntax and Semantics
Chapter 3 (part 3) Describing Syntax and Semantics Chapter 3 Topics Introduction The General Problem of Describing Syntax Formal Methods of Describing Syntax Attribute Grammars Describing the Meanings
More informationHow invariants help writing loops Author: Sander Kooijmans Document version: 1.0
How invariants help writing loops Author: Sander Kooijmans Document version: 1.0 Why this document? Did you ever feel frustrated because of a nasty bug in your code? Did you spend hours looking at the
More informationSchool of Computer & Communication Sciences École Polytechnique Fédérale de Lausanne
Principles of Dependable Systems Building Reliable Software School of Computer & Communication Sciences École Polytechnique Fédérale de Lausanne Winter 2006-2007 Outline Class Projects: mtgs next week
More informationCompositional Model Based Software Development
Compositional Model Based Software Development Prof. Dr. Bernhard Rumpe http://www.se-rwth.de/ Seite 2 Our Working Groups and Topics Automotive / Robotics Autonomous driving Functional architecture Variability
More informationG Programming Languages - Fall 2012
G22.2110-003 Programming Languages - Fall 2012 Lecture 3 Thomas Wies New York University Review Last week Names and Bindings Lifetimes and Allocation Garbage Collection Scope Outline Control Flow Sequencing
More informationCS-XXX: Graduate Programming Languages. Lecture 9 Simply Typed Lambda Calculus. Dan Grossman 2012
CS-XXX: Graduate Programming Languages Lecture 9 Simply Typed Lambda Calculus Dan Grossman 2012 Types Major new topic worthy of several lectures: Type systems Continue to use (CBV) Lambda Caluclus as our
More informationOn Meaning Preservation of a Calculus of Records
On Meaning Preservation of a Calculus of Records Emily Christiansen and Elena Machkasova Computer Science Discipline University of Minnesota, Morris Morris, MN 56267 chri1101, elenam@morris.umn.edu Abstract
More informationCIS 890: Safety Critical Systems
CIS 890: Safety Critical Systems Lecture: SPARK -- Analysis Tools Copyright 2007, John Hatcliff. The syllabus and all lectures for this course are copyrighted materials and may not be used in other course
More informationStatic program checking and verification
Chair of Software Engineering Software Engineering Prof. Dr. Bertrand Meyer March 2007 June 2007 Slides: Based on KSE06 With kind permission of Peter Müller Static program checking and verification Correctness
More informationReading Assignment. Symbolic Evaluation/Execution. Move from Dynamic Analysis to Static Analysis. Move from Dynamic Analysis to Static Analysis
Reading Assignment Symbolic Evaluation/Execution *R.W. Floyd, "Assigning Meaning to Programs, Symposium on Applied Mathematics, 1967, pp. 19-32 (Appeared as volume 19 of Mathematical Aspects of Computer
More informationThree General Principles of QA. COMP 4004 Fall Notes Adapted from Dr. A. Williams
Three General Principles of QA COMP 4004 Fall 2008 Notes Adapted from Dr. A. Williams Software Quality Assurance Lec2 1 Three General Principles of QA Know what you are doing. Know what you should be doing.
More informationCITS5501 Software Testing and Quality Assurance Formal methods
CITS5501 Software Testing and Quality Assurance Formal methods Unit coordinator: Arran Stewart May 1, 2018 1 / 49 Sources Pressman, R., Software Engineering: A Practitioner s Approach, McGraw-Hill, 2005
More informationSoftware Engineering 2 A practical course in software engineering. Ekkart Kindler
Software Engineering 2 A practical course in software engineering Quality Management Main Message Planning phase Definition phase Design phase Implem. phase Acceptance phase Mainten. phase 3 1. Overview
More informationVerification Overview Testing Theory and Principles Testing in Practice. Verification. Miaoqing Huang University of Arkansas 1 / 80
1 / 80 Verification Miaoqing Huang University of Arkansas Outline 1 Verification Overview 2 Testing Theory and Principles Theoretical Foundations of Testing Empirical Testing Principles 3 Testing in Practice
More informationSymbolic Execution and Proof of Properties
Chapter 7 Symbolic Execution and Proof of Properties Symbolic execution builds predicates that characterize the conditions under which execution paths can be taken and the effect of the execution on program
More informationVerification and Validation
Steven Zeil February 13, 2013 Contents 1 The Process 3 1 2 Non-Testing V&V 7 2.1 Code Review....... 8 2.2 Mathematically-based verification......................... 19 2.3 Static analysis tools... 23 2.4
More informationVerification and Validation
Steven Zeil February 13, 2013 Contents 1 The Process 2 2 Non-Testing V&V 3 2.1 Code Review........... 4 2.2 Mathematically-based verification.................................. 8 2.3 Static analysis tools.......
More informationIntroduction to Dynamic Analysis
Introduction to Dynamic Analysis Reading assignment Gary T. Leavens, Yoonsik Cheon, "Design by Contract with JML," draft paper, http://www.eecs.ucf.edu/~leavens/jml//jmldbc.pdf G. Kudrjavets, N. Nagappan,
More informationOutline. Introduction. 2 Proof of Correctness. 3 Final Notes. Precondition P 1 : Inputs include
Outline Computer Science 331 Correctness of Algorithms Mike Jacobson Department of Computer Science University of Calgary Lectures #2-4 1 What is a? Applications 2 Recursive Algorithms 3 Final Notes Additional
More informationAnnouncements. Testing. Announcements. Announcements
Announcements Testing HW0, HW1, and HW2 are graded Grades and feedback in Submitty Email us at csci2600@cs.lists.rpi.edu Use Submitty discussion board! HW0, HW1, and HW2, Quiz 1 and 2 Grades in Submitty
More informationLecture 11 Lecture 11 Nov 5, 2014
Formal Verification/Methods Lecture 11 Lecture 11 Nov 5, 2014 Formal Verification Formal verification relies on Descriptions of the properties or requirements Descriptions of systems to be analyzed, and
More informationTesting. Prof. Clarkson Fall Today s music: Wrecking Ball by Miley Cyrus
Testing Prof. Clarkson Fall 2017 Today s music: Wrecking Ball by Miley Cyrus Review Previously in 3110: Modules Specification (functions, modules) Today: Validation Testing Black box Glass box Randomized
More informationObject-Oriented Software Engineering Conquering Complex and Changing Systems. Chapter 9, Testing
Object-Oriented Software Engineering Conquering Complex and Changing Systems Chapter 9, Testing Preliminaries Written exam on for Bachelors of Informatik, and for other students who are not in the Informatik
More informationSoftware Architectures
Software Architectures Richard N. Taylor Information and Computer Science University of California, Irvine Irvine, California 92697-3425 taylor@ics.uci.edu http://www.ics.uci.edu/~taylor +1-949-824-6429
More informationFormal Methods. CITS5501 Software Testing and Quality Assurance
Formal Methods CITS5501 Software Testing and Quality Assurance Pressman, R. Software Engineering: A Practitioner s Approach. Chapter 28. McGraw-Hill, 2005 The Science of Programming, David Gries, 1981
More information! Use of formal notations. ! in software system descriptions. ! for a broad range of effects. ! and varying levels of use. !
What Are Formal Methods? David S. Rosenblum ICS 221 Winter 2001! Use of formal notations! first-order logic, state machines, etc.! in software system descriptions! system models, constraints, specifications,
More informationIteration. # a and b are now equal # a and b are no longer equal Multiple assignment
Iteration 6.1. Multiple assignment As you may have discovered, it is legal to make more than one assignment to the same variable. A new assignment makes an existing variable refer to a new value (and stop
More informationAlan J. Perlis - Epigrams on Programming
Programming Languages (CS302 2007S) Alan J. Perlis - Epigrams on Programming Comments on: Perlis, Alan J. (1982). Epigrams on Programming. ACM SIGPLAN Notices 17(9), September 1982, pp. 7-13. 1. One man
More informationTopics in Software Testing
Dependable Software Systems Topics in Software Testing Material drawn from [Beizer, Sommerville] Software Testing Software testing is a critical element of software quality assurance and represents the
More informationProgram Analysis. Program Analysis
Program Analysis Class #4 Program Analysis Dynamic Analysis 1 Static VS Dynamic Analysis Static analysis operates on a model of the SW (without executing it) If successful, produces definitive information
More informationVerification and Validation. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 22 Slide 1
Verification and Validation 1 Objectives To introduce software verification and validation and to discuss the distinction between them To describe the program inspection process and its role in V & V To
More informationNumerical Methods in Scientific Computation
Numerical Methods in Scientific Computation Programming and Software Introduction to error analysis 1 Packages vs. Programming Packages MATLAB Excel Mathematica Maple Packages do the work for you Most
More informationHoare triples. Floyd-Hoare Logic, Separation Logic
Hoare triples Floyd-Hoare Logic, Separation Logic 1. Floyd-Hoare Logic 1969 Reasoning about control Hoare triples {A} p {B} a Hoare triple partial correctness: if the initial state satisfies assertion
More informationObjectives. Chapter 19. Verification vs. validation. Topics covered. Static and dynamic verification. The V&V process
Objectives Chapter 19 Verification and Validation Assuring that a software system meets a user s need are to introduce software verification and validation (V&V) and to discuss the distinction between
More informationChapter 3. Semantics. Topics. Introduction. Introduction. Introduction. Introduction
Topics Chapter 3 Semantics Introduction Static Semantics Attribute Grammars Dynamic Semantics Operational Semantics Axiomatic Semantics Denotational Semantics 2 Introduction Introduction Language implementors
More informationSEQUENCES, MATHEMATICAL INDUCTION, AND RECURSION
CHAPTER 5 SEQUENCES, MATHEMATICAL INDUCTION, AND RECURSION Alessandro Artale UniBZ - http://www.inf.unibz.it/ artale/ SECTION 5.5 Application: Correctness of Algorithms Copyright Cengage Learning. All
More informationSteps for project success. git status. Milestones. Deliverables. Homework 1 submitted Homework 2 will be posted October 26.
git status Steps for project success Homework 1 submitted Homework 2 will be posted October 26 due November 16, 9AM Projects underway project status check-in meetings November 9 System-building project
More informationWarm-Up Problem. Let be a set of well-formed Predicate logic formulas. Let be well-formed Predicate logic formulas. Prove or disprove the following.
Warm-Up Problem Let be a set of well-formed Predicate logic formulas Let be well-formed Predicate logic formulas Prove or disprove the following If then 1/35 Program Verification Carmen Bruni Lecture 18
More informationPrinciples of Software Construction: Objects, Design, and Concurrency (Part 2: Designing (Sub )Systems)
Principles of Software Construction: Objects, Design, and Concurrency (Part 2: Designing (Sub )Systems) More Analysis for Functional Correctness Jonathan Aldrich Charlie Garrod School of Computer Science
More informationOBJECT ORIENTED SYSTEM DEVELOPMENT Software Development Dynamic System Development Information system solution Steps in System Development Analysis
UNIT I INTRODUCTION OBJECT ORIENTED SYSTEM DEVELOPMENT Software Development Dynamic System Development Information system solution Steps in System Development Analysis Design Implementation Testing Maintenance
More informationTESTING. Overview Slide 6.2. Testing (contd) Slide 6.4. Testing Slide 6.3. Quality issues Non-execution-based testing
Slide 6.1 Overview Slide 6.2 Quality issues Non-execution-based testing TESTING Execution-based testing What should be tested? Testing versus correctness proofs Who should perform execution-based testing?
More informationChapter 1. Introduction
1 Chapter 1 Introduction An exciting development of the 21st century is that the 20th-century vision of mechanized program verification is finally becoming practical, thanks to 30 years of advances in
More informationSpark verification features
Spark verification features Paul Jackson School of Informatics University of Edinburgh Formal Verification Spring 2018 Adding specification information to programs Verification concerns checking whether
More informationGoals: Define the syntax of a simple imperative language Define a semantics using natural deduction 1
Natural Semantics Goals: Define the syntax of a simple imperative language Define a semantics using natural deduction 1 1 Natural deduction is an instance of first-order logic; that is, it is the formal
More informationΗΜΥ 317 Τεχνολογία Υπολογισμού
ΗΜΥ 317 Τεχνολογία Υπολογισμού Εαρινό Εξάμηνο 2008 ΙΑΛΕΞΕΙΣ 18-19: Έλεγχος και Πιστοποίηση Λειτουργίας ΧΑΡΗΣ ΘΕΟΧΑΡΙ ΗΣ Λέκτορας ΗΜΜΥ (ttheocharides@ucy.ac.cy) [Προσαρμογή από Ian Sommerville, Software
More informationComputer Science 520/620 Spring 2013 Prof. L. Osterweil" Use Cases" Software Models and Representations" Part 4" More, and Multiple Models"
Computer Science 520/620 Spring 2013 Prof. L. Osterweil Software Models and Representations Part 4 More, and Multiple Models Use Cases Specify actors and how they interact with various component parts
More informationComputer Science 520/620 Spring 2013 Prof. L. Osterweil" Software Models and Representations" Part 4" More, and Multiple Models" Use Cases"
Computer Science 520/620 Spring 2013 Prof. L. Osterweil Software Models and Representations Part 4 More, and Multiple Models Use Cases Specify actors and how they interact with various component parts
More information(See related materials in textbook.) CSE 435: Software Engineering (slides adapted from Ghezzi et al & Stirewalt
Verification (See related materials in textbook.) Outline What are the goals of verification? What are the main approaches to verification? What kind of assurance do we get through testing? How can testing
More informationA conceptual framework for building good DSLs. Markus Voelter independent/itemis
DSL Design A conceptual framework for building good DSLs Markus Voelter independent/itemis voelter@acm.org www.voelter.de voelterblog.blogspot.de @markusvoelter +Markus Voelter based on material from a
More informationSoftware Security: Vulnerability Analysis
Computer Security Course. Software Security: Vulnerability Analysis Program Verification Program Verification How to prove a program free of buffer overflows? Precondition Postcondition Loop invariants
More informationRegression testing. Whenever you find a bug. Why is this a good idea?
Regression testing Whenever you find a bug Reproduce it (before you fix it!) Store input that elicited that bug Store correct output Put into test suite Then, fix it and verify the fix Why is this a good
More informationProgramming Languages Third Edition. Chapter 9 Control I Expressions and Statements
Programming Languages Third Edition Chapter 9 Control I Expressions and Statements Objectives Understand expressions Understand conditional statements and guards Understand loops and variation on WHILE
More informationCSCC24 Functional Programming Scheme Part 2
CSCC24 Functional Programming Scheme Part 2 Carolyn MacLeod 1 winter 2012 1 Based on slides from Anya Tafliovich, and with many thanks to Gerald Penn and Prabhakar Ragde. 1 The Spirit of Lisp-like Languages
More informationLecture 15 Software Testing
Lecture 15 Software Testing Includes slides from the companion website for Sommerville, Software Engineering, 10/e. Pearson Higher Education, 2016. All rights reserved. Used with permission. Topics covered
More informationCS558 Programming Languages
CS558 Programming Languages Winter 2017 Lecture 7b Andrew Tolmach Portland State University 1994-2017 Values and Types We divide the universe of values according to types A type is a set of values and
More information