Introduction to CASL, the Common Algebraic Specification … · 2005. 3. 9. · Introduction to...

Introduction to CASL,the Common Algebraic Specification

LanguageFranz Lichtenberger

Research Institute for Symbolic Computation (RISC)Johannes Kepler University, Linz, Austria

[email protected]linz.ac.at

Franz Lichtenberger http://www.risc.unilinz.ac.at 2

Contents

● Historical remarks● General remarks about CASL● Underlying Concepts● CASL by examples

(Basic Specifications only)


Historical Remarks

● First papers on Algebraic Specification of Abstract Data Types, around 1975: Liskov/Zilles, Guttag/Horning, ADJGroup (Goguen, Thatcher, Wagner, Wright)

● Several AlgSpec languages developed in the next 20 years● CoFI: The Common Framework Initiative for Algebraic

Specification and Development, EUProject, started 1995● The specification language defined by CoFI:

CASL – The Common Algebraic Specification Language


Algebraic Specification

● Observation/Claim/Thesis:● Data types are algebras (set(s)+operations+axioms)● Abstract data types (ADTs) are classes of (usually heterogeneous)

algebras● (Software) Systems can be specified by ADTs.

● Thus:ADTs / Software systems can/should be specified algebraically

● CASL: a language for specifying requirements and designs, not a programming language


CASL

● Core of a family of languages:● restrictable (e.g. for executability)● extendable (higher order, state based, reactive, modal, ...)

● CASL specifications denote classes of models● CASL has a complete formal definition● Abstract and concrete syntax are defined formally● CASL has a complete formal semantics● The foundations of CASL are rocksolid!

(Claim by CoFI)


CASL Specifications

● Basic specifications (this talk)● Structured specifications

● Large and complex specifications are easily built out of simpler ones by means of (a small number of) specification building operations

● Architectural specifications● impose structure on implementations

● Libraries● are named collections of named specifications● The CASL Basic Libraries contain the standard datatypes


Underlying concepts

● CASL is based on standard concepts of algebraic specification● Basic specifications declare symbols, and give axioms and

constraints● The semantics of a basic specification is (a signature and) a

class of models:● A signature ∑ corresponding to the symbols introduced by the

specification● a class of ∑-models, corresponding to those interpretations of the

signature that satisfy the axioms and constraints of the specification● When a model M satisfies a specification SP we write

M \models SP


Specifications

● CASL specifications may declare● sorts● subsorts● operations● predicates

● A spec is called manysorted if it has no subsort specifications (otherwise subsorted)

● A spec is called algebraic if it has no predicate declarations


Sorts

● A sort is a symbol which is interpreted as a set, called a carrier set

● The Elements of carrier sets are abstract representations of data: numbers, characters, lists, trees, etc.

● A sort is approx. a type in a programming language● CASL allows compound sort symbols, i.e.

List[Int]


Subsorts

● Subsort declarations are interpreted as embeddings● Set inclusion would be sufficient for, e.g.

Nat < Int● Embedding is necessaray for, e.g.

Char < String(Char and String are disjoint)

● An embedding is a 11 function


Operations

● Operations may be declared as total or partial● An operation symbol consists of its name together with its profile● Profile: number and sort of arguments, and result sort● An operations is interpreted as a total or a partial function from

the Cartesion product of the carrier sets of the arguments to the carrier set of the result sort

● The result of applying an operation is undefined if any of the arguments is undefined

● Constant: operation with no arguments, interpreted as an element of the carrier set of the result sort


Predicates

● A predicate symbol consists of a name and its profile● Profile: number and sorts of the arguments, but no result sort● Predicates are different from booleanvalued operations!!!● Predicates are used to form atomic formulas, rather than terms● A predicate symbol is interpreted as a relation on (i.e., a subset

of) the Cartesian product of the carrier sets of the argument sorts● Predicates are never undefined, they just do not hold if any of the

arguments is undefined (twovalued logic)● For booleanvalued operations: threevalued logic (true, false,

undefined)


Overloading

● Operation and predicate symbols may be overloaded, i.e.● can be declared with different profiles in the same specification● Examples:

● 'empty' for empty list and empty set● < : predicate on unrelated sorts such as Char and Int

● Overloading has to be compatible with embeddings between subsorts, i.e.

● for sorts Nat < Int, operation +, predicate <:interpretations are required to be such that it makes no difference whether the embedding from Nat to Int is applied to the arguments (and the result) or not


Atomic Formulas

● predicate applications● equations (strong or existential)

● existential: both sides are defined and equal● strong: hold as well, if both sides are undefined

● definedness assertions● subsort membership assertions


Axioms

● Axioms are formulas of firstorder logic● Logical connectors have usual interpretation● Quantification: universal, existential, uniqueexistential● Interpretation of quantification: completely standard!● Variables in formulas range over the carrier sets of specified

sorts● An axiom either holds or does not hold in a particular model:

there is no “maybe” or undefinedness about holdig(regardless of whether the values of terms occurring in the axioms are defined)


Constraints

● Sort generation constraints eliminate “junk” from specific carrier sets, i.e. restrict the class of models

● Default case: all sets allowed as carriers● Generated: no junk

all elements can be obtained by consecutively applying the operations of the sort in question

● Free: no junk, no confusiongenerated, and no equations hold except those implied by the axioms


CASL by examples

● Simple specifications can be written essentially as in many other algebraic specification languages

● CASL provides useful abbreviations and annotations● Tools: the Heterogeneous Tools Set (HETS) is the main analysis

tool for CASL;● it provides a parser, static analysis and translation to an

intermediate/exchange format (so called Aterms)● Useful only together with other tools like theorem provers

(Isabelle/HOL, etc.), SWdevelopment environments, ...● Not tried out yet!


Loose specifications

spec Strict_Partial_Order =%% Let's start with a simple example ! sort Elem pred __<__ : Elem * Elem %% pred abbreviates predicate forall x, y, z:Elem . not (x < x) %(strict)% . (x < y) => not (y < x) %(asymmetric)% . (x < y) /\ (y < z) => (x < z) %(transitive)% %{ Note that there may exist x, y such that neither x < y nor y < x. }%end


Specification extension

spec Total_Order = Strict_Partial_Orderthen forall x, y:Elem . (x < y) \/ (y < x) \/ x = y %(total)%end


Abbreviations

spec Total_Order_With_MinMax = Total_Orderthen ops min(x, y :Elem): Elem = x when x < y else y; max(x, y :Elem): Elem = y when min (x, y) = x else xendabbreviates forall x,y:Elem . min(x,y) = x when x<y else ywhich abbreviates (x<y => min(x,y)=x) /\ (not(x<y) => min(x,y)=y)


Prettyprinting

spec Partial_Order = Strict_Partial_Orderthen pred __<=__(x, y :Elem) <=> (x < y) \/ x = yend

“less or equal” can be prettyprinted using

%display __<=__ %LATEX __\le__

Not tried out yet!


Redundancy with %implies annotation

spec Partial_Order_1 = Partial_Orderthen %implies forall x, y, z:Elem . (x <= y) /\ (y <= z) => (x <= z) %(transitive)%end

Can be used to generate the proof obligation

Partial_Order \models (x <= y) /\ (y <= z) => (x <= z)


Attributes

spec Monoid = sort Monoid ops 1 : Monoid; __*__ : Monoid * Monoid > Monoid, assoc, unit 1end

assoc abreviates, as expected, the following axiom:

forall x,y,z:Monoid . (x*y)*z = x*(y*z)


Generic specifications via parameters

spec Generic_Monoid [sort Elem] = sort Monoid ops inj : Elem > Monoid; 1 : Monoid; __*__ : Monoid * Monoid > Monoid, assoc, unit 1 forall x, y:Elem . inj (x) = inj (y) => x = yend


Datatype declarations by constructors

spec Container [sort Elem] = type Container ::= empty | insert(Elem; Container) pred __is_in__ : Elem * Container forall e, e':Elem; C:Container . not (e is_in empty) . (e is_in insert (e', C)) <=> e = e' \/ (e is_in C)end

Abbreviation for:

sort Container ops empty: Container; insert: Elem * Container > Container


Generated Specifications

spec Generated_Container [sort Elem] = generated type Container ::= empty | insert(Elem; Container) pred __is_in__ : Elem * Container forall e, e':Elem; C:Container . not (e is_in empty) . (e is_in insert (e', C)) <=> e = e' \/ (e is_in C)end

● Generated types allow induction over the constructors!


Free specifications

spec Natural = free type Nat ::= 0 | suc(Nat)end

Equivalent to

generated type Nat ::= 0 | suc(Nat) forall x,y: Nat . suc(x)=suc(y) => x=y forall x:Nat . not(0 = suc(x))


Enumerated types

● Free datatype declarations are particulary convenient for defining enumerated types

spec Color = free type RGB ::= Red | Green | Blue free type CMYK ::= Cyan | Magenta | Yellow | Blackend

With generic instead of free one woud have to add

not(Red=Green) /\ not(Red=Blue) /\ ...


Freeness constraints

spec Integer =free {type Int ::= 0 | suc(Int) | pre(Int) forall x:Int . suc (pre (x)) = x . pre (suc (x)) = x}end


Predicates and freeness

● Predicates hold minimally in models of free specifications

spec Natural_Order = Naturalthenfree {pred __<__ : Nat * Nat forall x, y:Nat . 0 < suc (x) . (x < y) => (suc (x) < suc (y))}end


Inductive definitions of operations/predicates

spec Natural_Arithmetic = Natural_Orderthen ops __+__ : Nat * Nat > Nat; __*__ : Nat * Nat > Nat forall x, y:Nat . x + 0 = 0 . x + suc (y) = suc (x + y) . x * 0 = 0 . x * suc (y) = (x * y) + xend


Partial Functions

● Partial functions arise naturally● Partial functions are declared differently from total functions

spec Set_Partial_Choose [sort Elem] = Generated_Set [sort Elem]then op choose : Set >? Elemend


Partial functions: properties

● Terms containing partial functions may be undefined, i.e., they may fail to denote any value.

● Functions, even total ones, propagate undefinedness.● Predicates do not hold on undefined arguments.● Equations hold when both terms are undefined.● Special care is needed in specifications involving partial

functions


Partial functions: subtle sideeffects

● Asserting choose(S) is_in S as an axiom implies choose(S) is defined for any S.

● Asserting insert(choose(S),S)=S as an axiom implieds that choose(S) is defined for any S.

● If an operation is declared both as a total operation and as a partial operation with the same profile then it is interpreted as a total operation in all models of the specification.


Specifying Domains of Definition

● The domains of definition of partial functions can be specified exacty

spec Set_Partial_Choose_2 [sort Elem] = Set_Partial_Choose [sort Elem]then forall S:Set . def choose(S) <=> not (S = empty) forall S:Set . def choose(S) => choose(S) is_in Send


Domains of definition: specified too implicitely

● Same meaning as previous spec, but some reasoning necessary:

spec Set_Partial_Choose_3 [sort Elem] = Set_Partial_Choose [sort Elem]then . not def choose(empty) forall S:Set . not (S = empty) => choose(S) is_in Send


Partial functions and free specifications

● Partial functions are minimally defined by default in free specifications

spec List_Selectors_1 [sort Elem] = List [sort Elem]thenfree {ops head : List >? Elem; tail : List >? List forall e:Elem; L:List . head(cons(e, L)) = e . tail(cons(e, L)) = L}end


The same, but easier to understand

spec List_Selectors_2 [sort Elem] = List [sort Elem]then ops head : List >? Elem;tail : List >? List forall e:Elem; L:List . not def head(empty) . not def tail(empty) . head(cons(e, L)) = e . tail(cons(e, L)) = Lend


Partial selectors and constructors

● Selectors can be specified concissely in datatype declarations, and are usually partial

spec List_Selectors [sort Elem] = free type List ::= empty | cons(head:?Elem; tail:?List)end


Existential Equality

● Existential equality requires the definedness of both terms as well as their equality

spec Natural_Partial_Subtraction_2 = Natural_Partial_Subtraction_1then forall x, y, z:Nat . y x =e= z x => y = z %{ y x = z x => y = z would be wrong, def (yx) /\ def (zx) /\ y x = z x => y = z is correct, but better abbreviated in the above axiom }%end


Subsorting

● Subsort declaratins directly express relationsships between carrier sets

spec Generic_Monoid_1 [sort Elem] = sort Elem < Monoid ops 1 : Monoid; __*__ : Monoid * Monoid > Monoid, assoc, unit 1end


Inheritance

● Operations on a sort are automatically inherited by its subsortsspec Vehicle = Naturalthen sorts Car, Bicycle < Vehicle ops max_speed : Vehicle > Nat; weight : Vehicle > Nat; engine_capacity : Car > Natend● Inheritance applies also for subsorts that are declared afterwardsspec More_Vehicle = Vehiclethen sort Boat < Vehicleend


● Subsort membership can be checked or assertedspec Speed_Regulation = Vehiclethen ops speed_limit : Vehicle > Nat; car_speed_limit, bike_speed_limit : Nat forall v:Vehicle . (v in Car) => speed_limit(v) = car_speed_limit . (v in Bicycle) => speed_limit(v) = bike_speed_limitend


Subsorts in type declarations

● sorts Car, Bicycle, Boattype Vehicle ::= sort Car | sort Bicycle | sort Boat

● is equivalent to:sorts Car, Bicycle, Boat < Vehicle

● Vehicle 'contains' the union of Car, Bicycle, Boat● generated type Vehicle ::= sort Car | sort Bicycle | sort Boat

Vehicle 'is exactly' the union of Car, Bicycle, Boat● free type Vehicle ::= sort Car | sort Bicycle | sort Boat

Vehicle 'is exactly' the disjoint union of Car, Bicycle, Boat


Explicit definition of subsort values

spec Natural_Subsorts = Natural_Arithmeticthen pred even : Nat . even(0) . not even(1) forall n:Nat . even(suc(suc(n))) <=> even(n) sort Even = {x : Nat . even(x)} sort Prime = {x : Nat . 1 < x

/\ (forall y, z:Nat . x = y * z => y = 1 \/ z = 1)}end


Subsorts and overloading

spec Positive = Natural_Partial_Prethen sort Pos = {x : Nat . not x = 0}end

spec Positive_Arithmetic = Positivethen ops 1 : Pos;suc : Nat > Pos;

__+__, __*__ : Pos * Pos > Pos;__+__ : Pos * Nat > Pos;__+__ : Nat * Pos > Pos

end


Subsorts and partiality

● Using subsorts may avoid the need for partial functionsspec Positive_Pre = Positive_Arithmeticthen op pre : Pos > Natend● instead of then op pre : Nat >? Nat


Supersorts for errors or exceptions

spec Set_Error_Choose [sort Elem] = Generated_Set [sort Elem]then sort Elem < ElemError op choose : Set > ElemError pred __is_in__ : ElemError * Set forall S:Set . not S = empty => (choose(S) in Elem) /\ choose(S) is_in Send


Casting is explicit

spec Set_Error_Choose_1 [sort Elem] = Generated_Set [sort Elem]then sort Elem < ElemError op choose : Set > ElemError forall S:Set . not S = empty => (choose(S) as Elem) is_in Send


Final remarks

● This talk covered only basic specifications● Next talk: Structured specifications and libraries, with examples

of the CASL Basic Libraries● Further topics:

● Arcitectural specifications● Larger application example● Experiments with CASL + a theorem prover (probably ISABELLE)● Logic independence: the institution level

Introduction to CASL, the Common Algebraic Specification … · 2005. 3. 9. · Introduction to...

Documents

Transcript of Introduction to CASL, the Common Algebraic Specification … · 2005. 3. 9. · Introduction to...