Week 4

• Operational Contracts

• Requirements to Design

• Logical Architecture

OO Analysis and Design ProcessDomain Model

• Classes• Attributes• Associations

Use Cases• System Sequence Diagrams

• Interaction Diagrams

• Operation Contracts

Software Object Design **• Classes• Communications

• Operations and Methods

Don’t get hung up on terminology.Architecture -System vs LogicalDomain Model vs Domain Layer

Chapter 11

Operational Contracts

What are they? When and Why are they used?

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

Operational Contract

“Contracts describe changes that are likely required in the software objects.”

•Detailed description of behavior– Consider it optional but useful

•Components of a contract:– Operation signature – just a name– Cross reference – refer to use cases– Pre conditions – assumption about the state– Post conditions – state after completion

Example: enterItem

Operation: enterItem(itemID: ItemID, quantity: interger

Cross Reference: Use Cases: ProcessSale

Preconditions: There is a sale underway

Postconditions: A SalesLineItem instance sli was created

sli was associated with current Sale

sli.quantity became quantity

sli was assoicated with a ProductDescription, based on itemID

match

Fig. 11.2

: Cashier

enterItem(itemID, quantity)

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

Events trigger operations

Process sale

Post Conditions

• Changes in the state of objects in the domain model

• Observations not operations

• Three domain object state changes– Instance created or deleted– Attribute value changed– Association formed or broken

When Are Contracts Useful

• When complexity of required state changes too awkward/detailed to capture in use cases

• Describe what happens, not how– Sales Line Item associated with the sale by

stapling papers

• Proof of correctness (axiomatic semantics)

• Testing and verification

How to Create and Write Contracts

• Past tense descriptions and observations• Stage and curtain analogy• How complete?

• Best guess is a good start• Better to start with something that can be improved• Improves analysis and understanding• Useful for operations that are “complex and subtle.”

• Go back and update the Domain Model as needed.

• Do one for your project – just to do it.

Summary

• Update the domain model?

• When?– System operations that are complex or subtle

• Most common mistake?– Forgetting associations