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

Goals of Protocols• Refine design

– – Associate one or more methods (procedures) with

each responsibility

• Define protocols– Protocols

• set of signatures for methods to be implemented

– Signatures• method name, input and output parameters, and return

type

3

Importance of Protocols• Delegate implementation to programmers

– Specialization of personnel (analyst, designer, programmer)

• Program understanding– Maintenance

• Test Cases– Derive test cases from pre and post conditions

• Documentation–

4

Protocol Structure• Signature

– Method name– Type of input and output parameters– Description of input, output, input-output parameters– Description of internal data structures

• Purpose• Pre-conditions // require• Post-conditions // ensure • Uses

5

Properties• All ADTs and objects possess properties

(behavioral rules).• Properties can be stated using a set of Pre- and

Post-conditions for each method.• Properties can be stated using a set of invariants

for each object or ADT.• Good software engineering practice recommends

that you to state Pre- and Post-conditions for all methods.

6

Pre- and Post-conditions• Provide a set of conditions (a contract) that

the implementer of the method must meet

• Help the reader to know what they can expect of the method

7

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)• • Can be written formally or informally

8

Post-conditions• Must clearly state what is true when the

method completes execution

•

• Should be strong enough so that only correct implementations will satisfy the condition

9

Notes

• Generate protocols for main responsibilities– Protocols to public methods must be unambiguous

• Why?

–

• Common to discover holes in design at this point

• Repeat earlier phases of design

10

Example: ADT Stack -1

• 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.

11

Example: ADT Stack -2

• Public operations– Initialize– – Pop– IsEmpty– IsFull– Length

12

Example: ADT Stack -3

• IsEmpty() : boolean – PRE:

•

– POST: •

• The stack is unchanged

13

Example: ADT Stack -4

• pop (): object – PRE:

•

– POST: • If stack is not empty, then return the item from the top of the stack

• The length of the stack at the end of the operation is one less than the length of the stack at the start of the operation

• If stack length is greater than one, then the top of the stack is repositioned to the penultimate item in the stack.

• The remainder of the stack is unchanged.

14

Example: ADT Stack -4 (revisted)

• pop (): object – PRE:

•

– POST: (If stack is not empty, then

(the item from the top of the stack is returned ANDthe length of the stack at the end of the operation is one less than

the length of the stack at the start of the operation ANDthe remainder of the stack is unchanged)) AND

If stack length is greater than one at the start of the operation, then the top of the stack is repositioned to the penultimate item in the stack.

15

Example: ADT Stack -5

• push (IN: item) : void – PRE:

• The stack has been initialized and the stack is not full.

• item contains valid data.

– POST: •

• The top of the stack contains the object passed in as item.

• The remainder of the stack is unchanged.

• The stack is not empty.

16

Example: ADT Stack -6Robustness

• push (IN: item) : void – //Adding to the stack

PRE: // relaxing preconditions

• The stack has been initialized.

– POST: • The size of the stack is incremented by one. • The top of the stack contains the object passed in as item. • The remainder of the stack is unchanged. • The stack is not empty.

– Error conditions:• If the stack is full,

then display error message AND do not change the ADT state• If item does not contain valid data,

then display error message AND do not change the ADT state

17

Specifying Protocols

• Include in Detailed Design section of SDD• For each subsystem, group documentation of classes as

follows:Class: <name>Superclasses: <name> || noneSubclasses: <name> || noneCollaboration Graphs: See Figure <figure number>Description: <class descriptions>Contracts: <list of contracts with brief summary>Private variables: <type> <variable name> <brief description> […

<type <variable name> <brief description>] || noneSee handout for method template

18

Exercise: ADT List

List (void); bool isin (int item);void print (void);void count (void);void print_reverse (void);void insert (int item); void delete(int item);

Write the description and pre- and post- conditions for the following methods: