CSE584: Software Engineering

CSE503: Software Engineering
Lecture 17 (February 12, 1999)

David Notkin

Algebraic specifications exploit algebra, as opposed to logic, as the central formalism in proving properties about programs

In general, algebraic specifications are used to capture the semantics of abstract data types, rather than programs in general

ADTs are characterized using heterogeneous algebras

Homogeneous algebras are defined over a single set of elements (alternatively, a single type): for instance, the algebra over integers is homogeneous

Single sets aren't rich enough to capture most interesting ADTs

Strings (as sequences of characters), for instance, have an operation of concatentation (taking two strings and producing a string), as well as length (taking a string and producing an integer)

Consider an ADT defining strings; we might want to

create new strings (initially set to empty)
concatenate strings
appending a new character at the end of a string
determining the length of a given string
checking for empty strings
determining whether two strings are equal

Which sets are needed as part of the specification?

Strings
Char
Nat
Bool
The collection of sets that form the algebra is called its signature and each set is called a sort of the algebra (sometimes heterogeneous algebras are called multi-sorted algebras)

To define a heterogeneous algebra, three parts must be defined at first:

The signature
The operations
The domains and ranges of the operations
Collectively, this definition is called the syntax of the specification

Here's a string specification, using Larch notation:

algebra StringSpec;

introduces

sorts String, Char, Nat, Bool;

operations

new: () -> String

append: String, String -> String

add: String, Char -> String

length: String -> Nat

isEmpty: String -> Bool

equal: String, String -> Bool

Some notes:

The operation new has no arguments (domain), which is a standard way to represent constant functions

Although this part of the specification doesn't say it, new always returns the empty string

The meaning of operations is not specified here
Instead, the algebra's semantics are specified using equations that define properties that must always be true when the operations are applied
These are called axioms of the algebra

Example: concatentating empty string to a string gives the string back; and the string created by adding a char to any string is not an empty string; …

Here are axioms that define the semantics of this algebraic definition of strings

constrains new, append, add, length, isEmpty, equal so that

StringSpec generated by [new, add]

for all [s1, s2, s3: String; c: Char]

isEmpty (new()) = true;

isEmpty (add(s1,c)) = false;

length (new()) = 0;

length (add(s1,c)) = length (s1) + 1

append (s1, new()) = s1

append (s1, add(s2,c)) = add (append(s1,s2), c)

equal (new(), new()) = true

equal (new(), add(s1,c)) = false

equal (add(s1,c), new()) = false

equal (add(s1,c), add(s2,c)) = equal(s1,s2)

end StringSpec

The generated clause indicates that only those two operations can create new strings

One goal is to be able to derive other properties from these axioms

Just like with integer algebra, where commutativity and "x = x +0" allows to prove "x = 0 + x"
append (new(), add (new(), c)) = add (new(), c)

Possible problems with algebraic specifications include:

incompleteness, where we cannot prove additional properties that we indeed want to be true
inconsistency, where we can both prove and disprove some additional property
redundancy, where we have more axioms than we need to to prove additional properties

This may be OK in some cases but, in general, a (close to) minimal set of axioms is desirable

This is very much like Jackson's plea to reply on a small set of designations and phenomena

No state

In an important sense, algebraic specifications are state-less; they don't talk about a store or memory in any way
The equivalent of state is represented using function composition

append(append(append(append(append(append(new(),'a'),'c'),'q'),'u'),'i'),'t')

This is, by axioms, the same as

append(new(),append(append(append(append(append(append(new(),'a'),'c'),'q'),'u'),'i'),'t'))
The first version can be viewed as a canonical representation of that string

Term rewriting

The computations defined by an algebra can be viewed as term rewriting (or tree transformation, if you prefer)

Larch

Larch is one of the more practical notations and systems for defining algebraic specifications (MIT, Guttag, Garland, Horning, and others)
One of the most crucial ideas in Larch, with the goal of making it more practical, is to have a two-tiered specification approach

The top level is called LSL, Larch Shared Language, and it captures the basic specifications as described above
An algebraic specification in Larch (LSL) is called a trait

There are several examples in the handout I provided, including LSL descriptions of a Table trait, of a TaskQueue trait, etc.

The secondary level exploits a programming language-specific language to define the connection (interface) between the LSL and the programming language itself

LCL, for instance, is the interface language for C

A mapping is defined between them
Judgment is used about where to put specific information; on the whole, more in the LSL is better, for reuse and for language independence

LP: The Larch Prover (Larch Proof Assistant)