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 11 Memory Management C makes it easy to shoot.
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.
Design By Contract Using JMSAssert.
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.
De necessariis pre condiciones consequentia sine machina P. Consobrinus, R. Consobrinus M. Aquilifer, F. Oratio.
Semantics Static semantics Dynamic semantics attribute grammars
ICE1341 Programming Languages Spring 2005 Lecture #6 Lecture #6 In-Young Ko iko.AT. icu.ac.kr iko.AT. icu.ac.kr Information and Communications University.
Data Abstraction II SWE 619 Software Construction Last Modified, Spring 2009 Paul Ammann.
David Evans CS655: Programming Languages University of Virginia Computer Science Lecture 19: Minding Ps & Qs: Axiomatic.
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.
Copyright © 2006 Addison-Wesley. All rights reserved. 3.5 Dynamic Semantics Meanings of expressions, statements, and program units Static semantics – type.
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.
Copyright © 2006 The McGraw-Hill Companies, Inc. Programming Languages 2nd edition Tucker and Noonan Chapter 18 Program Correctness To treat programming.
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
Static and Dynamic Contract Verifiers For Java Hongming Liu.
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.
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.
CHAPTER 6 Stacks Array Implementation. 2 Stacks A stack is a linear collection whose elements are added and removed from one end The last element to be.
Software Quality: Testing and Verification II. 2 1.A failure is an unacceptable behaviour exhibited by a system — The frequency of failures measures software.
Describing Syntax and Semantics
Subclasses and Subtypes CMPS Subclasses and Subtypes A class is a subclass if it has been built using inheritance. ▫ It says nothing about the meaning.
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
Lecture 16 March 22, 2011 Formal Methods CS 315 Spring Adapted from slides provided by Jason Hallstrom and Murali Sitaraman (Clemson)
ISBN Chapter 3 Describing Semantics -Attribute Grammars -Dynamic Semantics.
Computer Science School of Computing Clemson University Discrete Math and Reasoning about Software Correctness Joseph E. Hollingsworth
Today’s Agenda  Quick Review  Continue on JML Formal Methods in Software Engineering1.
CS Data Structures I Chapter 2 Principles of Programming & Software Engineering.
Nyhoff, ADTs, Data Structures and Problem Solving with C++, Second Edition, © 2005 Pearson Education, Inc. All rights reserved Stacks.
Chapter 3 Part II Describing Syntax and Semantics.
Semantics In Text: Chapter 3.
ANU COMP2110 Software Design in 2003 Lecture 10Slide 1 COMP2110 Software Design in 2004 Lecture 12 Documenting Detailed Design How to write down detailed.
Lab 6 Stack ADT. OVERVIEW The stack is one example of a constrained linear data structure. In a stack, the elements are ordered from most recently added.
L13: Design by Contract Definition Reliability Correctness Pre- and post-condition Asserts and Exceptions Weak & Strong Conditions Class invariants Conditions.
(1) ICS 313: Programming Language Theory Chapter 11: Abstract Data Types (Data Abstraction)
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.
The Java Assertion. 2 Assertion A Java statement in JDK 1.4 & newer Intent: enables code to test assumptions. E.g., a method that calculates the a particle’s.
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.
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.
© Bertrand Meyer and Yishai Feldman Notice Some of the material is taken from Object-Oriented Software Construction, 2nd edition, by Bertrand Meyer (Prentice.
SWEN421 – Lecture 3 Building High Integrity Software with SPARK Ada
Design by Contract Jim Fawcett CSE784 – Software Studio
Design by Contract Jim Fawcett CSE784 – Software Studio
Topics: jGRASP editor ideosyncrasies assert debugger.
Accessible Formal Methods A Study of the Java Modeling Language
Programming Languages 2nd edition Tucker and Noonan
Programming Languages 2nd edition Tucker and Noonan
Design by contract Object-Oriented Software Construction by Bertrand Meyer, Prentice Hall The presence of a precondition or postcondition in a routine.
Hoare-style program verification
SWE 619 Software Construction Last Modified, Fall 2015 Paul Ammann
COMPUTER 2430 Object Oriented Programming and Data Structures I
Design by contract Object-Oriented Software Construction by Bertrand Meyer, Prentice Hall The presence of a precondition or postcondition in a routine.
Java Modeling Language (JML)
Assertions References: internet notes; Bertrand Meyer, Object-Oriented Software Construction; 4/25/2019.
CSE 1020:Software Development
Programming Languages 2nd edition Tucker and Noonan
Programming Languages 2nd edition Tucker and Noonan
Formal Methods Lecture 16 March 22, 2011 CS 315 Spring 2011
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 Stack 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 Stack Application public class Stack { private class Node { } private Node theStack = null; private int n = 0; public void push(int v) { } public int pop( ) {} public int top() {} public boolean isEmpty() {} public int size() {} } state variables help define INV public methods M public constructor C = Stack() helper class

Copyright © 2006 The McGraw-Hill Companies, Inc. Adding Class-Level Specifications public model Node S; private represents S <- theStack; public invariant S == null || n == private Node theStack = null; private int n = 0; more JML JML model variable class invariant INV Notes: 1) JML model variables allow a specification to distance itself from the classs 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 requires n > 0; ensures \result==\old(S).val && S==\old(S).next && public int pop( ) { int result = theStack.val; theStack = theStack.next; n = n-1; return result; } Notes: 1) \old denotes the value of S at entry to pop. 2)The ensures clause specifies that pop removes the top element and returns it.

Copyright © 2006 The McGraw-Hill Companies, Inc. Similar specifications for push ensures S.next==\old(S) && S.val==v; public void push(int v) { theStack = new Node(v, theStack); n = n+1; }

Copyright © 2006 The McGraw-Hill Companies, Inc. Pure methods requires n > 0; ensures \result==S.val && S == public int top() { return theStack.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 MyStack class public class myStackTest { public static void main(String[] args) { MyStack s = new MyStack(); int val; for (int i=0; i<args.length; i++) s.push(Integer.parseInt(args[i])); System.out.println("Stack size = " + s.size()); System.out.print("Stack contents ="); for (int i=1; i<=n; i++) { System.out.print(" " + s.top( )); s.pop( ); } System.out.println( ); System.out.println("Is Stack empty? " + s.isEmpty( )); }

Copyright © 2006 The McGraw-Hill Companies, Inc. Contract test 1: normal run % jmlrac myStackTest Stack size = 3 Stack contents = Is Stack empty? true %

Copyright © 2006 The McGraw-Hill Companies, Inc. Contract test 2: postcondition violation Exception in thread "main" org.jmlspecs.jmlrac.runtime.JMLNormalPostconditionError: by method MyStack.top regarding specifications at File "MyStack.java", line 31, character 26 when '\old(S)' is '\result' is 5 'this' is at MyStack.checkPost$top$MyStack(MyStack.java:999) at MyStack.top(MyStack.java:1078) at myStackTest.main(MyStackTest.java:15) Note: blame is with the callee MyStack, since a postcondition has been violated.

Copyright © 2006 The McGraw-Hill Companies, Inc. Contract test 3: invariant error Stack size = 3 Stack contents = 6 Exception in thread "main" org.jmlspecs.jmlrac.runtime.JMLInvariantError: by method "MyStack.java", line 16, character 17> regarding specifications at File "MyStack.java", line 11, character 30 when 'this' is at MyStack.checkInv$instance$MyStack(MyStack.java:102) at MyStack.pop(MyStack.java:525) at myStackTest.main(MyStackTest.java:21) Note: blame is again with the callee MyStack, since an invariant has been violated.

Copyright © 2006 The McGraw-Hill Companies, Inc. Contract test 4: precondition violation Note: blame is with the caller MyQueueTest, since a precondition has been violated. Stack size = 3 Stack contents = Is Stack empty? true Exception in thread "main" org.jmlspecs.jmlrac.runtime.JMLEntryPreconditionError: by method MyStack.pop regarding specifications at File "MyStack.java", line 16, character 21 when 'this' is at MyStack.checkPre$pop$MyStack(MyStack.java:330) at MyStack.pop(MyStack.java:479) at myStackTest.main(MyStacktest.java:24)

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. Correctness of pop() requires n > 0; ensures \result==\old(S).val && S==\old(S).next && public int pop( ) { int result = theStack.val; theStack = theStack.next; n = n-1; return result; } INV: n = size() P INV: n > 0 n = size() Q INV: result = old(S).val S = old(S).next n = size()

Copyright © 2006 The McGraw-Hill Companies, Inc. 1.Loose because a.We assume the validity of size(), and b.We omit some details. 2.The assignments in pop (), together with, ensure the validity of : a.Steps 1 and 4 establish \result = \old(S).val b.Step 2 establishes S = \old(S).next c.Step 3 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()) A loose correctness proof for pop()

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?