IFIP WG2.1 meeting, 京都市, Sep 2007 1 Refinement and Transformations in Specware A progress report Alessandro Coglio, Kestrel Institute Stephen Westfold,

Slides:



Advertisements
Similar presentations
Programmed Strategies for Program Verification Richard B. Kieburtz OHSU/OGI School of Science and Engineering and Portland State University.
Advertisements

Brief Introduction to Logic. Outline Historical View Propositional Logic : Syntax Propositional Logic : Semantics Satisfiability Natural Deduction : Proofs.
Substitution & Evaluation Order cos 441 David Walker.
Computing Fundamentals 2 Introduction to CafeOBJ Lecturer: Patrick Browne Lecture Room: K408 Lab Room: A308 Based on work by: Nakamura Masaki, João Pascoal.
Types of Logic Circuits
Hoare’s Correctness Triplets Dijkstra’s Predicate Transformers
8. Introduction to Denotational Semantics. © O. Nierstrasz PS — Denotational Semantics 8.2 Roadmap Overview:  Syntax and Semantics  Semantics of Expressions.
Lecture # 2 : Process Models
VIDE als voortzetting van Cocktail SET Seminar 11 september 2008 Dr. ir. Michael Franssen.
ISBN Chapter 3 Describing Syntax and Semantics.
CS 355 – Programming Languages
Formal Methods in Software Engineering Credit Hours: 3+0 By: Qaisar Javaid Assistant Professor Formal Methods in Software Engineering1.
School of Computing and Mathematics, University of Huddersfield CAS2545: WEEK 11 LECTURE: n The meaning of Algebraic Specifications TUTORIAL/PRACTICAL:
C. Varela; Adapted w/permission from S. Haridi and P. Van Roy1 Declarative Computation Model Defining practical programming languages Carlos Varela RPI.
Katz Formal Specifications Larch 1 Algebraic Specification and Larch Formal Specifications of Complex Systems Shmuel Katz The Technion.
CS 454 Theory of Computation Sonoma State University, Fall 2011 Instructor: B. (Ravi) Ravikumar Office: 116 I Darwin Hall Original slides by Vahid and.
Brief Introduction to Logic. Outline Historical View Propositional Logic : Syntax Propositional Logic : Semantics Satisfiability Natural Deduction : Proofs.
Computing Fundamentals 1 Lecture 1 Lecturer: Patrick Browne Room K308 Based on Chapter 1. A Logical approach to Discrete.
PSUCS322 HM 1 Languages and Compiler Design II Formal Semantics Material provided by Prof. Jingke Li Stolen with pride and modified by Herb Mayer PSU Spring.
Sparkle A theorem prover for the functional language Clean Maarten de Mol University of Nijmegen February 2002.
CS 454 Theory of Computation Sonoma State University, Fall 2011 Instructor: B. (Ravi) Ravikumar Office: 116 I Darwin Hall Original slides by Vahid and.
Describing Syntax and Semantics
1 Relational Algebra and Calculus Yanlei Diao UMass Amherst Feb 1, 2007 Slides Courtesy of R. Ramakrishnan and J. Gehrke.
Abstract Types Defined as Classes of Variables Jeffrey Smith, Vincent Fumo, Richard Bruno.
Consistency Checking of RM-ODP Specifications Kenneth Baclawski Mieczyslaw Kokar Jeffrey Smith Jerzy Letkowski.
Systems Architecture I1 Propositional Calculus Objective: To provide students with the concepts and techniques from propositional calculus so that they.
A Z Approach in Validating ORA-SS Data Models Scott Uk-Jin Lee Jing Sun Gillian Dobbie Yuan Fang Li.
MATH 224 – Discrete Mathematics
Kestrel Tools for Producing Reliable Software: Synthesis and Analysis Kestrel Institute Palo Alto, California Douglas R. Smith.
1 Inference Rules and Proofs (Z); Program Specification and Verification Inference Rules and Proofs (Z); Program Specification and Verification.
An Algebra for Composing Access Control Policies (2002) Author: PIERO BONATTI, SABRINA DE CAPITANI DI, PIERANGELA SAMARATI Presenter: Siqing Du Date:
Conjunctive normal form: any formula of the predicate calculus can be transformed into a conjunctive normal form. Def. A formula is said to be in conjunctive.
Lambda Calculus History and Syntax. History The lambda calculus is a formal system designed to investigate function definition, function application and.
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.
Copyright © Curt Hill Mathematical Logic An Introduction.
Second-Order Functions and Theorems in ACL2 Alessandro Coglio Workshop 2015 Kestrel Institute.
School of Computing and Engineering, University of Huddersfield CIA2326 Week 14 LECTURE: Formal Specifications. How to reason with Algebraic Specifications.
1 Relational Algebra and Calculas Chapter 4, Part A.
Logic in Computer Science - Overview Sep 1, 2009 박성우.
Propositional Calculus CS 270: Mathematical Foundations of Computer Science Jeremy Johnson.
Software Synthesis with ACL2 Eric Smith Kestrel Institute ACL2 Workshop 2015.
DOMAIN MODEL: ADDING ATTRIBUTES Identify attributes in a domain model. Distinguish between correct and incorrect attributes.
Chapter 3 Part II Describing Syntax and Semantics.
Math 1304 Calculus I 2.3 – Rules for Limits.
Automated Reasoning Early AI explored how to automated several reasoning tasks – these were solved by what we might call weak problem solving methods as.
Extra slides for Chapter 3: Propositional Calculus & Normal Forms Based on Prof. Lila Kari’s slides For CS2209A, 2009 By Dr. Charles Ling;
Programming Languages Third Edition Chapter 4 Logic Programming.
Object-Oriented Parsing and Transformation Kenneth Baclawski Northeastern University Scott A. DeLoach Air Force Institute of Technology Mieczyslaw Kokar.
Requirements Engineering Methods for Requirements Engineering Lecture-31.
CSE 311: Foundations of Computing Fall 2013 Lecture 8: Proofs and Set theory.
Chapter – 8 Software Tools.
CSC3315 (Spring 2009)1 CSC 3315 Languages & Compilers Hamid Harroud School of Science and Engineering, Akhawayn University
C HAPTER 3 Describing Syntax and Semantics. D YNAMIC S EMANTICS Describing syntax is relatively simple There is no single widely acceptable notation or.
June 21, Reasoning about explicit strictness in a lazy language using mixed lazy/strict semantics Marko van Eekelen Maarten de Mol Nijmegen University,
Metalogic Soundness and Completeness. Two Notions of Logical Consequence Validity: If the premises are true, then the conclusion must be true. Provability:
A Framework for Automated and Composable Testing of Component-based Services Miguel A. Jiménez, Ángela Villota, Norha M. Villegas, Gabriel Tamura, Laurence.
IS 2620: Developing Secure Systems Formal Verification/Methods Lecture 9 March 15, 2012.
CHAPTER 2 Boolean algebra and Logic gates
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
September 4, 1997 Programming Languages (CS 550) Lecture 6 Summary Operational Semantics of Scheme using Substitution Jeremy R. Johnson TexPoint fonts.
EPISTEMIC LOGIC.
Propositional Calculus: Boolean Algebra and Simplification
Functional Programming
Simplification of Boolean Expressions
OBJ first-order functional language based on equational logic
ONTOMERGE Ontology translations by merging ontologies Paper: Ontology Translation on the Semantic Web by Dejing Dou, Drew McDermott and Peishen Qi 2003.
Presentation transcript:

IFIP WG2.1 meeting, 京都市, Sep Refinement and Transformations in Specware A progress report Alessandro Coglio, Kestrel Institute Stephen Westfold, Kestrel Institute Lambert Meertens, Utrecht University

IFIP WG2.1 meeting, 京都市, Sep Specware Specware is the “flagship” system of Kestrel Institute, developed over a sequence of years The current release is Specware 4.2 Specware is a system that supports the correct-by-construction paradigm: start with a clear spec capturing the functional requirements as transparently as possible, and next massage it by provably correct refinement steps into an implementation

IFIP WG2.1 meeting, 京都市, Sep KIDS versus Specware KIDS (Kestrel Interactive Development System, Doug Smith, 1990) was designed for, and excelled in, transformational programming in the small Specware was designed for system development in the large  unfortunately, the initial designers paid scant attention to the convenience of doing the small steps Recently, Kestrel has begun to address this

IFIP WG2.1 meeting, 京都市, Sep Overview What Specware already had: –Specs, models, and refinement –Metaslang –Spec calculus –Proof obligations What is new: –Refinements refined –Transformations

IFIP WG2.1 meeting, 京都市, Sep Specs spec op isMonotonic? : (Nat  Nat)  Boolean def isMonotonic? f = fa (x, y) (x  y)  (f x  f y) op sq : (Nat  Nat | isMonotonic?) axiom sqDistributesOverTimes is fa (m, n) sq (m  n) = (sq m)  (sq n) endspec

IFIP WG2.1 meeting, 京都市, Sep Models A spec has zero or more models (mathematical “worlds” satisfying the spec) A spec with no models is inconsistent (e.g., one containing axiom foo is 0 = 1 ) The spec on the previous slide has many models, since there are many monotonic functions of type N  N that distribute over multiplication (e.g., the identity function)

IFIP WG2.1 meeting, 京都市, Sep Refinement A spec S is refined by a spec T if the models of S are a superset of those of T all naturals the primes 

IFIP WG2.1 meeting, 京都市, Sep Metaslang Metaslang is the language of the Specware system Metaslang is a typed higher-order language, comparable to ML or Haskell, but allowing “non-constructive” dictions and definitions (e.g., fa and ex ), and constraining the models by axioms. Metaslang has constructs for defining and composing specs and refinements

IFIP WG2.1 meeting, 京都市, Sep Spec calculus Import. Specs can “import” other specs, which then implies that they refine the imported specs Renaming. Types and ops declared in specs can be renamed; generally not a refinement Substitution. If spec S = F (A) contains a subspec A, and we have a refinement R : A  B, the notation S[R] stands for F (B), and S  S[R] is again a refinement

IFIP WG2.1 meeting, 京都市, Sep Proof obligations Proof obligations can be engendered both by specs and by refinements def n : Nat = 5206   9178 requires a proof that the result of evaluating 5206  9762–5537  9178 is nonnegative A refinement of the spec introducing function sq to one defining def sq n = n  n requires a proof that the function thus defined is monotonic and multiplicative

IFIP WG2.1 meeting, 京都市, Sep Connections to provers Generated proof obligations can currently be submitted to two theorem provers (after having been translated to the appropriate logic and language, if possible): –SNARK: an automated first-order prover –Isabelle/HOL: a higher-order prover Proofs of discharged proof obligations can be recorded in specs (in a prover-dependent format)

IFIP WG2.1 meeting, 京都市, Sep Two problems in practice The notion of refinement is too strict, not making a distinction between auxiliary ops that are purely ancillary to formulating the requirements (e.g. isMonotonic? ) and the “main” ops describing the “design object” The mechanisms for creating refinements are too coarse — they are awkward for small steps — and thereby discourage exploration as well as modularity in proofs

IFIP WG2.1 meeting, 京都市, Sep Observable ops We introduce a distinction between “observable” ops and the rest If a, b, and x are observable ops, the semantics of a spec can be given as the characteristic predicate of its set of models: a, b, x: P(a, b, x) If, however, x is not observable but auxiliary, the semantics becomes: a, b:  x: P(a, b, x)

IFIP WG2.1 meeting, 京都市, Sep Refinement refined If the semantics of spec S is given by: a, b:  x: P(a, b, x) while that of T is given by: a, b: Q(a, b) and it is the case that:  a, b: (  x: P(a, b, x))  Q(a, b) then S  T is a valid refinement Thus, auxiliary ops such as x may be “refined away”

IFIP WG2.1 meeting, 京都市, Sep Transformations The spec calculus has been extended by a new construct: transform S by { t0, t1,... } in which t0, t1,... are transformation steps Transformation steps are meaning-preserving edit operations on the text of the spec For example: replace expr by equivalent expr

IFIP WG2.1 meeting, 京都市, Sep Some transformation steps at N — focus on the definition of N first, next, last, previous, widen — move focus lr T — rewrite using equality of theorem T unfold N — unfold definition of N fold N — fold with definition of N simplify( rules ) — simplify using rules eval — evaluate ground terms

IFIP WG2.1 meeting, 京都市, Sep The Transformation Shell The Transformation Shell is an interactive tool (actually functioning as a special mode of the normal Specware Shell) using which users can interactively issue “transformation commands” corresponding to transformation steps, and see each time the result At the end of a session, the Transformation Shell produces a script in the form of a list of transformation steps

IFIP WG2.1 meeting, 京都市, Sep Example script An example of a script produced this way: SimplifiedSpec = transform RefinedSpec by {at construct', unfold iso, lr if_pull, lr if_subst, lr if_subst, SimpStandard, at flip', simplify (unfold iso), move (first), lr if_pull, eval, lr if_pull, lr if_subst, lr if_subst, SimpStandard, lr if_swap}

IFIP WG2.1 meeting, 京都市, Sep Candidate enhancements Refinement libraries On-the-spot introduction of new theorems needed for rewrites Transformation “strategies” (Stratego) User-defined transformation rules Such enhancements should be driven by need

IFIP WG2.1 meeting, 京都市, Sep Conclusion A relatively small effort has achieved a marked improvement in the practical usability of Specware There is still room for further considerable improvements, much of which is still also achievable with relatively small efforts before the law of diminishing returns kicks in