Use-Case Model : Adding

Detail with operation contracts

Larman ch. 11

Larman ch. 11 1
 UP artifacts

Sam ple UP Artifacts Partial artif acts,

ref ined in each
Domain iteration.
Business Model
Modeling *
* the domain objects,
attributes, and
associations that undergo
state changes

Use-Case Model

:System

foo( x ) Glossary ...

Requirements
bar( y )
system
text use sy stem operations sy stem
use case sequence operation
cases diagrams diagrams contracts

Design Model
Sof tware
the system operations
Architecture Doc.
Design are handled by
designing software to
fulfill the post-conditions
of the contracts

Larman ch. 11 2
 Operation contracts
• Part of the use-case model
– Analyze technique
• Use cases are the primary mechanism in UP to
describe system behavior
• Contracts help define system behavior
– Adds more details
– Contracts may not be needed.
• Objectives
– Define operation contracts with Post conditions
– Relate contracts to the Domain Model and the Use-
Case Model.

Larman ch. 11 3
 System operations handle system
events

: Cashier :Sy stem

enterItem(itemID, quantity ) System events invoke systems

Operations.
description, total

* [more items]
The System event makeNewSale
endSale()
invokes a System operation
total with taxes
called makeNewSale
makePay ment(amount)

change due, receipt

Larman ch. 11 4
 Contracts CO2 : enterItem
• Operation :
– Name of operation and parameters
– enterItem(itemID: ItemID, quantity : integer)
• Cross References :
– Optional use case this operation can occur within
– Use Cases : Process Sale
• Preconditions :
– Assumptions about the state of the system before execution of the operation
– There is a sale underway
• Postconditions :

– The state of the objects in the domain model after completion of the operation
– A SalesItem 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 ProductsSpecification, based on itemID match
(association formed)

Larman ch. 11 5
 Postconditions
• Describe changes in the state of objects
in the domain model that are true when
the operation has finished.
• They are not actions to be performed during the
operation
• Postconditions fall into these categories :
– Instance creation and deletion
– Attribute modification
– Associations (UML links) formed and broken.

Larman ch. 11 6
 WHAT !!!
• Focus on WHAT must happen in terms of
objects in the Domain Model.

– What instances can be created ?

– What associations can be formed ?
– What attribute can be modified ?

• Don’t describe HOW it is archived.

Larman ch. 11 7
 Contracts leads to….
• It is common to discover
– new conceptual Classes
– Attributes
– Associations
• Don’t be limited to the prior definition of
the Domain Model

Larman ch. 11 8
 Guidelines : Contracts
1. Identifying operations from the SSDs.
2. For system operations that are complex and
perhaps subtle in their results, or which are not
clear in the use case, constructs a contract.
3. To describe the postconditions, use the
following categories :
• Instance creation and deletion
• Attribute modification
• Associations formed and broken

Larman ch. 11 9
 Postconditions : past tense
• Notice that the statements are expressed
in the past tense :
– A SalesLineItem sli was created (instance
operation)
– Sli was associated with the current Sale
(association formed)

Larman ch. 11 10
 NextGen POS example
• P. 185-186

Larman ch. 11 11
 Artifact relationships
Domain Model

Sale 1 1..* Sales

...
LineItem
date
...
... quantity

the domain objects, attributes, and

domain objects
associations that undergo state changes

Use-Case Model

: Sy stem
Operation: makeNewSale
Process Sale : Cashier make
NewSale() Post-conditions:
1. Customer -...
arriv es ... system system
2. ... events enterItem
operations
3. Cashier (id, quantity )
enters item Operation: enterItem
identif ier.
4.... endSale()
Post-conditions:
- A SalesLineItem instance
sli was created
makePay ment -...
(amount)

Use Cases System Sequence Diagrams Contracts

in addition to the use cases,

some ideas and inspiration for the post- requirements that must be
conditions derive from the use cases satisfied by the design of the
software

requirements that Design Model

must be satisfied by
the design of the : Register : ProductCatalog : Sale
software
enterItem
(itemID, quantity )

spec := getProductSpec( itemID )

addLineItem( spec, quantity )

...

Larman ch. 11 12