Operation Contracts: Getting
ready to open the “System”
black box
All material from Applying UML
and Patterns, 3rd Edition, Craig
Larman, chapter 11.
Operation Contract
 Considered part of the Use Case Model
because they provide more analysis
detail on the effect of the system
operations implied in the use cases
Operation Contracts
 Define the effect of the system
operations on the domain model objects
System Operations
 Operations that the system as a black
box offers in its public interface
Public System Interface
 The entire set of system operations
across all use cases defines the public
system interface, viewing the system as
a single component or class.
System Operations
 Prime inputs to the contracts are the
system operations identified in SSDs
and the domain model
 Contracts in turn serve as input to the
object design as they describe changes
that are likely required in the software
objects or database.
Fig. 11.1
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
Requirements
Use Case Diagram
1. Customer
arrives ...
2. ...
3. Cashier
enters item
identifier.
system
events
ideas for
the postconditions
the domain
objects,
attributes,
and
associations
that undergo
changes
Glossary
Use Case Text
requirements
that must be
satisfied by
the software
: System
Operation:
enterItem(…)
Post-conditions:
-...
: Cashier
system
operations
Design
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
make
NewSale()
: Register
Design Model
: ProductCatalog
enterItem
(itemID, quantity)
spec = getProductSpec( itemID )
addLineItem( spec, quantity )
: Sale
System Operations
 Can be identified in SSDs
Operation Contracts
Process Sale Scenario
:System
: Cashier
makeNewSale()
loop
[ more items ]
enterItem(itemID, quantity)
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
Text, Figure 11.2
these input system events
invoke system operations
Sections of an Operation
Contract
 Operation: Name of the operation and parameters
 Cross References: Use cases and scenarios this
operation can occur within
 Preconditions: Noteworthy assumptions about the
state of the system or objects in the Domain Model
before execution of the operation.
 Postconditions: This is the most important section.
The state of objects in the Domain Model after
completion of the operation
Postconditions: most important
 Describe changes in the state of objects
in the domain model after completion of
the operation
what instances were created ?
 what associations were formed/broken?
 what attributes changed?
 Are not actions to be performed during the
operation

Examples of Operation
Contracts
from Process Sale Use
Case (Fig.11.9)
Operation Contract for
makeNewSale operation
 Operation: makeNewSale()
 Cross References:

Use Case: Process Sale
 Scenario: Process Sale
 Preconditions: none
 Postconditions
 a sale instance “s” was created (instance creation)
 s was associated with the Register (association
formed)
 attributes of s were initialized
What this looks like:
s:Sale was created
association was created
s:Sale
saleDate = currentDate()
saleTime = currentTime()
saleNum = nextSaleNum()
isComplete = false
1
attributes of s:Sale were initialized
1
Register
Example—Operation Contract for
enterItem operation
 Operation: enterItem(itemID,quantity)
 Cross References:

Use Case: Process Sale
 Scenario: Process Sale
 Preconditions: There is a sale underway.
Example—Operation Contract for
enterItem operation
 Postconditions:
 A salesLineItem instance sli was created (instance
creation)
 sli was associated with the current Sale
(association formed)
 sli.quantity became quantity (attribute
modification)
 sli was associated with a ProductDescription,
based on itemId match (association formed)
What this looks like:
associations were created
ProductSpecification
1
s:Sale
saleDate
saleTime
saleNum
isComplete
n
1
1..n
sli.quantity was initialized
to input quantity
sli:SalesLineItem
quantity
sli:SalesLineItem was created
Example—Operation Contract for
endSale operation
 Operation: endSale()
 Cross References:
 Use Case: Process Sale
 Scenario: Process Sale
 Preconditions: There is a sale underway
 Postconditions
 s.isComplete
modification)
became true (attribute
What this looks like:
s:Sale
saleDate
saleTime
saleNum
isComplete
s.isComplete became
true
Example—Operation Contract for
makePayment operation
 Operation: makePayment(amount:Money)
 Cross References:
 Use Case: Process Sale
 Scenario: Process Sale
 Preconditions: There is a sale underway
Example—Operation Contract for
makePayment operation
 Postconditions
 a payment instance “p” was created (instance
creation)
 p.amountTendered became amount (attribute
modification)
 p was associated with s:Sale (association former)
 s:Sale was associated with the Store (association
formed)
What this looks like:
associations were created
Store
1
n
s:Sale
saleDate
saleTime
saleNum
isComplete
p:Payment
amountTendered
1
1
p.amountTendered was
initialized to input amount
p:Payment was created
Why Operation Contracts?
 An excellent tool of OO requirements
analysis that describes in great detail
the changes required by a system
operation (in terms of the domain model
objects) without having to describe how
they are to be achieved
 Excellent preparation for opening the
System black box!