50.003 - Sequence Diagrams (Contd)

Learning Outcomes

By the end of this unit, you should be able to

1. Describe elements of UML activity diagram
2. Explain the steps to derive UML sequence diagram
3. Derive a UML sequence diagram

Sequence Diagram - Introduction

Refer to the previous lesson to recall the basics of sequence diagram.

Derivation of a Sequence Diagram

It is important to understand which artifacts are needed to derive a sequence diagram as well as how to do it. Sequence diagram represents the sequence of message (method) flow between classes for a given use case. We will need the artifacts which defines the users (use case diagram/description), classes (class diagram) and sequences of interactions (activity diagram). We can follow the following steps from the beginning to derive a sequence diagram for a given use case.

1. Identify the use case : To find the scope covered by the sequence diagram we should identify the use case first.

2. Derive use case diagram/description: The high level sequence of operations for a use case is mentioned in the use case description in the format of 1. user to system 2. system to user. The high level system will be refined to more specific class names later.

3. Derive classes: The entities involved in the usecase are identified in the domain class diagram. More implementation level classes can also be identified.

4. Derive activity diagram: What is the control flow of operations? A use case description can be transformed to the corresponding activity diagram by explicitly visualizing control flows (if-else, loops, parallel). Owning classes of the activities can also be included to the activity diagram as a refinement.

Example - Transfer Funds (Banking App)

Lets go through the above mentioned steps to derive the sequence diagram for Transfer Funds use case.

Identify the use case:

Use case is initiated by a customer of a banking app to transfer funds from the customer's account to another account.

Derive use case description

ID:	UC2	Name:	Transfer Funds
Description:	Customer transfers money from her account to another account
Created By:	Dileepa Fernando	Date Created:	1st May 2025
Last Updated By:	Dileepa Fernando	Date Updated:	3rd May 2025
Actors:	Customer, SMS Gateway
Triggers:	The Customer clicks on Transfer menu
Preconditions:	Customer is logged in and authenticated
Postconditions:	1. the customer transfers the mentioned fund value to the selected recipient 2. The customer's balance is reduced by the mentioned fund value
Error States:	Fund transfer fail
Flow:	1. Customer inputs transfer details (source account, destination account, amount) 2. System validates the input 3. System verifies sufficient balance 4. System transfers funds 5. System records transaction 6. System confirms transfer to user
Alternative Flow:	2A Invalid input: a. System shows validation error message b. Customer is prompted to correct the input c. Flow resumes at Step 1 3A Insufficient Balance: a. System shows validation error message b. Customer is prompted to correct the input c. Flow resumes at Step 1

Derive Domain Classes :

For this step, we do not need to draw a detailed class diagram. It is sufficient to identify the entities first. The entities in the transfer funds are customer ,bank account and transaction. Customer has one or more bank accounts (single one in this scenario) and bank account contains a list of transactions.

Class Diagram for Transfer Funds

Derive activity diagram :

Introduction

An activity diagram is a more explicit representation of use case description. The operational flow can be refined and the control flows (if-else, loop) can be explicitly shown. It is a directed graph having start node, stop node and activity nodes. The two nodes start does not have incoming edges while stop does not have outgoing edges.

Start Node	Stop Node

The other nodes can represent activities, condition checks or converging after condition checks.

1. Activity node (rounded rectangle)

   Activity Node

2. condition check node (hexagon) and converging node (diamond)

   Condition Check Node	Converging Node

An edge from one node to another means the activity in second node immediately follows the activity in first node. The activity can be checking a condition too.

1. Non Condition nodes other than stop, has exactly one edge going out.

   Activity Flow edge

2. Condition check nodes will have multiple edges going out and the edges can be annotated by the possible conditions. For each conditioned edge, there is a unique destination node which represents the next activity. All these destination nodes converge to a linear flow at a diamond node.

   Condition diverge and converge edges

3. There can be back edges referencing activities which already happened. Back edges represent loops. Back edge starts from a diamond node representing the loop condition and ends with the first activity of the loop.

   Loops and back edges

Derivation of Activity Diagram for Bank App - Transfer Funds

1. Draw the start and stop nodes
2. Consider the operational flow in use case description. If there are operations that can be written in detail as multiple steps
3. Identify the alternative flows. Consider adding condition nodes to represent the conditions resulting in alternative flows.

4. If the an alternative flow reaches a previous node represent it by a back edge.

   Initial Activity Diagram

5. Refine the activity diagram: The initial activity diagram needs to be refined to contain details about classes too.

   1. Use the class diagram to identify the classes involved in each activity (including condition checks) so that each activity can be tranformed to a message passed from one class to another. To achive this, we annotate the initial activity diagram with the domain classes. The class is generally identified by the object which changes after the activity. The annotation is applied to the outgoing edge after each activity node.

      Initial Activity Diagram Annotated with Domain classes

   2. If some activities cannot be related to a single class, it means that multiple classes are affected by the given activity. In this case, we decompose the activity node into multiple activity nodes (or sub activity diagram on its own) until we can assign each activity node to a single class. The decomposition can be another activity diagram on its own. In the example, we decompose the record transaction activity to the sequence of two activities create transaction followed by record transaction. Create transaction belongs to Transaction class while Record transaction belongs to account class allowing a single class annotation.

      With expanded activities

   3. Note that there are many activities without any specific class annotation. because those belong to the system. We can follow the high level MVC architecture and identify each class as one of MVC. The model refers to how data is being handled. Firstly, we have account and transaction classes in the model category which are already defined as domain classes. When it comes to implementation, we will have to add the database class as a model class. Secondly, We use UI class in general to refer view category. Finally, we define all other classes which route requests between view and model (Ex: Code in routes.js ) as controller classes. Following diagram shows the activity diagram, annotated with UI and controller classes.

      Adding missing class annotations

   4. Since we have the class annotations now, all we need to figure out is the lifelines and the messages between them. Life lines are exactly the annotated classes. Here, we are going to use the swim lane feature in activity diagram, where each swim lane (analogous to a life line) represents one class. Each node is placed in the swim lane which represents the class which is affected by the activity (including condition checks). The starting node and end node for each edge are not affected.

      Activity Diagram with Swim Lanes

   5. Note the loops and conditional sequences (highlighted in red)

6. Final mapping to the sequence diagram:

   1. Swim lanes to life lines: An activity node in a swim lane can be mapped to a message arrow ending at the life line with the same name. The message arrow should start from the life line corresponding to previous activity. The text on the message arrow should be the name of the current activity being considered. For example, validate input activity starts from UI life line (swim lane of previous activity input transfer details) and ends from the Controller life line (swim lane of current activity) with the message text of validate input.

   2. For object creation, indicate a create message (Ex: create transaction message from Account to Transaction)

   3. For each message, add a return message. (Ex: return message for Validate input )

   4. If message A depends on the result of the message B, the message order should be 1. message A 2. message B 3. return message B 4. return message A (Ex:1. input transfer details 2. validate input 3. return validate input 4. return input transfer details)

   5. Add activation bars between each message and corresponding return message. (Ex: validate input return validate input has activation bar at the life line Controller)

   6. Map conditions in activity diagram to alt fragments in sequence diagram. Map loops in activity diagram to loop fragments in sequence diagram. Copy the conditions from hexagons to loop header and alt header.

   Final mapping to Sequence Diagram