1

Use Case Diagrams

 What is UML
• Unified Modeling Language (UML) is a general purpose modelling language. The
main aim of UML is to define a standard way to visualize the way a system has
been designed. It is quite similar to blueprints used in other fields of engineering .
UML

4
UML

5
UML

6
 UML

1.Structural Diagrams – Capture

static aspects or structure of a
system. Structural Diagrams include:
Component Diagrams, Object
Diagrams, Class Diagrams and
Deployment Diagrams.
2.Behavior Diagrams – Capture
dynamic aspects or behavior of the
system. Behavior diagrams include:
Use Case Diagrams, State Diagrams, 7
UML

8
 Use Cases
• What is a Use Case
 A formal way of representing how a business system
interacts with its environment
 Illustrates the activities that are performed by the
users of the system
 A scenario-based technique in the UML
 A sequence of actions a system performs that yields a
valuable result for a particular actor.
 Use Case Analysis
• What is an Actor?
– A user or outside system that interacts with
the system being designed in order to obtain
some value from that interaction
• Use Cases describe scenarios that describe the
interaction between users of the system (the actor)
and the system itself.
 Use Cases
• Use case diagrams describe what a
system does from the standpoint of an
external observer. The emphasis is on
what a system does rather than how.

• Use case diagrams are closely

connected to scenarios. A scenario is
an example of what happens when
someone interacts with the system.
 Use Cases
• Here is a scenario for a medical clinic.

• A patient calls the clinic to make an appointment for a

yearly checkup. The receptionist finds the nearest empty
time slot in the appointment book and schedules the
appointment for that time slot. "

• We want to write a use case for this scenario.

• Remember: A use case is a summary of scenarios for a
single task or goal.
 Use Cases

• Step 1 Identify the actors

• As we read the scenario, define those
people or systems that are going to interact
with the scenario.

• A patient calls the clinic to make an appointment for a yearly checkup. The
receptionist finds the nearest empty time slot in the appointment book and
schedules the appointment for that time slot. "
 Questions for Identifying People Actors

• Who is interested in the scenario/system?

• Where in the organization is the scenario/system be used?
• Who will benefit from the use of the scenario/system?
• Who will supply the scenario/system with this information,
use this information, and remove this information?
• Does one person play several different roles?
• Do several people play the same role?
 Questions for Identifying Other Actors

• What other entity is interested in the scenario/system?

• What other entity will supply the scenario/system with
this information, use this information, and remove this
information?
• Does the system use an external resource?
• Does the system interact with a legacy system?
 Actors

• An Actor is outside or external the system.

• It can be a:
– Human
– Peripheral device (hardware)
– External system or subsystem
– Time or time-based event
• Represented by stick figure
 Use Cases
• A use case is a summary of scenarios
for a single task or goal.

• An actor is who or what initiates the

events involved in the task of the use
case. Actors are simply roles that
people or objects play.

• So as we read our scenario, what or

who is the actor????
 Use Cases

• So as we read our scenario, what or

who is the actor????

• A patient calls the clinic to make an appointment for a yearly checkup. The
receptionist finds the nearest empty time slot in the appointment book and
schedules the appointment for that time slot. "

• The actor is a Patient.

 Use Cases

• The use case is a summary of

scenarios for a single task or goal.

• So What is the Use Case????

• The Use Case is Make Appointment.

• It is a use case for the medical clinic.
 Use Cases

• The picture below is a Make Appointment use case for the medical clinic.
• The actor is a Patient. The connection between actor and use case is a
communication association (or communication for short).

k figures. Use cases are ovals. Communications are lines that link actors to use cases.

Actors are stick figures. Use cases are ovals. Communications are lines that link
actors to use cases.
 Use Case Componentss

• The use case has three components.

• The use case task referred to as the use case that

represents a feature needed in a software system.

• The actor(s) who trigger the use case to activate.

• The communication line to show how the actors

communicate with the use case.
Use Case Diagram - Use Case
Use Case
Use Case

Make
Appointment
Use Case - Actor
 Use Case - Relationships

• Relationships
– Represent communication between actor and use case
– Depicted by line or double-headed arrow line
– Also called association relationship

Make
Appointment
 Use Case - Relationships

• Boundary
– A boundary rectangle is placed around the perimeter of
the system to show how the actors communicate with
the system.

Make
Appointment
 Use-Case Diagram

A use case diagram is a collection of actors, use cases, and their communications.
 There can be 5 relationship types in a use case
diagram.

• Association between actor and use

case
• Generalization of an actor
• Extend between two use cases
• Include between two use cases
• Generalization of a use case

29
 Association between actor and use case

• An actor must be associated with at least one use case.

• An actor can be associated with multiple use cases.
• Multiple actors can be associated with a single use
case.

30
Generalization of an actor

31
Extend between two use cases

32
Extend between two use cases

33
 Extend between two use cases

• The extending use case is dependent on the

extended (base) use case. For example“Calculate
Bonus” use case doesn’t make much sense without
the “Deposit Funds” use case.
• The extending use case is usually optional for
example you can see that the extending use case is
triggered only for deposits over 10,000 or when the
age is over 55.
• The extended (base) use case must be meaningful
on its own. This means it should be independent and
must not rely on the behavior of the extending use
case.
34
Extend between two use cases

35
Extend between two use cases

36
Extend between two use cases

37
 Include between two use cases

Include relationship show that the behavior of the included use

case is part of the including (base) use case. The main reason for
this is to reuse common actions across multiple use cases.

In some situations, this is done to simplify complex behaviors.

Few things to consider when using the <<include>> relationship.

The base use case is incomplete without the included use case.
The included use case is mandatory and not optional.

38
Include between two use cases

39
Include between two use cases

40
Include and exclude relationship

41
 Generalization of a use case
• This is similar to the generalization of an actor. The behavior
of the ancestor is inherited by the descendant. This is used
when there is common behavior between two use cases and
also specialized behavior specific to each use case.

• For example, in the previous banking example, there might be

a use case called “Pay Bills”. This can be generalized to “Pay
by Credit Card”, “Pay by Bank Balance” etc.

• I hope you found this article about use case

relationships helpful and useful. You can use our
diagramming tool to easily create use case diagrams online. As
always if you have any questions don’t hesitate to ask them in
the comments section.
42
Generalization of a use case

43
Generalization relationship between actors

44
 Applying relationship on use case

Child use
case

Parent use
case

45
Class Diagram

46
Class Diagram

47
Class Diagram

48
Class Diagram

49
Class Diagram

50
Class Diagram

51
Class Diagram

52
Class Diagram

53
Class Diagram

54
Class Diagram

55
Class Diagram

56
Class Diagram

57
Class Diagram

58
Class Diagram

59
Class Diagram

A course can have zero or

more students

Student can
choose more
than one course
60
 Class Diagram
Multiplicity
A store can have
multiple items

Or multiple items
can be in one store

Where * indicates zero or more

61
 Class Diagram
Multiplicity

62
 Class Diagram
Multiplicity

63
Class Diagram

64
Class Diagram

65
Class Diagram

66
Class Diagram

67
Class Diagram

68
Class Diagram

69
Class Diagram

70
Class Diagram

Here building class

can send message
to office but vice
versa is not true.

71
Class Diagram

72
Class Diagram

73
Class Diagram

74
Class Diagram

75
Class Diagram

76
Class Diagram

77
Class Diagram

78
Class Diagram

79
Class Diagram

80
 Object Diagram
Structural Diagram

• A UML object diagram represents a specific instance of a

class diagram at a certain moment in time.

• An object diagram focuses on the attributes of a set of

objects and how those objects relate to each other.

• They are be useful to explain smaller portions of your

system, when your system class diagram is very complex

81
 Object Diagram
Structural Diagram

• Object diagram elements

• Object diagrams are simple to create: they're
made from objects, represented by rectangles,
linked together with lines.

(i) Objects
Objects are instances of a class. For example, if
"car" is a class, a 2007 Nissan Altima is an object
of a class.
Symbol for object

82
 Object Diagram
Structural Diagram

• Object diagram elements

Object Attributes:
Similar to classes, you are able to list object attributes inside a separate
compartment. However, unlike classes, object attributes should have values
assigned for them.

83
 Object Diagram
Structural Diagram

• Object diagram elements

(ii)Class titles

Class titles are the specific

attributes of a given class. In
the family tree object diagram,
class titles include the name,
gender, and age of the family
members. You can list class
titles as items on the object or
even in the properties of the
object itself (such as color). 84
 Object Diagram
Structural Diagram

• Object diagram elements

(iii) Links
Links are the lines that connect two shapes of an
object diagram to each other.

Link

85
 Object Diagram
Class to Object Diagram Example - Order System

86
 Object Diagram
Example 1

87
 Sequence Diagram

Sequence Diagrams are interaction diagrams that

detail how operations are carried out. They capture
the interaction between objects in the context of a
collaboration. Sequence Diagrams are time focus and
they show the order of the interaction visually by
using the vertical axis of the diagram to represent
time what messages are sent and when.

88
 Sequence Diagram
Purpose of Sequence Diagram
• Model high-level interaction between active objects in a
system
• Model the interaction between object instances within a
collaboration that realizes a use case
• Model the interaction between objects within a collaboration
that realizes an operation
• Either model generic interactions (showing all possible
paths through the interaction) or specific instances of a
interaction (showing just one path through the interaction)

89
Sequence Diagram

90
Sequence Diagram

91
Sequence Diagram

It has two dimensions

The horizontal axis shows the
objects.

92
Sequence Diagram
It has two dimensions
The vertical axis shows the time from top
to bottom

93
 Sequence Diagram Notation

Actor

• A type of role played by an entity that interacts with the subject (e.g., by
exchanging signals and data)

• external to the subject (i.e., in the sense that an instance of an actor is not
a part of the instance of its corresponding subject).

• represent roles played by human users, external hardware, or other

subjects.

94
 Sequence Diagram Notation

Lifeline

• A lifeline represents an individual participant in the Interaction.

.

95
 Sequence Diagram Notation

Activations

• A thin rectangle on a lifeline) represents the period during which an

element is performing an operation.

• The top and the bottom of the of the rectangle are aligned with the
initiation and the completion time respectively
.

96
 Sequence Diagram Notation

Call Message

• A message defines a particular communication between Lifelines of an

Interaction.

• Call message is a kind of message that represents an invocation of

operation of target lifeline.
.

97
Call Message

98
Call Message

99
 Sequence Diagram Notation

Return Message

• A message defines a particular communication between

Lifelines of an Interaction.

• Return message is a kind of message that represents the

pass of information back to the caller of a corresponded
former message.
.

100
Call Message

101
Sequence Diagram Notation

102
Sequence Diagram Notation

103
 Sequence Diagram Notation

Self Message

• A message defines a particular communication between Lifelines of an

Interaction.

• Self message is a kind of message that represents the invocation of

message of the same lifeline.

104
 Sequence Diagram Notation

Self Message

105
 Sequence Diagram Notation

Recursive Message

• A message defines a particular communication between

Lifelines of an Interaction.

• Recursive message is a kind of message that represents

the invocation of message of the same lifeline. It's target
points to an activation on top of the activation where the
message was invoked from.

106
 Sequence Diagram Notation

Recursive Message

107
 Sequence Diagram Notation

Create Message

• A message defines a particular communication between

Lifelines of an Interaction.

• Create message is a kind of message that represents the

instantiation of (target) lifeline.

108
Sequence Diagram Notation

109
 Sequence Diagram Notation

Destroy Message

• A message defines a particular communication between

Lifelines of an Interaction.

• Destroy message is a kind of message that represents the

request of destroying the lifecycle of target lifeline.

110
 Sequence Diagram Notation

Duration Message

• A message defines a particular communication between

Lifelines of an Interaction.

• Duration message shows the distance between two time

instants for a message invocation.

111
 Sequence Diagram Notation

Duration Message

• A message defines a particular communication between

Lifelines of an Interaction.

• Destroy message is a kind of message that represents the

request of destroying the lifecycle of target lifeline.

112
 Sequence Diagram Notation

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.

113
 Sequence Fragments

Sequence Fragments

• UML 2.0 introduces sequence (or interaction) fragments.

Sequence fragments make it easier to create and maintain
accurate sequence diagrams

• A sequence fragment is represented as a box, called a

combined fragment, which encloses a portion of the
interactions within a sequence diagram

• The fragment operator (in the top left cornet) indicates the
type of fragment

• Fragment types: ref, assert, loop, break, alt, opt, neg

. 114
 Sequence Fragments

Sequence Fragments

115
 Sequence Diagram

Advantages
• It is convenient to generate.

• It has convenient maintenance.

• It portrays the flow of messages between various objects.

• It can be used to execute forward engineering and reverse

engineering as well.

• It can conveniently update according to the changes in a

system.

• It scrutinizes various real-time operations.

116
 Sequence Diagram

Disadvantages
• Every sequence requires several notations for their
representation, so it can make these diagrams more
complicated.

The sequence type can be elected through the message type.

• The sequence diagram may get convoluted if there are so
many lifelines present in the system.

• When the sequence of the message flow modifies, then it

may be possible to generate an incorrect outcome.

117
 State Diagram
• A state diagram consists of states, transitions, events, and
activities. You use state diagrams to illustrate the dynamic view of
a system. They are especially important in modeling the behavior
of an interface, class, or collaboration.

• State diagrams emphasize the event-ordered behavior of an object,

which is especially useful in modeling reactive systems.

• You use state machines to model the behavior of any modeling

element, although, most commonly, that will be a class, a use
case, or an entire system which focuses on the event-ordered
behavior of an object, which is especially useful in modeling
reactive systems.

118
 State Diagram
Key Concepts of a State Machine

A state machine is a behavior that specifies the sequences of

states an object goes through during its lifetime in response to
events, together with its responses to those events.

A state is a condition or situation during the life of an object during

which it satisfies some condition, performs some activity, or waits
for some event.

119
 State Diagram
Key Concepts of a State Machine

Transition
A solid arrow represents the path between
different states of an object. Label the transition
with the event that triggered it and the action that
results from it. A state can have a transition that
points back to itself.

120
 State Diagram
Key Concepts of a State Machine

Initial State
A filled circle followed by an arrow represents the
object's initial state.

121
 State Diagram
Key Concepts of a State Machine

Final State
An arrow pointing to a filled circle nested inside
another circle represents the object's final state.

122
 State Diagram
Key Concepts of a State Machine

Synchronization and Splitting of Control

A short heavy bar with two transitions entering it

represents a synchronization of control. The first
bar is often called a fork where a single transition
splits into concurrent multiple transitions. The
second bar is called a join, where the concurrent
transitions reduce back to one.

123
State Diagram

124
State Diagram

125
 Activity Diagram

Activity diagram is another important behavioral diagram in

UML diagram to describe dynamic aspects of the system.
Activity diagram is essentially an advanced version of flow chart
that modeling the flow from one activity to another activity.

126
 Activity Diagram

When to Use Activity Diagram

• Activity Diagrams describe how activities are coordinated to provide a
service which can be at different levels of abstraction.

• Typically, an event needs to be achieved by some operations, particularly

where the operation is intended to achieve a number of different things that
require coordination, or how the events in a single use case relate to one
another, in particular, use cases where activities may overlap and require
coordination.

• It is also suitable for modeling how a collection of use cases coordinate to

represent business workflows

127
 Activity Diagram Notation

Activity
Is used to represent a set of actions

Action
A task to be performed

Control Flow
Shows the sequence of execution

Initial Node
Portrays the beginning of a set of
actions or activities

Activity Final Node

Stop all control flows and object flows in
an activity (or action)
128
 Activity Diagram Notation
Decision Node
Represent a test condition to ensure that
the control flow or object flow only goes
down one path

Merge Node
Bring back together different decision
paths that were created using a decision-
node.

Fork Node
Split behavior into a set of parallel or
concurrent flows of activities (or actions)

Join Node
Bring back together a set of parallel or
concurrent flows of activities (or actions).

129
Component Diagram

130
Component Diagram

131
 Elements of component diagram

(i)Component
A component is a logical unit block of the
system, a slightly higher abstraction than
classes. It is represented as a rectangle with
a smaller rectangle in the upper right corner
with tabs or the word written above the
name of the component to help distinguish it
from a class.

132
 Elements of component diagram

Component
A component is a logical unit block of the
system, a slightly higher abstraction than
classes. It is represented as a rectangle with
a smaller rectangle in the upper right corner
with tabs or the word written above the
name of the component to help distinguish it
from a class.

133
 Elements of component diagram

(ii)Interface
An interface (small circle or semi-circle on a stick) describes
a group of operations used (required) or created (provided)
by components. A full circle represents an interface created
or provided by the component. A semi-circle represents a
required interface, like a person's input.

134
 Elements of component diagram

(iiI) Dependencies

Draw dependencies among components using dashed

arrows

135
 Elements of component diagram

(iiI)
Port
Ports are represented using a square along
the edge of the system or a component. A
port is often used to help expose required
and provided interfaces of a component.

136
 Relationships

Graphically, a component diagram is a collection of vertices and arcs

and commonly contain components, interfaces and dependency,
aggregation, constraint, generalization, association, and realization
relationships. It may also contain notes and constraints.

(i) Association:
• An association specifies a semantic relationship that can occur
between typed instances.
• It has at least two ends represented by properties, each of which is
connected to the type of the end. More than one end of the
association may have the same type.

137
 Relationships

(ii) Composition:
• Composite aggregation is a strong form of aggregation
that requires a part instance be included in at most one
composite at a time.
• If a composite is deleted, all of its parts are normally
deleted with it.

138
 Relationships

(ii) Composition:
•Composite aggregation is a strong form of aggregation
that requires a part instance be included in at most one
composite at a time.
•If a composite is deleted, all of its parts are normally
deleted with it.

139
 Relationships

(iii) Aggregation

A kind of association that has one of its end marked shared as kind of
aggregation, meaning that it has a shared aggregation.

140
 Relationships

(iv) Constraint

A condition or restriction expressed in natural language text or

in a machine readable language for the purpose of declaring
some of the semantics of an element.

141
 Relationships

(V) Dependency

• A dependency is a relationship that signifies that a single or

a set of model elements requires other model elements for
their specification or implementation.
• This means that the complete semantics of the depending
elements is either semantically or structurally dependent on
the definition of the supplier element(s).

142
 Relationships

(iv) Dependency

•A dependency is a relationship that signifies that a single or a

set of model elements requires other model elements for their
specification or implementation.
•This means that the complete semantics of the depending
elements is either semantically or structurally dependent on
the definition of the supplier element(s).

143