VIDE als voortzetting van Cocktail SET Seminar 11 september 2008 Dr. ir. Michael Franssen.

Slides:



Advertisements
Similar presentations
Automated Theorem Proving Lecture 1. Program verification is undecidable! Given program P and specification S, does P satisfy S?
Advertisements

An Abstract Interpretation Framework for Refactoring P. Cousot, NYU, ENS, CNRS, INRIA R. Cousot, ENS, CNRS, INRIA F. Logozzo, M. Barnett, Microsoft Research.
PZ03D Programming Language design and Implementation -4th Edition Copyright©Prentice Hall, PZ03D - Program verification Programming Language Design.
Translation-Based Compositional Reasoning for Software Systems Fei Xie and James C. Browne Robert P. Kurshan Cadence Design Systems.
Pontus Boström and Marina Waldén Åbo Akademi University/ TUCS Development of Fault Tolerant Grid Applications Using Distributed B.
IT Requirements Capture Process. Motivation for this seminar Discovering system requirements is hard. Formally testing use case conformance is hard. We.
Background information Formal verification methods based on theorem proving techniques and model­checking –to prove the absence of errors (in the formal.
ISBN Chapter 3 Describing Syntax and Semantics.
Dynamic semantics Precisely specify the meanings of programs. Why? –programmers need to understand the meanings of programs they read –programmers need.
Copyright © 2006 Addison-Wesley. All rights reserved. 3.5 Dynamic Semantics Meanings of expressions, statements, and program units Static semantics – type.
1 Semantic Description of Programming languages. 2 Static versus Dynamic Semantics n Static Semantics represents legal forms of programs that cannot be.
CS 355 – Programming Languages
CLF: A Concurrent Logical Framework David Walker Princeton (with I. Cervesato, F. Pfenning, K. Watkins)
Train Control Language Teaching Computers Interlocking By: J. Endresen, E. Carlson, T. Moen1, K. J. Alme, Haugen, G. K. Olsen & A. Svendsen Synthesizing.
16/13/2015 3:30 AM6/13/2015 3:30 AM6/13/2015 3:30 AMIntroduction to Software Development What is a computer? A computer system contains: Central Processing.
ESC Java. Static Analysis Spectrum Power Cost Type checking Data-flow analysis Model checking Program verification AutomatedManual ESC.
VIDE Integrated Environment for Development and Verification of Programs.
Analysis Stage (Phase I) The goal: understanding the customer's requirements for a software system. n involves technical staff working with customers n.
CS 330 Programming Languages 09 / 18 / 2007 Instructor: Michael Eckmann.
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.
Sparkle A theorem prover for the functional language Clean Maarten de Mol University of Nijmegen February 2002.
CS 330 Programming Languages 09 / 16 / 2008 Instructor: Michael Eckmann.
Describing Syntax and Semantics
School of Computer ScienceG53FSP Formal Specification1 Dr. Rong Qu Introduction to Formal Specification
Slides 00 1 Advanced Logics Part 1: Lambda Calculus and Type Theory Lecturer: Lim Yohanes Stefanus Part 2: Modal Logic Lecturer: Gregory Wheeler.
Formal verification Marco A. Peña Universitat Politècnica de Catalunya.
Cormac Flanagan University of California, Santa Cruz Hybrid Type Checking.
MCA –Software Engineering Kantipur City College. Topics include  Formal Methods Concept  Formal Specification Language Test plan creation Test-case.
Software Process and Product Metrics
Software Engineering Tools and Methods Presented by: Mohammad Enamur Rashid( ) Mohammad Rashim Uddin( ) Masud Ur Rahman( )
Software Engineering Prof. Dr. Bertrand Meyer March 2007 – June 2007 Chair of Software Engineering Static program checking and verification Slides: Based.
Knowledge representation
Mathematical Modeling and Formal Specification Languages CIS 376 Bruce R. Maxim UM-Dearborn.
A Z Approach in Validating ORA-SS Data Models Scott Uk-Jin Lee Jing Sun Gillian Dobbie Yuan Fang Li.
A Java Implementation of Peirce’s Existential Graphs Bram van Heuveln Department of Philosophy State University College at Oneonta March 22, 2001.
Proof Carrying Code Zhiwei Lin. Outline Proof-Carrying Code The Design and Implementation of a Certifying Compiler A Proof – Carrying Code Architecture.
Overview of Formal Methods. Topics Introduction and terminology FM and Software Engineering Applications of FM Propositional and Predicate Logic Program.
ISBN Chapter 3 Describing Semantics -Attribute Grammars -Dynamic Semantics.
Formal Verification Lecture 9. Formal Verification Formal verification relies on Descriptions of the properties or requirements Descriptions of systems.
Checking Reachability using Matching Logic Grigore Rosu and Andrei Stefanescu University of Illinois, USA.
Page 1 Advanced Technology Center HCSS 03 – April 2003 vFaat: von Neumann Formal Analysis and Annotation Tool David Greve Dr. Matthew Wilding Rockwell.
FDT Foil no 1 On Methodology from Domain to System Descriptions by Rolv Bræk NTNU Workshop on Philosophy and Applicablitiy of Formal Languages Geneve 15.
Deriving Operational Software Specification from System Goals Xin Bai EEL 5881 Course Fall, 2003.
A Java implementation of Peirce’s Existential Graphs* faculty advisors: Bram van Heuveln (Philosophy) Dennis Higgins (Math & Computer Science) student.
A Java implementation of Peirce’s Existential Graphs
3.2 Semantics. 2 Semantics Attribute Grammars The Meanings of Programs: Semantics Sebesta Chapter 3.
ISBN Chapter 3 Describing Semantics.
Syntax and Semantics CIS 331 Syntax: the form or structure of the expressions, statements, and program units. Semantics: the meaning of the expressions,
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.
COP4020 Programming Languages Introduction to Axiomatic Semantics Prof. Robert van Engelen.
From Hoare Logic to Matching Logic Reachability Grigore Rosu and Andrei Stefanescu University of Illinois, USA.
Protocol Derivation Assistant Matthias Anlauff Kestrel Institute
All-Path Reachability Logic Andrei Stefanescu 1, Stefan Ciobaca 2, Radu Mereuta 1,2, Brandon Moore 1, Traian Serbanuta 3, Grigore Rosu 1 1 University of.
Formal Specification: a Roadmap Axel van Lamsweerde published on ICSE (International Conference on Software Engineering) Jing Ai 10/28/2003.
SAFE KERNEL EXTENSIONS WITHOUT RUN-TIME CHECKING George C. Necula Peter Lee Carnegie Mellon U.
Concepts and Realization of a Diagram Editor Generator Based on Hypergraph Transformation Author: Mark Minas Presenter: Song Gu.
Static Techniques for V&V. Hierarchy of V&V techniques Static Analysis V&V Dynamic Techniques Model Checking Simulation Symbolic Execution Testing Informal.
Formal Verification. Background Information Formal verification methods based on theorem proving techniques and model­checking –To prove the absence of.
CSC3315 (Spring 2009)1 CSC 3315 Languages & Compilers Hamid Harroud School of Science and Engineering, Akhawayn University
Some Thoughts to Consider 5 Take a look at some of the sophisticated toys being offered in stores, in catalogs, or in Sunday newspaper ads. Which ones.
June 21, Reasoning about explicit strictness in a lazy language using mixed lazy/strict semantics Marko van Eekelen Maarten de Mol Nijmegen University,
CENG 424-Logic for CS Introduction Based on the Lecture Notes of Konstantin Korovin, Valentin Goranko, Russel and Norvig, and Michael Genesereth.
Sparkle a functional theorem prover
Matching Logic An Alternative to Hoare/Floyd Logic
Logical architecture refinement
Programming Languages 2nd edition Tucker and Noonan
Test Case Test case Describes an input Description and an expected output Description. Test case ID Section 1: Before execution Section 2: After execution.
Towards a Unified Theory of Operational and Axiomatic Semantics
Programming Languages 2nd edition Tucker and Noonan
Presentation transcript:

VIDE als voortzetting van Cocktail SET Seminar 11 september 2008 Dr. ir. Michael Franssen

2 Verification Condition Generators (VCG)  A verification condition generator computes verification conditions for a given program extended with some annotations (directly or indirectly)  Proving the verification condition(s) yields higher reliability of the program  Using tools like ESC/Java helps to find common bugs in software otherwise unnoticed

3 Drawbacks of VCGs  Program correctness has been transfered to proof correctness  An automated theorem prover can be used, but is itself a complicated piece of software  Whether or not a first-order theorem holds is only semi-decidable  A VCG does not help you to obtain a correct program. It merely proves your program is correct.

4 Stepwise refinement  When a statement is inserted between a pre- postcondition pair, new pre- and postconditions can be computed directly for the remainder of the programming problem.  A tool can administer all proof obligations and solve simple proofs automatically.  One can build a library of programs that are proved to be correct.

5 Tool requirements Correctness should be ensured:  the tool must be based on a well-founded theory  even if the tool becomes large a bug in the tool should never lead to undetected bugs in the result. (Using the De Bruijn criterion) In order to be used by programmers:  the notations and concepts used should be as close to the pen and paper counterparts as possible.  the tool should be easy to use. (e.g. it needs an advanced graphical user interface).

6 Intermezzo: The De Bruijn criterion  There should be a representation of the proof, that can be checked by a small reliable program.  Hence, if I do not trust my tool, I can write a validator for the results myself.  This ensures that even if the tool becomes large and complex, errors will be detected in the end.  Size and complexity of the tool no longer influence reliability.

7 Tool requirements  The tool may not enforce a specific order of proving and programming.  It must be able to serve as a framework to be used for experiments towards larger scale programs.

8 Creating a theoretical framework 1)To construct proofs, we use a typed lambda calculus for first-order logic. First-order logic is very intuitive and widely known amongs all potential users. By using a typed lambda calculus, we achieve a high degree of reliability of the implementation of the tool (due to the De Bruijn criterion)

9  Fp:Q  F:P  Q  p:P  ( p:P.q):P  Q ,p:P q:Q  Fp:Q 1 st Order Logic in P-  F:P  Q  p:P  ( p:P.q):P  Q ,p:P q:Q 1 st Order Logic

10 Creating a theoretical framework 2)In order to support program derivation, a Hoare logic is used. Such a logic is intuitive to the students and directly connects a program to its specification. Another alternative would be a dynamic logic, but these are a lot less commonly known by potential users. Moreover, they connect programs with an operational semantics.

11  p:P’  P {P}S{Q}  q:Q  Q’ Hoare Logic in Cocktail {P}S{Q} {Q}T{R} {P}S;T{R} {P’}S{Q’}

12 Hoare Logic in Cocktail Regard S as a proof (program) that proves that {P}?{Q} is satisfiable. Denote this as S:P»Q. If P  Q holds, then {P}?{Q} is trivial, since nothing needs to be done! (that is, we need a proof p of P  Q). For this step from proof to program, we introduce a special “programming” construct.

13 The fake statement:  p:P  Q fake p:P»Q  p:P’  P fake p:P’»P  q:Q  Q’ fake q:Q»Q’ S:P»Q fake p;S;fake q:P’»Q’ Now use: The entire logic is now syntax-directed!

14 Creating a theoretical framework: 3)To automatically construct proofs, we implemented a tableau-based automated theorem prover as a proof of concept. This theorem prover constructs a tableau to prove a theorem, which is then translated into a lambda-term to ensure reliability of the system.

15 Mixing it all up: Cocktail  The logic, automated theorem prover and Hoare logic were moulded in order to fit together  A software architecture was designed to enable the simultaneous editing of several programs, proofs and theories through a set of coupled structure editors  Editors for our framework were implemented, employing a context sensitive graphical user interface

16 Cocktail’s theorem prover Forward and backward reasoning:  Reasoning through combining known information, yielding new information  Reasoning through decomposition of the current (sub)goal into smaller goals until the goal is trivial.  Rewriting:  Either by using a single rule containing an equation  Or by exhaustively using a set of rules in a specified order and direction (computing normal-forms)

17 Results:  The formal basis of the tool is a single coherent formalism, which ensures safety of the system in both theory and practice (25 Axiomatic Rules).  The tool supports interactive derivation of programs from specifications. The program and its correctness proof can be developed simultaneously.  Cocktail’s theorem prover is fairly intuitive for all users, using usual notations and tactics.  Implementation in Java is only 596 kB.

18 Future work (VIDE):  Integrate the extended automated theorem prover to deal with equational reasoning.  Constructing a new, more elaborate programming language.  Allow for derivation and post-verification of programs within a single tool.  Integrate other approaches and tools within the same framework.

19

20