Formal Methods. CITS5501 Software Testing and Quality Assurance

Size: px
Start display at page:

Download "Formal Methods. CITS5501 Software Testing and Quality Assurance"

Transcription

1 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 Semester 1, 2017

2 What Are Formal Methods? Formal Methods refers to a wide variety of techniques that are used to prove a system is correct. They are based on mathematics. Precise notation and rules must be used to ensure the integrity of the method. FM s are part of the development process. Formal methods can be divided into three tasks: 1. Specification: producing a precise description of what the system does. 2. Verification: producing a mathematical proof of the systems correctness 3. Validation: testing and checking a system s correctness. CITS5501

3 Why Use Formal Methods? To ensure the correctness of programs Safety critical systems Highly reliable systems To precisely communicate specifications and properties of programs To understand the complex problem domains To communicate confidence in a programs correctness CITS5501

4 Example Consider the following code segment to multiply i by j. n = 0 while j>0 do n = n+i j = j-1 return n To test the correctness of this code: we could test the code segment on a number of inputs. we could inspect the code to see if it conforms to our idea of multiplication. we could try to prove that at completion, for all integers i and j, n = i*j. What requirements do we need to be able to prove that the program is correct? CITS5501

5 Parts of Formal Methods Specification of the systems requirements. The specification is a formal description of what the program should do. It is either true or false. It does not have any other qualitative or quantitative aspect. It is not necessarily complete or deterministic. Abstraction/ Transformation of the system to a mathematical object. The abstraction of the system allows us to ignore irrelevant or complex details. They allow the method to be independent of the implementation. Examples: Code segments Z - Schemas UML, ERD s, Finite state machines The method: showing that the abstract system meets the specification. The method establishes whether the abstraction of the system meets the specification Examples Logical Proof: done by hand or machine Model-checking: using graph algorithms (optional) Transforming the system to an implementation.

6 Varieties of Formal Methods Specification Languages: expressive languages with general proof methods. E.g. VDM, Z, B. Program Correctness Proofs: associates logical inference rules with programming syntax. E.g. Hoare Triples, Gries Methodology. Model Based Approaches: domain specific languages with precise algorithms for correctness proofs. E.g. Temporal logic. We will look at program correctness proofs, and the Z specification language in this unit. CITS5501

7 A History of Formal Methods 1936 A. Turing introduces the Halting Problem The Software Crisis is identified C. Hoare axiomatizes a programming language VDM evolves at the IBM research in Vienna A. Pnueli introduces verification via temporal logic J-R. Abrial develops Z specification language E. Clarke develops BDD s for model checkin 2000 SLAM C program model checking from Microsoft 2014 BLAST model checking 2014 SeL4 Verified Linux microkernal with end to end proofs. CITS5501

8 Program Verification Society becomes more dependent on computers then important that programs are reliable and error-free Program verification ensures that a computer program is correct Program is correct if behaves in accordance with specifications; but program specification may be wrong, not address all aspects of requirements Program validation attempts to ensure that program meets original requirements Proof of correctness uses techniques of formal logic to prove that if the input variables satisfy certain specified predicates or properties, output variables produced by executing the program satisfy other specified properties.

9 Assertions Let X denote an arbitrary collection of input values for program or program segment P. Actions of P transform X into a corresponding group of output values Y Notation Y = P(X) suggests that the Y values depend on X values through actions of program P Predicate Q(X) describes conditions that input values are required to satisfy. These predicates are referred to as assertions. Assertions prior tp the execution of a piece of code are preconditions and assertions after the execution of a piece of code are postconditions. A program specification is given as a pair of precondition and post condition.

10 Example: square root algorithm a := 0; b := n + 1; {pre: 0 n} {inv P : a <b n+1 a 2 n <b 2 } while a + 1 <> b do begin end; d := (a + b) div 2; if d * d <= n then else {post: a 2 n < (a+1) 2 } a := d b := d The postcondition describes the integer approximation of a square root. The precondition requires n is nonnegative. This is a Hoare Triple. We can mathematically confirm that the program satisfies its specification.

11 Example pre and post conditions Specifying some lower bound on (elements of) the data: 0 n The integer square root problem 0 x 0 y The GCD problem Specifying (e.g. ordering) properties of the data. (forall j : 0 j < n-1 : a j a j+1 ) Searching an ordered list etc.. Summing the elements of an array Set s to the sum of the n elements of the array a[0..n-1]. s = ( j : 0 j < n : a j ) Finding the maximum Setting p to the position of a maximum element of a[0..n-1]. 0 p < n (forall j : 0 j < n : a j a p )

12 Proof Outlines Proof outlines consist of the program code interspersed with assertion at key points: Swapping the values of x and y {x = X y = Y} t := x; {t = X x = X y = Y} x := y; {t = X x = Y y = Y} y := t {x = Y y = X} Assertions in proof outlines may be named by preceding them with an identifier and a colon. Two assertions P1, P2 appearing on a line means P1 Þ P2. Setting x to its absolute value {x = X} if x < 0 then {x = X x < 0} x := x {x = X x > 0}{x = X } else {x = X x 0} skip {x = X x 0}{x = X } {x = X }

13 Strength of Predicates A predicate p1 is weaker than predicate p2: if p1 <- p2. if p1 makes fewer restrictions on the values of its identifiers. if p1 s states includes at least p2 s states. (The reverse property is stronger than!) For any command S and predicate R, which describes the desired result of executing S, we will define another predicate denoted wp(s, R) as follows: wp(s, R) represents the set of all states such that execution of S begun in any one of them is guaranteed to terminate in a finite amount of time in a state satisfying R. wp(s, R) is the weakest pre-condition for the execution of S to result in a state satisfying R Thus the notations: {Q}S{R} and Q -> wp(s, R) are equivalent.

14 A programming calculus We will use a simple abstract programming language to build our proofs over. The language just consists of assignment, integers, arithmetic, arrays, conditionals, and loops. Integer arithmetic and arrays already have a logical theory so we just have to provide one for assignment, conditional and loops. Syntax: assignment x := e (where e is an expression) conditional if B l -> S l [] B n -> S n fi (where B s are pred and S are prog) loop do B -> S od

15 Assignment Is formally defined: wp( x := e, R) = domain(e) cand R x e where domain(e) is a predicate which defines that set of states in which e may be evaluated, cand is conditional and R x e is the predicate R with every occurance of x replaced by e Example 1 wp( x := 5, x = 5) = (5 = 5) = T (The execution of x := 5 always establishes x = 5.) Example 2 wp( x := x+1, x < 0) = (x + 1 < 0) = x < 1 Example 4 wp( x := e, x = c) = (e = c)

16 A bigger example The sequence: t := x; x := y; y := t is often used to swap the values of x and y. We now prove that it does do so. wp( t := x; x := y; y := t, x = Y y = X) = wp( t := x; x := y, wp( y := t, x = Y y = X)) = wp( t := x; x := y, x = Y t = X) = wp( t := x, wp( x := y, x = Y t = X)) = wp( t := x, y = Y t = X) = y = Y x = X This is tedious to read and we prefer proof outlines: {x = Y y = X} t := x; {x = Y t = X} x := y; {y = Y t = X} y := t {y = Y x = X}

17 Conditionals Conditional statements allow execution to be dependent on the current state of the program variables. In Java (or C) if (x>=0) z = x; else z = -x; In our programming notation, we would express this as the following alternative command: if x 0 -> z := x [] x 0 -> z := x fi The general form is: if B l -> S l [] B 2 -> S 2... [] B n ->S n fi where: n 0 each B i is a Boolean expression (called a guard) for command S i. The guard ensures that the command is executed only under the right conditions. For abbreviation, let the general alternative command be referred to as IF, and let BB = B 1 B 2... B n

18 Proofs for conditionals This is defined as: wp(if,r) =domain(bb) BB (B l -> wp(s l, R))... (B n -> wp(s n, R)) This requires: the guards to be well-defined, at least one of them to be true, the execution of each command S i with a true guard B i must terminate with R true. Omitting the first conjunct, domain(bb), this can be written: wp(if, R) = (exists i : l i n : B i ) (forall i: l i n : B i -> wp(s i, R)) Example: Let us show that, under all conditions, the sequence of p1: if x 0 -> z := x [] x 0 -> z := x fi sets z to the absolute value of x. Call it IF1. wp(if1, z = x ) = (x 0 x 0) (x 0 -> wp( z : = x, z = x )) (x 0 -> wp( z := x, z = x )) = T (x 0 -> x = x ) (x 0 -> x = x ) = T T T = T

19 Loops This allows statements to be repeated (iterated) so long as certain conditions hold. In Java while (B) S In our programming notation we express a simple loop as the following iterative command: do B -> S od Weakest precondition? The predicate, H k (R), represents the set of all states in which execution of DO terminates in k or fewer iterations with R true. Thus H 0 (R) = ~BB R Here all guards are initially false (BB is false) and after 0 iterations R is satisfied. Now remember that DO is the same as: do BB -> IF od so we can define H k (R) recursively, in terms of H k-1 (R), remembering that the loop might not be executed at all. H k (R) = H 0 (R) wp(if, H k-1 (R)) for k > 0, Finally we can define wp(do, R): wp(do, R) = (exists k : 0 k : H k (R)) This is difficult to work with. Is there a better way?

20 Invariants Consider the following sequence for storing in z the product of a * b, for b 0, assuming we have no multiplication order. (NB The division is really a right shift!) {Q : b 0} x, y, z := a, b, 0; do IF y > 0 even(y) -> y, x := y 2, x + x [] odd(y) -> y, z := y 1, z + x od {R : z = a * b} The essence is to find an invariant, P. If: P is true before execution of DO; each iteration of the loop leaves P true, then P is true before and after each iteration and on termination. If Q -> P and P ~BB -> R, then Q -> wp(do, R). If DO terminates then the sequence has been proved. Note this is only partial correctness since termination cannot be guaranteed.

21 Example Let us confirm the invariant (plucked out of the air): P : y 0 z + x * y = a * b {Q : b 0} x, y, z := a, b, 0; do []y > 0 even(y) -> y, x := y 2, x + x [] odd(y) -> y, z := y 1, z + x od {R : z = a * b} Confirm that P is true before execution of DO. That is, confirm Q -> P. We assume it true and find the weakest precondition for the initialisation to establish it. wp( x, y, z := a, b, 0, y 0 z + x * y = a * b) = b a * b = a * b = Q Confirm that each iteration of the loop leaves P true. We consider the guarded commands in turn. The first: wp( y, x := y 2, x + x,y 0 z + x*y = a*b) = y 2 0 z + (x + x) * y 2 = a * b and this is implied by the conjunction of P and the guard: y 0 z + x * y = a * b y > 0 even(y)

22 Example (cont.) The second guarded command: wp( y, z := y 1, z + x, y 0 z + x * y = a * b) = y 1 0 z + x + x * (y 1) = a * b = y 1 z + x * (y 1 + 1) = a * b = y 1 z + x * y = a * b and this is implied by the conjunction of P and the guard: 3. Confirm that P ~BB R. y 0 z + x * y = a * b ~(y > 0 even(y)) ~odd(y) = y 0 z + x * y = a * b ~(y > 0) = y 0 z + x * y = a * b y 0 = y = 0 z + x * y = a * b -> z = a * b y 0 z + x * y = a * b odd(y) Remember we have proved that, only provided the sequence terminates, does it achieve the post-condition.

23 Annotation A full annotation might go like this: {Q : b 0} x, y, z := a, b, 0; {P : y 0 z + x * y = a * b} do y > 0 even(y) -> {P y>0 even(y)} y, x := y 2, x+x {P} [] odd(y) -> {P odd(y)} y, z := y 1, z + x {P} od {P y 0} {R : z = a * b} Using this approach, we are able to construct an algorithm and a proof of correctness at the same time. Indeed, it is easier to do this than prove a preexisting piece of code is correct. As with Test driven development, understanding these methods makes you a better coder.

24 Pro s for Formal Methods Improved confidence in the programs correctness. Improved communication, you can communicate about the correctness of the program. Better designs and a greater understanding of the problem domain. Not error free code. Use FM for. Safety critical systems - E.g. medical applications. Only one chance to get it right When implementing core functionality (e.g. microprocessors). Problem poorly understood. CITS5501 Highly complex problem domains.

25 Con s for Formal Methods Specifications can be harder to write than direct implementations. Proofs are difficult for even small programs The proof could be wrong. System and hardware constraints are abstracted out. Formal approaches are not suited to graphical, UI, or real-time functions. CITS5501

26 7 Sins of Specification Noise - irrelevant content Silence - omitting part of the requirements Over-specification Contradiction Ambiguity Forward referencing Wishful thinking. Meyer 1985 CITS5501

27 7 Myths of Formal Methods They can guarantee that software is perfect. They are all about program proving. They are only useful for safety-critical systems. They require highly trained mathematicians. They increase the cost of development They are unacceptable to users They are not used on real, large-scale software. Hall, 1990 CITS5501

28 7 More Myths of Formal Methods They delay the development process. They lack tools. They replace traditional engineering design methods. They only apply to software. They are unnecessary. They are not supported. Formal methods people always use formal methods. Bowen and Hinchy, CITS5501

! Use of formal notations. ! in software system descriptions. ! for a broad range of effects. ! and varying levels of use. !

! 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 information

Hoare Logic: Proving Programs Correct

Hoare 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 information

Lecture Notes: Hoare Logic

Lecture 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 information

An Annotated Language

An 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 information

Semantics. There is no single widely acceptable notation or formalism for describing semantics Operational Semantics

Semantics. 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 information

CITS5501 Software Testing and Quality Assurance Formal methods

CITS5501 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 information

6. Hoare Logic and Weakest Preconditions

6. 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 information

Programming Languages Third Edition

Programming 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 information

Chapter 3. Describing Syntax and Semantics ISBN

Chapter 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 information

SEQUENCES, MATHEMATICAL INDUCTION, AND RECURSION

SEQUENCES, 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 information

Guarded Commands, Nondeterminancy and Formal Derivation of Programs. Edsger W. Dijkstra. CACM 18, 8 pp (Aug. 1975).

Guarded Commands, Nondeterminancy and Formal Derivation of Programs. Edsger W. Dijkstra. CACM 18, 8 pp (Aug. 1975). CS322 E. W. Dijkstra, Guarded command, Nondeterminancy and Formal Derivation of Programs 1 Guarded Commands, Nondeterminancy and Formal Derivation of Programs Edsger W. Dijkstra CACM 18, 8 pp. 453-457

More information

COMP 507: Computer-Aided Program Design

COMP 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 information

Lecture 5 - Axiomatic semantics

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 information

Reasoning About Imperative Programs. COS 441 Slides 10

Reasoning 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 information

Part II. Hoare Logic and Program Verification. Why specify programs? Specification and Verification. Code Verification. Why verify programs?

Part 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

Lectures 20, 21: Axiomatic Semantics

Lectures 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 information

Abstract Interpretation

Abstract 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 information

Harvard School of Engineering and Applied Sciences CS 152: Programming Languages

Harvard 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 information

Numerical Computations and Formal Methods

Numerical Computations and Formal Methods Program verification Formal arithmetic Decision procedures Proval, Laboratoire de Recherche en Informatique INRIA Saclay IdF, Université Paris Sud, CNRS October 28, 2009 Program verification Formal arithmetic

More information

Chapter 3. Describing Syntax and Semantics

Chapter 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 information

Review: Hoare Logic Rules

Review: Hoare Logic Rules Review: Hoare Logic Rules wp(x := E, P) = [E/x] P wp(s;t, Q) = wp(s, wp(t, Q)) wp(if B then S else T, Q) = B wp(s,q) && B wp(t,q) Proving loops correct First consider partial correctness The loop may not

More information

SEQUENCES, MATHEMATICAL INDUCTION, AND RECURSION

SEQUENCES, MATHEMATICAL INDUCTION, AND RECURSION CHAPTER 5 SEQUENCES, MATHEMATICAL INDUCTION, AND RECURSION Copyright Cengage Learning. All rights reserved. SECTION 5.5 Application: Correctness of Algorithms Copyright Cengage Learning. All rights reserved.

More information

Shared Variables and Interference

Shared 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 information

COSC252: Programming Languages: Semantic Specification. Jeremy Bolton, PhD Adjunct Professor

COSC252: 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 information

Chapter 3 (part 3) Describing Syntax and Semantics

Chapter 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 information

FreePascal changes: user documentation

FreePascal changes: user documentation FreePascal changes: user documentation Table of Contents Jochem Berndsen February 2007 1Introduction...1 2Accepted syntax...2 Declarations...2 Statements...3 Class invariants...3 3Semantics...3 Definitions,

More information

Hoare Logic. COMP2600 Formal Methods for Software Engineering. Rajeev Goré

Hoare 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 information

CS2104 Prog. Lang. Concepts

CS2104 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 information

CSE 307: Principles of Programming Languages

CSE 307: Principles of Programming Languages CSE 307: Principles of Programming Languages Advanced Topics R. Sekar Topics 1 / 14 1. 2 / 14 Section 1 3 / 14 Semantics of Programs Syntax defines what programs are valid. Semantics defines what the valid

More information

Chapter 3. Describing Syntax and Semantics ISBN

Chapter 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 information

Softwaretechnik. Program verification. Software Engineering Albert-Ludwigs-University Freiburg. June 30, 2011

Softwaretechnik. Program verification. Software Engineering Albert-Ludwigs-University Freiburg. June 30, 2011 Softwaretechnik Program verification Software Engineering Albert-Ludwigs-University Freiburg June 30, 2011 (Software Engineering) Softwaretechnik June 30, 2011 1 / 28 Road Map Program verification Automatic

More information

The 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 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 information

Softwaretechnik. Program verification. Albert-Ludwigs-Universität Freiburg. June 28, Softwaretechnik June 28, / 24

Softwaretechnik. Program verification. Albert-Ludwigs-Universität Freiburg. June 28, Softwaretechnik June 28, / 24 Softwaretechnik Program verification Albert-Ludwigs-Universität Freiburg June 28, 2012 Softwaretechnik June 28, 2012 1 / 24 Road Map Program verification Automatic program verification Programs with loops

More information

Program Static Analysis. Overview

Program Static Analysis. Overview Program Static Analysis Overview Program static analysis Abstract interpretation Data flow analysis Intra-procedural Inter-procedural 2 1 What is static analysis? The analysis to understand computer software

More information

Spring 2018 PhD Qualifying Exam in Languages

Spring 2018 PhD Qualifying Exam in Languages Spring 2018 PhD Qualifying Exam in Languages Illinois Institute of Technology Department of Computer Science Monday, January 29, 2018 Instructions This exam is closed book and closed notes. Read each problem

More information

Shared Variables and Interference

Shared Variables and Interference Solved Shared Variables and Interference CS 536: Science of Programming, Fall 2018 A. Why Parallel programs can coordinate their work using shared variables, but it s important for threads to not interfere

More information

Goals: Define the syntax of a simple imperative language Define a semantics using natural deduction 1

Goals: 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

Main 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 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 information

AXIOMS OF AN IMPERATIVE LANGUAGE PARTIAL CORRECTNESS WEAK AND STRONG CONDITIONS. THE AXIOM FOR nop

AXIOMS 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 information

ELEMENTARY NUMBER THEORY AND METHODS OF PROOF

ELEMENTARY NUMBER THEORY AND METHODS OF PROOF CHAPTER 4 ELEMENTARY NUMBER THEORY AND METHODS OF PROOF Copyright Cengage Learning. All rights reserved. SECTION 4.8 Application: Algorithms Copyright Cengage Learning. All rights reserved. Application:

More information

Q Body of techniques supported by. R precise mathematics. R powerful analysis tools. Q Rigorous, effective mechanisms for system.

Q Body of techniques supported by. R precise mathematics. R powerful analysis tools. Q Rigorous, effective mechanisms for system. Introduction to Formal Methods 1 Introduction to Formal Methods 2 Formal Specification Requirements specification R notational statement of system services Software specification R formal abstract depiction

More information

Arguing for program correctness and writing correct programs

Arguing for program correctness and writing correct programs Arguing for program correctness and writing correct programs Saying things about states, programs Program state s1: x=4, y=-1.5, A={ me, you, he Assertions about program states x=3 False in s1 (y=x) x>=0

More information

A Partial Correctness Proof for Programs with Decided Specifications

A Partial Correctness Proof for Programs with Decided Specifications Applied Mathematics & Information Sciences 1(2)(2007), 195-202 An International Journal c 2007 Dixie W Publishing Corporation, U. S. A. A Partial Correctness Proof for Programs with Decided Specifications

More information

Chapter 3. Describing Syntax and Semantics

Chapter 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 information

III. Check if the divisors add up to the number. Now we may consider each of these tasks separately, assuming the others will be taken care of

III. Check if the divisors add up to the number. Now we may consider each of these tasks separately, assuming the others will be taken care of Top-Down Design 1 Top-Down Design: A solution method where the problem is broken down into smaller sub-problems, which in turn are broken down into smaller subproblems, continuing until each sub-problem

More information

CIS 890: Safety Critical Systems

CIS 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 information

Chapter 3. Semantics. Topics. Introduction. Introduction. Introduction. Introduction

Chapter 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 information

Software Engineering: A Practitioner s s Approach, 6/e Roger Pressman. Chapter 28 Formal Methods

Software Engineering: A Practitioner s s Approach, 6/e Roger Pressman. Chapter 28 Formal Methods Software Engineering: A Practitioner s s Approach, 6/e Roger Pressman Chapter 28 Formal Methods 1 Problems with Conventional Specification contradictions ambiguities vagueness incompleteness mixed levels

More information

Shell CSCE 314 TAMU. Haskell Functions

Shell CSCE 314 TAMU. Haskell Functions 1 CSCE 314: Programming Languages Dr. Dylan Shell Haskell Functions 2 Outline Defining Functions List Comprehensions Recursion 3 Conditional Expressions As in most programming languages, functions can

More information

PROPER TECHNIQUE OF SOFTWARE INSPECTION USING GUARDED COMMAND LANGUAGE

PROPER TECHNIQUE OF SOFTWARE INSPECTION USING GUARDED COMMAND LANGUAGE International Journal of Computer Science and Communication Vol. 2, No. 1, January-June 2011, pp. 153-157 PROPER TECHNIQUE OF SOFTWARE INSPECTION USING GUARDED COMMAND LANGUAGE Neeraj Kumar Singhania University,

More information

Introduction to Axiomatic Semantics (1/2)

Introduction 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 information

Forward Assignment; Strongest Postconditions

Forward Assignment; Strongest Postconditions 3/1 new version Forward Assignment; Strongest Postconditions CS 536: Science of Programming, Spring 2018 A. Why? At times, a forward version of the assignment rule is more appropriate than the backward

More information

Formal Methods for Software Engineers

Formal Methods for Software Engineers Formal Methods for Software Engineers Professor Ray Welland Department of Computing Science University of Glasgow ray@dcs.gla.ac.uk INF3120-FM 1 Overview Motivation Why have formal specifications? Where

More information

Defining Languages GMU

Defining Languages GMU Defining Languages CS463 @ GMU How do we discuss languages? We might focus on these qualities: readability: how well does a language explicitly and clearly describe its purpose? writability: how expressive

More information

Introduction to Axiomatic Semantics

Introduction 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 information

Software Quality Assurance

Software Quality Assurance Software Quality Assurance Every week we see new examples of: computer systems error/failure Here are some examples, taken from different industries Airport chaos after computer crash By Vanessa Allen,

More information

Constructing Algorithms and Pseudocoding This document was originally developed by Professor John P. Russo

Constructing Algorithms and Pseudocoding This document was originally developed by Professor John P. Russo Constructing Algorithms and Pseudocoding This document was originally developed by Professor John P. Russo Purpose: # Describe the method for constructing algorithms. # Describe an informal language for

More information

Axiomatic Specification. Al-Said, Apcar, Jerejian

Axiomatic Specification. Al-Said, Apcar, Jerejian Axiomatic Specification Al-Said, Apcar, Jerejian 1 Axioms: Wffs that can be written down without any reference to any other Wffs. Wffs that are stipulated as unproved premises for the proof of other wffs

More information

Introduction to Axiomatic Semantics (1/2)

Introduction 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 information

A CRASH COURSE IN SEMANTICS

A 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 information

Transforming Programs into Recursive Functions

Transforming Programs into Recursive Functions SBMF 2008 Transforming Programs into Recursive Functions Magnus O. Myreen, Michael J. C. Gordon 1 Computer Laboratory, University of Cambridge 15 JJ Thomson Avenue, Cambridge, UK Abstract This paper presents

More information

Verification Condition Generation

Verification Condition Generation Verification Condition Generation Jorge Sousa Pinto Departamento de Informática / Universidade do Minho jsp@di.uminho.pt www.di.uminho.pt/~jsp Outline (1) - From Hoare Logic to VCGen algorithms: an architecture

More information

The Rule of Constancy(Derived Frame Rule)

The 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 information

Symbolic Execution and Proof of Properties

Symbolic 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 information

Specifications. Prof. Clarkson Fall Today s music: Nice to know you by Incubus

Specifications. Prof. Clarkson Fall Today s music: Nice to know you by Incubus Specifications Prof. Clarkson Fall 2015 Today s music: Nice to know you by Incubus Question Would you like a tiny bonus to your final grade for being here on time today? A. Yes B. Sí C. Hai D. Haan E.

More information

Top Down Design. 2. Design Methodology

Top Down Design. 2. Design Methodology Top Down Design 1 A solution method where the problem is broken down into smaller subproblems, which in turn are broken down into smaller problems until each subproblem can be solved in a few steps. (Also

More information

MIDTERM EXAM (Solutions)

MIDTERM EXAM (Solutions) MIDTERM EXAM (Solutions) Total Score: 100, Max. Score: 83, Min. Score: 26, Avg. Score: 57.3 1. (10 pts.) List all major categories of programming languages, outline their definitive characteristics and

More information

CSCE 314 TAMU Fall CSCE 314: Programming Languages Dr. Flemming Andersen. Haskell Functions

CSCE 314 TAMU Fall CSCE 314: Programming Languages Dr. Flemming Andersen. Haskell Functions 1 CSCE 314: Programming Languages Dr. Flemming Andersen Haskell Functions 2 Outline Defining Functions List Comprehensions Recursion 3 Conditional Expressions As in most programming languages, functions

More information

Outline. Introduction. 2 Proof of Correctness. 3 Final Notes. Precondition P 1 : Inputs include

Outline. 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 information

How invariants help writing loops Author: Sander Kooijmans Document version: 1.0

How 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 information

Program Verification. Aarti Gupta

Program 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 information

Testing, Debugging, and Verification exam DIT082/TDA567. Day: 9 January 2016 Time: Will be published mid February or earlier

Testing, Debugging, and Verification exam DIT082/TDA567. Day: 9 January 2016 Time: Will be published mid February or earlier Testing, Debugging, and Verification exam DIT08/TDA567 Responsible: Day: 9 January 016 Time: 14 00 18 00 Atze van der Ploeg Results: Extra aid: Will be published mid February or earlier Only dictionaries

More information

Getting Started with AutoCorres

Getting Started with AutoCorres Getting Started with AutoCorres Japheth Lim Rohan Jacob-Rao David Greenaway September 10, 2018 Contents 1 Introduction 2 2 A First Proof with AutoCorres 2 2.1 Two simple functions: min and max...............

More information

Advances in Programming Languages

Advances in Programming Languages T O Y H Advances in Programming Languages APL4: JML The Java Modeling Language David Aspinall (slides originally by Ian Stark) School of Informatics The University of Edinburgh Thursday 21 January 2010

More information

Integers and Mathematical Induction

Integers and Mathematical Induction IT Program, NTUT, Fall 07 Integers and Mathematical Induction Chuan-Ming Liu Computer Science and Information Engineering National Taipei University of Technology TAIWAN 1 Learning Objectives Learn about

More information

Discrete Mathematics Lecture 4. Harper Langston New York University

Discrete Mathematics Lecture 4. Harper Langston New York University Discrete Mathematics Lecture 4 Harper Langston New York University Sequences Sequence is a set of (usually infinite number of) ordered elements: a 1, a 2,, a n, Each individual element a k is called a

More information

Lecture 6: Arithmetic and Threshold Circuits

Lecture 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 information

9/21/17. Outline. Expression Evaluation and Control Flow. Arithmetic Expressions. Operators. Operators. Notation & Placement

9/21/17. Outline. Expression Evaluation and Control Flow. Arithmetic Expressions. Operators. Operators. Notation & Placement Outline Expression Evaluation and Control Flow In Text: Chapter 6 Notation Operator evaluation order Operand evaluation order Overloaded operators Type conversions Short-circuit evaluation of conditions

More information

Distributed Systems Programming (F21DS1) Formal Verification

Distributed 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 information

1. 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. 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 information

Lecture 1 Contracts : Principles of Imperative Computation (Fall 2018) Frank Pfenning

Lecture 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 information

Violations of the contract are exceptions, and are usually handled by special language constructs. Design by contract

Violations of the contract are exceptions, and are usually handled by special language constructs. Design by contract Specification and validation [L&G Ch. 9] Design patterns are a useful way to describe program structure. They provide a guide as to how a program fits together. Another dimension is the responsibilities

More information

CORRECTNESS ISSUES AND LOOP INVARIANTS

CORRECTNESS ISSUES AND LOOP INVARIANTS Aout A2 and feedack. Recursion 2 CORRECTNESS ISSUES AND LOOP INVARIANTS S2 has een graded. If you got 30/30, you will proaly have no feedack. If you got less than full credit, there should e feedack showing

More information

COP4020 Programming Languages. Functional Programming Prof. Robert van Engelen

COP4020 Programming Languages. Functional Programming Prof. Robert van Engelen COP4020 Programming Languages Functional Programming Prof. Robert van Engelen Overview What is functional programming? Historical origins of functional programming Functional programming today Concepts

More information

Hardware versus software

Hardware 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

Chapter 3. Syntax - the form or structure of the expressions, statements, and program units

Chapter 3. Syntax - the form or structure of the expressions, statements, and program units Syntax - the form or structure of the expressions, statements, and program units Semantics - the meaning of the expressions, statements, and program units Who must use language definitions? 1. Other language

More information

Model Checking. Automatic Verification Model Checking. Process A Process B. when not possible (not AI).

Model Checking. Automatic Verification Model Checking. Process A Process B. when not possible (not AI). Sérgio Campos scampos@dcc.ufmg.br Why? Imagine the implementation of a complex hardware or software system: A 100K gate ASIC perhaps 100 concurrent modules; A flight control system dozens of concurrent

More information

Verification Overview Testing Theory and Principles Testing in Practice. Verification. Miaoqing Huang University of Arkansas 1 / 80

Verification 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 information

Formal Systems II: Applications

Formal Systems II: Applications Formal Systems II: Applications Functional Verification of Java Programs: Java Dynamic Logic Bernhard Beckert Mattias Ulbrich SS 2017 KIT INSTITUT FÜR THEORETISCHE INFORMATIK KIT University of the State

More information

Lecture 10 Design by Contract

Lecture 10 Design by Contract CS 5959 Writing Solid Code Fall 2015 Nov-23 Lecture 10 Design by Contract Zvonimir Rakamarić University of Utah Design by Contract Also called assume-guarantee reasoning Developers annotate software components

More information

In Our Last Exciting Episode

In Our Last Exciting Episode In Our Last Exciting Episode #1 Lessons From Model Checking To find bugs, we need specifications What are some good specifications? To convert a program into a model, we need predicates/invariants and

More information

Program Syntax; Operational Semantics

Program Syntax; Operational Semantics 9/5 Solved Program Syntax; Operational Semantics CS 536: Science of Programming, Fall 2018 A. Why Our simple programming language is a model for the kind of constructs seen in actual languages. Step-by-step

More information

P1 Engineering Computation

P1 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 information

Qualifying Exam Languages

Qualifying Exam Languages Illinois Institute of Technology Department of Computer Science Qualifying Exam Languages Fall 2015 This is a closed book and closed notes exam. Do ALL problems in this booklet. Read each question very

More information

Induction and Semantics in Dafny

Induction 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 information

Reasoning about programs

Reasoning 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 information

Last 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. 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 information

Lecture Notes on Ints

Lecture 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 information

Backward Reasoning: Rule for Assignment. Backward Reasoning: Rule for Sequence. Simple Example. Hoare Logic, continued Reasoning About Loops

Backward Reasoning: Rule for Assignment. Backward Reasoning: Rule for Sequence. Simple Example. Hoare Logic, continued Reasoning About Loops Backward Reasoning: Rule for Assignment Hoare Logic, continued Reasoning About Loops { wp( x=expression,q) x = expression; { Q Rule: the weakest precondition wp( x=expression,q) is Q with all occurrences

More information

Axiomatic Semantics. More Semantics. Review - Operational Semantics. Partial Correctness Assertions. Programs Theorems. Axiomatic Semantics

Axiomatic Semantics. More Semantics. Review - Operational Semantics. Partial Correctness Assertions. Programs Theorems. Axiomatic Semantics Axiomatic Semantics Still need volunteers to teach BDDs SAT-solvers SAT-based decision procedures Temporal logic (and maybe other modal logics) ESC/Java Please let me know soon Automated Deduction - George

More information