Object-Oriented Analysis and Design
CHAPTER 11, 32: OPERATION CONTRACTS & SYSTEM SEQUENCE
DIAGRAMS
1
What will we learn?
Operation Contracts – how to define the system operations, and
how to create contracts for them
Define SSDs and Operation Contracts for the example case studies
2
Operation Contracts
Often, the use cases and SSDs are enough to describe the system
Sometimes, more detail of the system behavior is required, and that is where
Operation Contracts are used
The Use-Case Model and Domain Model are the main OOA artifacts, but
Operation Contracts and State Models are also helpful
Remember the SSDs are part of the Use-Case Model artifact
Actually, the Operation Contracts are considered part of the Use-Case Model,
since they usually expand upon the SSD
3
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.
Use Case Text
system
events
ideas for
the postconditions
the domain
objects,
attributes,
and
associations
that undergo
changes
Glossary
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
: Sale
enterItem
(itemID, quantity)
spec = getProductSpec( itemID )
addLineItem( spec, quantity )
4
Operation Contracts
Operation Contracts describe pre- and post-condition changes to the objects in the Domain
Model as a result of a system operation. They are text based documentation.
Before looking at them in detail, let’s consider an example (terms like (instance creation) are
added for explanation in this example, and would not be part of the actual contract):
Contract CO2: enterItem
Operation:
Cross Reference:
Preconditions:
Postconditions:
enterItem(itemID: itemID, quantity: integer)
Use Cases: Process Sales
There is a sale underway
-A SalesLineItem instance sli was created (instance creation)
-sli was associated ith the current Sale (association formed)
-sli.quantity became quantity (attribute modification)
-sli was associated with a ProductDescription, based on itemID match
(association formed)
5
Operations Contracts - Sections
The sections of an Operations Contract are:
Operation:
Name of the operation, and parameters
Cross References:
Use cases 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. These are
non-trivial assumptions the reader should be aware of.
Postconditions:
The most important section. The state of objects in the Domain
Model after the completion of the operation.
6
System Operations
System operations can be thought of as operations the system (as a black-box)
offers to its users
They are identified when the SSDs are created
The SSDs show system events which usually trigger system operations
Some of the system events are input events (see next slide)
The entire set of system operations, across all use cases, defines a public
interface which views the system as one single component or class.
7
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
8
Operation Contracts: Postconditions
The postcondition describes changes in the state of objects in the Domain
Model. Such changes include instance creation, associations formed or broken,
and attributes changed.
Note that postconditions are not actions to be performed during the operation!
Postconditions describe the changes to the object, they do not explain how the
changes are done
Breaking an association is rare, but can happen (cancel sale, for example)
Instance deletion is also rare; remember, we are still in the Domain Model, not
the actual software classes, so freeing up memory is not an issue
9
Operation Contracts: Postconditions
The instances and associations that are created by an Operation Contract appear in the Domain
Model – the contract should capture the behavior expressed in the Use Case Model as it relates
to the objects and associations in the Domain Model
Note that postconditions (and in fact Operation Contracts) are optional – not every operation
needs a contract, and often the postconditions are obvious and do not need to be documented
This is another tool to help understand the system behavior
Again, this is an analysis tool – it will help define what changes, not how it changes
Usually postconditions are written in the past tense – A SalesLineItem was created, not is
created
10
Example: enterItem Postconditions
Look at the types of changes identified in the enterItem postcondition
First, recall the Main Scenario of the Process Sale use case (pg 69 of the book):
Main Success Scenario:
…
3. Cashier enters item identifier
4. System records sale line item and presents item description, price, and running total. Price
calculated from a set of price rules.
…
Also, recall the Domain Model and SSD for this example (next slides):
11
Sales
Customer
Captured-on
1
1
Initiates
Records-sales-on
1
Tax
LineItem
description
percentage
amount
Sale
1
Core::
Register
1
1
SalesLineItem
1..*
1
date
isComplete
time
*
1
Cashier
1..* /quantity
Logs-completed
1
Core::
Store
12
Products
Sales::
SalesLineItem
Described-by
0..1
*
1
Product
Description
ProductCatalog
1..*
1
description
price
itemID
1
Records-sale-of
Describes
*
Core::
Store
Stocks
1
*
Item
1
13
Process Sale Scenario
:NextGenPOS
System
: Cashier
«actor»
:TaxCalculator
makeNewSale
loop
[ more items ]
enterItem(itemID, quantity)
description, total
endSale
taxLineItems =
getTaxes( sale )
total with taxes
14
Operation Contracts
Contract CO2: enterItem
Operation:
Cross Reference:
Preconditions:
Postconditions:
enterItem(itemID: itemID, quantity: integer)
Use Cases: Process Sales
There is a sale underway
-A SalesLineItem instance sli was created (instance creation)
-sli was associated ith the current Sale (association formed)
-sli.quantity became quantity (attribute modification)
-sli was associated with a ProductDescription, based on itemID match
(association formed)
15
enterItem Postcondition: Putting it Together
Instance Creation and Deletion:
After itemID and quantity have been entered by the Cashier, the SalesLineItem object is created
This can be determined by the use case and Domain Model (composition of Sales)
Hence the postcondition: “A SalesLineItem instance sli was created”
Attribute Modification:
From the Domain Model, we see that the quantity attribute of the SalesLineItem is derived, or
calculated. This value is entered by the Cashier (not mentioned in the use case, but shown in the
SSD).
This gives the postcondition: “sli.quantity became quantity”
16
enterItem Postcondition: Putting it Together
Associations Formed or Broken:
After itemID and quantity are entered by the Cashier, and after we create the new SalesLineItem
object, we must form an association with the ProductDescription object, as noted in the Domain
Model. The new SalesLineItem is also associated with the Sale object. This gives the following
postconditions:
“sli was associated with the current Sale.”
“sli was associated with a ProductDescription, based upon itemID match”
Note that the original Domain Model did not show the SalesLineItem to ProductDescription
association as being qualified by itemID, but this does not mean we can’t include text in the
postcondition that describes how sli is associated with ProductDescription.
17
Review
How to analyze a system:
Use cases: Identify the main actors, and create the stories of how they interact. Add in details for each
scenario
Domain Model: Identify the main conceptual classes (look for nouns in the use cases) and how they are
associated with each other (look for verbs in the use cases)
System Sequence Diagrams: Create diagrams that show the system events that occur between the system
(as one big black box) and the users
Operations Contracts – detail any system operations that occur to impart changes to the system objects as
a result of the system events – relies on Domain Model, use cases, and SSDs
The use cases (text) and possible use case diagram, SSDs, and Operations Contracts make up the
Use-Case Model artifact in UP
The Domain Model is a separate artifact, sometimes included in the Business Modeling artifact
18
How to Create Operations Contracts
1.
Identify the system operations from the SSDs
2.
For complex system operations, or operations that may be subtle or not clearly understood,
construct a contract
3.
To describe the postconditions, use the following categories:
1.
2.
3.
Instance creation or deletion
Attribute modification
Associations formed or broken
Tip: Always use past tense, and if an instance is created, make sure you add an association for the
new instance.
19
system as black box
Back to the Process Sale use case SSD:
the name could be "NextGenPOS" but "System" keeps it
simple
the ":" and underline imply an instance, and are explained in a
later chapter on sequence diagram notation in the UML
external actor to
system
Process Sale Scenario
:System
: Cashier
makeNewSale
a UML loop
interaction
frame, with a
boolean guard
expression
loop
[ more items ]
enterItem(itemID, quantity)
description, total
endSale
return value(s)
associated with the
previous message
an abstraction that
ignores presentation
and medium
the return line is
optional if nothing is
returned
total with taxes
makePayment(amount)
a message with
parameters
it is an abstraction
representing the
system event of
entering the
payment data by
some mechanism
change due, receipt
20
NextGen POS Operation Contracts
Contract CO1: makeNewSale
Operation:
Cross References:
Preconditions:
Postconditions:
makeNewSale()
Uses cases: Process Sale
none
- A Sale instance s was created
- s was associated with a Register
- Attributes of s were initialized
Note that for this case, the contract is obvious and probably would not actually be written.
Remember, these are system description tools, and we are not trying to document every change
in the system; we just need to explain any operations that may not be obvious.
21
NextGen POS Operation Contracts
Contract CO2: enterItem
Operation:
Cross Reference:
Preconditions:
Postconditions:
enterItem(itemID: itemID, quantity: integer)
Use Cases: Process Sales
There is a sale underway
-A SalesLineItem instance sli was created
-sli was associated with the current Sale s
-sli.quantity became quantity
-sli was associated with a ProductDescription, based on itemID match
We saw this example earlier; this is more detailed and not as obvious as CO1, so it is reasonable
to include this.
22
NextGen POS Operation Contracts
Contract CO3: endSale
Operation:
Cross Reference:
Preconditions:
Postconditions:
endSale()
Use Cases: Process Sales
There is a sale underway
- s.isComplete became true
Note that according to the Domain Model, the Sale object does not have an isComplete
attribute, but this is a suggested addition that occurred when we created the Operation Contract
for endSale. We can then go back and modify the Domain Model to include this new attribute –
an example of iterative development.
23
NextGen POS Operation Contracts
Contract CO4: makePayment
Operation:
Cross Reference:
Preconditions:
Postconditions:
makePayment(amount: Money)
Use Cases: Process Sales
There is a sale underway
- A Payment instance p was created
- p.amountTendered became amount
- p was associated with the current Sale s
- The current Sale s was associated with the Store
Note the last association that was formed creates the association “logs-completed” between
Sale and Store in the Domain Diagram.
24
NextGen POS: Expanding the SSDs
We now want to expand the basic Process Sales SSD we created earlier to include an expanded
payment option
This would occur, for example, in a further iteration in the Elaboration phase
Recall the first iteration only included cash payments; then we enhanced the Domain Model to include
credit and check, and added subclasses to the Domain Model to reflect this
We will enhance the existing SSD to include these new details, and also add Operation Contracts
to explain them
Note that in this next iteration, the makePayment operation that we previously defined would
be renamed “makeCashPayment”
First, let’s recall the expanded Domain Model for these types of payments
25
Payments
Authorizes-payments-of
1
Payment
1..*
AuthorizationService
Core::Store
ServiceContract
amount
merchantID
Paid-by
1
1
Credit
Payment
CashPayment
amountTendered
Check
Payment
* * *
*
address
name
phoneNumber
Check
Authorized-by
1
*
Check
Authorization
Service
Credit
Authorization
Service
1
Authorized-by
Logs 
Establishescredit-for 
1
Accounts
Receivable
Establishesidentity-for 
1
1
CreditCard
Authorization Transactions::
PaymentAuthorizationReply
DriversLicense
expiryDate
number
number
1
1
Identifies
- CheckPayments have
CheckPaymentReplies
1
Abused-by
1
Sales::Customer
- CreditPayments have
CreditPaymentReplies
26
The basic scenario we
have been working
with:
Process Sale Scenario
:NextGenPOS
System
: Cashier
«actor»
:TaxCalculator
makeNewSale
loop
[ more items ]
enterItem(itemID, quantity)
description, total
endSale
taxLineItems =
getTaxes( sale )
total with taxes
27
Adding pay by credit; note
that the Accounts object
(Accounts Receivable in the
Domain Model) gets
updated.
:Customer
:NextGenPOS
System
«actor»
:CreditAuthorization
Service
«actor»
:Accounts
makeCreditPayment
(credNum, expiryDate)
reply = requestApproval( request )
postReceivable( receivable )
postSale( sale )
28
Adding pay by check:
:Cashier
:NextGenPOS
System
«actor»
:CheckAuthorization
Service
makeCheckPayment
(driversLicenseNumber)
reply = requestApproval(request)
29
NextGen POS Operation Contracts
Contract CO5: makeCreditPayment
Operation:
Cross Reference:
Preconditions:
Postconditions:
makeCreditPayment(creditAccountNumber, expiryDate)
Use Cases: Process Sales
An underway sale exists and all items have been entered
- A CreditPayment pmt was created
- pmt was associated with the current Sale s
- a CreditCard cc was created, cc.number = creditAccountNumber,
cc.expiryDate = expiryDate
- cc was associated with pmt
- a CreditCardPaymentRequest cpr was created
- pmt was associated with cpr
- a ReceivableEntry re was created
- re was associated with the external Accounts Receivable
- The current sale s was associated with the Store as a completed sale
30
NextGen POS Operation Contracts
Contract CO6: makeCheckPayment
Operation:
Cross Reference:
Preconditions:
Postconditions:
makeCheckPayment(driversLicenseNumber)
Use Cases: Process Sales
An underway sale exists and all items have been entered
- a CheckPayment pmt was created
- pmt was associated with the current sale s
- a DriverLicense dl was created; dl.number = driversLicenseNumber
- dl was associated with pmt
- a CheckPaymentRequest cpr was created
- pmt was associated with cpr
- current sale s was associated with the Store as a completed sale
31
Takeaways from Chapter 11, 32
Understand how to create Operations Contracts, based upon details from the use
cases, SSDs, and Domain Models.
Know the three type of postconditions and how to write them
32