Software Modelling Sequence Diagrams PDF

Document Details

WinningSanJose1484

Uploaded by WinningSanJose1484

University of Birmingham

2024

Tags

sequence diagrams software modelling UML diagrams software design

Summary

This document covers the topic of Software Modelling, specifically focusing on sequence diagrams. Topics include notation, examples, and interaction frames. This material is from the 2024-2025 academic year and contains questions on the subject.

Full Transcript

Week 4: Software Modelling [Part 2] Building Usable Software 2024-2025 Sequence Diagram Sequence Diagram An “interaction diagram” that models the interactions between objects or components in a system over time (focuses on the time ordering of messages). Demonstrat...

Week 4: Software Modelling [Part 2] Building Usable Software 2024-2025 Sequence Diagram Sequence Diagram An “interaction diagram” that models the interactions between objects or components in a system over time (focuses on the time ordering of messages). Demonstrate the behaviour of objects in a use case by describing the objects and the messages they pass (what and when). The diagrams are read left to right and descending. Object interactions arranged in a time sequence (i.e. time- oriented) Period of time that an object is performing an action Sequence Diagram: Notation Actor: Type of role where it interacts with the system and its objects (outside the scope). Objects: Instances of the classes which will be created and involved in the execution of an operation (use case). Lifeline: Represents an individual participant in the interaction. Activations: represents the period during which an element is performing an operation. Messages: Communication between objects (i.e. call, return, self-messages). Axes Horizontal: which objects/participants are acting. Vertical: forward in time Basic Sequence Diagram Customer 1 Server Bank Insert card Check balance Balance amount Display amount An object of class 1 sends a message to an object of class 2. The messages pass between the different objects until the object of class 1 receives the final message. Messages The direction of a solid arrow goes from the object calling the method towards the object where the method is implemented. displayMessage(text) is “void” → not have a dashed arrow check(data) should return a result → dashed arrow Creation and Destruction Create: Represents the instantiation of (target) lifeline and is denoted by a message arrow pointing to the object. Destroy: Denote the end of the useful life of an object. Duration: Shows the distance between two-time instants for a message invocation. Nested Activation Self-Message (self-call) A message an object sends to itself is usually shown as a U-shaped arrow pointing back to itself. Synchronous and Asynchronous Calls Synchronous message: Wait until the message is done. (Filled arrowhead) Asynchronous message: Continue processing and doesn’t have to wait for a response. And stick or half stick arrowhead preferred e.g. A bank customer could apply for credit card but can receive banking information over the phone or request money from an ATM, while waiting to hear about the credit application. Asynchronous Call: Example Asynchronous messages are sent from an object that will not wait for a response from the receiver before continuing its tasks. From Use Case to Sequence Diagram Sequence diagrams are derived from flows of events of use cases. An event always has a sender and a receiver. Find the objects for each event. Relation to object identification Objects/classes have already been identified during object modelling Additional objects are identified as a result of dynamic modelling But… We have seen an instance of an interaction diagram- only showing one possible message sequence. Since a use case can include many scenarios (e.g. exceptional or important variant behavior?) There is a need to show conditional behaviour. There is a need to show possible iterations. Need not draw a diagram for every possible case. This would lead to too many diagrams. Example: Self-Service Machine 1. The customer inserts money in the money slot. 2. The customer makes a selection. 3. The money travels to the register. 4. The register checks to see whether the selected product is in the dispenser. 5. The register updates its cash reserve. 6. The register has a dispenser to deliver the product to the front of the machine. Example: Self-Service Machine Self-service machine, three objects do the work we're concerned with: The front: the interface the self-service machine presents to the customer. The money registers part of the machine where money is collected. The dispenser: which delivers the selected product to the customer. Example: Self-Service Machine The "Buy a product" scenario. Because this is the best-case scenario, it's an instance sequence diagram Interaction Frames A message may be guarded by a condition. Messages are only sent if the guard evaluates to true at the time when the system reaches that point in the interaction. alt: Interaction Frames alt → Alternative: Envelopes use to show if statements. Only the one whose condition is true will execute. opt: Interaction frames Opt → Optional: Envelopes use for if statements which do not have an else clause. The fragment executes only if the supplied condition is true. This is equivalent to an alt with one trace. loop: Interaction frames for(x=1, x

Use Quizgecko on...
Browser
Browser