Use Case Model

Operation Contracts

Prepared By:
Sumit Sharma
and Sravanthi Gillala
 Objectives

 Create contracts for system operations.

 Unified Process Artifacts
Domain Model
Business Model
Vision

Requirements
Use Case Model Use Case Text
Glossary
Operation Contract System Sequence
Diagrams

Supplementary
Specifications

Interaction Diagrams Design

See Figure 11.1 in text for more detail
Why Contracts
• Use cases are the primary mechanism in the
UP to describe system behavior, and are
usually sufficient.
• However, sometimes a more detailed
description of system behavior has value.
• Contracts for operations can help define
system behavior.
Domain Model And Contracts

• A Domain Model is a visual representation of

conceptual classes or real-world objects in a
domain of interest.
• Contracts describe detailed system behavior
in terms of state changes to objects in the
Domain Model, after a system operation has
executed.
Keep it Agile
• In many, or even most software development
projects, operation contracts may be
unnecessary. For an agile process, use them
only when necessary to add additional detail
and understanding.
System Operations and
the System Interface

• Contracts may be defined for system

operations – operations that the system as a
black box offers in its public interface to handle
incoming system events. System operations can
be identified by discovering these system events.
• The entire set of system operations, across all
use cases, defines the public system interface,
viewing the system as a single component or
class.
Example Contract:
enterItem
Contract CO2: enterItem
Operation: enterItem(itemID : ItemID,
quantity : integer)
Cross References: Use Cases: Process Sale
Preconditions: There is a Sale Underway.
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
ProductSpecification, based on
itemID match (association formed)
 Contract Sections

Operation: Name Of operation, and parameters.

Cross References: (optional) Use cases this
can occur within.
Preconditions: Noteworthy assumptions about the
state of the system or objects in
the Domain Model before execution
of the operation.
Postconditions: -The state of objects in the
Domain Model after completion of
the operation.
Postconditions
• The postconditions describe changes in the state
of objects in the Domain Model. Domain Model
state changes include instances created,
associations formed or broken, and attributes
changed.
• Postconditions are not actions to be performed,
during the operation; rather, they are declarations
about the Domain Model objects that are true
when the operation has finished.
The Spirit of Postconditions: The
Stage and Curtain

• Express postconditions in the past tense, to

emphasize they are declarations about a
state change in the past.
– (better) A SalesLineItem was created.
– (worse) Create a SalesLineItem.
The Spirit of Postconditions: The
Stage and Curtain
• Think about postconditions using the following image:
The system and it’s objects are presented on a theatre
stage.
– Before the operation, take a picture of the stage.
– Close the curtains on the stage, and apply the system
operation
– Open the curtains and take a second picture.
– Compare the before and after pictures, and express as
postconditions the changes in the state of the stage (A
SalesLineItem was created…).
Writing Contracts Leads to Domain
Model Updates

• New conceptual classes, attributes, or

associations in the Domain Model are often
discovered during contract writing.
• Enhance the Domain Model as you make
new discoveries while thinking through the
operation contracts.
Contracts vs. Use Cases
• The use cases are the main repository of
requirements for the project. They may
provide most or all of the detail necessary to
know what to do in the design.
• If the details and complexity of required state
changes are awkward to capture in use
cases, then write operation contracts.
Contracts vs. Use Cases contd…

• If developers can understand what to do based on the use

cases and ongoing (verbal) collaboration with a subject
matter expert, avoid writing contracts.
• Operation contracts are uncommon. If a team is making
contracts for every system operation:
– the use cases are poorly done, or
– there is not enough collaboration or access to a subject matter
expert, or
– the team is doing too much unnecessary documentation.
 Guidelines: Contracts
• To make contracts:
– Identify system operations from the SSDs.
– For system operations that are complex and perhaps
subtle in their own results, or which are not clear in the use
case, construct a contract.
– To describe the postconditions, use:
- instance creation and deletion
- attribute modification
- associations formed and broken
The Most Common Mistake In
Creating Contracts

• The most common problem in creating

contracts is forgetting to include the forming
of associations. Particularly, when new
instances are created, it is very likely that
associations to several objects need be
established. Don’t forget to include all the
associations formed and broken.
Contracts, Operations,
and the UML

• The UML formally defines operations. To

quote:
– An operation is a specification of a transformation or
query that an object may be called to execute [RJB99]
• An operation is an abstraction, not an
implementation. By contrast, a method (in the
UML) is an implementation of an operation.
Contracts, Operations,
and the UML

• A UML operation has a signature (name and

parameters), and also an operation
specification, which describes the effects
produced by executing the operation; the
postconditions.
• A UML operation specification may not show
an algorithm or solution, but only the state
changes or effects of the operation.
Operation Contracts
Expressed with the OCL

• Associated with the UML is a formal language

called the Object Constraint Language (OCL)
[WK99], which can be used to express
constraints in models.
• The OCL defines an official format for specifying
pre- and postconditions for operations, as
demonstrated here:
System::makeNewSale()
pre: <statements in OCL>
post: …
Programming Language
Support for Contracts

• Some languages, such as Eiffel, have first-

class support for invariants and pre- and
postconditions.
• There are pre-processors that provide similar
support in Java.
Operation Contracts
Within the UP

• A pre- and postcondition contract is a well-

known style to specify an operation. In UML,
operations exist at many levels, from top level
classes down to fine-grained classes.
• Operation specification contracts for the top
level classes are part of the Use-Case Model.
Operation Contracts
Within the UP

• Phases
– Inception – Contracts are not needed during
inception – they are too detailed.
– Elaboration – If used at all, most contracts will
be written during elaboration, when most use
cases are written. Only write contracts for the
most complex and subtle system operations.
New Systems Operations
• Let us create new system operations for a
Point of Sale system to handle different forms
of payment:
– makeCreditPayment
– makeCheckPayment
 New System Operations (2)
• The system event and operation for cash payment
in an earlier iteration was simply makePayment.
• As the payments are of different types the operation
is renamed as makeCashPayment.
New System Operation Contracts

• System operation contracts are an optional

requirements artifact that adds fine detail
regarding the results of a system operation.
• The use case text itself is sufficient, at times.
• The contracts are not necessary.
New System Operation
Contracts (2)

• The contracts bring value, on occasion, by

their precise and detailed approach to
identifying what happens when a complex
operation is invoked on the system, in terms
of state changes to objects defined in the
Domain Model.
Contract:
makeCreditPayment

• Operation: makeCreditPayment
(creditAccountNumber, expiryDate)
• Cross References: Use Cases: Process Sale
• Preconditions: An underway sale exists and
all items have been entered.
Contract:
makeCreditPayment (2)

• Postconditions:
– A credit payment pmt was created
– pmt was associated with the current Sale sale
a CreditCard cc was created. cc.number =
creditAccountNumber, cc.expiryDate =
expiryDate
– cc was associated with pmt
Contract:
makeCreditPayment (3)

– a CreditPaymentRequest cpr was created

– pmt was associated with cpr
– a ReceivableEntry re was created
– re was associated with the external
AccountsReceivable
– Sale was associated with the Store as a
complete sale
makeCreditPayment
• There exists a postcondition indicating the
association of a new receivable entry in
accounts receivable.
• Although, this responsibility is outside the
bounds of the NextGen system, the accounts
receivable system is within the control of the
business.
makeCreditPayment (2)
• The statement has thus been added as a
correctness check.
• During testing, it is clear from this post-
condition that the accounts receivable system
should be tested for the presence of a new
receivable entry.
Contract:
makeCheckPayment

• Operation: makeCheckPayment
(driversLicenseNumber)
• Cross References: Use Cases: Process Sale
• Preconditions: An underway sale exists and
all items have been entered
Contract:
makeCheckPayment (2)

• Postconditions:
– a CheckPayment pmt was created
– pmt was associated with the current Sale sale
– a DriversLicense dl was created, dl.number =
driversLicenseNumber
– dl was associated with pmt
Contract:
makeCheckPayment (3)

– a CheckPaymentRequest cpr was created

– pmt was associated with cpr
– sale was associated with the Store as a
completed sale
 Summary
• Contracts describe detailed system behavior in terms of state
changes to objects in the Domain Model after a system
operation.
• Contracts have sections of Operations, Cross references,
Preconditions and Postconditions. Postconditions are the
most important section.
• Postconditions describe changes in the state of objects in the
Domain Model.
• Domain Model state changes include instances created,
associations formed or broken, and attributes changed.
 Summary
• Writing Contracts leads to Domain Model updates.
• In UML, an operation is a specification of a transformation or
query that an object may be called to execute.
• Most contracts will be written during elaboration, when most
use cases are written. Only write contracts for the most
difficult to understand or complicated system operations.
Bibliography
• Craig Larman, Applying UML and Patterns,
3rd Edition, Prentice Hall, 2002, ISBN 0-13-
148906-2