1. 1 Specifying Object Interfaces

2. 2 Major tasks in this stage: --are there any missing attributes or operations? --how can we reduce coupling, make interface simple? * what operations are public/private/protected? * what are input parameters of each operation? * what is the return type of each operation? --what “contracts” are there? (pre and post conditions, e.g.)

3. 3 Developers participating in class specification: * implementer—designs internal data structures and code for the class * user—will use the class as an application—must know boundary (interface specification) for the client class they are developing * extender—develops specialized version of the class— interface specifications provide constraints to this developer

4. 4 Preconditions, postconditions, invariants “contracts”: useful in white box and black box testing, include preconditions, postconditions, and invariants (loop or class, e.g.). Example: how do you ensure --there is no division by zero? --array bounds are not exceeded? --I/O error does not cause system crash? --faulty / missing component does not cause system crash? Also important in formal methods specifications

5. 5 Preconditions, postconditions, invariants--definitions precondition: logical condition that a caller of an operation guarantees before making the call postcondition: logical condition that an operation guarantees upon completion invariant: logical condition that is preserved by transformations example: loop invariant is preserved by the transformations effected by the loop instructions

6. 6 Example--stacks, queues, division example: what would be preconditions for common stack operations? What would be postconditions? Push: Pop: Isempty?: Top: what about a queue? What about division? (precondition; postcondition—e.g., type)

7. 7 Loop invariant example: does this program compute a n for n > 0? Algorithm strategy? float pow(float a, int n) { float r = 1; while (n > 0) {{if (n%2 == 0) {a = a*a;n=n/2;} else {r=r*a; n=n-1;} } return r; } "proof" using an invariant that this program is correct: let a in, n in be inputs; invariant: r x a n = a in ** n in proof:1. Invariant holds before entering loop first time 2. Invariant holds after iteration i if it held at iteration i-1 3. So, by induction, invariant is true for n > 0 3. Now, if loop terminates, n = 0, so we program does compute a n

8. 8 Other invariants example: class invariant is preserved by all class operations e.g., the size of an array is always >= 0 interface invariants: for public sections (users) implementation invariants: for class implementations (designers, coders)

9. 9 Invariants--examples example: suppose we have a bounded stack of floating point numbers interface invariant: after a push, the stack is no longer empty s.push(x) => not (s.empty) if the stack is not full and we push an element on the stack, then calling pop returns that element: not(s.full) and s.push(x); y=s.pop => x = y these make no reference to the particular implementation

10. 10 Invariants--examples (cont.) Implementation invariant: example: if we implement the stack as a bounded array then an invariant is that the stack pointer is within the array bounds using invariants in program: c++: assert c++, java: error checking--(e.g., try, catch) note: including checking increases program length, decreases efficiency

11. 11 Expressing constraints: Can use natural language or a special language such as OCL (Object Constraint Language) Constraint is a boolean expression, returns value true or false Constraint can be: --attached to an entry in the CRC card if desired (example: figure 9.4)—leads to cluttered documents --specified by keyword context

12. 12 Examples from text (this form or syntax in figure 9-5, page 360 should be used in object comments in project): context Tournament inv: self.getMaxNumPlayers( ) > 0 context Tournament::acceptPlayer(p:Player) pre: !is PlayerAccepted(p) context Tournament::acceptPlayer(p:Player) pre: getNumPlayers( ) < getmaxNumPlayers( ) context Tournament::acceptPlayer(p:Player) post: isPlayerAccepted(p)

13. 13 Useful OCL syntax: Collections of objects: distinguishes among sets, sequences, bags --set: for a single association --sequence: used for navigating a single ordered association --bag: may contain the same object multiple times (differs from set) Useful operations on collections: Size includes(object)—member select(expression)—members which satisfy given condition union(collection) interstction(collection) asSet(collection)—returns the set of members of the collection Quantifiers: forAll; exists We will revisit these concepts when we discuss formal methods

14. 14 Object design—steps: ---Identify missing attributes and operations ---specify types, signatures (e.g. is a collection ordered or not?), and visibility of each attribute and operation --specify pre and post conditions --specify invariants --note any inherited contracts --document the process in the Object Design Document --assign development responsibilities to developer team