1. Protocols Software Engineering II Wirfs Brock et al, Designing Object-Oriented Software, Prentice Hall, 1990. Mitchell, R., and McKim, Design by Contract, by Example, Addison-Wesley, 2002 La Trobe University, Data Structure,http://ironbark.bendigo. latrobe.edu.au/courses/subjects/DataStructures/mal/session070/lecture.html

2. Definitions • Responsibility: • Contract: • Signatures:

3. Why do we want to write protocols?

4. Protocol Structure • Signature • Method name • Type of return value • Type of input and output parameters • Description of input, output, input-output parameters • Purpose • Pre-conditions // require • Post-conditions // ensure

5. Process For each class For each contract Specify complete protocol (set of signatures) to support the contract

6. Advice • Make protocols general and useful • The more general a responsibility, the more messages needed to support it. • Define reasonable defaults

7. Example • display() • display (device) • display (region) • display (device, region) • display (device, region, rule) • display (device, region, rule, transform)

8. Specifying Classes • Class: Drawing • Superclasses: Displayable Object • Subclasses: None • Class Diagram: see Fig. 1 • Collaborations Diagram: see Figs. 2-5 • Description: This class represents the … • Contracts • Display itself • This contract is inherited from Displayable Object. • 2. Maintain the elements in a drawing • Know which elements are contained in the drawing • addElement(Drawing Element) • uses List • Pre: what is true before method is called • Post: what is true when the method completes

9. Specifying Classes Example elementAt(Point) returns Drawing Element uses List, Drawing Element (3) Pre: none Post: …

10. Pre-conditions • Capture the conditions that must be true before the method executes • Describe the required state of the ADT or object before entering the function • Written as a statement that is true or false • May consist of statements connected by logical operators (AND, OR) • Use true when no pre-condition exists

11. Post-conditions • Must clearly state what is true when the method completes execution • Describe the expected state upon exiting the function • Should be strong enough so that only correct implementations will satisfy the condition

12. Notes • Generate protocols for main responsibilities • Protocols to public methods must be unambiguous since it is the interface with clients • Protocols to private methods are notes to developer • Common to discover holes in design at this point • Repeat earlier phases of design

13. Example: ADT Stack • Additions are restricted to one end identified as the top of the stack. • Deletions are restricted to the top of the stack. • Only the item at the top of the stack is accessible • A stack is often referred to as a FILO (First In Last Out) list.

14. Stack Operations