algebraic specification and larch

Katz2004236386--Formal Specifications

Larch 1

Algebraic Specificationand Larch

Formal Specifications of Complex Systems

236368

Shmuel Katz

The Technion


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


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 ]


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.


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?


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


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 sST , i E• pop( push( s, i )) = s• top( push( s, i )) = i• empty( new) = true• empty( push( s, v )) = false


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


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 )


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?


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!


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)


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


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)


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


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 )


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.


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.


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


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 ( it ) ~ isEmpty ( t )


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


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.


Larch 23

What’s in an Interface?

• LOTOS processes are an interface language

• 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


Larch 24

Summary on algebraic specification

• Considered ‘fully abstract’ (compared to Considered ‘fully abstract’ (compared to Z--since state is implicit)Z--since state is implicit)

• Fits well with proof obligations, extends Fits well with proof obligations, extends terminology precisely, treats pure terminology precisely, treats pure functions rather than control or overlapfunctions rather than control or overlap

• Many versions--in LOTOS, Act II is used Many versions--in LOTOS, Act II is used instead of Larchinstead of Larch• Uses libraries, to ‘shield’ users Uses libraries, to ‘shield’ users

algebraic specification and larch

Documents