The University of Iowa

CS:2820 (22C:22)

Object-Oriented Software Development

Spring 2015



Operation Contracts



by
Mauricio Monsalve
 Design road

l  We have described:

-  Use Cases

-  Domain Model

-  System Sequence
Diagrams

l  We now describe

Operation Contracts

l  Afterwards, we go
into the Design Model

 Design road

Sample UP Artifact Relationships
Domain Model

Sale 1 1..* Sales

Business ...
LineItem
Modeling
date
...
... quantity

Vision
Use-Case Model

Process Sale
Process
Sale
use 1. Customer
case arrives ...
Cashier
names 2. ...
3. Cashier
enters item
identifier. Glossary
Require-

This is
Use Case Diagram Use Case Text
ments
ideas for system
the domain events requirements

where we
the post-
objects, that must be
conditions
attributes, satisfied by
: System
and the software

stand right
associations Operation: : Cashier
that undergo enterItem(…) make Supplementary
changes system NewSale() Specification
operations

now

Post-conditions:
enterItem
-...
(id, quantity)

Operation Contracts System Sequence Diagrams

starting events to
design for, and
more detailed
requirements that Design Model
must be satisfied : Register : ProductCatalog : Sale
by the software
enterItem
Design (itemID, quantity)

spec = getProductSpec( itemID )

addLineItem( spec, quantity )

 Operation Contracts

l  Use Cases often fully describe the behavior of a
system

l  But they may not be enough

l  Operation Contracts describe how the internal

state of the concepts in the Domain Model may
change

l  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  The system is still a black box at this stage

l  The System Sequence Diagrams show system

events

-  I.e., the SSD's messages

l  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

the system event enterItem

description, total invokes a system operation
called enterItem and so forth

this is the same as in object-

oriented programming when
endSale() 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  Operation—name of operation (parameters)

l  Cross Reference—the Use Cases in which the

OC occurs

l  Preconditions—noteworthy assumptions about

state of system or objects in DM before
execution

l  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  Write in past (passive voice?)

-  A LineSaleItem was created

l  Readability first

l  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 Object-
Oriented Analysis and Design and Iterative
Development by C. Larman. 3rd edition. Prentice
Hall/Pearson, 2005.