operation contracts. primary way to describe system behavior is with use cases operation contracts...
TRANSCRIPT
Operation Contracts
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
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)
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
Format of Operation Contract
Contract sections:– Operation – name and parameters– Cross References – use cases that apply– Preconditions– Postconditions
Operation Contracts
Postconditions – describe changes in state of objects in the domain model including:
• Instances created and deleted
• Associations formed or broken
• Attributes changed
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
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
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
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
Contract CO3: endSale
Operation: endSale()Cross references: Process Sale use casePreconditions:There is a sale underwayPostconditions: - Sale.isComplete became true
(attribute modification)
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)