1 / 15

Chapters 10 and 31

Chapters 10 and 31. System Sequence Diagrams. What is an SSD?. A diagram that illustrates input and output events related to the system Illustrates events from external actors

sorcha
Download Presentation

Chapters 10 and 31

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. Chapters 10 and 31 System Sequence Diagrams CS6359 Fall 2011 John Cole

  2. What is an SSD? • A diagram that illustrates input and output events related to the system • Illustrates events from external actors • It shows, for one particular scenario of a use case, the events that external actors generate, their order, and inter-system events • Systems are treated as black boxes; describe what they do but not how CS6359 Fall 2011 John Cole

  3. Why use SSDs? • Software systems respond to events. • Systems react to 3 things: External events, timer events, and faults or exceptions • Therefore, identify precisely the external events CS6359 Fall 2011 John Cole

  4. Naming Events and Operations • Keep the names as abstract or conceptual as possible • enterItem(itemID) is better than scan(itemID) • Start the name of the event with a verb CS6359 Fall 2011 John Cole

  5. What SSD Info in the Glossary? • Since SSD elements are terse, include details such as the operation name, parameters, and return data. E. g., in the Process Sale example, “receipt” is shown. However, a receipt can be a complex document that should be defined. CS6359 Fall 2011 John Cole

  6. Use Case for Process Sale CS6359 Fall 2011 John Cole

  7. Process Sale SSD CS6359 Fall 2011 John Cole

  8. Discussion of Process Sale • There is a loop for getting more items that returns a description and a total • The cashier can end the sale. The system returns the total with taxes CS6359 Fall 2011 John Cole

  9. Iterative and Evolutionary SSDs • Don’t create them for all scenarios unless necessary • Use them to clarify a complex process • Have lots of explanatory text with the diagram • Create most of them during elaboration CS6359 Fall 2011 John Cole

  10. SSD with Loop CS6359 Fall 2011 John Cole

  11. Credit Payment • Assume amount tendered is the exact amount of the sale CS6359 Fall 2011 John Cole

  12. Credit Payment • Card number and expiry date come from the card • The messages are synchronous, although they could be calls to Web services, AJAX, etc. CS6359 Fall 2011 John Cole

  13. Contract: makeCreditPayment • Preconditions: • Operation: makeCreditPayment(CardNumber, expiryDate) • Cross Ref: Use Cases: Process Sale • Precondition: A sale is underway and all items have been entered. CS6359 Fall 2011 John Cole

  14. Contract: makeCreditPayment • Postconditions: • A creditPaymentpmt was created • Pmt was associated with the current Sale sale • A Credit Card cc was created; cc.number = CardNumber and cc.expiry= ExpiryDate • Cc was associated with pmt • A CreditPaymentRequestcpr was created • Pmt was associated with cpr • A ReceivableEntry re was created • Re was assocaited with the external AccountsReceivable • Sale was associated with the Store as a completed sale CS6359 Fall 2011 John Cole

  15. Monopoly SSD • P. 179 CS6359 Fall 2011 John Cole

More Related