Algebraic Specification and Larch

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

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

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 ]

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.

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?

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

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

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

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 )

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?

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!

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)

13. Extra parts of the Shared Language • Making Stronger Theories: • generated by partitioned by • Combining Theories: • includes renaming assumes • Checking Consistency: • implies converts exempting

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)

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

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 )

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.

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.

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

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 )

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

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.

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

24. Summary on algebraic specification • 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 overlap • Many versions--in LOTOS, Act II is used instead of Larch • Uses libraries, to ‘shield’ users