System Sequence Diagrams and Operation Contracts http flic

  • Slides: 25
Download presentation
System Sequence Diagrams and Operation Contracts http: //flic. kr/p/55 R 24 j

System Sequence Diagrams and Operation Contracts http: //flic. kr/p/55 R 24 j

What are you going to learn about today? • System sequence diagrams (SSDs) –

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

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

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

Recall: Analysis bridges the gap between requirements and design http: //flic. kr/p/a 1 NZHb

Recall: Analysis bridges the gap between requirements and design http: //flic. kr/p/a 1 NZHb Design Analysis Requirements

Last time we learned about one type of OO analysis: Domain Modeling (using class

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

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 1. Customer arrives at POS checkout

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

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

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

Process Sale UC Main Success Scenario 1. Customer arrives at POS checkout with goods

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

POS Example: Process Sale SSD Message event

POS Example: Process Sale SSD Message event

Process Sale UC Main Success Scenario 1. Customer arrives at POS checkout with goods

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

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

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

Process Sale UC Main Success Scenario 1. Customer arrives at POS checkout with goods

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

POS Example: Process Sale SSD

POS Example: Process Sale SSD

Process Sale UC Main Success Scenario 1. Customer arrives at POS checkout with goods

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

POS Example: Process Sale SSD

POS Example: Process Sale SSD

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

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 Phone customer Phone

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

Activity: Creating an SSD for UC Checkout Bicycle Main success scenario 1. Mobile/Web Customer

Activity: Creating an SSD for UC Checkout Bicycle Main success scenario 1. Mobile/Web Customer provides identification 2. System authenticates Mobile/Web Customer 3. System presents Mobile/Web Customer’s available credits 4. Mobile/Web Customer sends checkout request with Station’s ID 5. System identifies ID of bicycle in Station to checkout 6. System instructs Station to release bicycle with that ID 7. Station unlocks bicycle 8. Station sends confirmation to System that bicycle was unlocked 9. System debits Mobile/Web Customers account and records checkout 10. System tells Mobile/Web Customer which bicycle to collect and presents updated credit information http: //flic. kr/p/5 dfuq. L

Why are SSDs useful? • Help you come up with a minimal set of

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

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 –

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: enter. Item Contract Operation: enterltem(iteml. D : Item. ID, quantity : integer)

POS Example: enter. Item Contract Operation: enterltem(iteml. D : Item. ID, quantity : integer) Cross references: UC Process Sale Preconditions: There is a sale underway. Postconditions: – – A Sales. Lineltem 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 Product. Specification, based on item. ID 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 Write a contract for each system operation revealed by

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

Summary • System sequence diagrams: Good for identifying – system operations and – potential

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