NJIT

Use Case Model Operation Contracts

Prepared By:

Sumit Sharma

and Sravanthi Gillala

2

Create contracts for system operations.

Objectives

3

Unified Process Artifacts

Business Model

Requirements

Design

Domain Model

Use Case Model

Operation Contract

Use Case Text

System Sequence Diagrams

Interaction Diagrams

Supplementary Specifications

Vision

Glossary

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

Operation: enterItem(itemID : ItemID,quantity : integer)

Cross References: Use Cases: Process SalePreconditions: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 CO2: enterItem

9

Contract Sections

Operation: Name Of operation, and parameters.

Cross References: (optional) Use cases thiscan 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 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…).

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. Don’t 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:

System::makeNewSale()pre: <statements in OCL>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