140 likes | 173 Views
Learn the importance of System Sequence Diagrams (SSD) in software development through Use Case Specifications. Dive into illustrating input and output events, system behavior analysis, and creating concrete scenarios. Larman's guidelines offer practical insights. Discover the necessity of abstract level intention in expressing system events. Enhance your understanding with exercises and examples.
E N D
BTS430 Systems Analysis and Design using UML System Sequence Diagrams
AGENDA • Use Case Specifications returned • Introduction of System Sequence Diagrams • Exercises
System Sequence Diagrams • A system sequence diagram …. Illustrates input and output events related to the system under discussion. • Larman, APPLYING UML AND PATTERNS, p. 173
System Sequence Diagrams • The use case text and its implied system events are input to a SSD (system sequence diagram). • Larman, APPLYING UML AND PATTERNS, p. 174
System Sequence Diagrams • Use cases describe how external actors interact with the software system… • An actor generates system events to a system, requesting some system operation to handle the event. • The use case text implies the event…the SSD makes it concrete and explicit. • Larman, APPLYING UML AND PATTERNS, p. 176
System Sequence Diagrams • A system sequence diagram is a picture that shows, for one particular scenario of a usecase, the events that external actors generate, their order and the inter-system events. • All systems are treated as a black box. • Larman, APPLYING UML AND PATTERNS, p. 176
Why Draw System Sequence Diagrams? • The external input events—the system events are an important part of analyzing system behavior. • System behavior is a description of what a system does, without explaining how it does it. • Larman, APPLYING UML AND PATTERNS, p. 173
System Sequence Diagrams • System events should be expressed at the abstract level of intention rather than in terms of the physical input device. • Larman, APPLYING UML AND PATTERNS, p. 178
How Many System Sequence Diagrams? • One for each frequent scenario • One for each complex scenario • Larman, APPLYING UML AND PATTERNS, p. 176