Katz2004 236386--Formal Specifications Larch 1 Algebraic Specification and Larch Formal Specifications of Complex Systems 236368 Shmuel Katz The Technion.

Slides:



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

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.
Giving a formal meaning to “Specialization” In these note we try to give a formal meaning to specifications, implementations, their comparisons. We define.
Rigorous Software Development CSCI-GA Instructor: Thomas Wies Spring 2012 Lecture 11.
© M. Winter COSC 4P41 – Functional Programming Testing vs Proving Testing –uses a set of “typical” examples, –symbolic testing, –may find errors,
Copyright © 2006 Addison-Wesley. All rights reserved.1-1 ICS 410: Programming Languages Chapter 3 : Describing Syntax and Semantics Axiomatic Semantics.
Program Proving Notes Ellen L. Walker.
Fall Semantics Juan Carlos Guzmán CS 3123 Programming Languages Concepts Southern Polytechnic State University.
CS 355 – Programming Languages
CMPT 354, Simon Fraser University, Fall 2008, Martin Ester 52 Database Systems I Relational Algebra.
Introduction to Computability Theory
School of Computing and Mathematics, University of Huddersfield CAS2545: WEEK 11 LECTURE: n The meaning of Algebraic Specifications TUTORIAL/PRACTICAL:
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.
Course Summary. © Katz, 2003 Formal Specifications of Complex Systems-- Real-time 2 Topics (1) Families of specification methods, evaluation criteria.
© Katz, Spring 2004 CS Formal SpecificationsLecture-- Lamport 1 Lamport ’s State Machines Formal Specifications of Complex Systems CS Spring.
1 Specifying Object Interfaces. 2 Major tasks in this stage: --are there any missing attributes or operations? --how can we reduce coupling, make interface.
Categories of Aspects Shmuel Katz Computer Science Department The Technion Haifa, Israel.
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.
1 מפרטים פורמאליים תירגול מספר 13 מפרטים פורמאליים - תירגול שחר דג LARCH הרמה הראשונה - הרחבת ההגדרה הבסיסית דוגמא – set Initial and Final algebras הרמה.
© Katz, 2007 Formal Specifications of Complex Systems-- Real-time 1 Adding Real-time to Formal Specifications Formal Specifications of Complex Systems.
Course Summary. © Katz, 2007 Formal Specifications of Complex Systems-- Real-time 2 Topics (1) Families of specification methods, evaluation criteria.
Dr. Muhammed Al-Mulhem 1ICS ICS 535 Design and Implementation of Programming Languages Part 1 Fundamentals (Chapter 4) Axiomatic Semantics ICS 535.
CS 330 Programming Languages 09 / 16 / 2008 Instructor: Michael Eckmann.
1 First order theories. 2 Satisfiability The classic SAT problem: given a propositional formula , is  satisfiable ? Example:  Let x 1,x 2 be propositional.
Mathematics throughout the CS Curriculum Support by NSF #
Stack and Queue.
Reading and Writing Mathematical Proofs
Mathematical Modeling and Formal Specification Languages CIS 376 Bruce R. Maxim UM-Dearborn.
1 Program Correctness CIS 375 Bruce R. Maxim UM-Dearborn.
ISBN Chapter 3 Describing Semantics -Attribute Grammars -Dynamic Semantics.
Interpretation Environments and Evaluation. CS 354 Spring Translation Stages Lexical analysis (scanning) Parsing –Recognizing –Building parse tree.
CS 363 Comparative Programming Languages Semantics.
Formal Semantics Chapter Twenty-ThreeModern Programming Languages, 2nd ed.1.
Formal Verification Lecture 9. Formal Verification Formal verification relies on Descriptions of the properties or requirements Descriptions of systems.
1 Chapter 17 Object-Oriented Data Structures. 2 Objectives F To describe what a data structure is (§17.1). F To explain the limitations of arrays (§17.1).
1 Linked-list, stack and queue. 2 Outline Abstract Data Type (ADT)‏ Linked list Stack Queue.
Chapter 3 Part II Describing Syntax and Semantics.
Automated Reasoning Early AI explored how to automated several reasoning tasks – these were solved by what we might call weak problem solving methods as.
SWEN 5130Requirements Engineering Algebraic Specification Slide 1 Algebraic Specification u Specifying abstract types in terms of relationships between.
Chapter 10, Slide 1 ABSTRACT DATA TYPES Based on the fundamental concept of ABSTRACTION:  process abstraction  data abstraction Both provide:  information.
Data Structures & Algorithms
Emilia Katz, Shahar Dag 1 Formal Specifications for Complex Systems (236368) Tutorial #13 Algebraic Specification and Larch.
INM175 Topic 8 1 Module INM175 Discrete Mathematics Topic 8 Algebraic Theories.
ece 627 intelligent web: ontology and beyond
(1) ICS 313: Programming Language Theory Chapter 11: Abstract Data Types (Data Abstraction)
Copyright © 2009 – Curt Hill Standard Template Library An Introduction.
CSSE501 Object-Oriented Development. Chapter 10: Subclasses and Subtypes  In this chapter we will explore the relationships between the two concepts.
Topics in OO, Design Patterns, Reasoning About Program Behavior... (part 2) Neelam Soundarajan Computer Sc. & Eng.
COMP 412, FALL Type Systems II C OMP 412 Rice University Houston, Texas Fall 2000 Copyright 2000, Robert Cartwright, all rights reserved. Students.
CS357 Lecture 13: Symbolic model checking without BDDs Alex Aiken David Dill 1.
CMSC 330: Organization of Programming Languages Operational Semantics.
Faithful mapping of model classes to mathematical structures Ádám Darvas ETH Zürich Switzerland Peter Müller Microsoft Research Redmond, WA, USA SAVCBS.
Collections Using Generics in Collections. 2 Chapter Objectives Define the concept and terminology related to collections Explore the basic structure.
C HAPTER 3 Describing Syntax and Semantics. D YNAMIC S EMANTICS Describing syntax is relatively simple There is no single widely acceptable notation or.
Interpreting the Object Constraint Presented by: Ed Kausmeyer.
M180: Data Structures & Algorithms in Java Stacks Arab Open University 1.
CSE Winter 2008 Introduction to Program Verification February 5 calculating with simplify.
Interface specifications At the core of each Larch interface language is a model of the state manipulated by the associated programming language. Each.
Laurea Triennale in Informatica – Corso di Ingegneria del Software I – A.A. 2006/2007 Andrea Polini IX. System Models (III)
1 Interactive Computer Theorem Proving CS294-9 October 19, 2006 Adam Chlipala UC Berkeley Lecture 9: Beyond Primitive Recursion.
Algebraic Specifications
The Larch Shared Language
Stateful Manifest Contracts
Aspect Validation: Connecting Aspects and Formal Methods
The Metacircular Evaluator
CASL-Common Algebraic Specification Language
Sub-system interfaces
Algebraic Specification Software Specification Lecture 34
Presentation transcript:

Katz Formal Specifications Larch 1 Algebraic Specification and Larch Formal Specifications of Complex Systems Shmuel Katz The Technion

Katz Formal Specifications Larch 2 The Basic Idea Describe a data structure and system through its operations and their effect on each other Operations are functions Axioms describe interactions of functions Extends logic with new terminology

Katz Formal Specifications Larch 3 A Stack signature push: ST x E --> ST pop: ST --> ST top: ST --> E new: --> ST axioms for s  ST and i  E pop( push( s, i )) = s top( push( s, i )) = i [ pop( new ) = undefined ] [ top( new ) = undefined ]

Katz Formal Specifications Larch 4 What have We Defined? Sequences of operations define an algebra of words over operators and variables Axioms define equivalence classes over the words: new = pop( push( new, 5 ) ) push( new, 6 ) = pop( push ( push( new, 6 ), 5 )) Claim: these axioms and signatures define ST, assuming E is already defined.

Katz Formal Specifications Larch 5 A Library Can say everything we need.... checkout: LIB x COPY x USERS --> LIB return: LIB x COPY x USERS --> LIB for a, b, c : COPY, u,v,w: USERS, L: LIB if a=b and u = v then return( checkout ( L, b, v ), a, u ) = L if a  b then return( checkout ( L, b, v), a, u ) = checkout (return( L, a, u ), b, v ) what if a=b and u  v ? or there is no checkout?

Katz Formal Specifications Larch 6 Larch Larch Shared Language with axioms and functions-- new terminology Larch Interface Languages: Input/Output specs. for program units Uses shared language terminology Specific for C, or C++, or Modula3,... LOTOS uses algebraic specification (Act II) and can be viewed as an interface language too LP: the Larch Prover

Katz Formal Specifications Larch 7 Components of the Shared Language stack : trait introduces push: ST x E --> ST pop: ST --> ST top: ST --> E new: --> ST empty: ST --> Bool asserts forall s  ST, i  E pop( push( s, i )) = s top( push( s, i )) = i empty( new) = true empty( push( s, v )) = false

Katz Formal Specifications Larch 8 A Table Tablespec: trait introduces new: --> Table add: Table, Ind, Val --> Table eval: Table, Ind --> Val _  _ : Ind, Table --> Bool isEmpty: Table --> Bool size: Table --> Integer

Katz Formal Specifications Larch 9 Tablespec (cont.) asserts forall i, j : Ind, v: Val, t: Table ~ ( i  new ) i  add( t, j, v ) = ( ( i = j )  ( i  t ) ) eval( add( t, i, v ), j ) = if i = j then v else eval( t, j ) size ( new ) = 0 size( add( t, i, v )) = if i  t then size (t) else size( t ) + 1 isEmpty( t ) = (size( t ) = 0 )

Katz Formal Specifications Larch 10 Notes No error values or undefined: errors are in the Interface Languages trait = characteristic, attribute, property,... Inside a trait a new sort (type) may be defined. How do we know if there are enough axioms?

Katz Formal Specifications Larch 11 Traits and Theories Theory defined by a trait: set of formulas (words) without free variables in typed first-order logic with equality..... the theory has: all axioms and rules of first-order logic all of the assertions in the trait everything that follows from the above Note: nothing else!

Katz Formal Specifications Larch 12 Initial and Final Algebras How should we relate to terms not connected by the axioms? Initial algebra: they must be different. Identify only what must be identified. Final algebra: they are the same. Identify whatever doesn’t violate the theory add( add (t, i, v ), j, v) ? add( add ( t, j, v ), i, v)

Katz Formal Specifications Larch 13 Extra parts of the Shared Language Making Stronger Theories: generated by partitioned by Combining Theories: includes renaming assumes Checking Consistency: implies converts exempting

Katz Formal Specifications Larch 14 S generated by s, t, u “All values of a sort S can be generated by operators s, t, and u” Every word of the algebra with no variables (representing a value of the sort) is equivalent to one that only has some of the operators in the list ST generated by new, push push(pop(push(pop(push(new, 5)),7)),9) = push(new, 9)

Katz Formal Specifications Larch 15 Kinds of Operators For a trait that defines a sort, have Constructors: change the sort Generators are some of these Extensions are the rest new, push, pop Observers: examine the sort top, isEmpty Often need axioms that apply each observer or extension to each generator

Katz Formal Specifications Larch 16 An Induction Rule To prove a property of a sort with “generated by”, use induction only on the words using operators in the list Example: in Tablespec include Table generated by new, add Now it is easy to prove  t: Table, i: Ind. ( (i  t )  ( size( t ) > 0 )

Katz Formal Specifications Larch 17 S partitioned by s, t, u “All distinct values of S can be differentiated by operators s, t, or u” If two words (values) are not equivalent, that can be seen by using the operators on those words. If we cannot distinguish them, they must be equivalent.

Katz Formal Specifications Larch 18 Examples of partition Sets are partitioned by the usual membership operation  : if the elements are the same, so are the sets. Include in Tablespec: Table partitioned by , eval A final algebra approach...now we can prove the order of adding the same element in two places doesn’t matter.

Katz Formal Specifications Larch 19 Renaming Can rename sorts and/or operators from any included trait trait ( new1 for old1, new2 for old2,...) Sparse : trait includes Tablespec ( Arr for Table, Nat for Ind, _[_] for eval, update for add ) Another way: use parameters in the original trait

Katz Formal Specifications Larch 20 Checks and Implications Basic requirement of a trait: internal consistency Claim: cannot ever prove true = false Any trait submitted to LP is checked for such a proof-- but might not catch the problem. Extra checks: implies P “ P can be proven from the rest of the trait ” implies forall t: Table, i: Ind ( i  t )  ~ isEmpty ( t )

Katz Formal Specifications Larch 21 The Larch handbook A library of useful Larch traits Common data structures: stack, queue, binary tree, set, bag, array,... Common properties: equivalence, total ordering,... Reusable components: calendar, symbol table

Katz Formal Specifications Larch 22 Interface Specifications traits provide well-defined terminology to be used in interface specifications Some operators of a trait may not appear in an interface specification for a specific system. Operators of a trait are implemented only if there is a module with such a requirement. A separate language for each Prog. Lang.

Katz Formal Specifications Larch 23 What’s in an Interface? LOTOS processes are an interface language: write push(s,i) in a process Often, input/output spec. for each module of the proposed system (Hoare logic) Inherits all keywords of the programming language, with their semantics var function t^ Uses terms from traits of LSL

Katz Formal Specifications Larch 24 Summary on algebraic specification Considered ‘fully abstract’ (compared to Z--since state is implicit)Considered ‘fully abstract’ (compared to Z--since state is implicit) Fits well with proof obligations, extends terminology precisely, treats pure functions rather than control or overlapFits well with proof obligations, extends terminology precisely, treats pure functions rather than control or overlap Many versions--in LOTOS, Act II is used instead of LarchMany versions--in LOTOS, Act II is used instead of Larch Uses libraries, to ‘shield’ usersUses libraries, to ‘shield’ users