An Object-Oriented logic for softwar and design. Author(s)Yatake, Kenro; Aoki, Toshiaki; Katay

Similar documents
An executable semantics of Object-Oriented models for simulation and theorem proving

Proof Carrying Code(PCC)

Integration of SMT Solvers with ITPs There and Back Again

Research Paper on Implementation of OCL Constraints in JAVA

CS6202: Advanced Topics in Programming Languages and Systems Lecture 0 : Overview

Quo Vadis Program Verification

The Formal Semantics of Programming Languages An Introduction. Glynn Winskel. The MIT Press Cambridge, Massachusetts London, England

CMSC 330: Organization of Programming Languages. Operational Semantics

An Evolution of Mathematical Tools

From IMP to Java. Andreas Lochbihler. parts based on work by Gerwin Klein and Tobias Nipkow ETH Zurich

Main Goal. Language-independent program verification framework. Derive program properties from operational semantics

Com S 541. Programming Languages I

Chapter 1. Introduction

Semantic Analysis Type Checking

CMSC 330: Organization of Programming Languages

Types. Type checking. Why Do We Need Type Systems? Types and Operations. What is a type? Consensus

Type Systems. Pierce Ch. 3, 8, 11, 15 CSE

Chapter 3 (part 3) Describing Syntax and Semantics

Advances in Programming Languages

From Hoare Logic to Matching Logic Reachability. Grigore Rosu and Andrei Stefanescu University of Illinois, USA

Verified Characteristic Formulae for CakeML. Armaël Guéneau, Magnus O. Myreen, Ramana Kumar, Michael Norrish April 27, 2017

Deductive Program Verification with Why3, Past and Future

Subtyping (cont) Lecture 15 CS 565 4/3/08

Computing Fundamentals 2 Introduction to CafeOBJ

Type Processing by Constraint Reasoning

Type checking. Jianguo Lu. November 27, slides adapted from Sean Treichler and Alex Aiken s. Jianguo Lu November 27, / 39

A Brief Introduction to Standard ML

Tradeoffs. CSE 505: Programming Languages. Lecture 15 Subtyping. Where shall we add useful completeness? Where shall we add completeness?

Semantics. There is no single widely acceptable notation or formalism for describing semantics Operational Semantics

Metamodeling. Janos Sztipanovits ISIS, Vanderbilt University

Subtyping (cont) Formalization of Subtyping. Lecture 15 CS 565. Inversion of the subtype relation:

Pierce Ch. 3, 8, 11, 15. Type Systems

Contents. Program 1. Java s Integral Types in PVS (p.4 of 37)

The Prototype Verification System PVS

Handling Integer Arithmetic in the Verification of Java Programs

First-Order Proof Tactics in Higher Order Logic Theorem Provers Joe Hurd p.1/24

An LCF-Style Interface between HOL and First-Order Logic Joe Hurd p.1/9

Verifying Java Programs with KeY

School of Computer & Communication Sciences École Polytechnique Fédérale de Lausanne

The design of a programming language for provably correct programs: success and failure

Formal Methods. CITS5501 Software Testing and Quality Assurance

The SMT-LIB 2 Standard: Overview and Proposed New Theories

CSE505, Fall 2012, Midterm Examination October 30, 2012

Verifying Java Programs. Verifying Java Programs. The Krakatoa/Why Tool Suite

Verifying Java Programs

Finite Model Generation for Isabelle/HOL Using a SAT Solver

Static semantics. Lecture 3-6: Semantics. Attribute grammars (2) Attribute grammars. Attribute grammars example. Dynamic semantics

Types and Type Inference

Why. an intermediate language for deductive program verification

Types and Type Inference

Theorem proving. PVS theorem prover. Hoare style verification PVS. More on embeddings. What if. Abhik Roychoudhury CS 6214

Contents. Chapter 1 SPECIFYING SYNTAX 1

Programming Languages Third Edition

1 Introduction. 3 Syntax

A CRASH COURSE IN SEMANTICS

Semantic Subtyping with an SMT Solver

Lecture 13: Subtyping

Type Systems. Today. 1. Organizational Matters. 1. Organizational Matters. Lecture 1 Oct. 20th, 2004 Sebastian Maneth. 1. Organizational Matters

Functional Programming with Isabelle/HOL

Types and Programming Languages. Lecture 5. Extensions of simple types

Denotational Semantics. Domain Theory

Types for References, Exceptions and Continuations. Review of Subtyping. Γ e:τ τ <:σ Γ e:σ. Annoucements. How s the midterm going?

At build time, not application time. Types serve as statically checkable invariants.

Formal Verification. Lecture 10

Functional Languages. Hwansoo Han

Simply-Typed Lambda Calculus

Verifying Java Programs Verifying Java Programs with KeY

Formal Systems II: Applications

Second-Order Type Systems

The Typed λ Calculus and Type Inferencing in ML

Formal Systems and their Applications

Operational Semantics. One-Slide Summary. Lecture Outline

Harvard School of Engineering and Applied Sciences CS 152: Programming Languages

Modules and Representa/on Invariants

CMSC 330: Organization of Programming Languages. Formal Semantics of a Prog. Lang. Specifying Syntax, Semantics

Defining Languages GMU

Tail Calls. CMSC 330: Organization of Programming Languages. Tail Recursion. Tail Recursion (cont d) Names and Binding. Tail Recursion (cont d)

Harvard School of Engineering and Applied Sciences CS 152: Programming Languages

Software Engineering: A Practitioner s s Approach, 6/e Roger Pressman. Chapter 28 Formal Methods

Satisfiability Modulo Theories. DPLL solves Satisfiability fine on some problems but not others

15-819M: Data, Code, Decisions

Subtyping. Lecture 13 CS 565 3/27/06

Programming Languages Lecture 14: Sum, Product, Recursive Types

λ calculus is inconsistent

From OCL to Typed First-order Logic

Formal specification in Event-B

Logic and Computation

Lecture 7: Type Systems and Symbol Tables. CS 540 George Mason University

Last class. CS Principles of Programming Languages. Introduction. Outline

Basic Verification Strategy

CS152: Programming Languages. Lecture 11 STLC Extensions and Related Topics. Dan Grossman Spring 2011

Verification of Selection and Heap Sort Using Locales

The semantics of a programming language is concerned with the meaning of programs, that is, how programs behave when executed on computers.

Jam: A Smooth Extension With Java Mixins

Specification, Verification, and Interactive Proof

Chapter 3. Semantics. Topics. Introduction. Introduction. Introduction. Introduction

Types, Type Inference and Unification

Verifying Java Programs Verifying Java Programs with KeY

CSCI-GA Scripting Languages

Overview of the KeY System

Transcription:

JAIST Reposi https://dspace.j Title An Object-Oriented logic for softwar and design Author(s)Yatake, Kenro; Aoki, Toshiaki; Katay Citation Issue Date 2005-09-21 Type Presentation Text version publisher URL http://hdl.handle.net/10119/8323 Rights 1st VERITE : JAIST/TRUST-AIST/CVS jo on VERIfication TEchnologyでの発表資料, 開催 Description :2005 年 9 月 21 日 ~22 日, 開催場所 : 金沢市文化ホール 3F Japan Advanced Institute of Science and

An Object-Oriented logic for software analysis and design Kenro Yatake, Toshiaki Aoki Takuya Katayama JAIST 2005.9.21

Background The Object-Oriented method has become the mainstream of software development. In the upstream phase of the development, analysis models are constructed with a language such as UML. To ensure that the system satisfies its requirements, formal verification method must be applied to the analysis models.

Verification target Invariant properties about object attributes. e.g. AC: The thermometer value always less than 30. Bank: Balance values never become negative. Apply theorem proving

The HOL system The use of HOL theorem prover Interactive prover of higher-order logic. A lot of mathematical libraries. No libraries which implement OO concepts. Implement object theory in HOL

Existing object theories in higher-order logic Semantics of Java program verification LOOP, Bali, Krakatoa, Types of object attributes are limited to primitive ones appearing in Java (integer, boolean, ). Compared to program verification, analysis model verification requires high availability of types. High abstract types (set, stack, tree ) Domain-specific types (date, time, currency, )

Objective Implement an object theory where object can have arbitrary types of attributes. Verification with a wide variety of types becomes possible making use of plentiful mathematical libraries and powerful datatype definition facilities of HOL.

Embedding problem The type system of HOL is too simple to express object concepts as a general type. Object??? HOL Unified type of arbitrary types Subtyping Referencing Simply-typed lambda calculus with a first-order language of types

Approach Application-specific theory Automatically construct object theories depending on the type information of individual applications. Class model Theory generator Object theory In effect, arbitrary types can be incorporated into object attributes.

Soundness Construct the theory by definitional extension The standard technique to construct sound theories in HOL Derive new theories from existing sound theories only by introduction of definitions and derivation by sound inference rules. Object Derive Heap memory Define List Pair Num Bool

Overview of the theory The theory is defined by mapping the class model elements to theory elements Class model Classes Attributes, types Inheritance HOL theory Types Operators Axioms fig x:int y:int rect w:num h:num crect c:color

Types Store The environment of a system which holds a state of all alive objects. Object references Object references are represented by types whose names are their class names. :store :fig :rect

Operators & axioms 6 kinds of primitive operators to handle objects are defined on the store. Object creation Alive test Attribute read Attribute write Casting Instance-of 36 axioms are introduced on the operators.

Object creators & alive testers Object creators creates a new object in a store. Alive testers tests if an object exists in a store. :store fig_new :store fig_ex f s. let (f,s ) = fig_new s in fig_ex f s The newly created object exists in the new store.

Attribute accessors Attribute accessors read and write the object attributes. :fig fig_set_x fig_set_y x y fig_get_x fig_get_y f x s. fig_ex f s (fig_get_x f (fig_set_x f A s) = A) The attribute x obtained just after updating it to A is equal to A.

Casting functions Casting functions change the apparent types of objects. :fig fig_cast_rect rect_cast_fig :rect r s. rect_ex r s (fig_cast_rect (rect_cast_fig r s) s = r) Upcasting and downcasting results in the original object.

Instance-of predicates Instance-of predicates remember the actual types of objects. :fig fig_is_rect rect_cast_fig rect_new :rect rect_is_rect r s. rect_is_rect r s fig_is_rect (rect_cast_fig r s) s

Heap memory model The theory is derived from the operational semantics of a heap memory model. fig x:int y:int rect w:num h:num crect c:color f0 r0 c0 f1 (2,3,r0) r1 (10,8,f2,c0) c1 (red,r2) f2 (-4,5,r1) r2 (6,12,f3,c1) c2 (blue,r4) f3 (1,-2,r2) r3 (4,10,f4,c0) f4 (10,0,r3) r4 (5,8,f5,c2) f5 (0,0,r4)

Object structure Subtyping mechanism is implemented by composing a single instance by multiple cells. fig x:int y:int rect w:num h:num crect c:color f3 :fig (1,-2,r2) c1 (red,r2) r2 (6,12,f3,c1) :rect :crect Strucrure of a crect instance

Prototype execution The theory is executable in moscow-ml Define the operational semantics of the heap memory model as actual operations in ML. - val (f,s1) = fig_new store_emp; > val f = <fig> : fig > val s1 = <store> : store - val s2 = fig_set_x f 10 s1; > val s2 = <store> : store - val x = fig_get_x f s2; > val x = 10 : int

Example: a simple library system Max number of items a customer can keep at a time Max number of days a customer can keep an item customer cid:num name:string Customer ID Class diagram library max:num days:num nextcid:num nextiid:num lend days:int Remaining days of the lent Collaboration diagram of lending service Next customer ID and item ID to be issued book isbn:num item iid:num title:string :customer library customer.lend->size = item.select(lend->size>0)->size cd 1:lib.lend(cid,iid) 1.5:lnd:=new_lend(d,cst,itm) Item ID OCL invariant The total number of items lent by all the customers is equal to the number of unavailable items. :library <<new>> :lend 1.1:[lib.check_lend(cid,iid)] 1.2:cst:=lib.get_customer(cid) 1.3:itm:=lib.get_item(iid) 1.4:d:=lib.get_days() 1.6:lib.add_lend(lnd) :item 1.5.4:cst.add_lend(lnd) 1.5.5:itm.add_lend(lnd) 1.5.1:lnd.set_days(d) 1.5.2:lnd.add_customer(cst) 1.5.3:lnd.add_item(itm)

Invariant verification Verify that the collaboration maintains the invariant. Collaboration Invariant F : store -> store P : store -> bool - s. P (s) P (F (s))

Collaboration definition in HOL 1:lib.lend(cid,iid) 1.5:lnd:=new_lend(d,cst,itm) :customer :library <<new>> :lend 1.1:[lib.check_lend(cid,iid)] 1.2:cst:=lib.get_customer(cid) 1.3:itm:=lib.get_item(iid) 1.4:d:=lib.get_days() 1.6:lib.add_lend(lnd) :item 1.5.4:cst.add_lend(lnd) 1.5.5:itm.add_lend(lnd) 1.5.1:lnd.set_days(d) 1.5.2:lnd.add_customer(cst) 1.5.3:lnd.add_item(itm) Collaboration diagram of the lending service HOL representation of the collaboration library_lend lib cid iid s = if library_check_lend lib cid iid s then let cst = library_get_custmer lib cid s in let itm = library_get_item lib iid s in let d = library_get_days lib s in let (lnd,s1) = new_lend cst itm d s in let s2 = library_add_lend lib lnd s1 in ( ok, s2) else ( fail, s) new_lend cst itm d s = let (lnd,s1) = lend_new s in let s2 = lend_set_days lnd d s1 in let s3 = lend_add_customer lnd cst s2 in let s4 = lend_add_item lnd itm s3 in let s5 = customer_add_lend cst lnd s4 in let s6 = item_add_lend lnd s5 in (lnd, s6) Library_get_customer lib cid s = let l = library_get_customerlist lib s in FST (FILTER ( x. customer_get_cid x s = cid) l) customer_add_lend cst lnd s = let l = customer_get_lendlist cst s in customer_set_lendlist (lnd::l) s

Invariant definition in HOL Maxnumberofitems a customer can keep atatime Maxnumberofdays a customer can keep an item customer cid:num name:string Customer ID library max:num days:num nextcid:num nextiid:num lend days:int Remaining days of the lent Next customer ID anditemidtobeissued book isbn:num item iid:num title:string library customer.lend->size = item.select(lend->size>0)->size cd Item ID OCL invariant Inv lib s = library_ex lib s ==> (library_get_customer_lendsum lib s = library_get_item_lendsum lib s) library_get_customer_lendsum lib s = let l = library_get_customer_list lib s in SUM (MAP ( x. customer_get_lendnum x s) l) HOL representation of the invariant library_get_item_lendsum lib s = let l = library_get_itemlist lib s in LENGTH (FILTER ( x. ~(item_is_available x s)) l) customer_get_lendnum cst s = LENGTH (customer_get_lendlist cst s) item_is_avalable itm s = (LENGTH (item_get_lendlist itm s) = 0)

Proof The collaboration of the lending service maintains the invariant. - lib cid iid s. Inv lib s Inv lib (library_lend lib cid iid s)

Related work Object embedding using extensible records W. Narashewski et al. 1998 No referencing concept. Axiomatic semantics of UML models T. Aoki et al. 2001 Directly introducing axioms in HOL. UML/OCL verification in B R. Marcano et al. 2002 Methods are defined only by attaching pre- and post-conditions.

Conclusion Defined an object theory for analysis model verification in HOL Application-specific Sound Executable Verification of a library system Verify a collaboration maintains an invariant.

Future work Make the proof efficient Define a collaboration as a sequencial OO program and implement verification condition generator. COE-related work (security) Verify security requirements of a system using the object theory. FW: bad packets never goes into the internal network.