TK2023 Object-Oriented Software Engineering

CHAPTER 7

OPERATION CONTRACTS

INTRODUCTION

Use cases are the primary mechanism to describe system behaviour.

Sometimes, a more detailed description of system behaviour can be useful.

CONTRACTS

Contracts describe detailed system behaviour in terms of state changes to objects in the domain model, after a system operation has executed.

System operations are operations that are invoked in response to incoming system events.

: Cashier

: System

enterItem(itemID, qty)

the system evententerItem is generated

the system operationenterItem is invoked

enterItem(itemID, qty)

The entire set of system operations, across all use cases, defines the public system interface; the system is viewed as a single class.

System

makeNewSale()enterItem(itemID, qty)endSale()makePayment(amt)…

Operation: Name of operation, and its parameters, if any.Cross References: (optional) Use cases within which this operation can occur.Preconditions: Noteworthy assumptions about the state of the system or objects in the domain model before execution of the operation. They are assumed to be true and will not be tested.Postconditions: The state of objects in the domain model after completion of the operation.

CONTRACT SECTIONS

A contract contains the following sections:

Operation: enterItem(itemID:ItemID, qty:Integer)

Cross References: Use Cases: Process Sale

Preconditions:

There is a sale currently going on

Postconditions:

- A SalesLineItem (sli) was created

- sli was associated with the current Sale

- sli.quantity was set to qty

- sli was associated with a ProductSpecification, based on itemID match

EXAMPLE OF A CONTRACT: enterItem

POSTCONDITIONS

The postconditions describe changes in the state of objects in the domain model. Domain model state changes include: instances created or deleted associations formed or broken attributes changed

Postconditions are not actions to be performed during the operation.

Remember that the postconditions are written in the context of the domain model objects.

Are postconditions necessary? Most often, the effect of a system operation is

relatively clear (from the use case, talking with the domain experts, etc).

Sometimes, the detail and precision in contracts can become useful during design.

Note that postconditions specify the changes a system operation needs to achieve without describing how they are to be achieved.

For example, consider the postconditionThe SalesLineItem (sli) was associated with the current Sale

But how will this be achieved? linking Java objects? inserting rows in a relational database? …

In other words, the design can be deferred. We need to focus on the analysis of what must happen, rather how it is to be accomplished.

AN ANALOGY BEFOREOPERATION

A B C D E F

DURINGOPERATION

ABC

D E

F

AFTEROPERATION

AN EXAMPLE BEFOREOPERATIONenterItem(1234, 3)

: Register : Sale

: ProductCatalog

: ProductSpecification

: SalesLineItem

linked to the corresponding ProductSpecification

DURINGOPERATIONenterItem(1234, 3)

AFTEROPERATIONenterItem(1234, 3)

: Register : Sale

: ProductCatalog

: ProductSpecification

: SalesLineItem

linked to the corresponding ProductSpecification

: SalesLineItem

qty = 3

linked to the ProductSpecification for itemID 1234

1. Instance creation2. Associations formed3. Attribute change

GUIDELINES FOR WRITING CONTRACTS To write contracts:

1. Identify system operations from the SSDs

2. Write contracts for system operations that are complex and perhaps subtle in their results, or which are not clear in the use case.

3. Describe postconditions using the following categories:a. Instance creation or deletion

b. Attribute modification

c. Associations formed or broken

State the postconditions in a declarative, passive past tense form. This will emphasize the postconditions as declarations of state changes. A SalesLineItem was created

Create a SalesLineItem

Remember to establish a memory between existing objects or those newly created by defining the forming of an association.Example (enterItem):

- A SalesLineItem (sli) was created

- sli was associated with the current Sale

Forgetting to include the forming of associations is the most common mistake made when writing contracts.

A NOTE OF CAUTION!

It may not be necessary to write complete and detailed set of postconditions for all system operations.

Treat contracts as an initial best guess; most likely, they are not complete and perfect specifications.

UPDATING THE DOMAIN MODEL It's quite common to discover new conceptual

classes, attributes or associations in the domain model while writing contracts.

So, do not be limited to the prior definition of the domain model; enhance it as you make new discoveries.

Operation: makeNewSale()

Cross References: Use Cases: Process Sale

Preconditions:

none

Postconditions:

- A Sale (s) was created

- s was associated with the Register

- Attributes of s were initialized

POS SYSTEM: SYSTEM OPERATIONS OF PROCESS SALE

Operation: enterItem(itemID:ItemID, qty:Integer)

Cross References: Use Cases: Process Sale

Preconditions:

There is a sale underway

Postconditions:

- A SalesLineItem (sli) was created

- sli was associated with the current Sale

- sli.quantity was set to qty

- sli was associated with a ProductSpecification, based on itemID match

Operation: endSale()

Cross References: Use Cases: Process Sale

Preconditions:

There is a sale underway

Postconditions:

- Sale.isComplete was set to true.

Operation: makePayment(amt:Money)

Cross References: Use Cases: Process Sale

Preconditions:

There is a sale underway

Postconditions:

- A Payment (p) was created

- p.amountTendered was set to amt

- p was associated with the current Sale

- The current Sale was associated with the Store (to add it to the historical log of completed sales)