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
Book a
• Not dashed or curved line ride
Rid
• A actor must have at least one association in er
Figure: association
the diagram between an actor and
an use case

• An use case can be associated with zero or

more actors

14
Generalization
• Represents the parent-child relation Rid
er
• Represented by a straight line with
hollow arrow Premium Irregular
Rider
Figure: Rider
Generalization relation
between actors
• Can indicate the relation between
• Either Actors pay
online
• Or Use cases

pay
pay with
with
bkash
card
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
<<includ
e>>

• 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
<<exten
• One use case (extension) extends the behavior of d>>
Give
another (base) review
Figure: extend relation

16
Dependency
Arrow Position
Book a
ride
• The arrow should be placed with the use case which <<includ
execute first. e>>

• In first example, You need to book a ride first then you Confirm
can confirm. So the arrow is with book a ride. the ride

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

<<exten
d>>
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

18
table
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
custom
Bank employee er

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
custom customer
er 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 ?

custom
er

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
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