System Sequence Diagrams and Operation Contracts http://flic.kr/p/55R24j

What are you going to learn about today? System sequence diagrams (SSDs) What? How? Why? Operation contracts http://flic.kr/p/8JpkTg

Recall: Iterative development process We are here http://en.wikipedia.org/wiki/File:Iterative_development_model_V2.jpg

Recall: Analysis bridges the gap between requirements and design http://flic.kr/p/a1NZHb Analysis Requirements

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)

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

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

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

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

POS Example: Process Sale SSD Message event

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

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

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

POS Example: Process Sale SSD

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

POS Example: Process Sale SSD

Prelude to an activity: Recall the bicycle sharing system http://en.wikipedia.org/wiki/File:Barclayscyclehire.jpg

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

Activity: Creating an SSD for UC Checkout Bicycle http://flic.kr/p/5dfuqL 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

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

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

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

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

Activity: Creating an operation contract http://flic.kr/p/5dfuqL Activity: Creating an operation contract Write a contract for each system operation revealed by your SSD from the previous activity

Summary System sequence diagrams: Good for identifying http://flic.kr/p/YSY3X Summary System sequence diagrams: Good for identifying system operations and potential object collaborations Operation contracts document the system interface