# State Machines and Statecharts by ert554898

VIEWS: 3 PAGES: 24

• pg 1
```									               Algebraic Specification
and Larch
Shmuel Katz
The Technion

Formal Specifications of
Complex Systems
236368

Katz2004        Larch 1
236386--Formal Specifications
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

Katz2004   Larch 2
236386--Formal Specifications
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                 ]
Katz2004       Larch 3
236386--Formal Specifications
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.
Katz2004       Larch 4
236386--Formal Specifications
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?
Katz2004   Larch 5
236386--Formal Specifications
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

Katz2004   Larch 6
236386--Formal Specifications
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
Katz2004   Larch 7
236386--Formal Specifications
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

Katz2004   Larch 8
236386--Formal Specifications
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 )

Katz2004      Larch 9
236386--Formal Specifications
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?

Katz2004    Larch 10
236386--Formal Specifications
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!

Katz2004      Larch 11
236386--Formal Specifications
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)

Katz2004         Larch 12
236386--Formal Specifications
Extra parts of the Shared Language

• Making Stronger Theories:
•       generated by      partitioned by

• Combining Theories:
•   includes   renaming                     assumes

• Checking Consistency:
•    implies converts                       exempting

Katz2004               Larch 13
236386--Formal Specifications
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)
Katz2004       Larch 14
236386--Formal Specifications
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
Katz2004     Larch 15
236386--Formal Specifications
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 )

Katz2004     Larch 16
236386--Formal Specifications
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.

Katz2004        Larch 17
236386--Formal Specifications
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.

Katz2004       Larch 18
236386--Formal Specifications
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
Katz2004       Larch 19
236386--Formal Specifications
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 )
Katz2004        Larch 20
236386--Formal Specifications
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

Katz2004     Larch 21
236386--Formal Specifications
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.
Katz2004        Larch 22
236386--Formal Specifications
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
Katz2004        Larch 23
236386--Formal Specifications
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