Spec# Andreas Vida. Motivation Correct and maintainable software Correct and maintainable software Cost effective software production Cost effective software.

Slides:



Advertisements
Similar presentations
Joint work with Mike Barnett, Robert DeLine, Manuel Fahndrich, and Wolfram Schulte Verifying invariants in object-oriented programs K. Rustan M. Leino.
Advertisements

Copyright © 2006 The McGraw-Hill Companies, Inc. Programming Languages 2nd edition Tucker and Noonan Chapter 18 Program Correctness To treat programming.
The Spec# programming system K. Rustan M. Leino Microsoft Research, Redmond, WA, USA Lunch seminar, Praxis Bath, UK 6 Dec 2005 joint work with Mike Barnett,
Object Invariants in Specification and Verification K. Rustan M. Leino Microsoft Research, Redmond, WA Joint work with: Mike Barnett, Ádám Darvas, Manuel.
Writing specifications for object-oriented programs K. Rustan M. Leino Microsoft Research, Redmond, WA, USA 21 Jan 2005 Invited talk, AIOOL 2005 Paris,
Program Verification Using the Spec# Programming System ETAPS Tutorial K. Rustan M. Leino, Microsoft Research, Redmond Rosemary Monahan, NUIM Maynooth.
Technologies for finding errors in object-oriented software K. Rustan M. Leino Microsoft Research, Redmond, WA Lecture 0 Summer school on Formal Models.
Spec# K. Rustan M. Leino Senior Researcher Programming Languages and Methods Microsoft Research, Redmond, WA, USA Microsoft Research faculty summit, Redmond,
Automated Theorem Proving Lecture 1. Program verification is undecidable! Given program P and specification S, does P satisfy S?
Lecture 4 Towards a Verifying Compiler: Data Abstraction Wolfram Schulte Microsoft Research Formal Methods 2006 Purity, Model fields, Inconsistency _____________.
Challenges in increasing tool support for programming K. Rustan M. Leino Microsoft Research, Redmond, WA, USA 23 Sep 2004 ICTAC Guiyang, Guizhou, PRC joint.
Copyright W. Howden1 Programming by Contract CSE 111 6/4/2014.
Rigorous Software Development CSCI-GA Instructor: Thomas Wies Spring 2013 Lecture 5 Disclaimer. These notes are derived from notes originally.
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.
Modular and Verified Automatic Program Repair Francesco Logozzo, Thomas Ball RiSE - Microsoft Research Redmond.
The Spec# programming system K. Rustan M. Leino Microsoft Research, Redmond, WA, USA Distinguished Lecture Series Max Planck Institute for Software Systems.
Abstraction and Modular Reasoning for the Verification of Software Corina Pasareanu NASA Ames Research Center.
Automated Software Verification with a Permission-Based Logic 20 th June 2014, Zürich Malte Schwerhoff, ETH Zürich.
The Java Modeling Language JML Erik Poll Digital Security Radboud University Nijmegen.
K. Rustan M. Leino Research in Software Engineering (RiSE) Microsoft Research, Redmond, WA, USA 3 December 2008 U. Lugano Lugano, Switzerland.
Dept. of Computer Science A Runtime Assertion Checker for the Java Modeling Language (JML) Yoonsik Cheon and Gary T. Leavens SERP 2002, June 24-27, 2002.
Formal Methods of Systems Specification Logical Specification of Hard- and Software Prof. Dr. Holger Schlingloff Institut für Informatik der Humboldt.
ECI 2007: Specification and Verification of Object-Oriented Programs Lecture 2 Courtesy: K. Rustan M. Leino and Wolfram Schulte.
Lecture 2 Towards a Verifying Compiler: Logic of Object oriented Programs Wolfram Schulte Microsoft Research Formal Methods 2006 Objects, references, heaps,
An overview of JML tools and applications Lilian Burdy Gemplus Yoonsik Cheon, Gary Leavens Iowa Univ. David Cok Kodak Michael Ernst MIT Rustan Leino Microsoft.
Introduction to Spec# Programming System Yossi Peery Advanced SW Tools Seminar TAU Nov 2006.
Software Testing and Quality Assurance
Static and Dynamic Contract Verifiers For Java Hongming Liu.
Chair of Software Engineering Einführung in die Programmierung Introduction to Programming Prof. Dr. Bertrand Meyer Lecture 6: Object Creation.
Managed Assertions : language-neutral behavioral contracts for components 2 nd Rotor Workshop 25 April 2003 Nam Tran Monash University
Building a program verifier K. Rustan M. Leino Microsoft Research, Redmond, WA 10 May 2006 Guest lecture, Shaz Qadeer’s cse599f, Formal Verification of.
OOP #10: Correctness Fritz Henglein. Wrap-up: Types A type is a collection of objects with common behavior (operations and properties). (Abstract) types.
K. Rustan M. Leino Microsoft Research, Redmond, WA, USA with Mike Barnett, Robert DeLine, Manuel Fahndrich, and Wolfram Schulte Toward enforceable contracts.
Chair of Software Engineering Einführung in die Programmierung Introduction to Programming Prof. Dr. Bertrand Meyer Lecture 6: Object Creation.
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.
Well-cooked Spaghetti: Weakest-Precondition of Unstructured Programs Mike Barnett and Rustan Leino Microsoft Research Redmond, WA, USA.
Chair of Software Engineering Automatic Verification of Computer Programs.
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.
Platforms and tools for Web Services and Mobile Applications Introduction to C# Bent Thomsen Aalborg University 3rd and 4th of June 2004.
Computer Science 340 Software Design & Testing Design By Contract.
Ranga Rodrigo. Class is central to object oriented programming.
Software Engineering Prof. Dr. Bertrand Meyer March 2007 – June 2007 Chair of Software Engineering Static program checking and verification Slides: Based.
1 Debugging and Testing Overview Defensive Programming The goal is to prevent failures Debugging The goal is to find cause of failures and fix it Testing.
Contract based programming Using pre- and post-conditions, and object invariants Contract based programming1.
1 Assertions. 2 assertions communicate assumptions about the state of the program, and stop processing if they turn out to be false very often comments.
Refactoring Improving the structure of existing code Refactoring1.
Design by Contract in Java Concept and Comparison.
Today’s Agenda  Quick Review  Continue on JML Formal Methods in Software Engineering1.
K. Rustan M. Leino Microsoft Research, Redmond, WA, USA with Mike Barnett, Robert DeLine, Manuel Fahndrich, and Wolfram Schulte Spec# Writing and checking.
Pre- and postconditions, Using assertions and exceptions 1 Pre- and postconditions Using assertions and exceptions.
Specifying and verifying programs in Spec# K. Rustan M. Leino Microsoft Research, Redmond, WA, USA Invited talk, PSI 2006 Novosibirsk, Russia 27 June 2006.
SWE 4743 Abstract Data Types Richard Gesick. SWE Abstract Data Types Object-oriented design is based on the theory of abstract data types Domain.
PROGRAMMING PRE- AND POSTCONDITIONS, INVARIANTS AND METHOD CONTRACTS B MODULE 2: SOFTWARE SYSTEMS 13 NOVEMBER 2013.
Microsoft Code Contracts How to program Pre-conditions, Post-conditions, and Object Invariants Microsoft Code Contracts1.
Extended Static Checking for Java Cormac Flanagan Joint work with: Rustan Leino, Mark Lillibridge, Greg Nelson, Jim Saxe, and Raymie Stata Compaq Systems.
1 Verification of object-oriented programs with invariants Mike Barnett, Robert DeLine, Manuel Fahndrich, K. Rustan M. Leino, Wolfram Schulte ECOOP 2003.
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.
Reasoning about object structures with Spec# K. Rustan M. Leino Microsoft Research, Redmond, WA Joint work with: Mike Barnett, Ádám Darvas, Manuel Fähndrich,
CSC 520 – Advanced Object Oriented Programming, Fall, 2010 Thursday, September 30 Week 5, Generics and Inheritance Techniques, Meyer Ch. 10 & 16.
Interfaces CMSC 202. Public Interfaces Objects define their interaction with the outside world through the their public interface. A class' public interface.
Design by Contract Jim Fawcett CSE784 – Software Studio
Weakest Precondition of Unstructured Programs
Accessible Formal Methods A Study of the Java Modeling Language
Spec# Writing and checking contracts in a .NET language
Hoare-style program verification
Java Modeling Language (JML)
Aditya Mangipudi Niharika Pamu Srikanth Polisetty
Assertions References: internet notes; Bertrand Meyer, Object-Oriented Software Construction; 4/25/2019.
Computer Science 340 Software Design & Testing
Presentation transcript:

Spec# Andreas Vida

Motivation Correct and maintainable software Correct and maintainable software Cost effective software production Cost effective software production Implicit assumptions easily broken → Need more formal specification Implicit assumptions easily broken → Need more formal specification Integration into a popular language Integration into a popular language

What has been done before Pioneering languages Pioneering languages GipsyGipsy EuclidEuclid More recent developments More recent developments EiffelEiffel SPARKSPARK JMLJML

Now: Spec# Extension of C# (Microsoft Research) that provides: Extension of C# (Microsoft Research) that provides: A sound programming methodologyA sound programming methodology Tools to enforce this methodologyTools to enforce this methodology Smooth adoption path for new-comersSmooth adoption path for new-comers

Components of Spec# Boogie static-verifier Boogie static-verifier Spec# compiler Spec# compiler Emits run-time checksEmits run-time checks Integration into Visual Studio Integration into Visual Studio IntelliSense code completionIntelliSense code completion Syntax HighlightingSyntax Highlighting

Spec# language features non-null types non-null types checked exceptions checked exceptions class contracts (object invariants) class contracts (object invariants) method contracts method contracts pre- and (exceptional) postconditionspre- and (exceptional) postconditions frame conditions frame conditions inheritance of specification inheritance of specification

Non-null types Notation: T! Notation: T! Constructors need initialiser-fields for each non- null field → evaluated before base-class-constructor call! Constructors need initialiser-fields for each non- null field → evaluated before base-class-constructor call! class Student: Person { Transcript! t; public Student(string name, EnrollmentInfo! e): t(new Transcript(e)), base(name) { /*…*/} //…}

Checked vs. unchecked exceptions C# only has unchecked exceptions C# only has unchecked exceptions Spec# in this way similar to Java Spec# in this way similar to Java Considers 2 types of exceptions: Considers 2 types of exceptions: Admissible failures → interface: ICheckedExceptionAdmissible failures → interface: ICheckedException Client failures, observed program errors → derived from: ExceptionClient failures, observed program errors → derived from: Exception

Method contracts Preconditions example: Preconditions example: class ArrayList { public virtual void Insert(int index, object value) requires 0 <= index && index <= Count; requires !IsReadOnly && !IsFixedSize; { /* … */ } //…}

Preconditions Enforced by run-time checks that throw a RequiresViolationException Enforced by run-time checks that throw a RequiresViolationException An alternative exception type can be specified using an otherwise clause: An alternative exception type can be specified using an otherwise clause: class A { class A { public void Foo(int a) requires a > 0 otherwise ArgumentOutOfRangeException; { /* … */ } }

Postconditions ArrayList.Insert’s postconditions: ArrayList.Insert’s postconditions: ensures Count == old(Count) + 1; ensures value == this[index]; ensures Forall{ int i in 0: index; old(this[i]) == this[i]}; ensures Forall{ int i in index: old(Count); old(this[i]) == this[i+1]} Complex quantified expressions supported Complex quantified expressions supported Boogie attempts to verify postconditions Boogie attempts to verify postconditions Eiffel’s mechanism: old() are saved away at the method’s entrance Eiffel’s mechanism: old() are saved away at the method’s entrance

Exceptional postconditions Methods have a throws-set (as in Java) Methods have a throws-set (as in Java) throws clause (only for checked exceptions) can be combined with postconditions: throws clause (only for checked exceptions) can be combined with postconditions: void ReadToken(ArrayList a) throws EndOfFileException ensures a.Count == old(a.Count); throws EndOfFileException ensures a.Count == old(a.Count); { /*… */ } “Foolproof”: if static checks can’t ensure that the exception is checked then run-time checks are emitted “Foolproof”: if static checks can’t ensure that the exception is checked then run-time checks are emitted

Class contracts Object invariants: Object invariants: class AttendanceRecord { Student[]! students; bool[]! absent; invariant students.Length == absent.Length; /*…*/ /*…*/} Often need to be temporarily broken → do this explicitely: expose (variable) { … }; Often need to be temporarily broken → do this explicitely: expose (variable) { … };

Frame conditions Restrict which part of the program state can be modified by a method Restrict which part of the program state can be modified by a method class C { int x, y; void M() modifies x; { x++; } } How to change private parts of an outside class? → wildcards: modifies this ^ ArrayList; How to change private parts of an outside class? → wildcards: modifies this ^ ArrayList; Still a problem: aggregate objects Still a problem: aggregate objects

Run-time checking Pre- and postconditions are turned into (tagged) inlined code Pre- and postconditions are turned into (tagged) inlined code Conditions violated at run-time → appropriate contract exception Conditions violated at run-time → appropriate contract exception 1 method is added to each class using invariants 1 method is added to each class using invariants Object fields added: Object fields added: invariant levelinvariant level owner of an objectowner of an object

Boogie: Static verification Intermediate language → BoogiePL Intermediate language → BoogiePL Inference system Inference system Obtains properties (loop invariants) then adds assert/assume statementsObtains properties (loop invariants) then adds assert/assume statements Creates acyclic control flow graph by introducing havoc statements Creates acyclic control flow graph by introducing havoc statements Calls the “Simplify” theorem prover Calls the “Simplify” theorem prover Maps results back onto source code Maps results back onto source code

Future plans Out-of-band specification Out-of-band specification Add specification for the.NET base class library → semi-automaticallyAdd specification for the.NET base class library → semi-automatically Provide Transformations: Provide Transformations: Contracts to natural languageContracts to natural language Spec# to C# compilerSpec# to C# compiler

Time for questions