Unified

Modelling
Language (UML)
Contents

▪ Introduction
▪ Types of UML Diagrams
▪ Views Supported in UML

2
Introduction
"A picture is worth a thousand
words..."
3
What is UML?
 UML is an acronym that stands for Unified Modeling
Language.
 UML is a modern approach to modeling and
documenting software.
 It is one of the most popular business process modeling
techniques.
 It is based on diagrammatic representations of
software components.
 By using visual representations, we are able to better
understand possible flaws or errors in software or
business processes.
 In 1994-1996, the UML was developed by three
software engineers working at Rational Software. It
UML - Introduction
 UML is a standard language for specifying,
visualizing, constructing, and documenting the
artifacts of software systems.
 In software engineering, an artifact is an item
created during the development process that helps
describe the software's design, architecture, and
function.
 Some examples of software artifacts include: Data
models, Prototypes, Workflow diagrams, Design
documents, Setup scripts, Databases, and Printed
documents.
 UML was created by the Object Management Group
(OMG) and UML 1.0 specification draft was proposed
to the OMG in January 1997.
 UML stands for Unified Modeling Language.
 UML is different from the other common
programming languages such as C++, Java,
COBOL, etc.
 UML is a pictorial language used to make
software blueprints.
 UML can be described as a general purpose
visual modeling language to visualize, specify,
construct, and document software system.
 Although UML is generally used to model
software systems, it is not limited within this
boundary. It is also used to model non-software
systems as well. For example, the process flow
in a manufacturing unit, etc.
What is the use of
UML?
 UML has been used as a general-purpose modeling language

in the field of software engineering. However, it has now

found its way into the documentation of several business

processes or workflows.
A Conceptual Model of UML
 A conceptual model can be defined as a model which
is made of concepts and their relationships.
 A conceptual model is the first step before drawing a
UML diagram. It helps to understand the entities in the
real world and how they interact with each other.

Three major elements :

 UML building blocks
 Rules to connect the building blocks
 Common mechanisms of UML
Building blocks of UML

 Things

 Relationships

 Diagrams
Things

 Things are the most important building blocks

of UML. Things can be −

 Structural

 Behavioral

 Grouping

 Annotational
UML Diagrams
Building Blocks of UML 9
3
▪ Interface - A set of operations that describes the functionality
of a class.

▪ Node - A physical element that exists at run time.

▪ Collaboration - It represents the interaction between things.

Represented in dotted line.

▪ Component - It represents the physical part of the

system(libraries, executables, etc...)

▪ Use Case - The core concept of object-oriented modeling. It

portrays a set of actions executed by a system to achieve the
goal.
3
Thing
s

3
Things and its types
▪ It refers to any concept, entity, or object that is being modeled within
a system and which can be described using UML.
▪ In other words, it is basically a real-world object/entity.

▪ There are 4 types present in "Things":

– Structural Things
– Behavioral Things
– Grouping Things
– Annotation Things

4
Structural Things
▪ It depicts the static behavior of a model. It represents the physical and
the conceptual models.

▪ Types include:
– Class
– Object
– Interface
– Node
– Collaboration
– Component
– Use Case 12
Behavioral Things
▪ It mainly depicts the dynamic behavior of a model.

▪ Types include:
– State Diagram - It defines a sequence of states that an entity
goes through in the software development lifecycle.

– Activity Diagram - It portrays all the activities completed by

different entities of a system.

– Interaction Diagram - It is used to envision the flow of

messages between several components in a system

4
Grouping Things
▪ It is a method that together binds the elements of the UML model.

▪ 'Package' is the only component under Grouping Things.

▪ It is like a container that groups related elements together, providing

a higher level of abstraction and modularity in the system.

4
Annotation Things
▪ A mechanism that captures the remarks, descriptions, and comments
of UML model elements.

▪ 'Note' is the only component under Annotation Things.

▪ It is used to attach the constraints, comments, and rules to the

elements of the model. It is a kind of yellow sticky note.

4
4
Relationships

4
Relationships and its types
▪ It illustrates the meaningful connections between things. It shows
the association between the entities and defines the functionality of
an application.

▪ There are 4 types present in Relationships:

– Dependency
– Association
– Generalization
– Realization

4
Dependency
▪ A kind of relationship in which a change in target element affects the
source element, or simply we can say that one element is dependent
on the other element.
▪ It is one of the most important notations in UML. It depicts
the dependency from one entity to another.

4
Association
▪ A fundamental relationship that represents a connection between
two or more classes or objects. It describes how instances of classes
or objects are related to each other.
▪ It illustrates how many elements are participating in a
particular interaction.

N-ary
Association 4
Generalization
▪ A fundamental concept which is used to model inheritance and
the hierarchy of classes in a diagram.
▪ It represents an "is-a" relationship between a more general
(superclass or base class) and a more specific (subclass or derived
class) class.

5
Realization
▪ A type of relationship between two objects, where the client (one
model element) implements the responsibility specified by the
supplier (another model element).

▪ It is typically used to model interfaces, abstract classes, and

other elements that define a set of operations.

5
Types of UML
Diagrams

5
5
1.0
Diagrams
Static Features of a
System

27
1.1 Class Diagrams
• A central modeling technique that runs through nearly all object-
oriented methods.
• This diagram describes the types of objects in the system and various kinds of
static relationships which exist between them.

Relationship Multiplicity
• Association • 0..1 zero to one (optional)
• Inheritance • n Specific number
• Aggregation • 0..* zero to many
• Composition • 1..* one to many
• m..n specific
number
range 28
Inheritance

5
Association

5
Aggregation

5
Composition

5
 Visibility:
Animal Class -
name
private
- name : string
-id : int
Attribut
+
#age : int
es public
+setName():void
#
+eat():void Metho protected
ds
~ package/
default
29
EXAMPLE

30
1.2 Component Diagrams
• Shows a set of components and their relationships.
• Represents the static implementation view of a system.
• Components map to one or more classes, interfaces, or collaborations.

When to use Component Diagrams?

1.To divide a single system into multiple components according to
the functionality.

2. To represent the component organization of the system

6
63
1.3 Object Diagrams
• An object diagram is a graph of instances, including objects and
data values.
• A static object diagram is an instance of a class diagram; it shows
a snapshot of the detailed state of a system at a point in time.

Purpose

1. Understand object behavior and their relationship from practical

perspective
2. Static view of an interaction.
3. Object relationships of a system
6
EXAMPLE

6
1.4 Profile Diagrams
• Provides a generic extension mechanism for customizing UML models for
particular domains and platforms.

• Profiles are defined using stereotypes, tagged value definitions, and constraints
which are applied to specific model elements, like Classes,
Attributes, Operations, and Activities.

• A Profile is a collection of such extensions that collectively customize UML

for a particular domain

35
1. Profile diagram has three types of extensibility mechanisms:
1. Stereotypes

Stereotypes allow you to increase vocabulary of UML. You can add, create new
model elements, derived from existing ones but that have specific properties that
are suitable to your problem domain.
2. Tagged Values
Tagged values are used to extend the properties of UML so that you can add
additional information in the specification of a model element. It allows you to
specify keyword value pairs of a model where keywords are the attributes.
3. Constraints
They are the properties for specifying semantics or conditions that must be held
true at all the time. It allows you to extend the semantics of UML building block
by adding new 36
37
1.5 Composite Structure Diagrams
• Depicts the internal structure of a classifier (such as a class,
component, or collaboration), including the interaction
points of the classifier to other parts of the system.

• A composite structure diagram performs a similar role to a class

diagram, but allows you to go into further detail in describing
the internal structure of multiple classes and showing the
interactions between them.

• Composite Structure Diagrams allow the users to "Peek Inside"

an object to see exactly what it is composed of.

38
7
1.6 Deployment Diagrams
• Deployment diagrams is a kind of structure diagram used in modeling the physical
aspects of an object-oriented system.

• They are often be used to model the static deployment view of a system (topology
of the hardware).

• They capture the hardware that will be used to implement the system and the links
between different items of hardware.

• They model physical hardware elements and the communication paths

between them

• Special kind of class diagram, which focuses on a system's nodes.

7
7
1.7 Package Diagrams
• Package diagrams are structural diagrams used to show the organization and
arrangement of various model elements in the form of packages.

• A package is a grouping of related UML elements, such as

diagrams, documents, classes, or even other packages.

• Package Diagram can be used to simplify complex class diagrams, it can

group classes into packages.

• Package diagrams can be used to visually clarify a wide variety of projects

and systems.

42
7
2.Behavioural
Diagrams
These UML diagrams visualize how the system behaves and
interacts with itself and with users, other systems, and other entities.
It includes use case diagrams, state diagrams, and activity diagrams.

7
2.1 Use Case Diagram
▪ It represents the functionality of a system by utilizing actors and
use cases. It encapsulates the functional requirement of a
system and its association with actors. It portrays the use case view
of a system.

7
Example: Use Case Diagram
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

7
2.1.1Association 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.

7
2.1.2 Generalisation of an Actor
▪ Generalization of an actor means that one actor can inherit the role
of the other actor.
▪ The descendant inherits all the use cases of the ancestor.
▪ The descendant has one or more use cases that are specific to that
role.

7
2.1.3 Extend Relationship Between Two
Use Cases
▪ It extends the base use case
and adds more functionality to
the system.
▪ The extending use case is
dependent on the
extended (base) use case.
▪ The extending use case is
usually optional
▪ The extended (base) use case
must be meaningful on its
own.
8
2.1.4 Include between two use cases
▪ Include relationship show that
the behaviour 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
behaviours.
▪ The base use case is
incomplete without the
included use case.
▪ The included use case is
mandatory and not
optional. 8
2.1.5 Generalization of a use case

▪ The behaviour of the ancestor is inherited by the descendant.

▪ This is used when there is common behaviour between two use cases
and specialized behaviour specific to each use case.
▪ For example, there might be a use case called “Pay Bills”. This can
be generalized to “Pay by Credit Card”, “Pay by Bank Balance”.

8
2.2 Activity Diagram
▪ It models the flow of control from one activity to the other. With
the help of an activity diagram, we can model sequential and
concurrent activities.
▪ It visually depicts the workflow as well as what causes an event
to occur.

8
Example: Activity
Diagram

8
2.3 State Machine Diagram
▪ It portrays the system's behaviour utilizing finite state transitions. It
is also known as the State-charts diagram.
▪ It models the dynamic behaviour of a class in response to
external stimuli.
▪ These are very useful to describe the behaviour of objects that
act differently according to the state they are in at the moment.

8
Example: State
Machine
Diagram

8
2.4 Interaction Diagrams

▪ Interaction diagrams are a subclass of behavioural diagrams that

give emphasis to object interactions and depicts the flow between
various use case elements of a system.
▪ It shows how objects interact with each other and how the data
flows within them.
▪ It consists of communication, interaction overview, sequence,
and timing diagrams.

8
2.4.1 Sequence Diagram
▪ It shows the interactions between the objects in terms of messages
exchanged over time. It delineates in what order and how the
object functions are in a system.

8
Example:
Sequence
Diagram

8
2.4.2 Communication Diagram
▪ It shows the interchange of sequence messages between the objects.
It focuses on objects and their relations. It describes the static and
dynamic behaviour of a system.
▪ Communication diagrams are similar to sequence diagrams, but
the focus is on messages passed between objects.

9
Example: Communication Diagram

9
2.4.3 Timing Diagram
▪ It is a special kind of sequence diagram used to depict the object's
behaviour over a specific period. It governs the change in state
and object behaviour by showing the time and duration
constraints.
▪ If it’s only one object, the diagram is straightforward. But, if there
is more than one object is involved, a Timing diagram is used to
show interactions between objects during that time frame.

9
Example:
Timing Diagram

62
2.4.4 Interaction Overview
diagram
▪ It is a mixture of activity and sequence diagram that depicts a
sequence of actions to simplify the complex interactions into
simple interactions.

9
Example: Interaction
Overview diagram

9
View
s
9
Views supported in UML
• UML divides the complete system into different views to tackle
complexity.

• Each view focuses on a specific aspect of the system.

• The primary views are:

1. Use Case View (Functional View)
2. Logical/Static Structural View
3. Behavioral View
4. Implementation View (Component View)
5. Environment View (Deployment View)

9
Use Case View

• Purpose: Represents the system's functionality and interaction

with external actors.

• Main Elements: Use cases, Actors

• Diagrams: Use Case Diagram

9
Example – Online Bookstore
• Use Cases:
• "Search for a Book", "Add Book to Cart", "Purchase
Book“

• Actors:
• Customer, Payment Gateway, Administrator

68
Structural View

• Purpose: Describes the static structure of the system in terms of

classes, objects, and relationships.

• Main Elements: Classes, Interfaces, Associations,

Generalizations, Aggregations, and Compositions.

• Diagrams: Class Diagram, Object Diagram, Package

Diagram, Composite Structure Diagram

69
Example – Library Management
System
• Classes:
• Book (Attributes: ISBN, Title, Author), Member (Attributes:
MemberID, Name), Loan (Attributes: LoanDate, ReturnDate)

• Relationships:
• Member can have multiple Loans (One-to-Many)

70
Behavioral View

• Purpose: Illustrates the dynamic behaviour of the system.

• Main Elements: States, Transitions, Activities

• Diagrams: Activity Diagram, State Machine Diagram,

Interaction Diagrams (Sequence Diagram, Communication
Diagram, Interaction Overview Diagram, Timing Diagram)

71
Example – Automated Coffee
Machine
• Activities:
• Select Drink, Make Payment, Dispense Drink
• Sequence:
• Customer selects a drink -> Machine prompts payment ->
Customer makes payment -> Machine dispenses drink

72
Implementation View

• Purpose: Describes the components and artifacts of the

system.

• Main Elements: Components, Artifacts

• Diagrams: Component Diagram, Deployment Diagram

Example – E-commerce Website
Backend
• Components:
• User Management Module, Product Catalogue Module, Order Processing
Module

• Artifacts:
• UserDatabase.dll, ProductCatalog.dll
Environmental View

• Purpose: Shows how the system will be physically deployed in

the hardware environment.

• Main Elements: Nodes, Artifacts

• Diagrams: Deployment Diagram

Example – Cloud-based
Application Deployment
• Nodes:
• Web Server (e.g., AWS EC2 instance),
Database Server (e.g., AWS RDS
instance)

• Artifacts:
• MyApp.war (deployed on the web
server), MyDatabase.sql (running on the
database
server)
Importance of Views
• Decomposition

• Communication

• Abstraction

• Validation

1
Best Practices in Using UML Views

• Appropriate

• Consistency

• Simple Diagrams

• Standard Notation

• Regular Update

1
Views supported in UML
 User’s view
 Structural view
 Behavioral view
 Implementation view
 Environmental view
 Users’ view :
 User’s view defines numerous functionalities of the device this is to be had to
its user.

 This view captures the view of the system in terms of the

functionalities offered by the system to its users.

 This view is just like the black box in which the various details of the system
like interior structure, implementation etc is hidden from the user.

 It view is referred as central view because all other views have to conform to
this view. It is indeed remarkable that even for object oriented development,
we need a functional view.

 That is because, after all, a user considers a system as providing a set of

Structural view :
 From the name structural view, this view defines the structure of the
problem.

 The structure of the problem can be defined on the basis of objects or classes
which is very important to understand the working of the system and for its
implementation.

 This view is also used to capture the relationships among objects or classes.

 This view is referred as the static model, reason behind it is that the
structure of a system doesn’t change with time.
Behavioural view :
 This view defines how objects interact with each other, just to
realize the system behaviour.

 It therefore constitutes is referred as dynamic model of the

system, reason behind this is that it captures the time-
dependent (dynamic) behaviour of the system.
Implementation view :

 This view captures the various important components of the

system and their inter-dependencies.

 For example the implementation view might show the GUI

part, middleware, and database part as the different parts and
also would capture their inter-dependencies.

Environmental view :
 This view describes the implementation of the numerous
additives on specific portions of hardware.
 For an smooth system, the utilization case model, class diagram,
and one among the interaction diagrams could also be sufficient.
 For a system during which the objects undergo many state
changes, a state chart diagram could also be necessary.
 For a system, which is implemented on an outsized number of
hardware components, a deployment diagram could also be
necessary.
 So, the sort of models to be constructed depends on the matter
at hand.
THANK YOU