You are on page 1of 38

Use Case Model

Operation Contracts
Prepared By:
Sumit Sharma
and Sravanthi Gillala

NJIT
Objectives
 Create contracts for system operations.

2
Unified Process Artifacts
Domain Model Business Model
Vision

Use Case Model Use Case Text


Requirements
Glossary
Operation Contract System Sequence
Diagrams

Supplementary
Specifications

Interaction Diagrams Design

3 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.

4
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.

5
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.

6
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.
7
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)

8
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.

9
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.
10
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.

11
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…).
12
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.

13
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.

14
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.
15
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
16
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.

17
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.

18
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.

19
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: …

20
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.

21
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.

22
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.
23
New Systems Operations
 Let us create new system operations for a
Point of Sale system to handle different
forms of payment:
 makeCreditPayment

 makeCheckPayment

24
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.

25
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.

26
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.

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

28
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

29
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
30
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.

31
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.

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

33
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

34
Contract:
makeCheckPayment (3)
 a CheckPaymentRequest cpr was
created
 pmt was associated with cpr

 sale was associated with the Store as a

completed sale

35
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.
36
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.

37
Bibliography
 Craig Larman, Applying UML and
Patterns, 3rd Edition, Prentice Hall,
2002, ISBN 0-13-148906-2

38

You might also like