© bertrand meyer and yishai feldman notice some of the material is taken from object-oriented...

© Bertrand Meyer and Yishai

Feldman

Notice

Some of the material is taken from Object-Oriented Software Construction, 2nd edition, by Bertrand Meyer (Prentice Hall). Included here by permission of ISE, for the benefit of IDC students. Other uses, duplication or distribution require permission from ISE <[email protected]>. For more material see http://eiffel.com


Feldman

Reusability: Table Searchhas (t: TABLE, x: ELEMENT): BOOLEAN is -- Is there an occurrence of x in t?local pos: POSITIONdo from pos := INITIAL_POSITION (x, t) until EXHAUSTED (pos, t) or else FOUND ( pos, x, t) loop pos := NEXT (pos, x, t) end Result := not EXHAUSTED (pos, t)end


Feldman

Requirements on Module Structures

Type Variation (Genericity) Routine Grouping Implementation Variation Representation Independence

(Dynamic Binding) Factoring Out Common Behaviors


Feldman

Table Implementations


Feldman

has for Sequential Tables

has (t: SEQUENTIAL_TABLE; x: ELEMENT): BOOLEAN is -- Is there an occurrence of x in t?do from start until after or else found (x) loop forth end Result := not afterend


Feldman

Sequential Table Operations

start forth after found(x)


Feldman

Sequential Table Implementations

Array

Linked List

File


Feldman

Sequential Tables: Summary

start forth after found(x)Array i := 1 i := i + 1 i > count t@i = xLinkedList

c := first_cell c := c.right c = Void c.item = x

File rewind read end_of_file f = x


Feldman

Syntactic Overloading(Ad-hoc Polymorphism)

square (x: INTEGER): INTEGER is do endsquare (x: REAL): REAL is do endsquare (x: DOUBLE): DOUBLE is do endsquare (x: COMPLEX): COMPLEX is do end

Syntactic Overloading is a facility for clients. It makes it possible to write the same client text when using different implementations of a certain concept.


Feldman

Semantic Overloading(True Polymorphism)

Dynamic binding Supports Representation Independence


Feldman

Genericity

INTEGER_TABLE_HANDLINGELECTRON_TABLE_HANDLINGACCOUNT_TABLE_HANDLING

replaced byTABLE_HANDLING [G]

Generic derivationTABLE_HANDLING [INTEGER]TABLE_HANDLING [ELECTRON]TABLE_HANDLING [ACCOUNT]


Feldman

Role of Genericity

Genericity is a facility for the authors of supplier modules. It makes it possible to write the same supplier text when using the same implementation of a certain concept, applied to different kinds of objects.


Feldman

Abstract Data Types: Criteria

Precise and unambiguous Complete No overspecification!


Feldman

Push:count := count + 1

rep[count] := x

Push:rep[free] := x

free := free – 1

Stacks as Arrays


Feldman

Stacks as Linked Lists

Push: new(n)

n.item := x

n.previous := last

last := n


Feldman

Variations on Stacks


Feldman

Stack Operations

Queries (selectors) item (top): get top element (if non-empty) empty: is stack empty?

Commands (mutators) put (push): add an element on top of the stack remove (pop): remove the top element (if non-

empty) Creator (constructor)

make (new): create a new stack, initially empty


Feldman

Formal ADT Specifications

Types Functions Axioms Preconditions


Feldman

Types

STACK [G]

A type is a collection of objects characterized by functions, axioms, and preconditions. It is a set of objects.

G is a formal generic parameter; to get a specific type, provide an actual generic parameter: STACK [ACCOUNT], or even STACK [STACK [ACCOUNT]].


Feldman

Functions

put: STACK [G] G STACK [G] remove: STACK [G] STACK [G] item: STACK [G] G empty: STACK [G] BOOLEAN new: STACK [G]


Feldman

Axioms

For any x: G, s: STACK [G],A1 • item (put (s, x)) = xA2 • remove (put (s, x)) = sA3 • empty (new)A4 • not empty (put (s, x))


Feldman

Explicit Definition of put Function

put (<count, rep>, x) = <count + 1, rep [count+1: x]>

Relies on specific representation!


Feldman

Reasoning by Axioms (1)

S1 = new

S2 = put (S1, 1)

S3 = put (S2, 2)

E1 = item (S3)


Feldman


S1 = new

S2 = put (S1, 1)

S3 = put (S2, 2)

E1 = item (S3) = item (put (S2, 2)) = 2

A1


Feldman


S1 = new

S2 = put (S1, 1)

S3 = put (S2, 2)

S4 = remove (S3)

E2 = item (S4)


Feldman


S1 = new

S2 = put (S1, 1)

S3 = put (S2, 2)

S4 = remove (S3) = remove (put (S2, 2)) = S2

E2 = item (S4) A2


Feldman


S1 = new

S2 = put (S1, 1)

S3 = put (S2, 2)

S4 = S2

E2 = item (S4) = item (S2) = item (put (S1, 1))

= 1A1


Feldman


S1 = new

S2 = put (S1, 1)

S3 = put (S2, 2)

S4 = remove (S3)

B1 = empty (S4)


Feldman


S1 = new

S2 = put (S1, 1)

S3 = put (S2, 2)

S4 = remove (S3) = S2

B1 = empty (S4) = empty (S2)

= empty (put (S1, 1)) = false

A4


Feldman

Partial Functions

inv : R R

inv (x) = 1/x

inv is not defined for all inputs; its domain is R – 0


Feldman

Preconditions

remove (s: STACK [G]) require not empty (s)

item (s: STACK [G]) require not empty (s)


Feldman

ADT Specification of StacksTYPES• STACK [G]FUNCTIONS• put: STACK [G] G STACK [G]• remove: STACK [G] STACK [G]• item: STACK [G] G• empty: STACK [G] BOOLEAN• new: STACK [G]

AXIOMSFor any x: G, s: STACK [G]A1 • item (put (s, x)) = xA2 • remove (put (s, x)) = sA3 • empty (new)A4 • not empty (put (s, x))PRECONDITIONS• remove (s: STACK [G]) require not empty (s)• item (s: STACK [G]) require not empty (s)


Feldman

Well-Formed Expressions

Expressions built from the ADT's functions applied to arguments of the appropriate type.

new

put (new, x)

item (new)

empty (put (new, x))

put (x)

put (x, new)


Feldman

Correct ADT Expressions

Let f (x1, , xn) be a well-formed expression involving one or more functions on a certain ADT.This expression is correct if and only if all the xi are (recursively) correct, and their values satisfy the precondition of f, if any.


Feldman

Query Expressions

Expressions whose outermost function is a query.

empty (put (put (new, x1), x2))item (put (put (new, x1), x2))


Feldman

Query Expressions

Expressions whose outermost function is a query.

empty (put (put (new, x1), x2)) = falseitem (put (put (new, x1), x2)) = x2


Feldman

Sufficient Completeness

An ADT specification for a type T is sufficiently complete if and only if the axioms of the theory make it possible to solve the following problems for any well-formed expression e:S1 • Determine whether e is correct.S2 • If e is a query expression and has been shown to be correct, express e’s value in a form not involving any value of type T.


Feldman

ADT Consistency

An ADT specification is consistent if and only if, for any well-formed query expression e, the axioms make it possible to infer at most one value for e.


Feldman

Weight

The weight of a well-formed stack expression not involving item or empty is defined inductively as follows:W1 • The weight of the expression new is 0.W2 • The weight of the expression put (s, x) is ws + 1, where ws is the weight of s.W3 • The weight of the expression remove (s) is ws – 1, where ws is the weight of s.


Feldman

Weight Consistency Rule

A well-formed stack expression e, involving neither item nor empty, is correct if and only if its weight is non-negative, and any subexpression of e is (recursively) correct.


Feldman

Zero Weight Rule

Let e be a well-formed and correct stack expression not involving item or empty. Then empty (e) is true if and only if e has weight 0.


Feldman

Induction Proof: Base Case

new is correct since it has no preconditions

empty (new) is true by axiom A3.


Feldman

Inductive Case 1: put

e = put (s, x) put has no preconditions, therefore e is

correct s is correct s and all its subexpressions have non-negative weight e and all its subexpressions have non-negative weight

s is correct weight(s) 0 weight(e) > 0 not empty (e) by A4.


Feldman

Inductive Case 2: remove (Weight Consistency)

e = remove (s) e is correct s and all its subexpressions are

correct and not empty (s) weight(s) > 0 and all subexpressions of e are correct weight(e) 0 and all subexpressions of e are correct


Feldman

Inductive Case 2: remove(Zero Weight)

e = remove (s) weight(s) > 0, therefore s (and also e) has an

instance of put. The outermost put in e is enclosed in remove; use A2 to simplify remove (put (s, x)) = s, reducing e to an expression with the same weight and value but smaller nesting level, for which Zero Weight is true by induction.


Feldman

Canonical Reduction Rule

Any well-formed and correct stack expression involving neither item nor empty has an equivalent “canonical” form that does not involve remove (that is to say, may only involve new and put).The canonical form is obtained by applying the stack axiom A2 as many times as possible.


Feldman

Sufficient CompletenessBase Case

Stack expresssion must be new empty (new) is correct and true by A3 item (new) is incorrect since the

precondition not empty (new) is false.


Feldman

Sufficient Completeness Inductive Case

By induction and canonical reduction, the stack expression can be reduced to new (already handled) or put (s', x).

empty (s) is correct and false by A4 item (s) is correct (since empty (s) is false)

and its value is x by A1


Feldman

Classes

A class is an abstract data type equipped with a possibly partial implementation.


Feldman

Deferred and Effective Classes

A class that is fully implemented is said to be effective.A class that is implemented only partially, or not at all, is said to be deferred (abstract). Any class is either deferred or effective.


Feldman

Elements of Effective Classes

(E1) An ADT specification (E2) A choice of representation. (E3) A mapping from the functions to

the representation in the form of a set of mechanisms, or features (methods), each implementing one of the functions in terms of the representation, so as to satisfy the axioms and preconditions.


Feldman

ARRAY_UP

feature

representation is ARRAY[G]

count is INTEGER

put (x: G) is -- Push x onto stack. -- (No check for possible stack overflow.) do count := count + 1 representation [count] := x end


Feldman

Information Hiding


Feldman

Paradise Lost

put (x: G) is -- Push x on top of stack requireThe precondition, if any doThe appropriate implementation, if known ensure

item = x -- item (put (s, x)) = x not empty -- not empty (put (s, x))end


Feldman

Object-Oriented Software Construction

Object-oriented software construction is the building of software systems as structured collections of possibly partial abstract data type implementations.

© bertrand meyer and yishai feldman notice some of the material is taken from object-oriented...

Documents

table x

stack g stack g item

stack stack account

endsquare x

stack g g stack gremove

x push

x loop

occurrence of x