1. System Sequence Diagrams and Operation Contracts

2. What are you going to learn about today?
System sequence diagrams (SSDs)
What?
How?
Why?
Operation contracts

3. Recall: Iterative development process
We are here

4. Recall: Analysis bridges the gap between requirements and design
Analysis
Requirements

5. Last time we learned about one type of OO analysis: Domain Modeling (using class diagrams) Another useful OO analysis activity is creating System Sequence Diagrams (SSDs)

6. System Sequence Diagrams (SSDs)
Model interactions between the system to be build and external actors
Capture one scenario of events
System is a black box
Emphasizes system events
Represented using UML sequence diagram notation

7. Consider the Process Sale UC
Main Success Scenario
Customer arrives at POS checkout with goods to purchase
Cashier starts a new sale
Cashier enters item identifier
System records sale line item and presents item description, price, and running total
Cashier repeats steps 3-4 until indicates done
System presents total, and asks for payment
Customer pays and System handles payment
System logs completed sale
System presents receipt
SSDs can help you abstract out system events

8. POS Example: Process Sale SSD
External actor
System as black box
Actor lifelines
Time progresses downward

9. Process Sale UC Main Success Scenario
Customer arrives at POS checkout with goods to purchase
Cashier starts a new sale
Cashier enters item identifier
System records sale line item and presents item description, price, and running total
Cashier repeats steps 3-4 until indicates done
System presents total, and asks for payment
Customer pays and System handles payment
System logs completed sale
System presents receipt

10. POS Example: Process Sale SSD
Message event

11. Process Sale UC Main Success Scenario
Customer arrives at POS checkout with goods to purchase
Cashier starts a new sale
Cashier enters item identifier
System records sale line item and presents item description, price, and running total
Cashier repeats steps 3-4 until indicates done
System presents total, and asks for payment
Customer pays and System handles payment
System logs completed sale
System presents receipt

12. POS Example: Process Sale SSD
Looping event
Loop guard
“Return” values from previous message

13. Process Sale UC Main Success Scenario
Customer arrives at POS checkout with goods to purchase
Cashier starts a new sale
Cashier enters item identifier
System records sale line item and presents item description, price, and running total
Cashier repeats steps 3-4 until indicates done
System presents total, and asks for payment
Customer pays and System handles payment
System logs completed sale
System presents receipt

14. POS Example: Process Sale SSD

15. Process Sale UC Main Success Scenario
Customer arrives at POS checkout with goods to purchase
Cashier starts a new sale
Cashier enters item identifier
System records sale line item and presents item description, price, and running total
Cashier repeats steps 3-4 until indicates done
System presents total, and asks for payment
Customer pays and System handles payment
System logs completed sale
System presents receipt

16. POS Example: Process Sale SSD

17. Prelude to an activity: Recall the bicycle sharing system

18. Prelude to an activity: Recall the bicycle sharing system
Bicycle stations
The System
Mobile/web customer
Phone customer
Phone system
Service tech
Phone support

19. Activity: Creating an SSD for UC Checkout Bicycle
Activity: Creating an SSD for UC Checkout Bicycle
Main success scenario
Mobile/Web Customer provides identification
System authenticates Mobile/Web Customer
System presents Mobile/Web Customer’s available credits
Mobile/Web Customer sends checkout request with Station’s ID
System identifies ID of bicycle in Station to checkout
System instructs Station to release bicycle with that ID
Station unlocks bicycle
Station sends confirmation to System that bicycle was unlocked
System debits Mobile/Web Customers account and records checkout
System tells Mobile/Web Customer which bicycle to collect and presents updated credit information

20. Why are SSDs useful?
Help you come up with a minimal set of system operations your system must support
Help you identify operations that in multiple UCs
Suggest object collaborations for your subsequent software design
Larman even recommends creating an SSD for each main success scenario of your UCs

21. System events discovered with the SSDs
reveal
System operations that handle the events
all of which form
The system interface

22. Operation contracts document the system interface
Each operation contract consists of:
Operation – Name of op
Cross references – List of UCs that the op occurs in
Preconditions – Noteworthy assumptions about the state of the System or objects in the Domain Model before the operation executes
Postconditions – State of the System or objects in the Domain Model after the operation completes

23. POS Example: enterItem Contract
Operation: enterltem(itemlD : ItemID, quantity : integer)
Cross references: UC Process Sale
Preconditions: There is a sale underway.
Postconditions:
A SalesLineltem 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 ProductSpecification, based on itemID match (association formed).
Note the changes to the Domain Model.
Such changes may be:
Instance creation or deletion
Attribute change of value
Associations formed or broken

24. Activity: Creating an operation contract
Activity: Creating an operation contract
Write a contract for each system operation revealed by your SSD from the previous activity

25. Summary System sequence diagrams: Good for identifying
Summary
System sequence diagrams: Good for identifying
system operations and
potential object collaborations
Operation contracts document the system interface