Use Case Model Operation Contracts

1
Use Case Model Operation Contracts

• Prepared By
• Sumit Sharma
• and Sravanthi Gillala

2
Objectives

• Create contracts for system operations.

3
Unified Process Artifacts
Business Model
Requirements
Design
See Figure 11.1 in text for more detail
4
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.

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

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

7
System Operations andthe 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.

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

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

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

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

12
The Spirit of Postconditions The Stage and
Curtain

• Think about postconditions using the following
  imageThe system and its 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).

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

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

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

16
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

17
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. Dont
  forget to include all the associations formed and
  broken.

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

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

20
Operation ContractsExpressed 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 SystemmakeNewSale() pre
  ltstatements in OCLgt post

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

22
Operation ContractsWithin 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.

23
Operation ContractsWithin 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.

24
New Systems Operations

• Let us create new system operations for a Point
  of Sale system to handle different forms of
  payment
• makeCreditPayment
• makeCheckPayment

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

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

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

28
Contract makeCreditPayment

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

29
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

30
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

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

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

33
Contract makeCheckPayment

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

34
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

35
Contract makeCheckPayment (3)

• a CheckPaymentRequest cpr was created
• pmt was associated with cpr
• sale was associated with the Store as a completed
  sale

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

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

38
Bibliography

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