UML Diagrams

Ref: Whitten et all, Systems Analysis and Design Methods 7e. McGraw-Hill Higher Education
 Key Ideas
• Introduction to UML diagrams
• Use case diagram
• Sequence diagram
• Class diagram
• & Activity diagram

Slide 2
 UML diagram
• Stands for Unified Modeling Language
• A language with notion which can be understand by all the parties involved with software
• Initiated by Rational Software in 1994-95
• Popular tools –
• Rational Rose
• Microsoft Visio
• Draw.io

3
Different Types of UML

4
Use case diagram
 What is Use Case ?
• Use case diagrams considers mostly as a requirement analysis tools
• It identifies the uses of the system based on a case
• Use indicates the actions
• Case indicates the action linked with actor (who performs the action)
• All the action verbs mentioned in requirement specification is an use case in this diagram
• To draw the use case diagram, one need to
• Identify all the entity who will performs action
• And all the actions needed to support by the system

6
 Components of Use Case diagram
• Use case diagram is composed of four components
• Actor
• Use case
• System boundary
• Relations

7
 Actor
• The entity which performs the actions or roles in the system
• Actor is responsible for giving input to the system
• Responsible to use processed output for performing particular
action
• Actor must be connected with at least one use case

• Primary actor
Figure: Actor in Usecase
• Secondary actor
• External hardware
• Other System

8
 Types of Actor

Primary actor
• People who performs the main system functions.
• For example rider of a ride sharing system. As s/he is requesting for ride, or paying the money
using the system.

Secondary actor
• People who performs the administrative functions.
• For the aforementioned system a manager who sets the discounts is an example of Secondary
actor.

9
 Types of Actor (cont.)

External hardware
• Any external hardware device which is a part of the application.
• If the system using amazon datastore as their database.

Other System
• Any external system which has interaction with the current system.
• Payment gateway is an example of such actor.

10
 Use Cases
• Indicates the system functions performed by an actor

• It can also describes the sequence of actions in a system

• Every Use case must have a unique name

• Use case must be started with principal verb Book a ride

• Use cases in the diagram must be enclosed by the system boundary

Figure: An Use case
• Every Use case should be connected with either actor or another use case

• Must be represented by an ellipse

11
 System Boundary

• Shows how the system interacts with the user

• Class in which use case are executed

• Represented by the use cases within a rectangle and actors will

outside of the system boundary

Figure: The system boundary of Use case

12
 Relation
• Also Known as by communication line
• It represents the connection between any two components
of use case diagram
• Can be of three types
• Association
• Generalization
• Dependency

13
 Association
• Connects an actor with the use case
• Identifies the actor(s) are responsible/user of the use case
• Represented by a straight solid line
• No arrow
• Not dashed or curved line
Book a
• A actor must have at least one association in the diagram Rider
ride

• An use case can be associated with zero or more actors Figure: association between an
actor and an use case

14
 Generalization
• Represents the parent-child relation Rider

• Represented by a straight line with hollow

arrow Premium Rider Irregular Rider
Figure: Generalization relation between actors

• Can indicate the relation between

• Either Actors pay
online
• Or Use cases

pay with pay with

card bkash

Figure: Generalization relation between use cases

15
 Dependency
• Indicates the dependency relationship between two use
cases. Book a ride
• Two types of dependencies : Include & Extend
<<include>>

• Include relationships Confirm

the ride
• One use case (base) includes the functionality of another
(inclusion case) Figure: Include relation

• Supports re-use of functionality

Finish the
ride
• Extend relationships
<<extend>>
• One use case (extension) extends the behavior of another (base)
Give review

Figure: extend relation

16
 Dependency
Arrow Position
Book a ride

• The arrow should be placed with the use case which execute <<include>>
first.
• In first example, You need to book a ride first then you can confirm. Confirm
So the arrow is with book a ride. the ride

• in second example, You need to finish the ride first then you can give Figure: Include relation
review or not. So arrow is with Finish the ride.

Finish the
ride

<<extend>>

Give review

Figure: extend relation

17
 Use case Description
• Every use case diagram must have its description
• Usually description is presented in tabular form
• The diagram should have a unique id
• Typically the description form include the fields –
Use case Name, Id, Actor(s), Description, Precondition, Postcondition, Action Flow, Exceptions,
etc.
• All the fields might not be available for all the diagrams.

Figure: An Use case description table

18
Use case example 1 : Purchasing an item

19
 How to Create a Use Case Diagram

1. Identifying Actors
2. Identifying Use Cases
3. Look for Common Functionality to use Include
4. Is it Possible to Generalize Actors and Use Cases
5. Optional Functions or Additional Functions

Slide 20
 How to Create a Use Case Diagram

Identifying Actors

Customer
customer
Bank employee
NFRC Customer
Bank Employee

NFRC customer

Slide 21
 How to Create a Use Case Diagram

Identifying Use Cases

• A good way to do this is to identify what the actors need from the system

• A customer will need to

1. open accounts

2. Deposit funds

3. withdraw funds

4. request check books

Slide 22
 How to Create a Use Case Diagram

Open
account
Convert
Deposit currency
funds NFRC customer
customer
Withdraw
funds

Open
account
Bank employee

Slide 23
 How to Create a Use Case Diagram

• Look for Common Functionality to use Include

• find two or more use cases that share common functionality

Withdraw
funds <<include>>

Update
<<include>>
balance
Deposit
funds

Slide 24
 How to Create a Use Case Diagram

• Is it Possible to Generalize Actors ?

customer

NFRC customer

Slide 25
 How to Create a Use Case Diagram

• Optional Functions or Additional Functions

• There are some functions that are triggered optionally

Amount over 50000 or

Age over 55

<<extend>>
Deposit Calculate
funds bonus

Slide 26
 Practice

• Hospital Management System is a large system including several

subsystems or modules providing variety of functions. UML use case
diagram example below shows actor and use cases for a hospital's
reception.
• Purpose: Describe major services (functionality) provided by a hospital's
reception.
• Hospital Reception subsystem or module supports some of the many job
duties of hospital receptionist. Receptionist schedules patient's
appointments and admission to the hospital, collects information from
patient upon patient's arrival and/or by phone. For the patient that will stay
in the hospital ("inpatient") she or he should have a bed allotted in a ward.
Receptionists might also receive patient's payments, record them in a
database and provide receipts, file insurance claims and medical reports.

Slide 28
Slide 29
• Bank customer has to provide pin for login, verified by bank, there could be
mistake while entering the pin, customer can do transactions like (fund transfer,
withdraw, change pin, balance check, deposit) etc., ATM Machine will provide a
print out if customer wants to get a receipt of their transaction considering
some charges, charges will also apply for each transaction. There is system
administrator who monitors users’ transaction and report if any suspicious
activities is noticed. Also maintains ATM machine money loading and
maintenance.

Slide 30
UML Activity Diagrams
 OUTLINE
• Introduction
• Activity Diagrams - notation
• How to apply activity diagrams
• Guidelines
• Examples
 What is an Activity Diagram?
• An Activity Diagram is one of the Behavior diagrams.
• Activity modelling is the sequence and conditions for coordinating lower-level
behaviors, rather than which classifiers own those behaviors.
• These are commonly called control flow and object flow models.
• The behaviors coordinated by these models can be initiated because other
behaviors finish executing, because objects and data become available, or because
events occur external to the flow.
• A UML Activity Diagram shows sequential and parallel activities in a process.
• Useful for modelling:
• Business processes
• Workflows
• Data flows
• Complex algorithms
 Initial and Final Nodes
• Initial Node:
• An initial node is a control node at which flow starts when the
activity is invoked.
• An activity may have more than one initial node.

• Final Node:
• An activity may have more than one activity final node;
the first one reached stops all flows in the activity.
 Action
• Action:
• An action represents a single step within an activity that is not further
decomposed within the activity.
• An activity represents a behavior that is composed of individual elements that are
actions.
• An action is simple from the point of view of the activity containing it, but may be
complex in its effect and not be atomic.
• An activity can be reused in many places, whereas an instance of an action is only
used once at a particular
• An action will not begin execution until all of its input conditions are satisfied.
Merge and Decision Nodes
• Merge Node:
• A merge node is a control node that brings together
multiple alternate flows.
• It is not used to synchronize concurrent flows but to
accept one among several alternate flows.
• A merge node has multiple incoming edges and a single
outgoing edge.

• Decision Node:
• A decision node accepts tokens on an incoming edge and
presents them to multiple outgoing edges.
• Which of the edges is actually traversed depends on the
evaluation of the guards on the outgoing edges.
 Join and Fork Nodes
• Join Node:
• A join node is a control node that synchronizes multiple flows.
• A join node has multiple incoming edges and one outgoing edge.

• Fork Node:
• A fork node is a control node that splits a flow into multiple
concurrent flows.
• A fork node has one incoming edge and multiple outgoing edges.

Fork Node

Join Node
 Object Node

• Object Node:
• An object node is an activity node that indicates an
instance of a particular classifier, possibly in a
particular state, may be available at a particular point
in the activity.
• Object nodes can be used in a variety of ways,
depending on where objects are flowing from and to.
 NOTE

• Note:
• A note (comment) gives the ability to attach various remarks to
elements.
• A comment carries no semantic force, but may contain
information that is useful to a modeler.
 Business Process Modelling

• Example: Parcel shipping

• The process of shipping a parcel is non-trivial; there are many

parties involved (customer, driver,. . . ) and many steps.

• The process can be captured by a Use Case diagram, but

activity diagrams are great example of “a picture being worth a
thousand words”.

• Object nodes are useful for illustrating what is moving around.

Activity Diagram Parcel shipping
Activity Diagram of order management
system
Guideline for Activity Modelling

• The technique proves most valuable for very complex

processes, usually involving many parties.
• On a first overview “level 0” diagram, keep all the actions
at a very high level of abstraction, so that the diagram is
short. Then expand details in sub-diagrams at the “level
1” level,. . . etc.
• Try to make the level of abstraction of action nodes
roughly equal within a diagram (Very different levels of
abstraction might be a node labelled “Deliver Order” and
a node labelled “Calculate Tax”).
More Examples: Recycling Activity Diagrams
 Swimlanes

• Swimlanes (or activity partitions) indicate where activities

take place.
• Swimlanes can also be used to identify areas at the
technology level where activities are carried out
• Swimlanes allow the partition an activity diagram so that
parts of it appear in the swimlane relevant to that element
in the partition
 Swimlanes

• Partitions may be constructed on the basis of:

• the class and actor doing the activity
• Partitioning by class and actor can help to identify new
associations that have not been documented in the
class model
• the use case the activity belongs to
• Partitioning by use cases can help document how use
cases interact
 Example Activity
Process Order - Problem Description
Once the order is received, the
activities split into two parallel sets of
activities. One side fills and sends the
order while the other handles the
billing.

On the Fill Order side, the method of

delivery is decided conditionally.
Depending on the condition either
the Overnight Delivery activity or the
Regular Delivery activity is
performed.

Finally the parallel activities combine

to close the order.
Example Swimlanes
 Class work
• ATM system of BRAC bank
• Customer
• ATM
• Bank server