object-oriented analysis and design chapter 11, 32: operation contracts & system sequence...

1

Object-Oriented Analysis and DesignCHAPTER 11, 32: OPERATION CONTRACTS & SYSTEM SEQUENCE DIAGRAMS

2

What will we learn?Operation Contracts – how to define the system operations, and how to create contracts for themDefine SSDs and Operation Contracts for the example case studies

3

Operation Contracts Often, the use cases and SSDs are enough to describe the system

Sometimes, more detail of the system behavior is required, and that is where Operation Contracts are used

The Use-Case Model and Domain Model are the main OOA artifacts, but Operation Contracts and State Models are also helpfulRemember the SSDs are part of the Use-Case Model artifact

Actually, the Operation Contracts are considered part of the Use-Case Model, since they usually expand upon the SSD

4

Operation: enterItem(…)

Post-conditions:- . . .

Operation Contracts

Sale

date. . .

SalesLineItem

quantity

1..*1 . . .

. . .

Domain Model

Use-Case Model

Design Model: Register

enterItem(itemID, quantity)

: ProductCatalog

spec = getProductSpec( itemID )

addLineItem( spec, quantity )

: Sale

Require-ments

Business Modeling

Design

Sample UP Artifact Relationships

: System

enterItem(id, quantity)

Use Case Text

System Sequence Diagrams

makeNewSale()

system events

Cashier

Process Sale

: Cashier

use case

names

system operations

Use Case Diagram

Vision

SupplementarySpecification

Glossary

starting events to design for, and more detailed requirements that must be satisfied by the software

Process Sale

1. Customer arrives ...2. ...3. Cashier enters item identifier.

the domain objects, attributes, and associations that undergo changes

requirements that must be satisfied by the software

ideas for the post-conditions

5

Operation Contracts Operation Contracts describe pre- and post-condition changes to the objects in the Domain Model as a result of a system operation. They are text based documentation.

Before looking at them in detail, let’s consider an example (terms like (instance creation) are added for explanation in this example, and would not be part of the actual contract):

Contract CO2: enterItem

Operation: enterItem(itemID: itemID, quantity: integer)Cross Reference: Use Cases: Process SalesPreconditions: There is a sale underwayPostconditions: -A SalesLineItem instance sli was created (instance creation)

-sli was associated ith the current Sale (association formed)-sli.quantity became quantity (attribute modification)-sli was associated with a ProductDescription, based on itemID match(association formed)

6

Operations Contracts - Sections The sections of an Operations Contract are:

Operation: Name of the operation, and parameters

Cross References: Use cases this operation can occur within

Preconditions: Noteworthy assumptions about the state of the system or objects in the Domain Model before execution of the operation. These arenon-trivial assumptions the reader should be aware of.

Postconditions: The most important section. The state of objects in the Domain Model after the completion of the operation.

7

System Operations System operations can be thought of as operations the system (as a black-box) offers to its users

They are identified when the SSDs are created

The SSDs show system events which usually trigger system operations

Some of the system events are input events (see next slide)

The entire set of system operations, across all use cases, defines a public interface which views the system as one single component or class.

8

: Cashier


endSale()

makePayment(amount)

description, total

total with taxes

change due, receipt

makeNewSale()

these input system events invoke system operations

the system event enterItem invokes a system operationcalled enterItem and so forth

this is the same as in object-oriented programming when we say the message foo invokes the method (handling operation) foo

[ more items ]loop

:System

Process Sale Scenario

9

Operation Contracts: Postconditions

The postcondition describes changes in the state of objects in the Domain Model. Such changes include instance creation, associations formed or broken, and attributes changed.

Note that postconditions are not actions to be performed during the operation!

Postconditions describe the changes to the object, they do not explain how the changes are done

Breaking an association is rare, but can happen (cancel sale, for example)

Instance deletion is also rare; remember, we are still in the Domain Model, not the actual software classes, so freeing up memory is not an issue

10

Operation Contracts: Postconditions

The instances and associations that are created by an Operation Contract appear in the Domain Model – the contract should capture the behavior expressed in the Use Case Model as it relates to the objects and associations in the Domain Model

Note that postconditions (and in fact Operation Contracts) are optional – not every operation needs a contract, and often the postconditions are obvious and do not need to be documented

This is another tool to help understand the system behavior

Again, this is an analysis tool – it will help define what changes, not how it changes

Usually postconditions are written in the past tense – A SalesLineItem was created, not is created

11

Example: enterItem Postconditions

Look at the types of changes identified in the enterItem postcondition

First, recall the Main Scenario of the Process Sale use case (pg 69 of the book):

Main Success Scenario:…3. Cashier enters item identifier4. System records sale line item and presents item description, price, and running total. Price calculated from a set of price rules.…

Also, recall the Domain Model and SSD for this example (next slides):

12

Sales

Cashier

Customer

1..*

SalesLineItem

/quantity

Sale

dateisCompletetime

Initiates

Core::Register

Records-sales-on

Captured-on

Core::Store

Logs-completed*

1

1

1

1

1

1

1

1

TaxLineItem

descriptionpercentageamount

1..* 1

13

Products

1..*

Core::Store

Stocks

*

Describes

*

Sales::SalesLineItem

Described-by *

Records-sale-of

0..1

ProductDescription

descriptionpriceitemID

ProductCatalog

Item1

1

1

1

1

14


:NextGenPOSSystem

: Cashier

endSale


description, total

total with taxes

makeNewSale

«actor»:TaxCalculator

taxLineItems = getTaxes( sale )

[ more items ]loop

15

Operation Contracts Contract CO2: enterItem

Operation: enterItem(itemID: itemID, quantity: integer)Cross Reference: Use Cases: Process SalesPreconditions: There is a sale underwayPostconditions: -A SalesLineItem instance sli was created (instance creation)

-sli was associated ith the current Sale (association formed)-sli.quantity became quantity (attribute modification)-sli was associated with a ProductDescription, based on itemID match(association formed)

16

enterItem Postcondition: Putting it Together

Instance Creation and Deletion:

After itemID and quantity have been entered by the Cashier, the SalesLineItem object is createdThis can be determined by the use case and Domain Model (composition of Sales)

Hence the postcondition: “A SalesLineItem instance sli was created”

Attribute Modification:

From the Domain Model, we see that the quantity attribute of the SalesLineItem is derived, or calculated. This value is entered by the Cashier (not mentioned in the use case, but shown in the SSD).

This gives the postcondition: “sli.quantity became quantity”

17

enterItem Postcondition: Putting it Together

Associations Formed or Broken:

After itemID and quantity are entered by the Cashier, and after we create the new SalesLineItem object, we must form an association with the ProductDescription object, as noted in the Domain Model. The new SalesLineItem is also associated with the Sale object. This gives the following postconditions:

“sli was associated with the current Sale.”

“sli was associated with a ProductDescription, based upon itemID match”

Note that the original Domain Model did not show the SalesLineItem to ProductDescription association as being qualified by itemID, but this does not mean we can’t include text in the postcondition that describes how sli is associated with ProductDescription.

18

Review How to analyze a system:

Use cases: Identify the main actors, and create the stories of how they interact. Add in details for each scenarioDomain Model: Identify the main conceptual classes (look for nouns in the use cases) and how they are associated with each other (look for verbs in the use cases)System Sequence Diagrams: Create diagrams that show the system events that occur between the system (as one big black box) and the usersOperations Contracts – detail any system operations that occur to impart changes to the system objects as a result of the system events – relies on Domain Model, use cases, and SSDs

The use cases (text) and possible use case diagram, SSDs, and Operations Contracts make up the Use-Case Model artifact in UP

The Domain Model is a separate artifact, sometimes included in the Business Modeling artifact

19

How to Create Operations Contracts

1. Identify the system operations from the SSDs

2. For complex system operations, or operations that may be subtle or not clearly understood, construct a contract

3. To describe the postconditions, use the following categories:1. Instance creation or deletion2. Attribute modification3. Associations formed or broken

Tip: Always use past tense, and if an instance is created, make sure you add an association for the new instance.

20


:System: Cashier

endSale

makePayment(amount)

a UML loop interaction frame, with a boolean guard expression

external actor to system


system as black box

the name could be "NextGenPOS" but "System" keeps it simple

the ":" and underline imply an instance, and are explained in a later chapter on sequence diagram notation in the UML

a message with parameters

it is an abstraction representing the system event of entering the payment data by some mechanism

description, total

return value(s) associated with the previous message

an abstraction that ignores presentation and medium

the return line is optional if nothing is returned

total with taxes

change due, receipt

makeNewSale

[ more items ]loop

Back to the Process Sale use case SSD:

21

NextGen POS Operation Contracts

Contract CO1: makeNewSale

Operation: makeNewSale()Cross References: Uses cases: Process SalePreconditions: nonePostconditions: - A Sale instance s was created

- s was associated with a Register- Attributes of s were initialized

Note that for this case, the contract is obvious and probably would not actually be written. Remember, these are system description tools, and we are not trying to document every change in the system; we just need to explain any operations that may not be obvious.

22


Contract CO2: enterItem

Operation: enterItem(itemID: itemID, quantity: integer)Cross Reference: Use Cases: Process SalesPreconditions: There is a sale underwayPostconditions: -A SalesLineItem instance sli was created

-sli was associated with the current Sale s-sli.quantity became quantity-sli was associated with a ProductDescription, based on itemID match

We saw this example earlier; this is more detailed and not as obvious as CO1, so it is reasonable to include this.

23


Contract CO3: endSale

Operation: endSale()Cross Reference: Use Cases: Process SalesPreconditions: There is a sale underwayPostconditions: - s.isComplete became true

Note that according to the Domain Model, the Sale object does not have an isComplete attribute, but this is a suggested addition that occurred when we created the Operation Contract for endSale. We can then go back and modify the Domain Model to include this new attribute – an example of iterative development.

24


Contract CO4: makePayment

Operation: makePayment(amount: Money)Cross Reference: Use Cases: Process SalesPreconditions: There is a sale underwayPostconditions: - A Payment instance p was created

- p.amountTendered became amount- p was associated with the current Sale s- The current Sale s was associated with the Store

Note the last association that was formed creates the association “logs-completed” between Sale and Store in the Domain Diagram.

25

NextGen POS: Expanding the SSDs

We now want to expand the basic Process Sales SSD we created earlier to include an expanded payment option

This would occur, for example, in a further iteration in the Elaboration phaseRecall the first iteration only included cash payments; then we enhanced the Domain Model to include credit and check, and added subclasses to the Domain Model to reflect this

We will enhance the existing SSD to include these new details, and also add Operation Contracts to explain them

Note that in this next iteration, the makePayment operation that we previously defined would be renamed “makeCashPayment”

First, let’s recall the expanded Domain Model for these types of payments

26

Payments

Check

AccountsReceivable

CreditPayment

CheckPayment

CheckAuthorization

Service

CreditAuthorization

Service

Authorized-by

Authorized-by

***

AuthorizationService

addressnamephoneNumber

Core::StorePayment

amount

Establishes-credit-for

Logs

*

CreditCard

expiryDatenumber

DriversLicense

number

1..*

Establishes-identity-for

Paid-by

CashPayment

amountTendered *

Sales::CustomerAbused-by

Identifies

Authorization Transactions::PaymentAuthorizationReply

- CheckPayments have CheckPaymentReplies

- CreditPayments have CreditPaymentReplies

1

1

1

111

1

1 1

1

1

Authorizes-payments-of

merchantID

ServiceContract

1

27


:NextGenPOSSystem

: Cashier

endSale


description, total

total with taxes

makeNewSale

«actor»:TaxCalculator

taxLineItems = getTaxes( sale )

[ more items ]loop

The basic scenario we have been working with:

28

makeCreditPayment(credNum, expiryDate)

reply = requestApproval( request )

:Customer

postReceivable( receivable )

:NextGenPOSSystem

«actor»:CreditAuthorization

Service

«actor»:Accounts

postSale( sale )

Adding pay by credit; note that the Accounts object (Accounts Receivable in the Domain Model) gets updated.

29

makeCheckPayment(driversLicenseNumber)

reply = requestApproval(request)

:Cashier

:NextGenPOSSystem

«actor»:CheckAuthorization

Service

Adding pay by check:

30


Contract CO5: makeCreditPayment

Operation: makeCreditPayment(creditAccountNumber, expiryDate)Cross Reference: Use Cases: Process SalesPreconditions: An underway sale exists and all items have been enteredPostconditions: - A CreditPayment pmt was created

- pmt was associated with the current Sale s- a CreditCard cc was created, cc.number = creditAccountNumber, cc.expiryDate = expiryDate- cc was associated with pmt- a CreditCardPaymentRequest cpr was created- pmt was associated with cpr- a ReceivableEntry re was created- re was associated with the external Accounts Receivable- The current sale s was associated with the Store as a completed sale

31


Contract CO6: makeCheckPayment

Operation: makeCheckPayment(driversLicenseNumber)Cross Reference: Use Cases: Process SalesPreconditions: An underway sale exists and all items have been enteredPostconditions: - a CheckPayment pmt was created

- pmt was associated with the current sale s- a DriverLicense dl was created; dl.number = driversLicenseNumber- dl was associated with pmt- a CheckPaymentRequest cpr was created- pmt was associated with cpr- current sale s was associated with the Store as a completed sale

32

Takeaways from Chapter 11, 32Understand how to create Operations Contracts, based upon details from the use cases, SSDs, and Domain Models.

Know the three type of postconditions and how to write them

object-oriented analysis and design chapter 11, 32: operation contracts & system sequence...

Documents