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