1 / 28

System sequence diagram (SSD)

SENG 403. System sequence diagram (SSD). Agenda. Brief introduction to SSD Example (A sales systems (Cashier)) Example (Monopoly game). What is an SSD ?. A system sequence diagram (SSD): is a fast and easily created artifact. illustrates input and output events related to the systems.

Download Presentation

System sequence diagram (SSD)

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. SENG 403 System sequence diagram (SSD) SENG 403 – Winter 2012

  2. Agenda • Brief introduction to SSD • Example (A sales systems (Cashier)) • Example (Monopoly game) SENG 403 – Winter 2012

  3. What is an SSD? • A system sequence diagram (SSD): • is a fast and easily created artifact. • illustrates input and output events related to the systems. SENG 403 – Winter 2012

  4. Example 1 (from Trace Modeller Co.) SENG 403 – Winter 2012

  5. Review • A fast review of the notions and rules in UML sequence diagrams SENG 403 – Winter 2012

  6. Synchronous message 1 • The sender waits until the receiver has finished processing the message, only then does the caller continue (i.e. a blocking call). • Most method calls in object-oriented programming languages are synchronous. • A closed and filled arrowhead signifies that the message is sent synchronously. SENG 403 – Winter 2012

  7. Synchronous message 2 • If you want to show that the receiver has finished processing the message and returns control to the sender, draw a dashed arrow from receiver to sender. • Optionally, a value that the receiver returns to the sender can be placed near the return arrow SENG 403 – Winter 2012

  8. Found message • A message of which the caller is not shown. • Either • the sender is not known, • or that it is not important who the sender was. • Originates from a filled circle SENG 403 – Winter 2012

  9. Asynchronous message • The sender does not wait for the receiver to finish processing the message • An open arrowhead is used to indicate that a message is sent asynchrously. SENG 403 – Winter 2012

  10. Self message • An object sends to itself SENG 403 – Winter 2012

  11. Instantaneous message 1 • The time it takes to arrive at the receiver is negligible. • Drawn as a horizontal arrow. SENG 403 – Winter 2012

  12. Non-instantaneous message • Sometimes it takes a considerable amount of time to reach the receiver. • E.g. across a network. • Such a non-instantaneous message is drawn as a slanted arrow. SENG 403 – Winter 2012

  13. Loop 1 • Prefixed with an asterisk. • The message is sent repeatedly. • A guard indicates the condition that determines whether or not the message should be sent (again). SENG 403 – Winter 2012

  14. loop2 • Sending the same message to different elements in a collection. • The receiver of the repeated message is a multiobject. SENG 403 – Winter 2012

  15. Loop 3 • Multiple messages sent in the same iteration • a 'loop' combined fragment can be used. SENG 403 – Winter 2012

  16. Conditional 1 • The message is only sent if a certain condition is met. • The condition is between brackets. SENG 403 – Winter 2012

  17. Conditional 2 • Several messages conditionally sent under the same guard (condition). • Use an 'opt' combined fragment. • The combined fragment is shown as a large rectangle with an 'opt' operator plus a guard • contains all the conditional messages under that guard SENG 403 – Winter 2012

  18. Conditional 3 • Alternative interactions • use an 'alt' combined fragment. SENG 403 – Winter 2012

  19. Example 2 • Success scenario of a cash-only Process Sale scenario. • The cashier generates makeNewSale, enterItem, endSale, and makePayment system events. SENG 403 – Winter 2012

  20. Example 2 (continued)Sequence diagrams and system operation handling. • In the current iteration (for this sales system) we are considering the following scenarios and system operations: • makeNewSale • enterItem • endSale • makePayment SENG 403 – Winter 2012

  21. Example 2 (Continued) Lower level (detailed in the domain layer) SENG 403 – Winter 2012

  22. Example 2 (Continued) Naming issues • “enterItem” is better than “scan” (that is, laser scan) because it captures the intent of the operation while remaining abstract and noncommittal with respect to design choices about what interface is used to capture the system event. • It could by via laser scanner, keyboard, voice input, or anything. SENG 403 – Winter 2012

  23. Example 3 (Monopoly game) SENG 403 – Winter 2012

  24. Example 3(SSD for a Play Monopoly Game scenario.) • Initialization • Play game SENG 403 – Winter 2012

  25. Example 3Practice: Do not start we initializations SENG 403 – Winter 2012

  26. Example 3 SENG 403 – Winter 2012

  27. Example 3 SENG 403 – Winter 2012

  28. Resources • Website (tool): • Trace modeller (UML Sequence Diagram Editor) • A gallery of UML sequence diagrams: • http://www.tracemodeler.com/gallery/index.html • Book: • Craig Larman, Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and the Unified Process (3nd Edition), Prentice Hall PTR. • Chapters 10, 15 and 18 • Video: • UML Sequence diagram basics review: • http://www.youtube.com/watch?v=SPwUtekrqS8 • Online article: • Donald Bell, IBM Corporation, UML Basics: The sequence diagram. http://www.ibm.com/developerworks/rational/library/3101.html SENG 403 – Winter 2012

More Related