This research is funded in part the U. S. National Science Foundation grant CCR-0113181. DEET for Component-Based Software Murali Sitaraman, Durga P. Gandi.

Slides:



Advertisements
Similar presentations
Copyright 2000 Cadence Design Systems. Permission is granted to reproduce without modification. Introduction An overview of formal methods for hardware.
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?
Copyright W. Howden1 Programming by Contract CSE 111 6/4/2014.
CPSC 388 – Compiler Design and Construction
Reading Mathematical Contracts
Semantics Static semantics Dynamic semantics attribute grammars
Addressing the Challenges of Current Software. Questions to Address Why? What? Where? How?
Introducing Formal Methods, Module 1, Version 1.1, Oct., Formal Specification and Analytical Verification L 5.
Abstraction and Modular Reasoning for the Verification of Software Corina Pasareanu NASA Ames Research Center.
Chair of Software Engineering From Program slicing to Abstract Interpretation Dr. Manuel Oriol.
Formal Semantics of Programming Languages 虞慧群 Topic 5: Axiomatic Semantics.
This research has been funded in part by grants from the U. S. National Science Foundation for the past 20 years. Towards Verified Software: Research and.
ISBN Chapter 3 Describing Syntax and Semantics.
1 Semantic Description of Programming languages. 2 Static versus Dynamic Semantics n Static Semantics represents legal forms of programs that cannot be.
Automated creation of verification models for C-programs Yury Yusupov Saint-Petersburg State Polytechnic University The Second Spring Young Researchers.
Java Programming, 3e Concepts and Techniques Chapter 5 Arrays, Loops, and Layout Managers Using External Classes.
Program analysis Mooly Sagiv html://
Sets and Maps Chapter 9. Chapter 9: Sets and Maps2 Chapter Objectives To understand the Java Map and Set interfaces and how to use them To learn about.
Program analysis Mooly Sagiv html://
Programming Language Semantics Mooly SagivEran Yahav Schrirber 317Open space html://
OOP #10: Correctness Fritz Henglein. Wrap-up: Types A type is a collection of objects with common behavior (operations and properties). (Abstract) types.
1 Program Analysis Mooly Sagiv Tel Aviv University Textbook: Principles of Program Analysis.
Semantics with Applications Mooly Sagiv Schrirber html:// Textbooks:Winskel The.
Describing Syntax and Semantics
Efficient Modular Glass Box Software Model Checking Michael Roberson Chandrasekhar Boyapati The University of Michigan.
Program Analysis Mooly Sagiv Tel Aviv University Sunday Scrieber 8 Monday Schrieber.
CS 267: Automated Verification Lecture 13: Bounded Model Checking Instructor: Tevfik Bultan.
272: Software Engineering Fall 2012 Instructor: Tevfik Bultan Lecture 4: SMT-based Bounded Model Checking of Concurrent Software.
Mathematics throughout the CS Curriculum Support by NSF #
Jason Hallstrom (Clemson), Joan Krone (Denison), Joseph E. Hollingsworth (IU Southeast), and Murali Sitaraman(Clemson) This workshop is funded in part.
Chapter Seven Advanced Shell Programming. 2 Lesson A Developing a Fully Featured Program.
Computer Science School of Computing Clemson University Discrete Math and Reasoning about Software Correctness Murali Sitaraman
Computer Science School of Computing Clemson University Specification and Reasoning in SE Projects Using a Web IDE Charles T. Cook (Clemson) Svetlana V.
Towers of Hanoi. Introduction This problem is discussed in many maths texts, And in computer science an AI as an illustration of recursion and problem.
Computer Science School of Computing Clemson University Mathematical Reasoning across the Curriculum Software Development Foundations and Software Engineering.
Lecture 16 March 22, 2011 Formal Methods CS 315 Spring Adapted from slides provided by Jason Hallstrom and Murali Sitaraman (Clemson)
Software Engineering Prof. Dr. Bertrand Meyer March 2007 – June 2007 Chair of Software Engineering Static program checking and verification Slides: Based.
Dr. Tom WayCSC Code Reviews & Inspections CSC 4700 Software Engineering.
Chapter 1 Introduction Dr. Frank Lee. 1.1 Why Study Compiler? To write more efficient code in a high-level language To provide solid foundation in parsing.
Computer Science School of Computing Clemson University Introduction to Formal Specification Murali Sitaraman Clemson University.
Inferring Specifications to Detect Errors in Code Mana Taghdiri Presented by: Robert Seater MIT Computer Science & AI Lab.
SAVCBS 2006 p. 1 Specification of Iterators Bruce W. Weide Reusable Software Research Group The Ohio State University
Computer Science School of Computing Clemson University Discrete Math and Reasoning about Software Correctness Joseph E. Hollingsworth
CS Data Structures I Chapter 2 Principles of Programming & Software Engineering.
Chapter 3 Part II Describing Syntax and Semantics.
Semantics In Text: Chapter 3.
1 CSCD 326 Data Structures I Software Design. 2 The Software Life Cycle 1. Specification 2. Design 3. Risk Analysis 4. Verification 5. Coding 6. Testing.
This research is funded in part by grant CCR from the U. S. National Science Foundation. Profiles: A Compositional Mechanism for Performance Specification.
Scientific Debugging. Errors in Software Errors are unexpected behaviors or outputs in programs As long as software is developed by humans, it will contain.
How to execute Program structure Variables name, keywords, binding, scope, lifetime Data types – type system – primitives, strings, arrays, hashes – pointers/references.
 Fall Chart 2  Translators and Compilers  Textbook o Programming Language Processors in Java, Authors: David A. Watts & Deryck F. Brown, 2000,
Static Techniques for V&V. Hierarchy of V&V techniques Static Analysis V&V Dynamic Techniques Model Checking Simulation Symbolic Execution Testing Informal.
Computer Science School of Computing Clemson University Mathematical Reasoning with Objects.
Formal Methods in Software Engineering1 Today’s Agenda  Mailing list  Syllabus  Introduction.
Integrating Math Units and Proof Checking for Specification and Verification SAVCBS Workshop 2008 SIGSOFT 2008 / FSE 16 November 9th, 2008 Hampton Smith.
Design by Contract. The Goal Ensure the correctness of our software (correctness) Recover when it is not correct anyway (robustness) Correctness: Assertions.
Finding bugs with a constraint solver daniel jackson. mandana vaziri mit laboratory for computer science issta 2000.
Lecture 18 March 29, 2011 Formal Methods 3 CS 315 Spring Adapted from slides provided by Jason Hallstrom and Murali Sitaraman (Clemson)
ALLOY: A Formal Methods Tool Glenn Gordon Indiana University of Pennsylvania COSC 481- Formal Methods Dr. W. Oblitey 26 April 2005.
Modular Alternatives to Testing
Types for Programs and Proofs
CS 326 Programming Languages, Concepts and Implementation
Component Implementations Using RESOLVE
Lecture 2 of Computer Science II
Introduction to Components and Specifications Using RESOLVE
Introduction to Components and Specifications Using RESOLVE
More Mathematical Reasoning (Conditional Statements)
Mathematical Reasoning with Data Abstractions
Formal Methods Lecture 16 March 22, 2011 CS 315 Spring 2011
Presentation transcript:

This research is funded in part the U. S. National Science Foundation grant CCR DEET for Component-Based Software Murali Sitaraman, Durga P. Gandi Clemson University Wolfgang Küchlin, Carsten Sinz Universität Tübingen Bruce W. Weide The Ohio State University Correspondence:

What is DEET? DEET is Best Bug Repellent – New England Journal of Medicine, DEET is Detecting Errors Efficiently without Testing.

Correctness Problem and Well-Known Approaches Problem: Does the program do what is specified to do? Formal verification objective: Prove that it does, using static analysis. Testing (and runtime checking) objective: Find errors, i.e., find mismatches between specified intent and program behavior, through execution.

DEET vs. Verification vs. Testing DEET is a static analysis approach, like formal verification. DEET is intended for error detection, like testing. DEET has potential to serve as a cost-effective and efficient prelude to both testing and verification.

Benefits of the DEET Approach It can analyze one component at a time in a modular fashion. It does not depend on code or even stub availability for reused components; it can detect substitutability bugs. It is automatic and does not require manual input selection. It can pinpoint the origin of the error in a component-based system.

Contextual Differences Between DEET and Other Approaches Context of Alloy and ESC industrial languages, such as Java objectives are incremental based on current practice minimal expectations of programmers Context of DEET research language, i.e., Resolve objectives are set in the context of software practice as it could be a competent programmer hypothesis

Component-Based Software Using Design-By-Contract Paradigm uses implements uses implements uses

Ramifications of Contextual Differences DEET is a step towards meeting the larger objective of specification-based modular verification. In Resolve, components have specifications, and implementations are expected to have loop invariants, representation invariants, abstraction relations. Clean and rich semantics of Resolve allows variables to be viewed as having values from arbitrary mathematical spaces; references are not an issue.

An Example

Abstraction in Specification Think of a List as a pair of mathematical strings: A string of entries that are to the left of the "current position", and A string of entries to the right. Initially, both strings are empty.

View of a List of Trees with Abstraction S1 = ( <, >, <> ) S2 = ( <>, <> ) LeftRight

View After Insert (T, S2) S2 = ( <, >, <> ) T = S2 = ( <, >, <> ),

Mathematical Modeling Concept List_Template (type Entry); uses String_Theory, …; Type List is modeled by ( Left: String(Entry); Right: String(Entry) ); exemplar S; initialization ensures S.Left = empty_string and S.Right = empty_string;... end List_Template;

List Operations Concept List_Template (type Entry); uses … Type List is modeled by … Oper Insert(E: Entry; S: List); Oper Remove(E: Entry; S: List); Oper Advance(S: List); Oper Reset(S: List); Oper Advance_To_End(S: List); Oper Left_Length(S: List): Integer; Oper Right_Length(S: List): Integer; Oper Swap_Rights(S1, S2: List); end List_Template;

Design and Specification of Operations Operation Insert(clears E: Entry; updates S: List); Ensures S.Left = #S.Left and S.Right = ° #S.Right; Operation Remove(replaces E: Entry; updates S: List); Requires |S.Right| > 0; Ensures S.Left = #S.Left and #S.Right = ° S.Right;

Part II: Erroneous Code Example

A Specification of List Reverse Operation Reverse(updates S: List); Requires |S.Left| = 0; Ensures S.Left = #S.Right Rev and S.Right = empty_string;

Example Behavior of Reverse #S = (, <, > ) S = ( <>, <> ) LeftRight,

An Erroneous Implementation Procedure Reverse (updates S: List); decreasing |S.Right|; Var E: Entry; If Right_Length(S) > 0 then Remove(E, S); Reverse(S); Insert(E, S); end; end Reverse;

DEET Steps for Error Detection

Step 1: Verification Condition Generation What do we need to prove that the code is correct? What can we assume? What do we need to confirm?

Step 1: Verification Condition Generation Procedure Reverse (updates S: List); decreasing |S.Right|; Var E: Entry; 0Assume: |S 0.Left| = 0; If Right_Length(S) > 0 then Remove(E, S); Reverse(S); Insert(E, S); end; 5Confirm: S 5.Left = S 0.Right Rev and S 5.Right = empty_string end Reverse;

Step 1: Verification Condition Generation State PathAssumeConfirm Condition Condition 0|S 0.Left| = 0 If Right_Length(S) > 0 then 1 |S 0.Right| > 0 S 1 = S 0 |S 1.Right| > 0 Remove(E, S); 2 |S 0.Right| > 0 S 2.Left = S 1.Left and S 1.Right = ° S 2.Right |S 0.Left| = 0 and |S 2.Right| < |S 0.Right| Reverse(S);

Step 2: Error Hypothesis Generation Conjoin assumptions and negation of what needs to be confirmed. Search for a counterexample.

Step 3: Efficient Searching for Counterexamples by Restricting "Scope" Restrict the "scopes" of participating variables, i.e., limit the mathematical values they can have. For variables of type Entry, suppose the scope is restricted to be of size 1. Entry scope becomes: {Z0} For variables of type Str(Entry), suppose that the length is restricted to be at most 1. The scope of String of Entries becomes: {Str_Empty, Str_Z0}

Step 3: Use Scope Restriction to Generate a Boolean Formula: Example Boolean formula that corresponds to P1 = P0: ((S1_Left_equals_Str_Empty S0_Left_equals_Str_Empty) (S1_Left_equals_Str_Z0 ((S1_Left_equals_Str_Empty S0_Left_equals_Str_Empty) (S1_Left_equals_Str_Z0 S0_Left_equals_Str_Z0)) S0_Left_equals_Str_Z0)) ((S1_Right_equals_Str_Empty S0_Right_equals_Str_Empty) (S1_Right_equals_Str_Z0 S0_Right_equals_Str_Z0))

Step 4: Employ a SAT Solver to Search for a Solution Set these to true S0_Left_equals_Str_Empty S0_Left_equals_Str_EmptyS0_Right_equals_Str_Z0…S5_Left_equals_Str_EmptyS5_Right_equals_Str_Z0 Set these to false S0_Left_equals_Str_Z0 S0_Left_equals_Str_Z0S0_Right_equals_Str_Empty…

Efficiency of DEET We used Sinz/Küchlin solver that can handle non- CNF formulae easily. It took the solver a fraction of a second to find the counterexample. We tried it on an example with 2000 statements and 6000 variables. It took the solver less than 2 seconds to find two counterexamples on a 1.2MHz Athlon PC.

Status and Future Directions Our thesis: DEET can be an efficient and cost- effective prelude to more exhaustive testing or verification. Its scalability and utility for error detection needs to be shown through practical experimentation.