1 / 14

Protocols

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

flynn-salas
Download Presentation

Protocols

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

More Related