operation contracts. primary way to describe system behavior is with use cases operation contracts...

12
Operation Contracts

Upload: ashlynn-lewis

Post on 13-Dec-2015

215 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: Operation Contracts. Primary way to describe system behavior is with use cases Operation contracts provide more details in terms of state changes to objects

Operation Contracts

Page 2: Operation Contracts. Primary way to describe system behavior is with use cases Operation contracts provide more details in terms of state changes to objects

Operation Contracts

• Primary way to describe system behavior is with use cases

• Operation contracts provide more details in terms of state changes to objects in domain model after system operation has executed postconditions

Page 3: Operation Contracts. Primary way to describe system behavior is with use cases Operation contracts provide more details in terms of state changes to objects

Contract CO2: enterItem

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

Cross references:Process Sale use case

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 ProductDescription, based on itemID match (association formed)

Page 4: Operation Contracts. Primary way to describe system behavior is with use cases Operation contracts provide more details in terms of state changes to objects

Fig. 11.1

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

Page 5: Operation Contracts. Primary way to describe system behavior is with use cases Operation contracts provide more details in terms of state changes to objects

Format of Operation Contract

Contract sections:– Operation – name and parameters– Cross References – use cases that apply– Preconditions– Postconditions

Page 6: Operation Contracts. Primary way to describe system behavior is with use cases Operation contracts provide more details in terms of state changes to objects

Operation Contracts

Postconditions – describe changes in state of objects in the domain model including:

• Instances created and deleted

• Associations formed or broken

• Attributes changed

Page 7: Operation Contracts. Primary way to describe system behavior is with use cases Operation contracts provide more details in terms of state changes to objects

Operation Contracts

• Similar to use case but provides more detail

• Expressed in a declarative form not as an action

• Provide more detail on postconditions

• Postconditions expressed in past tense

Page 8: Operation Contracts. Primary way to describe system behavior is with use cases Operation contracts provide more details in terms of state changes to objects

Operation Contracts

Guideline: How to create and write contracts:– Identify system operations from SSDs– Construct a contract for those system

operations that are complex or subtle in their results

– Describe postconditions using terms:• Instance creation/deletion• Attribute modification• Associations formed/broken

Page 9: Operation Contracts. Primary way to describe system behavior is with use cases Operation contracts provide more details in terms of state changes to objects

Contract CO1: makeNewSale

Operation: makeNewSale()Cross references: Process Sale use casePreconditions:NonePostconditions: - A Sale instance s was created

(instance creation)- s was associated with a Register

(association formed)- Attributes of s were initialized

Page 10: Operation Contracts. Primary way to describe system behavior is with use cases Operation contracts provide more details in terms of state changes to objects

Fig. 9.27

Register

id

ItemStore

nameaddress

Sale

dateTime/ total

CashPayment

amountTendered

SalesLineItem

quantity

Cashier

id

Customer

ProductCatalog

ProductDescription

itemIDdescriptionprice

Stocks

*

Houses

1..*

Used-by

*

Contains

1..*

Describes

*

Captured-on

Contained-in

1..*

Records-sale-of

0..1

Paid-by Is-for

Logs-completed

*

Works-on

1

1

1

1 1..*

1

1

1

1

1

1

1

0..1 1

1

Ledger

Records-accounts-

for

1

1

Page 11: Operation Contracts. Primary way to describe system behavior is with use cases Operation contracts provide more details in terms of state changes to objects

Contract CO3: endSale

Operation: endSale()Cross references: Process Sale use casePreconditions:There is a sale underwayPostconditions: - Sale.isComplete became true

(attribute modification)

Page 12: Operation Contracts. Primary way to describe system behavior is with use cases Operation contracts provide more details in terms of state changes to objects

Contract CO4: makePayment

Operation: makePayment(amount : Money)

Cross references:Process Sale use case

Preconditions: There is a sale underway

Postconditions: - A Payment instance p was created (instance creation)

- p.amountTendered became amount (attribute modification)

- p was associated with the current Sale (association formed)

- The current Sale was associated with the Store (association formed)