Software Quality Assurance
|
|
- Lauren McKenzie
- 5 years ago
- Views:
Transcription
1 Software Quality Assurance Every week we see new examples of: computer systems error/failure Here are some examples, taken from different industries
2 Airport chaos after computer crash By Vanessa Allen, PA News 17 May 2002 Air passengers faced travel chaos today after a software problem at Britain's air traffic system triggered mass delays and cancellations. British Airways cancelled 14 flights from Gatwick and Heathrow and all airports in Britain were likely to suffer delays. It was the third air traffic problem to have hit the part privatised service in the past two months.
3 These failures are spectacular since injury/loss of life and/or major financial loss are involved. Systems whose failure involves serious risk, including: loss of life, injury major financial loss are called safety critical systems.
4 Safety critical systems can be found in such industries as: Transport - automobile, rail, avionics, space Medical - monitoring, treatment Manufacturing- power especially nuclear, chemical, pharmaceutical Financial - banking, insurance, stock exchange
5 Of course, many non-safety critical systems e.g. Windows, Word etc can be expected to fail every few hours! In this chapter we consider technical aspects of software quality assurance. There are also managerial aspects to this issue that we have considered previously.
6 6.1. Debugging, Testing and Verification How can we engineer quality into software? Modern software engineering has three techniques: Debugging Testing Verification
7 These terms are often used with different meanings by different authors! Debugging: A process (usually interactive) of locating and identifying software errors using a debugging tool. Such a tool can automatically detect/identify untrapped exceptions, and locate their source.
8 e.g. array-out-of-bounds error null pointer division by zero stack/heap overflow runtime type error (dynamic type systems) A debugger is often supplied as part of a language development environment.
9 Observations: 1. The concept of a run-time exception can be precisely defined, so exception trapping can be automated. 2. The process of debugging is never obviously finished. 3. Not every error causes a run-time exception, e.g. infinite loops. Because of (3) we need other techniques.
10 Black-Box Testing: An interactive or batch process of executing a program using a specific set of inputs (the test set) and comparing results with predicted results usually based on some user requirement (the oracle step). Test failures are recorded and must be traced back to code errors.
11 Observations: 1. (Mostly) no finite number of tests establishes that a program is correct for all inputs. 2. The number of inputs we can test is very small as a percentage of the total number of inputs e.g. 32 bit integers, 100 int variables = possible inputs, 2 20 testable?
12 3. User requirements are often unclear about what the software should do. Makes it difficult to predict output/detect an error. 4. It can be difficult to trace an error to its source: no one-to-one relationship between error and lines of code. 5. Increasing use of GUIs/networks etc leads to unrepeatable errors!
13 Of these, problems (1) and (3) are the most problematic. Regarding (3), we can ask : Can all user requirements be made precise mathematically? (at least in theory)
14 Even if the answer is yes, testing still faces an unsolvable problem with issue (1). (1) Motivates a more powerful approach to software quality assurance, known variously as formal methods, program verification or simply verification.
15 Program Verification. A process that involves mathematically proving that a program correctly implements a set of user requirements (including termination), for all possible inputs (even if there are infinitely many).
16 For verification to work we need: 1. A mathematical model (a semantics) of the program to be checked 2. A mathematical model of the user requirements involved. 3. A mathematical procedure or technique to compare 1 with 2. Try to prove: program = requirements
17 6.2. Modeling Requirements with Logic Mathematics gives us a language to talk about different mathematical structures, e.g. integers, sets, rational numbers, real numbers, Booleans, Strings, etc. First-order predicate logic.
18 First-Order Logic Summary 1. Basic Syntactic Components (aka Data type) Variables: x, y, z, x, y, z, Constants: -2, -1, 0, 1, 2, Operations: +, -, *, /, mod, Relations: =,, is a data type for integer arithmetic
19 There are many non-numeric data types, e.g. Strings Variables: x, y, z, x, y, z, Constants: ε, a z, A Z, punctuation Operations: concat, head, tail, Relations: =, prefix, suffix, contains, We can obviously also combine data types.
20 Also structured or generic data types, e.g. Stack (of integers) Variables: x, y, z, x, y, z, (int) Variables: X, Y, Z, X, Y, Z, (stack) Constants: -2, -1, 0, 1, 2, (int) Constants: empty (stack) Operations: +, -, *, /, mod, (int) Operations: push, pop, top, (stack) Relations: =, (int) Relations: = (stack)
21 Remark In O-O design and programming many classes are used to introduce new data types.
22 2. Expressions Denote values in the data type when variables have been assigned values. e.g: (( x + y ) * ( -z) ) + 3 (integer) concat( a, tail( concat( b, x ) ) (string) ( false & ( true y ) ) (Boolean) Expressions are defined inductively, starting from components of a data type. Also occur as r.h.s of assignment statements.
23 3. Atomic Formulas Denote truth values (true or false) when variables have been assigned values. e.g.: (2 + y ) ( 3 * z ) (sometimes true) head( concat( a, x ) ) = a (always true) (true x) = false (always false) Atomic formulas always combine n expressions with a single n-ary relation symbol from the data type.
24 4. Formulas Denote truth values (true or false) when free variables have been assigned values. e.g.: ( 1 = 0 ) ( 1 0 ) (and) ( 1 = 0 ) ( 1 0 ) (or) (1 = 0 ) (not) x ( x = 0 ) (there exists quantifier) x( x 0 ) (for all quantifer) Formulas are defined inductively, starting from atomic formulas.
25 6.3. Programming Language Syntax & Semantics The question of what a program is allowed to look like (structurally) is called its syntax. The question of what a program actually does is called its semantics. Usually we describe its syntax formally using BNF (Backus Nauer Format) and semantics in words with reference to the program structure.
26 But to make a proof about the program, words alone are not precise enough. In this section we look at the formal syntax and semantics of a simple C -like imperative programming language While Programs
27 Syntax of While Programs While programs are built up from assignment statements, of the form <var> = <exp> Using sequencing (;), if_then_else, and the while loop (Pascal style).
28 We can make a formal BNF definition by: <WP> ::= <Ass> <WP> ; <WP> if <Bool_exp> then {<WP>} else {<WP>} while <Bool_exp> do { <WP> }
29 A typical small while program (notice semicolon (;) is a separator) x := m; y := n; while ( ~(y = 0) ) do { x := x + 1; y := y 1 }
30 State Transition Semantics of While Programs We can explain the semantics of a while program P in terms of state transition semantics what is the effect of successfully running P on the computers memory (state)?
31 In this approach we compare: the initial state of the computer (before running p) with the final state (after running p) assuming such a final state exists!
32 The initial state is called a precondition. The final state is called a postcondition. Pre and postconditions are first-order predicate logic formulas over the program variables (plus maybe auxiliary variables).
33 Hoare Triples A triple {<f.o. formula>} <WP> {<f.o formula>} is called a Hoare triple (after C.A.R. Hoare, inventor of monitors, Hoare s logic, quicksort, etc, etc )
34 {<f.o. formula>} <WP> {<f.o formula>} precondition postcondition while program
35 There are two possible semantics to a Hoare triple {p} S {q} 1. Partial correctness interpretation 2. Total correctness interpretation
36 Partial Correctness Under the partial correctness interpretation means that: {p} S {q} if p is a true statement about the variables of S initially, and S terminates then q is a true statement about the variables of S afterwards.
37 Total Correctness Under the total correctness interpretation means that: {p} S {q} if p is a true statement about the variables of S initially, then S terminates and q is a true statement about the variables of S afterwards.
38 Which One? Termination is obviously an important safety aspect of software (think nuclear power station!). However, the analysis of termination uses variants, while the analysis of functional correctness uses invariants.
39 The two approaches are quite different, and best carried out separately. Technically, we can have a complete logic for partial correctness (c.f. Gödel s Completeness Theorem allows all true statements to be proved). We cannot have a complete logic for total correctness
40 Examples Consider the world s simplest program: { x = 7 } x:= x+1 { x = 8 } (1) is a true statement, both under the partial and total correctness interpretations since x:= x+1 has no loops.
41 There is nothing special about the input value 7: { x = y } x:=x+1 { x = y+1 } (2) is a more general true statement, both under the partial and total correctness interpretations. Notice the auxiliary variable y. This is the most general statement we can imagine!
42 Exercise: Try to find some true Hoare triples which are more general than (1) but less general than (2). How many are there? Let s specify a program that does addition.
43 { n 0 } // precondition x := m; y := n; while ( ~(y = 0) ) do { x := x + 1; y := y 1 } { x = m + n } //postcondition
44 This Hoare triple is true under both partial and total correctness interpretations. Notice how the precondition filters out all cases leading to an infinite loop. Notice how we copy m and n into x and y so we can refer to them unchanged in the postcondition.
45 { true } // precondition x := m; y := n; while ( ~(y = 0) ) do { x := x + 1; y := y 1 } { x = m + n } //postcondition
46 Now we have weakened (generalised) the precondition, true places no constraints on the input data at all! Since true is satisfied by all input values of n, including negative values, the triple is not true under total correctness interpretation. It is still true under partial correctness.
47 { x > 0 & y > 0 } GCD { divides( res, x) & divides( res, y ) & ~( h ( h > res & divides( h, x) & divides( h, y) ) } Where: def divides( X, Y) Z ( X * Z = Y )
48 is a specification for an algorithm for computing the greatest common divisor (gcd) of x and y, returning its result in res. Exercise: Write out Euclid s algorithm for gcd as a while program. We can add arrays of integers and Booleans. We just sketch the approach with an example of a simple linear search on an array.
49 {true} out := max; count := 0; while ( count < max ) do { if ( my_array[count] = in ) then { out := count } else { skip }; count := count + 1 } } { out = max ~ x ( my_array[x] = in ) & out < max my_array[out] = in }
50 We can basically just add array expressions as expressions in our logic. We can think of them as functions over a finite domain. We can, (but won t), formalise this.
51 6.4. Hoare s Logic of While Programs In this section we introduce Hoare s logic of while programs (usually just called Hoare s Logic). This should be a logic for reasoning about programs. But what actually is a logic?
52 First-Order Predicate Calculus (Revisited) First-order logic consists of a language, and a set of rules (a calculus), for deriving new facts (theorems) from existing facts (axioms). This approach is often called the axiomatic method.
53 Rules: φ, φ ϕ (Modus Ponens) ϕ φ ϕ φ φ φ φ (Expansion) (Contraction)
54 (ϕ φ) δ (Associativity) ϕ ( φ δ ) _φ ϕ_ ( -Introduction) x φ ϕ where x is not free in ϕ
55 A formal proof P using first-order predicate calculus, from a set T of axioms, is a sequence of formulas P φ 1, φ 2,, φ n where for each i = 1 n, either: (1) φ i is in T, or (2) φ i follows from φ j, φ k for j, k < i, by one of the rules of the predicate calculus We say P is a proof of φ n.
56 Hoare s Proof Rules There is one axiom schema (i.e. an infinite set of axioms for each x, φ and t.) { φ x [t] } x := t { φ } (Assignment Schema) where φ x [t] means φ with variable x replaced by term t everywhere x is free.
57 There are 4 proof rules, one for each programming construct and one as glue. (Composition) { φ } S 1 {ϕ }, {ϕ } S 2 {δ } { φ } S 1 ;S 2 { δ }
58 (Composition) { φ & b } S 1 {ϕ }, {φ & ~b } S 2 {ϕ } { φ } if b then{s 1 }else{ S 2 } {ϕ } (While Rule) { φ & b } S {φ } { φ } while b do{s} {φ & ~b }
59 We need a 4 th rule to act as logical glue to the rest of predicate calculus, to reason about the data types. (Recall Section 6.2.) (Consequence) φ 0 φ, { φ } S {ϕ }, ϕ ϕ 0 { φ 0 } S { ϕ 0 }
60 A formal proof P using Hoare s logic, from a set T of data type axioms (first-order formulas), is a sequence of first-order formulas and Hoare triples P φ 1, φ 2,, φ n (we say P is a proof of φ n ) where for each i = 1 n, either:
61 (1) φ i is a Hoare triple {p i } S i {q i } which is either an assignment axiom, or follows from previous Hoare triples and/or firstorder formulas φ j, φ k, φ l for j, k, l < i, by one of the rules of Hoare s logic (2) φ i is a first-order formula and follows from φ j, φ k for j, k < i, by one of the rules of the predicate calculus
62 6.5. Floyd s Method Hoare s logic is cumbersome and difficult to use correctly. It s really only useful if implemented on computer using some AI program to reason. We need a practical method for analysing correctness.. on the back of an envelope!
63 Floyd s method is also known as the method of invariant assertions. It uses a graphical model of programs as flowcharts, and usually gives a compact visual proof, at least for small programs. It s easier to use by hand, but harder to automate.
64 Flowcharts A flowchart is a graphical representation of a single procedure or function in an imperative (C or Pascal like) language. There are 4 building blocks for flowcharts. These are linked together by their arrows to construct a flowchart.
65 1. Assignment Blocks A box containing a single variable assignment. We will sometimes allow sequences of assignments separated by semicolon to save space. v := exp
66 2. Decision (Choice) Diamonds A diamond shape containing a single Boolean expression. no cond yes
67 3. Start Symbol A round cornered box marking the unique entry point of the flowchart. Start
68 4. Halt Symbol A round cornered box marking a (not necessarily unique) exit point from the flowchart. Halt
69 Start x:= m y:= n no y >0 yes Halt x:= x+1 y:= y-1
70 Above, we have a simple flowchart to add two positive integers m and n. It is a straightforward exercise to translate any while program into a flowchart. e.g. the above flowchart would be a translation of
71 x := m; y := n; while ( y > 0 ) do { x := x + 1; y := y 1 }
72 Translating flowcharts into while programs is more difficult because of the unbounded branching structure of flowcharts effectively a hidden goto construct. The famous Böhm Jacopini Theorem states that this can be done. This is the theoretical foundation for structured programming.
73 Labeling with Invariant Assertions Floyd s method consists of labeling the entry point of every graphic symbol: box, diamond halt with a first order logic formula. [N.B. A start symbol has no entry point.]
74 Definition. A labeling of a flowchart is valid if for every execution of the flowchart (on any input data), if the label formula after Start is true (the precondition) then every label formula is true at the instant that execution passes through it. In particular the label entering Halt is true as we pass through it (the postcondition).
75 Since valid labels are always true when we pass through them (but perhaps not at other times) we call such logical assertions invariant assertions Here is a valid labeling of the previous flowchart.
76 m 0 & n 0 Start x 0 & n 0 x = m+(n-y) & y 0 x = m+n no x:= m y:= n y >0 yes x = m+(n-y) & y > 0 Halt x = m+(n-(y-1)) & y > 0 x:= x+1 y:= y-1
77 The formula after the Start symbol represents the precondition for the algorithm. In this case m 0 & n 0 (a sufficient condition for the algorithm to work)
78 Each formula before a Halt symbol (there may be several) represents a (local) postcondition for the algorithm. We should take the disjunction (or) of all such postconditions, as the global postcondition. But if all such formulas are the same we can take any one of them.
79 A formula before the entry point of a loop (which must be a branching instruction) is called a loop invariant, in this case x = m+(n-y) & y 0 Notice again in this algorithm we take copies of m an n with x and y, so we can compare the final values with the initial values.
80 We can apply Floyd s method to proving a partial correctness statement {p}s{q} by: (1) Translating the program S into a flowchart (2) Labeling the Start symbol with p and each Halt symbol with q. (3) Finding a valid labeling of all other flowchart points so that the total labeling is valid.
81 (1) and (2) are easy. The hard work is (3). Question: How can we find a valid labeling of all the other points? Answers: 1. Drag the precondition forwards with logical rules 2. Drag the postcondition backwards with logical rules 3. Make inspired guesses at loops!
82 What logical rules can we use? Recall the axiom schemas and rules of Hoare s logic. We will define some related rules for flowcharts. First notice that we can carry out ordinary first-order logic on any label.
83 This means we can: 1. Replace any sub-formula by a logically equivalent formula. 2. Weaken any formula, i.e. if p q and we have p we can replace it with q. 3. Add any tautology as a conjunction, e.g. if we have p we can replace it by say p & x = x.
84 1. Branching Rule (Forwards) P hypothesis P & ~cond no cond yes P & cond conclusions
85 2. Assignment Rule (Forwards) P hypothesis x := exp P [exp/x] conclusion
86 Conditions on Forwards Assignment Rule: (1). Every occurrence of x in an occurrence of exp must be free in P. Thus x doesn t get bound by a quantifier in P[exp/x] after the substitution [exp/ x]. Otherwise we must rename bound instances of x. (2) If x does not occur in exp, then not every occurrence of exp must be replaced by x in the conclusion. (Otherwise they must be.)
87 (3). No function occurring in exp has side effects which affect the value of exp. This can be achieved if a function f returns values through its return parameter only. Otherwise we must manually check the side effects of f. An operation like x + 1 will satisfy this condition, while operations like x++ or ++x will not.
88 Condition (1) prevents e.g: x:int ( x * x 0 ) x := x * x x:int ( x 0 ) The hypothesis is obviously true, while the conclusion is obviously false.
89 If we rename x in the hypothesis, (say to y) then it is clear that it isn t referring specifically to the program variable x. y:int ( y * y 0 ) x := x * x y:int ( y * y 0 )
90 Condition (2) makes the assignment rule flexible and useful. E.g. to derive the obvious labeling true x := m x = m
91 we can reason Add a tautology true & m = m x := m true & x = m Here there is only one substitution of m. This is clearly necessary to get the result.
92 We obtain the result by weakening the hypothesis and conclusion again (in this case deleting a conjunct) true x := m x = m
93 3. Assignment Rule (Backwards) P[x/exp] conclusion x := exp P hypothesis This rule has no conditions, so it may be easier to use!
94 The difficult part of Floyd s method is always finding the right loop invariants. It can be proven mathematically that we must guess these, i.e. there is no universal rule that we can use to calculate the result. Let s analyse the validity of the labeled flowchart we saw above.
95 It s convenient to split the diagram into an outer loop free part and an inner loop body. (A) m 0 & n 0 Start x:= m (B) x 0 & n 0 (C) x = m+(n-y) & y 0 y:= n (D) x = m+n no y >0 yes Halt
96 Formula (A) is our precondition m 0 & n 0 So it doesn t logically follow from anything. Formula (B) x 0 & n 0 follows from (A) using the forward assignment rule, when we replace m in (A) by x.
97 Formula (C) x = m+(n-y) & y 0 is a good guess. It doesn t follow by either rule, but is clearly true the first time around. Formula (D) x = m+n follows from x = m + ( n y ) & y = 0 which follows from (C) by the branching rule.
98 Now let s check the validity of formulas labeling the loop body. (E) x = m+(n-y) & y > 0 (F) x = m+(n-(y-1)) & y > 0 x:= x+1 y:= y-1 (C) (G) x = m+(n-y) & y 0
99 Formula (E) x = m+(n-y) & y > 0 follows from (C) and the branching rule with the condition y > 0. From (E) we can conclude x + 1 = m + ( ( n-y ) + 1 ) & y > 0 hence x + 1 = m + ( n - (y - 1 ) ) & y > 0
100 From this formula, using the forwards assignment rule we obtain formula (F) x = m+(n-(y-1)) & y > 0 From (F) we can deduce x = m+(n-(y-1)) & y-1 0 From this formula using the assignment rule we obtain formula (G) (the same as (C) ) x = m+(n-y) & y 0
101 Thus we have established that: If we enter the loop body with the loop invariant (C) true, then we exit it with (C) being true. So (C) really is a loop invariant.
102 Notice that (C) is allowed to become (temporarily) false inside the loop body. E.g. inspecting (F) we see that (C) is clearly false at the same point. However, the invariant (C) must be restored by the time we leave the loop body.
103 Compare this loop body analysis using Floyd s method with Hoare s proof rule for while loops (While Rule) { φ & b } S {φ } { φ } while b do{s} {φ & ~b }
104 The analyses are identical General Strategy: Pull out the loop body S and prove its invariant. Then put it back in context. Notice also how the formula ~b in Hoare s Rule reappears in the Branching Rule for Floyd s method.
105 Finally remember that Floyd s method is for proving partial correctness. It does not prove that we will reach a Halt symbol, but that if we reach a halt symbol then the postcondition will be true. The Hoare triples derivable from Floyd s method are the same as those using Hoare s. So Floyd s method is relatively complete too.
106 6.6. Verifying Functional Programs A functional program works by transforming its input values into some output values without any intermediate state. We call this stateless or side effect free programming.
107 We also say that functional program fragments are referentially transparent. They have the same meaning (reference) regardless of their context. This makes functional programs exceptionally easy to analyze mathematically.
108 We can make a simple model of functional programming to illustrate the proof method of verification by induction. First, we extend while programs (which are state based) to allow function routines.
109 <FWP> ::= function <identifier> ( <var_decl>* ) : <return_type> { <WP> } function header function body
110 We also extend the syntax of expressions so that function identifiers can appear inside Expressions, e.g. x := my_function( y1,, yn ) Such function routines are not yet stateless since we have allowed semicolon (;) and while loops inside.
111 Definition. A function routine f FWP is purely functional or stateless if its body contains only assignment statements, and if_then_else constructs Let s see some examples
112 function plus ( x, y : int ) : int { if ( y = 0 ) then { plus := x } else { plus := 1 + plus ( x, y 1 ) } } Notice we also use a function name as a return variable name of return type.
113 function times ( x, y : int ) : int { if ( y = 0 ) then { times := 0 } else { times := plus ( x, times( x, y 1 ) ) } }
114 Notice one function routine can call another. The calling routine is then stateless if it has no while loops or assignments and the called routine is stateless too. The advantage of stateless function routines is the ease with which they can be analysed.
115 Motivation. In an imperative program there may be an unbounded number of states. Using Floyd s method we must discover an invariant for each possible state. In a stateless function routine there are just two states: initial and final.
116 We only need to find a relationship between these two states. Since recursion and induction go hand in hand the key to analysis is induction. We assume a basic familiarity with proof by induction and illustrate the verification method by examples.
117 Example 1. Claim For all x 0 and all y 0, plus( x, y ) = x + y. Proof. By induction on y. Basis. Suppose y = 0. Then by definition of plus: plus ( x, y ) = plus( x, 0 ) = x = x + 0 = x + y
118 Induction Step. Suppose y > 0. By definition of plus, plus( x, y ) = 1 + plus( x, y-1 ) = 1 + ( x + ( y 1 ) ) by the induction hypothesis since y-1 < y (**) = x + y by laws of arithmetic.
119 Claim For all x 0 and all y 0 times( x, y ) = x*y Proof. By induction on y. Basis. Suppose y = 0. By definition of times times( x, y ) = times( x, 0 ) = 0 = x * 0 = x * y.
120 Induction Step. Suppose y > 0. By definition of times: times( x, y ) = plus( x, times( x, y-1 ) ) = plus( x, x * ( y-1) ) by the induction hypothesis, since y-1 < y (**) = x + x*(y-1) By our result above for plus, and since x 0 and y >0, so that x*(y-1) 0. (***) = x * y
121 Notes: 1. The variable for induction is usually the recursion variable of the program, i.e. the variable which is modified (often decremented) in recursive calls. 2. (**) To use the induction hypothesis we must ensure that the induction variable strictly decreases.
122 3. (***) To use a result about a purely functional or stateless routine we must prove that we can satisfy its preconditions. Let s see a more complex example involving tail recursion.
123 function power ( q, b, e : int ) : int { if ( e = 0 ) then { power := q } else { if even(e) then{ power = power(q, b*b, e/2)} else{ power = power(q*b, b, e-1)} } }
124 Claim For all e 0 power(q, b, e) = q*b e and hence power(1, b, e) = b e. Proof. By induction on e. Basis. Suppose e = 0. Then by definition of power, power( q, b, e) = q = q * b 0 = q * b e
125 Induction Step Suppose e > 0. We have two sub-cases. Sub-case 1. Suppose e is even. Then by definition of power, power( q, b, e ) = power( q, b*b, e/2 ) = q * (b 2 ) e/2 by the induction hypothesis, since e/2 < e because e > 0, = q * b 2*e/2 = q * b e
126 Sub-case 2. Suppose e is not even. Then by definition of power, power( q, b, e ) = power( q*b, b, e-1 ) = q * b * b e-1 by the induction hypothesis since e-1 < e, = q * b e. Notice how sub-cases 1 and 2 reflect the branching structure of the program.
127 For non-numeric data types such as strings, we need to find a natural number function of data elements such as string length, to perform induction over. Consider the following algorithm.
128 function equals( x,y:string ) :bool { if x = empty then { if y = empty then { equals := true } else { equals := false } } else { equals := ( head(x)= head(y)) & equals ( tail(x), tail(y) ) }
129 Claim For all x : string and for all y : string, equals( x, y ) = true x = y Proof. By induction on the length of x. Basis. Suppose x = 0, i.e. x is empty. We have two sub-cases.
130 Subcase 1. Suppose y is empty. Then by definition of equals, equals( x, y ) = equals( empty, empty ) = true but x = y so equals( x, y ) = true x = y
131 Subcase 2. Suppose y is not empty. Then by definition of equals, equals( x, y ) = equals( empty, y ) = false and x y so equals( x, y ) = true x = y.
132 Induction Step. Suppose x > 0. Then x empty. By definition of equals, equals( x, y ) = ( head(x) = head(y) ) & equals ( tail(x), tail(y) ) = ( head(x) = head(y) ) & tail(x) = tail(y)
133 by the induction hypothesis, since tail(x) < x because x empty = ( x = y ). So equals( x, y ) = true x = y. Choosing the best variable for induction over can be critical to simplifying a proof. Consider the following algorithm.
134 function plus (x, y : int ) : int { if ( x = 0 ) then { plus := y } else { if ( y = 0 ) then{ plus := x } else{ plus := 1 + plus( x, y-1) } } }
135 Claim. For all x 0 and for all y 0, plus( x, y ) = x + y. At first sight it seems we should prove this result by induction on x, with basis case corresponding to the line of code if ( x = 0 ) then { plus := y }
136 But notice that in the recursive call plus := 1 + plus( x, y-1) x doesn t decrease! So we can t use the induction hypothesis about x. Instead we would need a subinduction result for y. Things are much easier if we prove by induction on y from the beginning.
137 Proof. By induction on y. Basis. Suppose y = 0. Sub-case 1. Suppose x = 0. By definition of plus, plus( x, y ) = plus( 0, y ) = y = 0 = x + y. Sub-case 2. Suppose x 0. Then by definition of plus plus( x, y ) = plus( x, 0 ) = x = x + y.
138 Induction Step. Suppose y > 0. Subcase 1. Suppose x = 0. Then by definition of plus, plus( x, y ) = plus( 0, y) = y = x + y.
139 Sub-case 2. Suppose x 0. Then by definition of plus, plus( x, y ) = 1 + plus( x, y-1 ) = 1 + ( x + (y-1) ) by the induction hypothesis, since y-1 < y = x + y. Conclusion. Functional programming is the study of recursion and induction.
Lecture 5 - Axiomatic semantics
Program Verification March 2014 Lecture 5 - Axiomatic semantics Lecturer: Noam Rinetzky Scribes by: Nir Hemed 1.1 Axiomatic semantics The development of the theory is contributed to Robert Floyd, C.A.R
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 informationHoare Logic. COMP2600 Formal Methods for Software Engineering. Rajeev Goré
Hoare Logic COMP2600 Formal Methods for Software Engineering Rajeev Goré Australian National University Semester 2, 2016 (Slides courtesy of Ranald Clouston) COMP 2600 Hoare Logic 1 Australian Capital
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 information6. Hoare Logic and Weakest Preconditions
6. Hoare Logic and Weakest Preconditions Program Verification ETH Zurich, Spring Semester 07 Alexander J. Summers 30 Program Correctness There are many notions of correctness properties for a given program
More informationHarvard School of Engineering and Applied Sciences CS 152: Programming Languages
Harvard School of Engineering and Applied Sciences CS 152: Programming Languages Lecture 19 Tuesday, April 3, 2018 1 Introduction to axiomatic semantics The idea in axiomatic semantics is to give specifications
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 informationIntroduction to Axiomatic Semantics
Introduction to Axiomatic Semantics Meeting 10, CSCI 5535, Spring 2009 Announcements Homework 3 due tonight Homework 2 is graded 13 (mean), 14 (median), out of 21 total, but Graduate class: final project
More informationHoare Logic: Proving Programs Correct
Hoare Logic: Proving Programs Correct 17-654/17-765 Analysis of Software Artifacts Jonathan Aldrich Reading: C.A.R. Hoare, An Axiomatic Basis for Computer Programming Some presentation ideas from a lecture
More informationThe Rule of Constancy(Derived Frame Rule)
The Rule of Constancy(Derived Frame Rule) The following derived rule is used on the next slide The rule of constancy {P } C {Q} {P R} C {Q R} where no variable assigned to in C occurs in R Outline of derivation
More informationAn Annotated Language
Hoare Logic An Annotated Language State and Semantics Expressions are interpreted as functions from states to the corresponding domain of interpretation Operators have the obvious interpretation Free of
More informationLecture 1 Contracts : Principles of Imperative Computation (Fall 2018) Frank Pfenning
Lecture 1 Contracts 15-122: Principles of Imperative Computation (Fall 2018) Frank Pfenning In these notes we review contracts, which we use to collectively denote function contracts, loop invariants,
More informationChapter 3. Describing Syntax and Semantics ISBN
Chapter 3 Describing Syntax and Semantics ISBN 0-321-49362-1 Chapter 3 Topics Describing the Meanings of Programs: Dynamic Semantics Copyright 2015 Pearson. All rights reserved. 2 Semantics There is no
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 informationCMSC 330: Organization of Programming Languages
CMSC 330: Organization of Programming Languages Operational Semantics CMSC 330 Summer 2018 1 Formal Semantics of a Prog. Lang. Mathematical description of the meaning of programs written in that language
More informationPropositional Logic Formal Syntax and Semantics. Computability and Logic
Propositional Logic Formal Syntax and Semantics Computability and Logic Syntax and Semantics Syntax: The study of how expressions are structured (think: grammar) Semantics: The study of the relationship
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 informationSemantics. There is no single widely acceptable notation or formalism for describing semantics Operational Semantics
There is no single widely acceptable notation or formalism for describing semantics Operational Describe the meaning of a program by executing its statements on a machine, either simulated or actual. The
More informationLecture 1 Contracts. 1 A Mysterious Program : Principles of Imperative Computation (Spring 2018) Frank Pfenning
Lecture 1 Contracts 15-122: Principles of Imperative Computation (Spring 2018) Frank Pfenning In these notes we review contracts, which we use to collectively denote function contracts, loop invariants,
More informationHoare logic. A proof system for separation logic. Introduction. Separation logic
Introduction Hoare logic Lecture 6: Examples in separation logic In the previous lecture, we saw how reasoning about pointers in Hoare logic was problematic, which motivated introducing separation logic.
More informationAXIOMS FOR THE INTEGERS
AXIOMS FOR THE INTEGERS BRIAN OSSERMAN We describe the set of axioms for the integers which we will use in the class. The axioms are almost the same as what is presented in Appendix A of the textbook,
More informationHardware versus software
Logic 1 Hardware versus software 2 In hardware such as chip design or architecture, designs are usually proven to be correct using proof tools In software, a program is very rarely proved correct Why?
More information(a) (4 pts) Prove that if a and b are rational, then ab is rational. Since a and b are rational they can be written as the ratio of integers a 1
CS 70 Discrete Mathematics for CS Fall 2000 Wagner MT1 Sol Solutions to Midterm 1 1. (16 pts.) Theorems and proofs (a) (4 pts) Prove that if a and b are rational, then ab is rational. Since a and b are
More informationProgram Verification. Program Verification 307/434
Program Verification Program Verification 307/434 Outline Introduction: What and Why? Pre- and Postconditions Conditionals while-loops and Total Correctness Arrays Program Verification Introduction 308/434
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 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 informationReasoning about programs
Reasoning about programs Last time Coming up This Thursday, Nov 30: 4 th in-class exercise sign up for group on moodle bring laptop to class Final projects: final project presentations: Tue Dec 12, in
More informationLast time. Reasoning about programs. Coming up. Project Final Presentations. This Thursday, Nov 30: 4 th in-class exercise
Last time Reasoning about programs Coming up This Thursday, Nov 30: 4 th in-class exercise sign up for group on moodle bring laptop to class Final projects: final project presentations: Tue Dec 12, in
More informationAbstract Interpretation
Abstract Interpretation Ranjit Jhala, UC San Diego April 22, 2013 Fundamental Challenge of Program Analysis How to infer (loop) invariants? Fundamental Challenge of Program Analysis Key issue for any analysis
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 informationChapter 3. Describing Syntax and Semantics
Chapter 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 of Programs:
More informationThis is already grossly inconvenient in present formalisms. Why do we want to make this convenient? GENERAL GOALS
1 THE FORMALIZATION OF MATHEMATICS by Harvey M. Friedman Ohio State University Department of Mathematics friedman@math.ohio-state.edu www.math.ohio-state.edu/~friedman/ May 21, 1997 Can mathematics be
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 information3.7 Denotational Semantics
3.7 Denotational Semantics Denotational semantics, also known as fixed-point semantics, associates to each programming language construct a well-defined and rigorously understood mathematical object. These
More informationNote that in this definition, n + m denotes the syntactic expression with three symbols n, +, and m, not to the number that is the sum of n and m.
CS 6110 S18 Lecture 8 Structural Operational Semantics and IMP Today we introduce a very simple imperative language, IMP, along with two systems of rules for evaluation called small-step and big-step semantics.
More informationCS 125 Section #4 RAMs and TMs 9/27/16
CS 125 Section #4 RAMs and TMs 9/27/16 1 RAM A word-ram consists of: A fixed set of instructions P 1,..., P q. Allowed instructions are: Modular arithmetic and integer division on registers; the standard
More informationIntroduction to Axiomatic Semantics (1/2)
#1 Introduction to Axiomatic Semantics (1/2) How s The Homework Going? Remember: just do the counterexample guided abstraction refinement part of DPLL(T). If you notice any other errors, those are good
More informationOne of the most important areas where quantifier logic is used is formal specification of computer programs.
Section 5.2 Formal specification of computer programs One of the most important areas where quantifier logic is used is formal specification of computer programs. Specification takes place on several levels
More informationCS2104 Prog. Lang. Concepts
CS2104 Prog. Lang. Concepts Operational Semantics Abhik Roychoudhury Department of Computer Science National University of Singapore Organization An imperative language IMP Formalizing the syntax of IMP
More informationReasoning About Imperative Programs. COS 441 Slides 10
Reasoning About Imperative Programs COS 441 Slides 10 The last few weeks Agenda reasoning about functional programming It s very simple and very uniform: substitution of equal expressions for equal expressions
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 informationPart II. Hoare Logic and Program Verification. Why specify programs? Specification and Verification. Code Verification. Why verify programs?
Part II. Hoare Logic and Program Verification Part II. Hoare Logic and Program Verification Dilian Gurov Props: Models: Specs: Method: Tool: safety of data manipulation source code logic assertions Hoare
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 informationIntroduction to Axiomatic Semantics (1/2)
#1 Introduction to Axiomatic Semantics (1/2) How s The Homework Going? Remember that you can t just define a meaning function in terms of itself you must use some fixed point machinery. #2 #3 Observations
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 informationInduction and Semantics in Dafny
15-414 Lecture 11 1 Instructor: Matt Fredrikson Induction and Semantics in Dafny TA: Ryan Wagner Encoding the syntax of Imp Recall the abstract syntax of Imp: a AExp ::= n Z x Var a 1 + a 2 b BExp ::=
More informationp x i 1 i n x, y, z = 2 x 3 y 5 z
3 Pairing and encoding functions Our aim in this part of the course is to show that register machines can compute everything that can be computed, and to show that there are things that can t be computed.
More informationTheorem proving. PVS theorem prover. Hoare style verification PVS. More on embeddings. What if. Abhik Roychoudhury CS 6214
Theorem proving PVS theorem prover Abhik Roychoudhury National University of Singapore Both specification and implementation can be formalized in a suitable logic. Proof rules for proving statements in
More informationCOMP 507: Computer-Aided Program Design
Fall 2014 April 7, 2015 Goal: Correctness proofs Prove that an algorithm written in an imperative language is correct Induction for algorithmic correctness Induction for functional programs: The program
More informationP1 Engineering Computation
1EC 2001 1 / 1 P1 Engineering Computation David Murray david.murray@eng.ox.ac.uk www.robots.ox.ac.uk/ dwm/courses/1ec Hilary 2001 1EC 2001 2 / 1 Algorithms: Design, Constructs and Correctness 1EC 2001
More informationSpecification and Verification I
Title: Lecturer: Class: Specification and Verification I Mike Gordon Computer Science Tripos, Part II Duration: Twelve lectures Specification and Verification I Mike Gordon Overview These lecture notes
More informationLECTURE 16. Functional Programming
LECTURE 16 Functional Programming WHAT IS FUNCTIONAL PROGRAMMING? Functional programming defines the outputs of a program as a mathematical function of the inputs. Functional programming is a declarative
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 informationPropositional Logic. Part I
Part I Propositional Logic 1 Classical Logic and the Material Conditional 1.1 Introduction 1.1.1 The first purpose of this chapter is to review classical propositional logic, including semantic tableaux.
More informationMain Goal. Language-independent program verification framework. Derive program properties from operational semantics
Main Goal Language-independent program verification framework Derive program properties from operational semantics Questions: Is it possible? Is it practical? Answers: Sound and complete proof system,
More informationThe Formal Semantics of Programming Languages An Introduction. Glynn Winskel. The MIT Press Cambridge, Massachusetts London, England
The Formal Semantics of Programming Languages An Introduction Glynn Winskel The MIT Press Cambridge, Massachusetts London, England Series foreword Preface xiii xv 1 Basic set theory 1 1.1 Logical notation
More informationFall 2018 Lecture 1
15-150 Fall 2018 Lecture 1 Stephen Brookes 1 Themes functional programming correctness, termination, and performance types, specifications, and proofs evaluation and equivalence referential transparency
More informationLecture Notes on Ints
Lecture Notes on Ints 15-122: Principles of Imperative Computation Frank Pfenning Lecture 2 August 26, 2010 1 Introduction Two fundamental types in almost any programming language are booleans and integers.
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 informationOverview. CS389L: Automated Logical Reasoning. Lecture 6: First Order Logic Syntax and Semantics. Constants in First-Order Logic.
Overview CS389L: Automated Logical Reasoning Lecture 6: First Order Logic Syntax and Semantics Işıl Dillig So far: Automated reasoning in propositional logic. Propositional logic is simple and easy to
More informationDefinition: A context-free grammar (CFG) is a 4- tuple. variables = nonterminals, terminals, rules = productions,,
CMPSCI 601: Recall From Last Time Lecture 5 Definition: A context-free grammar (CFG) is a 4- tuple, variables = nonterminals, terminals, rules = productions,,, are all finite. 1 ( ) $ Pumping Lemma for
More information15-819M: Data, Code, Decisions
15-819M: Data, Code, Decisions 08: First-Order Logic André Platzer aplatzer@cs.cmu.edu Carnegie Mellon University, Pittsburgh, PA André Platzer (CMU) 15-819M/08: Data, Code, Decisions 1 / 40 Outline 1
More informationIntermediate representations IR #1: CPS/L 3. Code example. Advanced Compiler Construction Michel Schinz
Intermediate representations Intermediate representations Advanced Compiler Construction Michel Schinz 2016 03 03 The term intermediate representation (IR) or intermediate language designates the data-structure(s)
More informationFundamental Concepts. Chapter 1
Chapter 1 Fundamental Concepts This book is about the mathematical foundations of programming, with a special attention on computing with infinite objects. How can mathematics help in programming? There
More informationCOSC252: Programming Languages: Semantic Specification. Jeremy Bolton, PhD Adjunct Professor
COSC252: Programming Languages: Semantic Specification Jeremy Bolton, PhD Adjunct Professor Outline I. What happens after syntactic analysis (parsing)? II. Attribute Grammars: bridging the gap III. Semantic
More informationFunctional Programming Languages (FPL)
Functional Programming Languages (FPL) 1. Definitions... 2 2. Applications... 2 3. Examples... 3 4. FPL Characteristics:... 3 5. Lambda calculus (LC)... 4 6. Functions in FPLs... 7 7. Modern functional
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 informationContents. Chapter 1 SPECIFYING SYNTAX 1
Contents Chapter 1 SPECIFYING SYNTAX 1 1.1 GRAMMARS AND BNF 2 Context-Free Grammars 4 Context-Sensitive Grammars 8 Exercises 8 1.2 THE PROGRAMMING LANGUAGE WREN 10 Ambiguity 12 Context Constraints in Wren
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 informationChapter 3. Describing Syntax and Semantics ISBN
Chapter 3 Describing Syntax and Semantics ISBN 0-321-49362-1 Chapter 3 Topics Introduction The General Problem of Describing Syntax Formal Methods of Describing Syntax Attribute Grammars Describing the
More informationChapter 3. Describing Syntax and Semantics
Chapter 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 of Programs:
More informationLogic and Computation Lecture 20 CSU 290 Spring 2009 (Pucella) Thursday, Mar 12, 2009
Logic and Computation Lecture 20 CSU 290 Spring 2009 (Pucella) Thursday, Mar 12, 2009 Note that I change the name of the functions slightly in these notes from what I used in class, to be consistent with
More informationLecture Notes: Hoare Logic
Lecture Notes: Hoare Logic 17-654/17-754: Analysis of Software Artifacts Jonathan Aldrich (jonathan.aldrich@cs.cmu.edu) Lecture 3 1 Hoare Logic The goal of Hoare logic is to provide a formal system for
More informationMathematical Induction
Mathematical Induction Victor Adamchik Fall of 2005 Lecture 3 (out of three) Plan 1. Recursive Definitions 2. Recursively Defined Sets 3. Program Correctness Recursive Definitions Sometimes it is easier
More information6.001 Notes: Section 6.1
6.001 Notes: Section 6.1 Slide 6.1.1 When we first starting talking about Scheme expressions, you may recall we said that (almost) every Scheme expression had three components, a syntax (legal ways of
More informationComputation Club: Gödel s theorem
Computation Club: Gödel s theorem The big picture mathematicians do a lot of reasoning and write a lot of proofs formal systems try to capture the ideas of reasoning and proof in a purely mechanical set
More informationDiagonalization. The cardinality of a finite set is easy to grasp: {1,3,4} = 3. But what about infinite sets?
Diagonalization Cardinalities The cardinality of a finite set is easy to grasp: {1,3,4} = 3. But what about infinite sets? We say that a set S has at least as great cardinality as set T, written S T, if
More informationDenotational Semantics of a Simple Imperative Language Using Intensional Logic
Denotational Semantics of a Simple Imperative Language Using Intensional Logic Marc Bender bendermm@mcmaster.ca CAS 706 - Programming Languages Instructor: Dr. Jacques Carette Dept. of Computing and Software
More informationIntro to semantics; Small-step semantics Lecture 1 Tuesday, January 29, 2013
Harvard School of Engineering and Applied Sciences CS 152: Programming Languages Lecture 1 Tuesday, January 29, 2013 1 Intro to semantics What is the meaning of a program? When we write a program, we use
More informationCMSC 330: Organization of Programming Languages. Formal Semantics of a Prog. Lang. Specifying Syntax, Semantics
Recall Architecture of Compilers, Interpreters CMSC 330: Organization of Programming Languages Source Scanner Parser Static Analyzer Operational Semantics Intermediate Representation Front End Back End
More informationProgram Verification. Aarti Gupta
Program Verification Aarti Gupta 1 Agenda Famous bugs Common bugs Testing (from lecture 6) Reasoning about programs Techniques for program verification 2 Famous Bugs The first bug: A moth in a relay (1945)
More informationRecursion. Lars-Henrik Eriksson. Functional Programming 1. Based on a presentation by Tjark Weber and notes by Sven-Olof Nyström
Lars-Henrik Eriksson Functional Programming 1 Based on a presentation by Tjark Weber and notes by Sven-Olof Nyström Tjark Weber (UU) Recursion 1 / 41 Comparison: Imperative/Functional Programming Comparison:
More informationHandout 9: Imperative Programs and State
06-02552 Princ. of Progr. Languages (and Extended ) The University of Birmingham Spring Semester 2016-17 School of Computer Science c Uday Reddy2016-17 Handout 9: Imperative Programs and State Imperative
More informationHandout 10: Imperative programs and the Lambda Calculus
06-02552 Princ of Progr Languages (and Extended ) The University of Birmingham Spring Semester 2016-17 School of Computer Science c Uday Reddy2016-17 Handout 10: Imperative programs and the Lambda Calculus
More informationSummary of Course Coverage
CS-227, Discrete Structures I Spring 2006 Semester Summary of Course Coverage 1) Propositional Calculus a) Negation (logical NOT) b) Conjunction (logical AND) c) Disjunction (logical inclusive-or) d) Inequalities
More informationSOFTWARE ENGINEERING DESIGN I
2 SOFTWARE ENGINEERING DESIGN I 3. Schemas and Theories The aim of this course is to learn how to write formal specifications of computer systems, using classical logic. The key descriptional technique
More informationFormal Syntax and Semantics of Programming Languages
Formal Syntax and Semantics of Programming Languages Mooly Sagiv Reference: Semantics with Applications Chapter 2 H. Nielson and F. Nielson http://www.daimi.au.dk/~bra8130/wiley_book/wiley.html The While
More informationRecursively Enumerable Languages, Turing Machines, and Decidability
Recursively Enumerable Languages, Turing Machines, and Decidability 1 Problem Reduction: Basic Concepts and Analogies The concept of problem reduction is simple at a high level. You simply take an algorithm
More informationDeriving a Slicing Algorithm via FermaT Transformations
Deriving a Slicing Algorithm via FermaT Transformations M. P. Ward and H. Zedan Software Technology Research Lab De Montfort University The Gateway, Leicester LE1 9BH, UK martin@gkc.org.uk and zedan@dmu.ac.uk
More informationELEMENTARY NUMBER THEORY AND METHODS OF PROOF
CHAPTER 4 ELEMENTARY NUMBER THEORY AND METHODS OF PROOF Copyright Cengage Learning. All rights reserved. SECTION 4.3 Direct Proof and Counterexample III: Divisibility Copyright Cengage Learning. All rights
More informationSTABILITY AND PARADOX IN ALGORITHMIC LOGIC
STABILITY AND PARADOX IN ALGORITHMIC LOGIC WAYNE AITKEN, JEFFREY A. BARRETT Abstract. Algorithmic logic is the logic of basic statements concerning algorithms and the algorithmic rules of deduction between
More informationaxiomatic semantics involving logical rules for deriving relations between preconditions and postconditions.
CS 6110 S18 Lecture 18 Denotational Semantics 1 What is Denotational Semantics? So far we have looked at operational semantics involving rules for state transitions, definitional semantics involving translations
More informationThe story so far. Elements of Programming Languages. Pairs in various languages. Pairs
Elements of Programming Languages Lecture 6: Data structures James Cheney University of Edinburgh October 9, 2017 The story so far We ve now covered the main ingredients of any programming language: Abstract
More informationA CRASH COURSE IN SEMANTICS
LAST TIME Recdef More induction NICTA Advanced Course Well founded orders Slide 1 Theorem Proving Principles, Techniques, Applications Slide 3 Well founded recursion Calculations: also/finally {P}... {Q}
More informationLecture 6: Arithmetic and Threshold Circuits
IAS/PCMI Summer Session 2000 Clay Mathematics Undergraduate Program Advanced Course on Computational Complexity Lecture 6: Arithmetic and Threshold Circuits David Mix Barrington and Alexis Maciel July
More informationELEMENTARY NUMBER THEORY AND METHODS OF PROOF
CHAPTER 4 ELEMENTARY NUMBER THEORY AND METHODS OF PROOF Copyright Cengage Learning. All rights reserved. SECTION 4.3 Direct Proof and Counterexample III: Divisibility Copyright Cengage Learning. All rights
More informationShared Variables and Interference
Illinois Institute of Technology Lecture 24 Shared Variables and Interference CS 536: Science of Programming, Spring 2018 A. Why Parallel programs can coordinate their work using shared variables, but
More informationCS 242. Fundamentals. Reading: See last slide
CS 242 Fundamentals Reading: See last slide Syntax and Semantics of Programs Syntax The symbols used to write a program Semantics The actions that occur when a program is executed Programming language
More informationTyping Control. Chapter Conditionals
Chapter 26 Typing Control 26.1 Conditionals Let s expand our language with a conditional construct. We can use if0 like before, but for generality it s going to be more convenient to have a proper conditional
More informationSoftware Engineering Lecture Notes
Software Engineering Lecture Notes Paul C. Attie August 30, 2013 c Paul C. Attie. All rights reserved. 2 Contents I Hoare Logic 11 1 Propositional Logic 13 1.1 Introduction and Overview..............................
More information