Specification and Implementation of Abstract Data Types

cs7100(Prasad) L4-5ADT 1

Data Abstraction• Clients

– Interested in WHAT services a module provides, not HOW they are carried out. So, ignore details irrelevant to the overall behavior, for clarity.

• Implementors– Reserve the right to change the code, to

improve performance. So, ensure that clients do not make unwarranted assumptions.

Specification of Data Types Type : Values + Operations Specify Syntax Semantics Signature of Ops Meaning of Ops

Model-based Axiomatic(Algebraic) Description in terms of Give axioms satisfied standard “primitive” data types by the operations

Syntax of LISP S-expr

• operations: nil, cons, car, cdr, null• signatures:

nil: S-exprcons: S-expr S-expr S-expr car: S-expr S-exprcdr: S-expr S-exprnull: S-expr Boolean

for atom a: a : S-expr

• Signature tells us how to form complex terms from primitive operations.

• Legalnilnull(cons(nil,nil))cons(car(nil),nil)

• Illegalnil(cons)null(null)cons(nil)

Semantics of +: What to expect? + : N x N N

1 + 2 = 3

zero + succ(succ(zero)) = succ(succ(zero))

x + 0 = x

2 * (3 + 4) = 2 * 7 = 14 = 6 + 8

x * ( y + z) = y * x + x * z

Semantics of S-Expr : What to expect?

null(nil) = truecar(cons(nil,nil)) = nilnull(cdr(cons(nil,cons(nil,nil)))) = false

• for all e,f in S-Exprcar(cons(e,f)) = enull(cons(e,f)) = false

Formal Spec. of ADTs Characteristics of an “Adequate” Specification

– Completeness (No “undefinedness”)– Consistency/Soundness (No conflicting definitions)

• MinimalityMinimality

GOAL: Learn to write sound and complete

algebraic(axiomatic) specifications of ADTs

Classification of Operations• Observers

– generate a value outside the type• E.g., null in ADT S-expr

• Constructors– required for representing values in the type

• E.g., nil, cons, atom a in ADT S-expr

• Non-constructors– remaining operations

• E.g., car, cdr in ADT S-expr

S-Expr in LISP a : S-Expr

nil : S-Exprcons : S-Expr x S-Expr S-Exprcar : S-Expr S-Expr cdr : S-Expr S-Exprnull : S-Expr Boolean

Observers : nullConstructors : a, nil, consNon-constructors : car, cdr

Algebraic Spec

• Write axioms (equations) that characterize the meaning of all the operations.

• Describe the meaning of the observers and the non-constructors on all possible constructor patterns.

• Note the use of typed variables to abbreviate the definition. (“Finite Spec.”)

• for all s, t in S-expr

cdr(nil) = ?error? cdr(a) = ?error? cdr(cons(s,t)) = t car(nil) = ?error? car(a) = ?error?

car(cons(s,t)) = s null(nil) = true null(a) = false null(cons(s,t)) = false

• Omitting the equation for “nil” implies that implementations that differ in the interpretation of “nil” are all equally acceptableacceptable.

S-Exprs• car(a) => “unconstrained”

• cons(a,nil) => “S-expr value”

Expression Evaluation:

• car(cons(a,nil)) = a• cons( car(cons(a,nil)), cdr(cons(a,a)) ) =

cons( a , a )

• If car and cdr are also regarded as constructors (as they generate values in the type), then the spec. must consider other cases to guarantee completeness (or provide sufficient justification for their omission).

• for all s in S-expr: null(car(s)) = ...

null(cdr(s)) = ...

Motivation for Classification : Minimality

ADT Table (symbol table/directory)empty : Tableupdate : Key x Info x Table TablelookUp: Key x Table nfo

For all k, ki in Key, i in Info, t in Table:lookUp(k,empty) = errorlookUp(k,update(ki, i, t)) = if k = ki then i else lookUp(k,t)(“last update overrides the others”)

TableTables• empty• update(5, “abc”, empty)• update(10, “xyz”, update(5, “abc”, empty))• update(5, “xyz”, update(5, “abc”, empty))

(Search )• lookup (5, update(5, “xyz”, update(5, “abc”, empty)) ) • lookup (5, update(5, “xyz”, update(5, “xyz”, empty)) )• lookup (5, update(5, “xyz”, empty) )• “xyz”

Implementations– Array-based– Linear List - based– Tree - based

• Binary Search Trees, AVL Trees, B-Trees etc– Hash Table - based

• These exhibit a common Table behavior, but differ in performance aspects (search time).

• Correctness of a program is assured even when the implementation is changed as long as the spec is satisfied.

(cont’d)• Accounts for various other differences (Data

Invariants) in implementation such as

– Eliminating duplicates.– Retaining only the final binding.– Maintaining the records sorted on the key.– Maintaining the records sorted in terms of the

frequency of use (a la caching).

A-list in LISP a : A

nil : A-listcons : A x A-list A-listcar : A-list A cdr : A-list A-listnull : A-list Boolean

• Observers : null, car• Constructors : nil, cons• Non-constructors : cdr

• for all L in A-list

cdr(cons(a,L)) = L

car(cons(a,L)) = a

null(nil) = true null(cons(a,L)) = false

• Consciously silent about nil-list.

Natural Numberszero : succ : add : x iszero : Boolean

observers : iszeroconstructors : zero, succnon-constructors : add

Each number has a unique representation in terms of its constructors.

for all i,j in add(i,j) = ?

add(zero,i) = iadd(succ(j), i) = succ(add(j,i))

iszero(i) = ?iszero(zero) = trueiszero(succ(i)) = false

(cont’d)add(succ(succ(zero)), succ(zero)) = succ(succ(succ(zero))) (*using multi-step rewrite*)

� The first rule eliminates add from an expression, while the second rule simplifies the first argument to add.

� Associativity, commutativity, and identity properties of add can be deduced from this definition through purely mechanical means.

A-list Revisted a : A

nil : A-listlist : A A-listappend : A-list x A-list A-listnull : A-list Boolean

• values – nil, list(a), append(nil, list(a)), ...

Algebraic Spec• constructors

– nil, list, append (Note that a is not an operation (or a constructor) of A-list.)

• Observerfor all l1,l2 in A-listnull(nil) = truenull(list(a)) = falsenull(append(l1,l2)) = null(l1) /\ null(l2)

• Problem : Same value has multiple representation in terms of constructors.

• Solution : Add axioms for constructors.• for all l,l1,l2,l3 in A-list

– Identity Ruleappend(l, nil) = lappend(nil, l) = l

– Associativity Rule append(append(l1, l2), l3)

= append(l1, append(l2, l3))

Intuitive understanding of constructors• The constructor patterns correspond to

distinct memory/data patterns required to store/represent values in the type.

• The constructor axioms can be viewed operationally as rewrite rules to simplify constructor patterns. Specifically, constructor axioms correspond to computations necessary for equality checking and aid in defining a normal form.

• Cf. == vs equal in Java

Writing ADT Specs• Idea: Specify “sufficient” axioms

such that syntactically distinct terms (patterns) that denote the same value can be proven so.

• Note: A term essentially records the detailed history of construction of the value.

General Strategy for ADT Specs

• Syntax– Specify signatures and classify operations.

• Constructors– Write axioms to ensure that two constructor

terms that represent the same value can be proven so.

• E.g., identity, associativity, commutativity rules.

• Non-constructors– Provide axioms to collapse a non-constructor

term into a term involving only constructors.• Observers

– Define the meaning of an observer on all constructor terms, checking for consistency.

Implementation of a type An interpretation of the operations of the ADT

that satisfies all the axioms.

Declarative Specification• Let *: N x N N denote integer

multiplication. Equation: n * n = n Solution: n = 0 \/ n = 1.

• Let f: N x N N denote a binary integer function. Equation: 0 f 0 = 0 Solution: f = “multiplication” \/

f = “addition” \/ f = “subtraction” \/ ...

• for all n, m in N, s in SetSetdelete(n,empty) = emptydelete(n,insert(m,s)) = if (n=m) then delete(n,s) (invalid: s) else insert(m,delete(n,s))

delete(5, insert(5,insert(5,empty)) ) {5,5}== empty {}

=/= insert(5,empty)

delete : SetSet

• Previous axioms capture “remove all occurrences” semantics.

• For “remove last occurrence” semantics:

for all n, m in N, s in ListListdelete(n,empty) = emptydelete(n,insert(m,s)) = if (n=m) then s else insert(m,delete(n,s))

delete(5, insert(5,insert(5,empty)) ) [5,5]== insert(5,empty) [5]

delete : ListList

• Previous axioms capture “remove all / last occurrences” semantics.

• For “remove first occurrence” semantics:

for all n, m in N, s in ListListdelete(n,empty) = emptydelete(n,insert(m,s)) = if (n=m) and not (n in s) then s else insert(m,delete(n,s))

delete(1, insert(1,insert(2,insert(1,insert(5,empty)))) ) [5,1,2,1]

== insert(1,insert(2,insert(5,empty))) [5,2,1]

delete : ListList

size: List vs Set

• size(insert(m,l)) = 1 + size(l)– E.g., size([2,2,2]) = 1 + size([2,2])

• size(insert(m,s)) = if (m in s) then size(s) else 1 + size(s)

– E.g., size({2,2,2}) = size({2,2}) = size ({2}) = 1

Model-based vs Algebraic

• A model-based specification of a type satisfies the corresponding axiomatic specification. Hence, algebraic spec. is “more abstract” than the model-based spec.

• Algebraic spec captures the least common-denominator (behavior) of all possible implementations.

Axiomatization: Algebraic Structures• A set G with operation * forms a group if

• Closure: a,b G implies a*b G.• Associativity: a,b,c G implies a*(b *c) = (a*b)*c.• Identity: There exists i G such that i*a = a*i = a for all a G.• Inverses: For every a G there exists an element ~a G such that a * ~a = ~a * a = i.

• Examples:• (Integers, +), but not (N, +)• (Reals {0}, *), but not (Integers, *)• (Permutation functions, Function composition)

Example car( cons( x, y) ) = x cdr( cons (x, y) ) = y

(define (cons x y) (lambda (m) (cond ((eq? m ’first) x) (eq? m ’second) y) ))) ; “closure”(define (car z) (z ’first))(define (cdr z) (z ’second))

Applications of ADT spec• Least common denominator of all possible

implementations.– Focus on the essential behavior.

• An implementation is a refinement of ADT spec.– IMPL. = Behavior SPEC + Rep “impurities”– To prove equivalence of two implementations,

show that they satisfy the same spec.– In the context of OOP, a class implements an

ADT, and the spec. is a class invariant.

Implementations refine algebraic spec; Equivalence/Substituitivity by abstraction

ADT Spec

Impl. 1 Impl. 2

• Indirectly, ADT spec. gives us the ability to vary or substitute an implementation.

(Cont’d)• ADT spec. are absolutely necessary to automate

formal reasoning about programs. Theorem provers such as Boyer-Moore prover (NQTHM), LARCH, PVS, and HOL routinely use such axiomatization of types.

• Provides a theory of equivalence of values that enables design of a suitable canonical form.

• Identity delete• Associativity remove parenthesis• Commutativity sort

Spec vs ImplThe reason to focus on the behavioral aspects,

ignoring efficiency details initially, is that the notion of a “best implementation” requires application specific issues and trade-offs. In other words, the distribution of work among the various operations is based on a chosen representation, which in turn, is dictated by the pragmatics of an application. However, in each potential implementation, there is always some operations that will be efficient while others will pay the price for this comfort.

Ordered Integer Lists (abbreviated OIL)

null : OIL Booleannil : OIL hd : OIL Inttl : OIL OIL ins : Int x OIL OIL order : Int_list OIL

Constructors: nil, insNon-constructors: tl, orderObservers: null, hd

• Problem: – syntactically different, but semantically equivalent

constructor terms

ins(2,ins(5,nil)) = ins(5,ins(2,nil))ins(2,ins(2,nil)) = ins(2,nil)

– hd should return the smallest element.• It is not the case that for all i in Int, l in OIL,

hd(ins(i,l)) = i. • This holds iff i is the minimum in ins(i,l).

– Similarly for tl.

Axioms for Constructors• Idempotence

– for all Ordered Integer Lists l; for all i in Int ins(i, ins(i, l)) = ins(i, l)

• Commutativity– for all Ordered Integer Lists l; for all i, j in int

ins(i, ins(j, l)) = ins(j, ins(i, l))

Completeness : Any permutation can be generated by exchanging adjacent elements.

Axioms for Non-constructorstl(nil) = errortl(ins(i, l)) = ?tl(ins(i,nil)) = nil

tl(ins(i,ins(J, l))) = i < j => ins(j, tl(ins(i, l)) ) i > j => ins(i, tl(ins(j, l)) ) i = j => tl( ins(i, l ) ) (cf. constructor axioms for duplicate elimination)

order(nil) = nil order(cons(i, l))= ins(i,order(l))

Axioms for Observershd(nil) = error hd(ins(i,nil)) = i

hd(ins(i,ins(j, l))) = i < j => hd( ins(i, l) ) i > j => hd( ins(j, l) )

i = j => hd( ins(i, l) )

null(nil) = true null(ins(i, l)) = false

Scheme Implementation

(define null null?)(define nil ’()) (define ins cons)

(define (hd ol) *min* )(define (tl ol) *list sans min* )

(define (order lis) *sorted list* )

Possible Implementations• Representation Choice 1:

– List of integers with duplicates• ins is cons but hd and tl require linear-time search

• Representation Choice 2: – Sorted list of integers without duplicates

• ins requires search but hd and tl can be made more efficient

• Representation Choice 3: – Balanced-tree : Heap

Abstract Type – ML Style

ADT Set Example

Integer Sets: Algebraic specificationempty : intsetinsert : intset -> int -> intset remove : intset -> int -> intsetmember : intset -> int -> bool

• for all s intset, m,n int: member empty n = false member (insert s m) n = (n=m) orelse (member s n) remove empty n = empty remove (insert s m) n = if (n=m) then remove s n else insert (remove s n) m

abstype intset = Empty | Insert of intset*int with val empty = Empty

fun insert s n = Insert(s,n)

fun member Empty n = false | member (Insert(s,m)) n = (n=m) orelse (member s n) fun remove Empty n = Empty | remove (Insert(s,m)) n = if (n=m) then remove s n else Insert(remove s n, m)end;

val s1 = (insert empty 5);val s2 = (insert s1 3);val s1 = (insert s2 8);

(member s1 8);(member s1 5);(member s1 1);

val s3 = (remove s1 5);(member s3 5);(member s1 5);

abstype intset = Set of int listwith val empty = Set []

fun insert (Set s) n = Set(n::s)

fun member (Set s) n = List.exists (fn i => (i=n)) s

fun remove (Set s) n = Set (List.filter (fn i => (i=n)) s) end;

(* member and remove are not primitives in structure List because they are defined only for equality types. *)

abstype intset = Set of (int -> bool)

with val empty = Set (fn n => false)

fun insert (Set s) n = Set (fn m => (m = n) orelse (s m))

fun member (Set s) n = (s n) fun remove (Set s) n = Set (fn m => (not(m = n)) andalso (s m))end;

More use cases

• Defining polynomials in one variable with operations such as additions, subtraction, scalar multiplication, multiplication, evaluation, division, differentiation, and integration.

anxn + a(n-1)x(n-1) + … + a1x1 + a0

(cont’d)• Defining Description Logic (OWL-DL)

constructs, models (satisfying interpretation), negation normal form, etc.

• Java Data structure APIs : Sets, Lists, Arrays, etc.

• IR : Choosing between implementations: Both Hashtables and Balanced-trees are viable for normal queries, but latter is necessary for wildcard queries.

Specification and Implementation of Abstract Data Types

Documents

RADIOLOGICAL EFFLUENT TECHNICAL SPECIFICATION IMPLEMENTATION … · 2012-12-02 · TECHNICAL EVALUATION REPORT RADIOLOGICAL EFFLUENT TECHNICAL SPECIFICATION IMPLEMENTATION (A-2) NEW

Reuse Repository-Specification Design Implementation

Cs784(Prasad)L34ADT1 Specification and Implementation of Abstract Data Types

Specification of Communication Stack Types · Specification of Communication Stack Types AUTOSAR Release 4.2.2 5 of 28 Document ID 050: AUTOSAR_SWS_CommunicationStackTypes - AUTOSAR

VISA Implementation Specification for Textual Languages

Specification and Implementation Guide for …cars9.uchicago.edu/software/epics/Modbus_over_serial_line_V1_02.pdf · MODBUS over serial line specification and implementation guide

01-068r3 Web Map Service Implementation Specification

VISA Implementation Specification for COM - IVI … Alliance . VPP-4.3.4: VISA Implementation Specification for COM. October 16, 2013. Revision 5.2

Specification-by-Example: A Cucumber Implementation

Specification and Implementation Guide for …...2006/12/20 · MODBUS over serial line specification and implementation guide V1.02 Modbus.org Modbus.org …

From UML Specification into FPGA Implementation

TfNSW TransXChange Implementation Specification...TfNSW TransXChange Implementation Specification Version 2.5.10 Issued: 28 March 2019 Specification Governance Document details Release

VISA Implementation Specification for Textual Languagesivifoundation.org/downloads/Class Specifications... · Web viewThe VISA Implementation Specification for Textual Languages

VISA Implementation Specification for Textual Languages · Web view2016-03-17 · This section introduces the VISA Implementation Specification for Textual Languages. This specification

D3.2.2 Specification and Implementation of Virtualized ... · Deliverable 3.2.2: Specification and Implementation of Virtualized Unified Access interfaces V2 Copyright 2015 VITAL

OpenGIS Coordinate Transformation Service Implementation Specification

Specification of CAN State Manager - autosar.org · AUTOSAR_TPS_ECUConfiguration.pdf [5] Specification of Standard Types AUTOSAR_SWS_StandardTypes.pdf [6] Specification of Communication

THE SPECIFICATION OF DATA TYPES

Ceg860 (Prasad)LADT1 Specification and Implementation of Abstract Data Types Algebraic Techniques

AUTOMATING SPECIFICATION TO IMPLEMENTATION SOFTWARE