The University of Iowa
CS:2820 (22C:22)
Object-Oriented Software Development
Spring 2015
Operation Contracts
by
Mauricio Monsalve
Design road
l 
l 
l 
We have described:
-  Use Cases
-  Domain Model
-  System Sequence
Diagrams
We now describe
Operation Contracts
Afterwards, we go
into the Design Model
Design road
Sample UP Artifact Relationships
Domain Model
Sale
Business
Modeling
1..*
1
date
...
Sales
LineItem
...
...
quantity
Vision
Use-Case Model
Process Sale
Process
Sale
use
case
names
Cashier
This is
where we
stand right
now
Requirements
Use Case Diagram
1. Customer
arrives ...
2. ...
3. Cashier
enters item
identifier.
Use Case Text
system
events
ideas for
the postconditions
the domain
objects,
attributes,
and
associations
that undergo
changes
Operation:
enterItem(…)
Post-conditions:
-...
Design
requirements
that must be
satisfied by
the software
: System
: Cashier
system
operations
make
NewSale()
Supplementary
Specification
enterItem
(id, quantity)
System Sequence Diagrams
Operation Contracts
starting events to
design for, and
more detailed
requirements that
must be satisfied
by the software
Glossary
: Register
Design Model
: ProductCatalog
enterItem
(itemID, quantity)
spec = getProductSpec( itemID )
addLineItem( spec, quantity )
: Sale
Operation Contracts
l 
l 
l 
l 
Use Cases often fully describe the behavior of a
system
But they may not be enough
Operation Contracts describe how the internal
state of the concepts in the Domain Model may
change
Operation Contracts are described in terms of
preconditions and postconditions
Operation Contracts
This is a sample OC
for “enterItem”
Operation Contracts
l 
Operation Contracts are defined in terms of
system operations
-  Operations (say, methods) that the system
offers as a whole
l 
l 
l 
The system is still a black box at this stage
The System Sequence Diagrams show system
events
-  I.e., the SSD's messages
System operations handle system events
Writing Operation Contracts
Process Sale Scenario
:System
: Cashier
makeNewSale()
loop
[ more items ]
enterItem(itemID, quantity)
these input system events
invoke system operations
description, total
the system event enterItem
invokes a system operation
called enterItem and so forth
endSale()
this is the same as in objectoriented programming when
we say the message foo
invokes the method (handling
operation) foo
total with taxes
makePayment(amount)
change due, receipt
Writing Operation Contracts
Writing Operation Contracts
l 
l 
l 
l 
Operation—name of operation (parameters)
Cross Reference—the Use Cases in which the
OC occurs
Preconditions—noteworthy assumptions about
state of system or objects in DM before
execution
Postconditions—state of objects in DM after
execution of operation
Postconditions
l 
Most important part of OCs!
l 
Include changes in state of DM
l 
Book uses categories (note that the names are
for reference only):
-  Instance creation or deletion
- 
Association formed or broken
- 
Attribute modification
Postconditions
l 
l 
l 
Write in past (passive voice?)
-  A LineSaleItem was created
Readability first
Common mistake—forgetting that instance
creation often implies association formation,
and similarly, that instance deletion often
implies association breaking
Practical summary
l 
Identify system operations from the SSDs
l 
Identify subtle or complex system operations
l 
Construct a contract for each of the above; for
postconditions, use the following categories
l  Instance created-deleted
l 
Attribute modified
l 
Association formed-broken
Credits
Notes and figures adapted from
Applying UML and Patterns: An Introduction to ObjectOriented Analysis and Design and Iterative
Development by C. Larman. 3rd edition. Prentice
Hall/Pearson, 2005.