110 likes | 227 Views
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
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.