Static and Dynamic Contract Verifiers For Java Hongming Liu.

Slides:



Advertisements
Similar presentations
Where Agile Meets Formal Methods
Advertisements

Copyright © 2006 The McGraw-Hill Companies, Inc. Programming Languages 2nd edition Tucker and Noonan Chapter 18 Program Correctness To treat programming.
Automated Theorem Proving Lecture 1. Program verification is undecidable! Given program P and specification S, does P satisfy S?
Design by Contract.
Copyright W. Howden1 Programming by Contract CSE 111 6/4/2014.
Design By Contract Using JMSAssert.
Building Bug-Free O-O Software: An Introduction to Design By Contract A presentation about Design By Contract and the Eiffel software development tool.
Carlos D. Rivera February 28, 2007 Design-by-Contract.
Karlstad University Computer Science Design Contracts and Error Management Design Contracts and Errors A Software Development Strategy Eivind J. Nordby.
Verifying Executable Object-Oriented Specifications with Separation Logic Stephan van Staden, Cristiano Calcagno, Bertrand Meyer.
ISBN Chapter 3 Describing Syntax and Semantics.
Feb 2003 R McFadyen1 Contracts (Ch 13) Used to help understand requirements more completely based on assertions; assertions are applicable to any.
Jan 2005 Ron McFadyen1 Contracts Used to help understand requirements more completely (and so may not always be necessary) based on assertions;
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.
1 Specifying Object Interfaces. 2 Major tasks in this stage: --are there any missing attributes or operations? --how can we reduce coupling, make interface.
Software Testing and Quality Assurance
Chair of Software Engineering Einführung in die Programmierung Introduction to Programming Prof. Dr. Bertrand Meyer Lecture 4: The Interface of a Class.
Chair of Software Engineering Einführung in die Programmierung Introduction to Programming Prof. Dr. Bertrand Meyer Lecture 4: The Interface of a Class.
OOP #10: Correctness Fritz Henglein. Wrap-up: Types A type is a collection of objects with common behavior (operations and properties). (Abstract) types.
ESC Java. Static Analysis Spectrum Power Cost Type checking Data-flow analysis Model checking Program verification AutomatedManual ESC.
Page 1 Building Reliable Component-based Systems Chapter 6 - Semantic Integrity in Component Based Development Chapter 6 Semantic Integrity in Component.
September 2002 R McFadyen1 Domain Model Use Case Model text diagram SSD System operation contracts Design Model Figure 13.3.
Design by Contract David Talby. Software Correctness When is a class correct? – It ’ s a relative concept; what is required? – But it ’ s the correct.
Chair of Software Engineering Automatic Verification of Computer Programs.
Describing Syntax and Semantics
Eiffel Language and Design by Contract Contract –An agreement between the client and the supplier Characteristics –Expects some benefits and is prepared.
Adding Contracts to Ada Ehud Lamm Adding Design By Contract to Ada.
Sept Ron McFadyen1 Extend Relationship.
1 © Wolfgang Pelz Design by Contract Design by Contract™ Based on material drawn from: Bertrand.
Computer Science 340 Software Design & Testing Design By Contract.
Component-Based Software Engineering Components and Interfaces Paul Krause.
Ranga Rodrigo. Class is central to object oriented programming.
Pre/Post Condition Logic 03/06/2013. Agenda Hoare’s Logic Overview Application to Pre/Post Conditions.
Introduction Ellen Walker CPSC 201 Data Structures Hiram College.
Contract based programming Using pre- and post-conditions, and object invariants Contract based programming1.
Tammy Dahlgren with Tom Epperly, Scott Kohn, and Gary Kumfert Center for Applied Scientific Computing Common Component Architecture Working Group October.
Design by Contract in Java Concept and Comparison.
More About Classes Ranga Rodrigo. Information hiding. Copying objects.
CS 261 – Data Structures Preconditions, Postconditions & Assert.
OOSC - JMSAssert. Design By Contract A powerful technique for writing reliable software. Specifying the software purpose with the implementation. Key.
(c) University of Washington15-1 CSC 143 Java List Implementation via Arrays Reading: 13.
Semantics In Text: Chapter 3.
Pre- and postconditions, Using assertions and exceptions 1 Pre- and postconditions Using assertions and exceptions.
Computer Science 209 Software Development Handing Errors and Creating Documentation.
Class Design I Class Contracts Readings: 2 nd Ed: Section 9.5, Advanced Topic nd Ed: Section 8.5, Advanced Topic 8.2 Some ideas come from: “Practical.
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.
SWE 4743 Abstract Data Types Richard Gesick. SWE Abstract Data Types Object-oriented design is based on the theory of abstract data types Domain.
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.
Static Techniques for V&V. Hierarchy of V&V techniques Static Analysis V&V Dynamic Techniques Model Checking Simulation Symbolic Execution Testing Informal.
/ PSWLAB Evidence-Based Analysis and Inferring Preconditions for Bug Detection By D. Brand, M. Buss, V. C. Sreedhar published in ICSM 2007.
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.
Object Design More Design Patterns Object Constraint Language Object Design Specifying Interfaces Review Exam 2 CEN 4010 Class 18 – 11/03.
Design by Contract. The Goal Ensure the correctness of our software (correctness) Recover when it is not correct anyway (robustness) Correctness: Assertions.
© Bertrand Meyer and Yishai Feldman Notice Some of the material is taken from Object-Oriented Software Construction, 2nd edition, by Bertrand Meyer (Prentice.
CSE 374 Programming Concepts & Tools Hal Perkins Fall 2015 Lecture 17 – Specifications, error checking & assert.
Design by Contract Jim Fawcett CSE784 – Software Studio
Design by Contract Jim Fawcett CSE784 – Software Studio
Used to help understand requirements more completely
Topics: jGRASP editor ideosyncrasies assert debugger.
Software Development Handing Errors and Creating Documentation
CSE 143 Error Handling [Section 2.8] 3/30/98 CSE 143.
Design by Contract in Python: Present and Future Aaron Bingham
Specifying Object Interfaces
Assertions References: internet notes; Bertrand Meyer, Object-Oriented Software Construction; 4/25/2019.
Computer Science 340 Software Design & Testing
Programming Languages 2nd edition Tucker and Noonan
Design Contracts and Errors A Software Development Strategy
Presentation transcript:

Static and Dynamic Contract Verifiers For Java Hongming Liu

Agenda Introduction to Design by Contract. Existing Design by Contract solutions. Our Design by Contract toolset.

Design by Contract Design by Contract (DBC) theory suggests associating a specification with every software element. These specifications (or contracts) govern the interaction of the element with the rest of the world. Component of a system communicate with one another on the basis of precisely defined benefits and obligations.

Design by Contract Contract tags are specified as comments: an example from the java.lang.String class: /** index >= 0 index < this.length() */ char charAt(int index){…} Three types of basic contract tags: Method preconditions. Method postconditions. Class invariants.

Design by Contract – Tags Three tag types standard to DBC solutions: Method precondition a boolean expression assumed to be true whenever the method is called. Method postcondition a boolean expression assumed to be true when the method returns. Class invariant a boolean expression that can assumed to be true in all instances when the point of execution is not in a transit state.

Design by Contract Sets forth a system of obligations and benefits. The client has the obligation to satisfy the preconditions of a method before calling that method. The supplier of the method has the obligation to satisfy the postconditions of the method before returning from that method. Both receive the benefit of input or output values that are guaranteed to comply to the contract.

Design by Contract – Tags Three extended tags found in our DBC solution: Assert assertion for a statement, equivalent to the Java assert. Fact fact that is guaranteed to hold for a statement. Loop invariant Invariant that holds for each iteration of a loop.

Design by Contract - Benefits Gives a better understanding of software construction. A systematic approach to building bug-free object- oriented systems. A method for documenting software components. An effective framework for debugging, testing, and quality assurance. Better understanding and control of the inheritance mechanism. A technique for dealing with abnormal cases, leading to an effective language construct for exception handling.

Design by Contract Existing Tools include: JDK 1.4 (assert) iContract JMSAssert Eiffel

Our DBC Toolset Components of our DBC Toolset: DocGen – generates documentation (Javadoc) that includes DBC information. ContractChecker – creates modified versions of Java classes with additional code that is used for runtime checking of the contract. Static Contract Verifier – statically checks Java code for specific problems, such a possible null- pointer exceptions, array out of bounds exceptions, or contract adherence at compile-time (Static Contract Verification).

Our DBC Toolset Advantages of our DBC Toolset: Uses a specified syntax with high expressiveness. DocGen provides documentation that includes contract information. Static Analysis provides a partial alternative to time-consuming runtime checking with Static Analysis and Static Contract Verification.

Static Contract Verification Uses a weakest precondition algorithm. /** * weakest precondition: this.x >=1 this.x >= 2 this’.x >= 0 */ public void decrementX() { this.x = this.x - 1; }

Example – Contract Generation /** * From a hypothetical Stack class. this.size >= 1 this'.size == this.size - 1 */ public Object pop() { Object e = this.stack[this.size - 1]; this.size = this.size - 1; return e; }

Generated Code - Part 1 of 2 public Object pop() { if (!(this.size >= 1)) { Contract contract = Contract.getInstance(); contract.reportViolation(new PreconditionException("PreconditionException.o ccurs:.the.precondition.contract.is.violated:")); } Object e = this.stack[this.size - 1]; this.size = this.size - 1; Object _$$_return = e; /* continued… */

Generated Code - Part 2 of 2 if (!(this.size == _pre$$_this.size - 1)) { Contract contract = Contract.getInstance(); contract.reportViolation(new PostconditionException("PostconditionException. occurs:.the.postcondition.contract.is.violated:")); } return _$$_return; }

Miscellaneous Thank you to Dr. Jia, Frank Qin, and Jing Wang. Project website is at: Questions?