Copyright © 2006 The McGraw-Hill Companies, Inc. Programming Languages 2nd edition Tucker and Noonan Chapter 18 Program Correctness To treat programming.

Slides:



Advertisements
Similar presentations
Chapter 22 Implementing lists: linked implementations.
Advertisements

Copyright © 2006 The McGraw-Hill Companies, Inc. Programming Languages 2nd edition Tucker and Noonan Chapter 18 Program Correctness To treat programming.
Writing specifications for object-oriented programs K. Rustan M. Leino Microsoft Research, Redmond, WA, USA 21 Jan 2005 Invited talk, AIOOL 2005 Paris,
Automated Theorem Proving Lecture 1. Program verification is undecidable! Given program P and specification S, does P satisfy S?
Copyright W. Howden1 Programming by Contract CSE 111 6/4/2014.
Ceg860(Prasad)L10DC1 Design by Contract Invariants Pre-post conditions : Rights and Obligations Exceptions : Contract Violations.
Rigorous Software Development CSCI-GA Instructor: Thomas Wies Spring 2012 Lecture 6 Disclaimer. These notes are derived from notes originally.
Rigorous Software Development CSCI-GA Instructor: Thomas Wies Spring 2012 Lecture 8.
Semantics Static semantics Dynamic semantics attribute grammars
The Java Modeling Language JML Erik Poll Digital Security Radboud University Nijmegen.
Copyright © 2006 Addison-Wesley. All rights reserved.1-1 ICS 410: Programming Languages Chapter 3 : Describing Syntax and Semantics Axiomatic Semantics.
ISBN Chapter 3 Describing Syntax and Semantics.
1 Design by Contract with JML CS 3331 Fall 2009 Gary T. Leavens and Yoonsik Cheon. Design by Contract with JML. Available from
Formal Methods of Systems Specification Logical Specification of Hard- and Software Prof. Dr. Holger Schlingloff Institut für Informatik der Humboldt.
Copyright © 2006 The McGraw-Hill Companies, Inc. Programming Languages 2nd edition Tucker and Noonan Chapter 18 Program Correctness To treat programming.
ESC Java. Static Analysis Spectrum Power Cost Type checking Data-flow analysis Model checking Program verification AutomatedManual ESC.
Copyright © 2006 The McGraw-Hill Companies, Inc. Programming Languages 2nd edition Tucker and Noonan Chapter 18 Program Correctness To treat programming.
Software Testing and Quality Assurance
Copyright © 2006 The McGraw-Hill Companies, Inc. Programming Languages 2nd edition Tucker and Noonan Chapter 10 Function Implementation In theory, there.
JML and Class Specifications Class invariant JML definitions Queue example Running JML in Eclipse.
Queues CS-240 & CS-341 Dick Steflik. Queues First In, First Out operation - FIFO As items are added they are chronologically ordered, items are removed.
OOP #10: Correctness Fritz Henglein. Wrap-up: Types A type is a collection of objects with common behavior (operations and properties). (Abstract) types.
Copyright © 2006 The McGraw-Hill Companies, Inc. Programming Languages 2nd edition Tucker and Noonan Chapter 18 Program Correctness To treat programming.
Queues CS-240 & CS-341 Dick Steflik. Queues First In, First Out operation - FIFO As items are added they are chronologically ordered, items are removed.
Software Quality: Testing and Verification II. 2 1.A failure is an unacceptable behaviour exhibited by a system — The frequency of failures measures software.
Software Verification Bertrand Meyer Chair of Software Engineering Lecture 2: Axiomatic semantics.
Describing Syntax and Semantics
Proving Program Correctness The Axiomatic Approach.
Ranga Rodrigo. Class is central to object oriented programming.
Computer Science School of Computing Clemson University Discrete Math and Reasoning about Software Correctness Murali Sitaraman
Liang, Introduction to Java Programming, Seventh Edition, (c) 2009 Pearson Education, Inc. All rights reserved Chapter 18 Exception Handling.
Design by Contract in Java Concept and Comparison.
ISBN Chapter 3 Describing Semantics -Attribute Grammars -Dynamic Semantics.
Program Correctness. 2 Program Verification An object is a finite state machine: –Its attribute values are its state. –Its methods optionally: Transition.
Computer Science School of Computing Clemson University Discrete Math and Reasoning about Software Correctness Joseph E. Hollingsworth
Lab 7 Queue ADT. OVERVIEW The queue is one example of a constrained linear data structure. The elements in a queue are ordered from least recently added.
Today’s Agenda  Quick Review  Continue on JML Formal Methods in Software Engineering1.
A Survey on Java Modeling Languages Gergely Kovásznai,Eszterházy Károly College Wolfgang Schreiner,Johannes Kepler University Gábor Kusper,Eszterházy Károly.
Chapter 3 Part II Describing Syntax and Semantics.
Semantics In Text: Chapter 3.
COP4020 Programming Languages Introduction to Axiomatic Semantics Prof. Robert van Engelen.
13 Aug 2013 Program Verification. Proofs about Programs Why make you study logic? Why make you do proofs? Because we want to prove properties of programs.
Verificare şi Validarea Sistemelor Soft Tem ă Laborator 1 ESC/Java2 Extended Static Checker for Java Dat ă primire laborator: Lab 1 Dat ă predare laborator:
ANU COMP2110 Software Design in 2003 Lecture 10Slide 1 COMP2110 Software Design in 2004 Lecture 12 Documenting Detailed Design How to write down detailed.
L13: Design by Contract Definition Reliability Correctness Pre- and post-condition Asserts and Exceptions Weak & Strong Conditions Class invariants Conditions.
Principle of Programming Lanugages 3: Compilation of statements Statements in C Assertion Hoare logic Department of Information Science and Engineering.
Defensive Programming CNS 3370 Copyright 2003, Fresh Sources, Inc.
PROGRAMMING PRE- AND POSTCONDITIONS, INVARIANTS AND METHOD CONTRACTS B MODULE 2: SOFTWARE SYSTEMS 13 NOVEMBER 2013.
DBC NOTES. Design By Contract l A contract carries mutual obligations and benefits. l The client should only call a routine when the routine’s pre-condition.
Chapter 4 ADTs Stack and Queue. 4-2 Formal ADT Specifications The Java interface construct lets us collect together method interfaces into a syntactic.
1 Exceptions When the Contract is Broken. 2 Definitions A routine call succeeds if it terminates its execution in a state satisfying its contract A routine.
Reasoning and Design (and Assertions). How to Design Your Code The hard way: Just start coding. When something doesn’t work, code some more! The easier.
CORRECTNESS ISSUES AND LOOP INVARIANTS Lecture 8 CS2110 – Fall 2014.
© Bertrand Meyer and Yishai Feldman Notice Some of the material is taken from Object-Oriented Software Construction, 2nd edition, by Bertrand Meyer (Prentice.
Chapter 3 of Programming Languages by Ravi Sethi
Topics: jGRASP editor ideosyncrasies assert debugger.
Accessible Formal Methods A Study of the Java Modeling Language
Programming Languages 2nd edition Tucker and Noonan
Stateful Manifest Contracts
Lecture 5 Floyd-Hoare Style Verification
Axiomatic semantics Points to discuss: The assignment statement
Programming Languages 2nd edition Tucker and Noonan
Hoare-style program verification
Predicate Transformers
Java Modeling Language (JML)
Program correctness Axiomatic semantics
Programming Languages 2nd edition Tucker and Noonan
Programming Languages 2nd edition Tucker and Noonan
COP4020 Programming Languages
Presentation transcript:

Copyright © 2006 The McGraw-Hill Companies, Inc. Programming Languages 2nd edition Tucker and Noonan Chapter 18 Program Correctness To treat programming scientifically, it must be possible to specify the required properties of programs precisely. Formality is certainly not an end in itself. The importance of formal specifications must ultimately rest in their utility - in whether or not they are used to improve the quality of software or to reduce the cost of producing and maintaining software. J. Horning

Copyright © 2006 The McGraw-Hill Companies, Inc. Contents 18.1 Axiomatic Semantics 18.2 Formal Methods Tools: JML JML Exception Handling 18.3 Correctness of Object-Oriented Programs Design by Contract The Class Invariant Correctness of a Queue Application Final Observations 18.4 Correctness of Functional Programs

Copyright © 2006 The McGraw-Hill Companies, Inc. Review JML JML ExpressionMeaning requires p;p is a precondition for the call ensures p;p is a postcondition for the call signals (E e) p; when exception e is raised by the call, p is a postcondition loop_invariant p;p is a loop invariant invariant p;p is a class invariant \result == e;e is the result returned by the call \old v the value of v at entry to the call (\product int x ; p(x); e(x)) the product of e(x) for all x that satisfy p(x) (\sum int x ; p(x); e(x)) the sum of e(x) for all x that satisfy p(x) p ==> qp  q

Copyright © 2006 The McGraw-Hill Companies, Inc Design by Contract

Copyright © 2006 The McGraw-Hill Companies, Inc. The contract for a Queue class

Copyright © 2006 The McGraw-Hill Companies, Inc The Class Invariant A class C is formally specified if: 1. Every constructor and public method M in the classhas preconditions and postconditions, and 2. C has a special predicate called its class invariant INV which, for every object o in C, argument x and call o.M(x), must be true both before and after the call. Note: During a call, INV may temporarily become false. Why are we doing this??? i)Formal specifications provide a foundation for rigorous OO system design (e.g., “design by contract”). ii)They enable static and dynamic assertion checking of an entire OO system. iii)They enable formal correctness proof of an OO system.

Copyright © 2006 The McGraw-Hill Companies, Inc Correctness of a Queue Application public class Queue { private class Node { } private Node first = null; private Node last = null; private int n = 0; public void enqueue(Object v) { } public Object dequeue( ) {} public Object front() {} public boolean isEmpty() {} public int size() {} public void display() {} } state variables help define INV public methods M public constructor C = Queue() “helper” class

Copyright © 2006 The McGraw-Hill Companies, Inc. Adding Class-Level Specifications public model Node H, T; private represents H <- first; private represents T <- last; public invariant n == private Node first = null; private Node last = null; private int n = 0; more JML JML model variables class invariant INV Notes: 1) JML model variables allow a specification to distance itself from the class’s implementation details. 2) spec_public allows JML specifications to treat a Java variable as public without forcing the code to do the same.

Copyright © 2006 The McGraw-Hill Companies, Inc. Adding Method Specifications ensures T.prior == \old(T) && H.prior == null && T.val.equals(v) public void enqueue(Object v) { last = new Node(v, last, null); if (first == null) first = last; else (last.prior).next = last; n = n+1; } Notes: 1) \old denotes the value of T at entry to enqueue. 2)The ensures clause specifies that enqueue adds v to the tail T, and that the head H is not affected.

Copyright © 2006 The McGraw-Hill Companies, Inc. What specifications for public Object dequeue( ) { Object result = first.val; first = first.next; if (first != null) first.prior = null ; else last = null; n = n-1; return result; }

Copyright © 2006 The McGraw-Hill Companies, Inc. “Pure” methods requires n > 0; ensures \result == H.val && H == public Object front() { return first.val; } Note: A method is pure if: 1) it has no non-local side effects, and 2) it is provably non-looping.

Copyright © 2006 The McGraw-Hill Companies, Inc. Test driving the Queue class public class QueueTest { public static void main(String[] args) { Queue q = new Queue(); int val; int n = Integer.parseInt(args[0]); for (int i=1; i <= n; i++) q.enqueue(args[i]); System.out.print("Queue contents = "); q.display(); System.out.println("Is Queue empty? " + q.isEmpty()); System.out.println("Queue size = " + q.size()); while (! q.isEmpty()) { System.out.print(" dequeue " + q.dequeue()); System.out.print(" Queue contents = "); q.display(); } System.out.println("Is Queue empty now? " + q.isEmpty()); }

Copyright © 2006 The McGraw-Hill Companies, Inc. Contract test 1: normal run % jmlrac QueueTest Queue contents = last --> <-- first Is Queue empty? false Queue size = 5 dequeue 1 Queue contents = last --> <-- first dequeue 2 Queue contents = last --> <-- first dequeue 3 Queue contents = last --> 5 4 <-- first dequeue 4 Queue contents = last --> 5 <-- first dequeue 5 Queue contents = last --> <-- first Is Queue empty now? true %

Copyright © 2006 The McGraw-Hill Companies, Inc. Contract test 2: precondition violation Queue contents = last --> <-- first … dequeue 4 Queue contents = last --> 5 <-- first dequeue 5 Queue contents = last --> <-- first Exception in thread "main" org.jmlspecs.jmlrac.runtime.JMLEntryPreconditionError: by method Queue.dequeue regarding specifications at File "../../home/allen/Desktop/workspace/myQueueTest/myqueuetest/ Queue.java", line 36, character 29 when 'this' is at myqueuetest.Queue.checkPre$dequeue$Queue(Queue.java:626) at myqueuetest.Queue.dequeue(Queue.java:771) at myqueuetest.QueueTest.main(QueueTest.java:16) Note: blame is with the caller QueueTest, since a precondition has been violated.

Copyright © 2006 The McGraw-Hill Companies, Inc. Contract test 3: postcondition violation Note: blame is with the supplier Queue, since a postcondition has been violated. Queue contents = last --> <-- first Is Queue empty? False Exception in thread "main" org.jmlspecs.jmlrac.runtime. JMLNormalPostconditionError: by method Queue.dequeue regarding specifications at File "../../home/allen/Desktop/workspace/ myQueueTest/myqueuetest/Queue.java", line 37, character 52 when '\old(H)' is '\result' is 5 'this' is …

Copyright © 2006 The McGraw-Hill Companies, Inc. Contract test 4: invariant error % jmlrac QueueTest Exception in thread "main" org.jmlspecs.jmlrac.runtime.JMLInvariantError: by method "../../home/allen/Desktop/workspace/ myQueueTest/myqueuetest/Queue.java", line 28, character 24> regarding specifications at File "../../home/allen/Desktop/workspace/myQueueTest/ myqueuetest/Queue.java", line 22, character 38 … Note: blame is again with the supplier Queue, since an invariant has been violated.

Copyright © 2006 The McGraw-Hill Companies, Inc. Class and System Correctness So far, we have only done testing; what about formal verification? 1. A class C is (formally) correct if: a. It is formally specified, and b. For every object o and every constructor and public method M in the class, the Hoare triple is valid for every argument x. 2. A system is correct if all its classes are correct.

Copyright © 2006 The McGraw-Hill Companies, Inc. E.g., Correctness of dequeue() requires n > 0; ensures \result.equals(\old(H).val) && H == public Object dequeue( ) { Object result = first.val; first = first.next; if (first != null) first.prior = null ; To prove: else last = null; n = n-1; where: return result; } Note: We again use rules of inference and reason through the code, just like we did with Factorial

Copyright © 2006 The McGraw-Hill Companies, Inc. A “loose” correctness proof for dequeue() 1.“Loose” because a.We assume the validity of size(), and b.We omit some details. 2.The assignments in dequeue(), together with, ensure the validity of : a.Steps 1 and 7 establish \result = \old(first).val b.Steps 2-5 establish first = \old(first).next c.Step 6 and our assumption establish n = size(): I.e., n = \old(n) -1 and size() = \old(size()) -1 So, n = size(), since \old(n) = \old(size())

Copyright © 2006 The McGraw-Hill Companies, Inc Final Observations 1.Formal verification: a.is an enormous task for large programs. b.only proves that specifications and code agree. c.only proves partial correctness (assumes termination). 2.Tools exist for: a. Statically checking certain run-time properties of Java programs (ESC/Java2) b. formally verifying Ada programs (Spark) 3.Tools are being developed to help with formal verification of Java programs (Diacron, LOOP) 4. What is the cost/benefit of formal methods?