1 / 22

Webapp Design with System Sequence Diagrams

http://flic.kr/p/7Az9cn. Webapp Design with System Sequence Diagrams. A Key Software Design Principle…. Also: Each of your objects should have only one reason to change. From Head First Software Development Chapter 5.

dperryman
Download Presentation

Webapp Design with System Sequence Diagrams

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. http://flic.kr/p/7Az9cn Webapp Design with System Sequence Diagrams

  2. A Key Software Design Principle… Also: Each of your objects should have only one reason to change. From Head First Software Development Chapter 5

  3. Design Questions:How many servlets should you have?How to assign responsibilities to servlets?

  4. Creating System Sequence Diagrams (SSDs)can help! 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

  5. Consider a Use Case (UC) for a POS System Point-of-Sale (POS) System Use Case: Archetypal scenario of interaction w/ system http://flic.kr/p/4UtQzk

  6. Process Sale Use Case (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

  7. POS Example: Process Sale SSD System asblack box External actor Actor lifelines Time progresses downward

  8. 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

  9. POS Example: Process Sale SSD Messageevent

  10. 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

  11. Loop guard Loopingevent POS Example: Process Sale SSD “Return” values fromprevious message

  12. 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

  13. POS Example: Process Sale SSD

  14. 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

  15. POS Example: Process Sale SSD

  16. Why are SSDs useful? • Help you come up with a minimal set of system operations your system must support • Each system operation can be a servlet System operations

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

  18. Translate this SSD into a servlet-based web app itemID: New Sale End Quant.: Enter Description: … Total: $ ... Total+tax: $ ... Payment: $ Enter Change: $... Receipt: … … …

  19. Design Question:What standard actions should a servlet perform? • Validate input! • Perform appropriate interaction with model • Forward request to appropriate view

  20. What types of bad input should you check for? Hint: http://xkcd.com/327/

  21. What types of bad input should you check for? • Values that violate preconditions of model operations • SQL injection attacks • If input contains evil SQL snippet, and your program inserts that input into an SQL query, then ... • Cross-site scripting attacks • If input contains evil JavaScript snippet, and your program inserts that input into a web page, then … • Anything that might be a problem (hard!)

  22. Recap • Single-Responsibility Principle (SRP) • Create SSDs to reveal system operations • Each servlet has responsibility to handle one system operation • Make sure your servlets validate input!

More Related