Sub-system interfaces

Slides:



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

PROOF BY CONTRADICTION
Semantics Static semantics Dynamic semantics attribute grammars
A System to Generate Test Data and Symbolically Execute Programs Lori A. Clarke September 1976.
Addressing the Challenges of Current Software. Questions to Address Why? What? Where? How?
1 How to transform an analyzer into a verifier. 2 OUTLINE OF THE LECTURE a verification technique which combines abstract interpretation and Park’s fixpoint.
© M. Winter COSC 4P41 – Functional Programming Testing vs Proving Testing –uses a set of “typical” examples, –symbolic testing, –may find errors,
1 Dependent Types for Termination Verification Hongwei Xi University of Cincinnati.
8. Introduction to Denotational Semantics. © O. Nierstrasz PS — Denotational Semantics 8.2 Roadmap Overview:  Syntax and Semantics  Semantics of Expressions.
Formal Semantics of Programming Languages 虞慧群 Topic 5: Axiomatic Semantics.
Copyright © 2006 Addison-Wesley. All rights reserved.1-1 ICS 410: Programming Languages Chapter 3 : Describing Syntax and Semantics Axiomatic Semantics.
Fall Semantics Juan Carlos Guzmán CS 3123 Programming Languages Concepts Southern Polytechnic State University.
CHAPTER 3 COLLECTIONS Abstract Data Types. 2 A data type consists of a set of values or elements, called its domain, and a set of operators acting on.
Constraint Logic Programming Ryan Kinworthy. Overview Introduction Logic Programming LP as a constraint programming language Constraint Logic Programming.
Katz Formal Specifications Larch 1 Algebraic Specification and Larch Formal Specifications of Complex Systems Shmuel Katz The Technion.
CHAPTER 3 COLLECTIONS SET Collection. 2 Abstract Data Types A data type consists of a set of values or elements, called its domain, and a set of operators.
Sparkle A theorem prover for the functional language Clean Maarten de Mol University of Nijmegen February 2002.
©Ian Sommerville 2000Software Engineering, 6/e, Chapter 91 Formal Specification l Techniques for the unambiguous specification of software.
Dr. Muhammed Al-Mulhem 1ICS ICS 535 Design and Implementation of Programming Languages Part 1 Fundamentals (Chapter 4) Axiomatic Semantics ICS 535.
MCA –Software Engineering Kantipur City College. Topics include  Formal Methods Concept  Formal Specification Language Test plan creation Test-case.
Advanced Database CS-426 Week 2 – Logic Query Languages, Object Model.
©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 9 Slide 1 Formal Specification l Techniques for the unambiguous specification of software.
CAS- 734 (Presentation -1) By : Vasudha Kapil
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.
1 Program Correctness CIS 375 Bruce R. Maxim UM-Dearborn.
Introduction to Formal Methods Based on Jeannette M. Wing. A Specifier's Introduction to Formal Methods. IEEE Computer, 23(9):8-24, September,
Overview of Formal Methods. Topics Introduction and terminology FM and Software Engineering Applications of FM Propositional and Predicate Logic Program.
WXGE6103 Software Engineering Process and Practice Formal Specification.
More About Classes Ranga Rodrigo. Information hiding. Copying objects.
CS 363 Comparative Programming Languages Semantics.
Formal Verification Lecture 9. Formal Verification Formal verification relies on Descriptions of the properties or requirements Descriptions of systems.
Cs7120 (prasad)L7-TDEF1 Type Definitions. cs7120 (prasad)L7-TDEF2 Concrete Types Primitive types ( int, bool, char, string, etc ) Type constructors (
Programming Languages and Design Lecture 3 Semantic Specifications of Programming Languages Instructor: Li Ma Department of Computer Science Texas Southern.
Ceg860 (Prasad)LADT1 Specification and Implementation of Abstract Data Types Algebraic Techniques.
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.
SWEN 5130Requirements Engineering Algebraic Specification Slide 1 Algebraic Specification u Specifying abstract types in terms of relationships between.
Formal Methods in Software Engineering Credit Hours: 3+0 By: Qaisar Javaid Assistant Professor.
Data Structures and Algorithms Dr. Tehseen Zia Assistant Professor Dept. Computer Science and IT University of Sargodha Lecture 1.
A theory of DbC for multiparty distributed interactions Emilio Tuosto University of Leicester Nobuko Yoshida Imperial College London Kohei Honda Queen.
© 2006 Pearson Addison-Wesley. All rights reserved 2-1 Chapter 2 Principles of Programming & Software Engineering.
272: Software Engineering Fall 2012 Instructor: Tevfik Bultan Lecture 9: Test Generation from Models.
Copyright © Cengage Learning. All rights reserved. CHAPTER 4 ELEMENTARY NUMBER THEORY AND METHODS OF PROOF ELEMENTARY NUMBER THEORY AND METHODS OF PROOF.
Faithful mapping of model classes to mathematical structures Ádám Darvas ETH Zürich Switzerland Peter Müller Microsoft Research Redmond, WA, USA SAVCBS.
Interface specifications At the core of each Larch interface language is a model of the state manipulated by the associated programming language. Each.
Prof. I. J. Chung Data Structure #1 Professor I. J. Chung.
Maitrayee Mukerji. INPUT MEMORY PROCESS OUTPUT DATA INFO.
Formal Specification.
By P. S. Suryateja Asst. Professor, CSE Vishnu Institute of Technology
Abstract Data Type.
Sparkle a functional theorem prover
Input Space Partition Testing CS 4501 / 6501 Software Testing
The Larch Shared Language
Type Definitions cs776 (prasad) L8tdef.
Algebraic Specification
Lecture 5 Floyd-Hoare Style Verification
A Design Structure for Higher Order Quotients
Denotational Semantics (Denotational Semantics)
The specification is written in LCL
CS 220: Discrete Structures and their Applications
CSE S. Tanimoto Introduction to ML
CSE S. Tanimoto Introduction to ML
Class Greeting.
CASL-Common Algebraic Specification Language
Motivation for Language Specification
CSE S. Tanimoto Introduction to ML
OBJ first-order functional language based on equational logic
CSE S. Tanimoto Introduction to ML
COP4020 Programming Languages
Presentation transcript:

Sub-system interfaces Sub-system A Sub-system B

Larch Family of Languages Family of Specification Languages Specification components: Larch Shared Language – common to all languages Larch Interface Language – particular to specific PL LSL: an algebraic language LIL: tailored to a programming language

Larch Interface Language (Larch/L) Two-tiered specification in Larch Programming Language L Program unit Implementation satisfies Larch Interface Language (Larch/L) Interface spec Local Specification Based on Root trait Incorporates (includes, imports, or assumes) Larch shared language … Trait Trait Two-tiered specification in Larch

Some Aspects of Larch Languages Composability. Incremental construction of specifications from other specifications Emphasis on Presentation. Readable. Larch composition mechanisms are operations on specification, rather than on theories or models. Suitability for integrated interactive tools. Good for interactive construction and incremental checking of specs. Semantic Checking. Checking of specs when they are being constructed. (i.e. theorem prover for semantic checking)

Trait: is the basic unit of specification in LSL Trait: is the basic unit of specification in LSL. It introduces operators and specifies their properties. Sometimes collection of operators correspond to an ADT. Theory: is a set of theorems that can be proved about the terms defined in a trait. Theory contains equations and inequation (~(true = false)) that can be proved by substituting equal for equal. BUT, if 2 terms can not be proven to be equal then they are not necessarily unequal. Also if two terms are not provably unequal, it does not mean they are equal. Signature: domains and ranges of the operators used for sort-check (similar to type-check in PL). Constraints: limit the operators by means of equations that relate the terms containing them.

Larch Interface Language (LIL) Localized programming language dependencies Each LIL encapsulates features needed to write specifications in a particular Programming Language and incorporates LSL in a uniform way.

Larch Prover (LP) LP is an interactive theorem proving system for multi-sorted first-order logic Assist users in finding and correcting flaws in conjectures Works efficiently on large problems Is not designed to find difficult proofs automatically Checks for syntax and type errors in LSL specifications Two files of input suitable for use with LP: LP axiomatization for an LSL specification LP proof obligations associated with logical claims made by specifiers about the logical properties of their specifications

The Larch Shared Language (LSL) LSL specifications define two kinds of symbols, operators and sorts. operators stand for total functions from tuples of values to values. Sorts stand for disjoint non-empty sets of values, and are used to indicate the domains and ranges of operators. The trait is the basic unit of specification in LSL. A trait introduces some operators and specifies some of their properties. Sometimes the trait defines an abstract type. However, it is frequently useful to define a set of properties that does not fully characterize a type.

Example - Table Table: trait includes Integer introduces new:  Tab add: Tab, Ind, Val  Tab - - : Ind, Tab  Bool lookup: Tab, Ind  Val size: Tab  Int

Example - Table asserts  i, i1: Ind, v: Val, t: Tab (i  new); i  add(t, i1, v) == i = i1  i  t; lookup(add(t, i, v), i1) == if i = i1 then v else lookup(t, i1); size(new) == 0; size(add(t, i, v)) == if i  t then size(t) else size(t) + 1