© 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. For more material see

© Bertrand Meyer and Yishai Feldman Reusability: Table Search has (t: TABLE, x: ELEMENT): BOOLEAN is -- Is there an occurrence of x in t? local pos: POSITION do 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

© Bertrand Meyer and Yishai Feldman Requirements on Module Structures u Type Variation (Genericity) u Routine Grouping u Implementation Variation u Representation Independence (Dynamic Binding) u Factoring Out Common Behaviors

© Bertrand Meyer and Yishai Feldman Table Implementations

© Bertrand Meyer and Yishai 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 after end

© Bertrand Meyer and Yishai Feldman Sequential Table Operations u start u forth u after u found(x)

© Bertrand Meyer and Yishai Feldman Sequential Table Implementations Array Linked List File

© Bertrand Meyer and Yishai Feldman Sequential Tables: Summary startforthafterfound)x( Arrayi=:1i i+ 1i > count = x Linked List c=:first_cellc=:c.rightc = Voidc.item = x Filerewindreadend_of_filef  =x

© Bertrand Meyer and Yishai Feldman Syntactic Overloading (Ad-hoc Polymorphism) square (x: INTEGER): INTEGER is do  end square (x: REAL): REAL is do  end square (x: DOUBLE): DOUBLE is do  end square (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.

© Bertrand Meyer and Yishai Feldman Semantic Overloading (True Polymorphism) u Dynamic binding u Supports Representation Independence

© Bertrand Meyer and Yishai Feldman Genericity INTEGER_TABLE_HANDLING ELECTRON_TABLE_HANDLING ACCOUNT_TABLE_HANDLING replaced by TABLE_HANDLING [G] Generic derivation TABLE_HANDLING [INTEGER] TABLE_HANDLING [ELECTRON] TABLE_HANDLING [ACCOUNT]

© Bertrand Meyer and Yishai 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.

© Bertrand Meyer and Yishai Feldman Abstract Data Types: Criteria u Precise and unambiguous u Complete u No overspecification!

© Bertrand Meyer and Yishai Feldman Push : count := count + 1 rep[count] := x Push : rep[free] := x free := free – 1 Stacks as Arrays

© Bertrand Meyer and Yishai Feldman Stacks as Linked Lists Push : new(n) n.item := x n.previous := last last := n

© Bertrand Meyer and Yishai Feldman Variations on Stacks

© Bertrand Meyer and Yishai Feldman Stack Operations u Queries (selectors) v item (top): get top element (if non-empty) v empty: is stack empty? u Commands (mutators) v put (push): add an element on top of the stack v remove (pop): remove the top element (if non- empty) u Creator (constructor) v make (new): create a new stack, initially empty

© Bertrand Meyer and Yishai Feldman Formal ADT Specifications u Types u Functions u Axioms u Preconditions

© Bertrand Meyer and Yishai Feldman Types u 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]].

© Bertrand Meyer and Yishai Feldman Functions u put: STACK [G]  G  STACK [G] u remove: STACK [G]  STACK [G] u item: STACK [G]  G u empty: STACK [G]  BOOLEAN u new:  STACK [G]

© Bertrand Meyer and Yishai Feldman Axioms For any x: G, s: STACK [G], A1 item (put (s, x)) = x A2 remove (put (s, x)) = s A3 empty (new) A4 not empty (put (s, x))

© Bertrand Meyer and Yishai Feldman Explicit Definition of put Function put (, x) = Relies on specific representation!

© Bertrand Meyer and Yishai Feldman Reasoning by Axioms (1) S1 = new S2 = put (S1, 1) S3 = put (S2, 2) E1 = item (S3)

© Bertrand Meyer and Yishai Feldman Reasoning by Axioms (2) S1 = new S2 = put (S1, 1) S3 = put (S2, 2) E1 = item (S3) = item (put (S2, 2)) = 2 A1

© Bertrand Meyer and Yishai Feldman Reasoning by Axioms (3) S1 = new S2 = put (S1, 1) S3 = put (S2, 2) S4 = remove (S3) E2 = item (S4)

© Bertrand Meyer and Yishai Feldman Reasoning by Axioms (4) S1 = new S2 = put (S1, 1) S3 = put (S2, 2) S4 = remove (S3) = remove (put (S2, 2)) = S2 E2 = item (S4) A2

© Bertrand Meyer and Yishai Feldman Reasoning by Axioms (5) S1 = new S2 = put (S1, 1) S3 = put (S2, 2) S4 = S2 E2 = item (S4) = item (S2) = item (put (S1, 1)) = 1 A1

© Bertrand Meyer and Yishai Feldman Reasoning by Axioms (6) S1 = new S2 = put (S1, 1) S3 = put (S2, 2) S4 = remove (S3) B1 = empty (S4)

© Bertrand Meyer and Yishai Feldman Reasoning by Axioms (7) 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

© Bertrand Meyer and Yishai Feldman Partial Functions inv : R  R inv (x) = 1/x inv is not defined for all inputs; its domain is R –  0 

© Bertrand Meyer and Yishai Feldman Preconditions remove (s: STACK [G]) require not empty (s) item (s: STACK [G]) require not empty (s)

© Bertrand Meyer and Yishai Feldman ADT Specification of Stacks TYPES 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] AXIOMS For any x: G, s: STACK [G] A1 item (put (s, x)) = x A2 remove (put (s, x)) = s A3 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)

© Bertrand Meyer and Yishai 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)

© Bertrand Meyer and Yishai Feldman Correct ADT Expressions Let f (x 1, , x n ) be a well-formed expression involving one or more functions on a certain ADT. This expression is correct if and only if all the x i are (recursively) correct, and their values satisfy the precondition of f, if any.

© Bertrand Meyer and Yishai Feldman Query Expressions Expressions whose outermost function is a query. empty (put (put (new, x1), x2)) item (put (put (new, x1), x2))

© Bertrand Meyer and Yishai Feldman Query Expressions Expressions whose outermost function is a query. empty (put (put (new, x1), x2)) = false item (put (put (new, x1), x2)) = x2

© Bertrand Meyer and Yishai 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.

© Bertrand Meyer and Yishai 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.

© Bertrand Meyer and Yishai 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.

© Bertrand Meyer and Yishai 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.

© Bertrand Meyer and Yishai 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.

© Bertrand Meyer and Yishai Feldman Induction Proof: Base Case u new is correct since it has no preconditions u empty (new) is true by axiom A3.

© Bertrand Meyer and Yishai Feldman Inductive Case 1: put u e = put (s, x) u 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 u s is correct  weight(s)  0  weight(e) > 0 u not empty (e) by A4.

© Bertrand Meyer and Yishai Feldman Inductive Case 2: remove (Weight Consistency) u e = remove (s) u 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

© Bertrand Meyer and Yishai Feldman Inductive Case 2: remove (Zero Weight) u 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.

© Bertrand Meyer and Yishai 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.

© Bertrand Meyer and Yishai Feldman Sufficient Completeness Base Case u Stack expresssion must be new u empty (new) is correct and true by A3 u item (new) is incorrect since the precondition not empty (new) is false.

© Bertrand Meyer and Yishai Feldman Sufficient Completeness Inductive Case u By induction and canonical reduction, the stack expression can be reduced to new (already handled) or put (s', x). u empty (s) is correct and false by A4 u item (s) is correct (since empty (s) is false) and its value is x by A1

© Bertrand Meyer and Yishai Feldman Classes A class is an abstract data type equipped with a possibly partial implementation.

© Bertrand Meyer and Yishai 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.

© Bertrand Meyer and Yishai 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.

© Bertrand Meyer and Yishai 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

© Bertrand Meyer and Yishai Feldman Information Hiding

© Bertrand Meyer and Yishai Feldman Paradise Lost put (x: G) is -- Push x on top of stack require  The precondition, if any  do  The appropriate implementation, if known  ensure item = x-- item (put (s, x)) = x not empty -- not empty (put (s, x)) end

© Bertrand Meyer and Yishai 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.