Download
1 / 10
110 likes | 246 Views
This section delves into the essentials of creating object-level sequence diagrams, focusing on the need for well-defined scenarios and domain class diagrams. A scenario outlines the responsibilities of objects within the sequence diagram, translating into class methods. Learn how to decipher the interactions between various classes and understand the concept of composition, where container objects manage component objects' interactions. This guide provides examples, highlighting the relationship between scenarios and sequence diagrams, particularly when adding information such as OHIP data to existing patient records.
E N D
BTS430 Systems Analysis and Design using UML Design Part 2: Object-Level Sequence Diagrams With An example of composition
Sequence Diagram Essentials • Before you can start drawing a sequence diagram you typically need: • a scenario • a domain class diagram • sometimes you are also given a system level sequence diagram
A scenario tells us: • What the objects in the sequence diagram must do • In other words, what responsibilities the objects must take on • A responsibility typically translates into a class method. • Sometimes scenarios are very general; sometimes very specific • It is up to us (with help from clients) to translate the scenario into the details that will help us determine object interaction.
Scenarios—deciphering meaning • All of the following are really saying the same thing: • The manager selects a customer and requests customer address. The system displays customer address. • The manager enters customer name and requests to retrieve address. The system retrieves the customer from the database and returns the address • The manager specifies customer name and clicks on get address. The system creates a customer object with the specified name, and requests to retrieve the customer from the database. The system can then query the customer object to get the name.
System Level SDs—how they fit in Scenario: Add to product inventory System Level Sequence Diagram: Add to product inventory
Resulting Object Level SD Note that the messages from InventoryClerk to InventoryHandler here are exactly the same as the messages from InventoryClerk to System in the System level SD. In the Object level SD we have simply opened up the black box to show details of the object interaction.
A Domain Class Diagram identifies: • Key business classes • In our sequence diagram we use objects from these classes • Associations between classes • An association between classes typically indicates that the classes can “talk” to each other (depending on direction of the association) • A composition indicates that objects must go through the container object (e.g. Order) to “talk” to the component object (e.g. OrderItem)
Example—with composition Domain Class Diagram: Note—this means the Patient object already exists! Scenario: Add OHIP Information To Patient Precondition: The View Patient scenario has been executed—a Patient is displayed on the Patient Screen
Resulting Sequence Diagram The container object (Patient) takes responsibility for the component object (OHIPInfo); since OHIPInfo exists only within Patient, the Patient DB update will look after updating the DB with OHIP Info.
