Formal Methods. CITS5501 Software Testing and Quality Assurance
|
|
- Brandon Robertson
- 5 years ago
- Views:
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. !
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 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 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 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 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 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 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 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 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 informationSEQUENCES, MATHEMATICAL INDUCTION, AND RECURSION
CHAPTER 5 SEQUENCES, MATHEMATICAL INDUCTION, AND RECURSION Alessandro Artale UniBZ - http://www.inf.unibz.it/ artale/ SECTION 5.5 Application: Correctness of Algorithms Copyright Cengage Learning. All
More informationGuarded 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 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 informationLecture 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 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 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 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 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 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 informationNumerical 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 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 informationReview: 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 informationSEQUENCES, 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 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 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 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 informationFreePascal 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 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 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 informationCSE 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 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 informationSoftwaretechnik. 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 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 informationSoftwaretechnik. 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 informationProgram 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 informationSpring 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 informationShared 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 informationGoals: Define the syntax of a simple imperative language Define a semantics using natural deduction 1
Natural Semantics Goals: Define the syntax of a simple imperative language Define a semantics using natural deduction 1 1 Natural deduction is an instance of first-order logic; that is, it is the formal
More 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 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 informationELEMENTARY 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 informationQ 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 informationArguing 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 informationA 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 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 informationIII. 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 informationCIS 890: Safety Critical Systems
CIS 890: Safety Critical Systems Lecture: SPARK -- Analysis Tools Copyright 2007, John Hatcliff. The syllabus and all lectures for this course are copyrighted materials and may not be used in other course
More 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 informationSoftware 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 informationShell 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 informationPROPER 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 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 informationForward 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 informationFormal 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 informationDefining 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 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 informationSoftware 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 informationConstructing 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 informationAxiomatic 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 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 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 informationTransforming 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 informationVerification 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 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 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 informationSpecifications. 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 informationTop 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 informationMIDTERM 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 informationCSCE 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 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 informationHow invariants help writing loops Author: Sander Kooijmans Document version: 1.0
How invariants help writing loops Author: Sander Kooijmans Document version: 1.0 Why this document? Did you ever feel frustrated because of a nasty bug in your code? Did you spend hours looking at the
More 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 informationTesting, 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 informationGetting 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 informationAdvances 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 informationIntegers 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 informationDiscrete 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 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 information9/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 informationDistributed Systems Programming (F21DS1) Formal Verification
Distributed Systems Programming (F21DS1) Formal Verification Andrew Ireland Department of Computer Science School of Mathematical and Computer Sciences Heriot-Watt University Edinburgh Overview Focus on
More 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 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 informationViolations 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 informationCORRECTNESS 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 informationCOP4020 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 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 informationChapter 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 informationModel 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 informationVerification Overview Testing Theory and Principles Testing in Practice. Verification. Miaoqing Huang University of Arkansas 1 / 80
1 / 80 Verification Miaoqing Huang University of Arkansas Outline 1 Verification Overview 2 Testing Theory and Principles Theoretical Foundations of Testing Empirical Testing Principles 3 Testing in Practice
More informationFormal 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 informationLecture 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 informationIn 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 informationProgram 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 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 informationQualifying 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 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 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 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 informationBackward 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 informationAxiomatic 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