UML BASICS

Ms Devibala Subramanian
Assistant Professor
PG & Research Department of Computer Science
Sri Ramakrishna College of Arts and Science
Coimbatore
Introduction to UML

Unified Modeling Language (UML) is a general purpose standardized

modeling language used to visualize the design of a system.

UML is used to specify, visualize, construct, and document the

artifacts of a software system that has to designed.

Includes a set of graphic notation techniques to create visual models of

software systems.

It is quite similar to blueprints used in other fields of engineering.

UML is not a programming language, it is rather a visual language .

We use UML diagrams to portray the behavior and structure of a
system.

UML helps software engineers, businessmen, and system architects

with modeling, design, and analysis.

The Object Management Group (OMG) adopted Unified Modelling

Language as a standard in 1997. It’s been managed by OMG ever
since.

The International Organization for Standardization (ISO) published

UML as an approved standard in 2005. UML has been revised over
the years and is reviewed periodically
.
Why do we need UML?

Complex applications need collaboration and planning from multiple

teams and hence require a clear and concise way to communicate
amongst them.

Businessmen do not understand code. So UML becomes essential to

communicate with non-programmers about essential requirements,
functionalities, and processes of the system.

A lot of time is saved down the line when teams can visualize
processes, user interactions, and the static structure of the system
Different Types of UML Diagrams

UML is linked with object-oriented design and analysis.

UML makes use of elements and forms associations between them to

form diagrams.

Diagrams in UML can be broadly classified as:

Structural UML Diagrams

Class Diagram

The most widely use UML diagram is the class diagram.

It is the building block of all object oriented software systems.

We use class diagrams to depict the static structure of a system by

showing system’s classes, their methods and attributes.

Class diagrams also help us identify relationship between different

classes or objects.
Composite Structure Diagram

We use composite structure diagrams to represent the internal structure of a class

and its interaction points with other parts of the system.

A composite structure diagram represents relationship between parts and their

configuration which determine how the classifier (class, a component, or a
deployment node) behaves.

They represent internal structure of a structured classifier making the use of parts,
ports, and connectors.

We can also model collaborations using composite structure diagrams.

They are similar to class diagrams except they represent individual parts in detail
as compared to the entire class.
Object Diagram

An Object Diagram can be referred to as a screenshot of the instances in a system

and the relationship that exists between them.

Since object diagrams depict behaviour when objects have been instantiated, we
are able to study the behaviour of the system at a particular instant.

An object diagram is similar to a class diagram except it shows the instances of

classes in the system.

We depict actual classifiers and their relationships making the use of class
diagrams.

On the other hand, an Object Diagram represents specific instances of classes and
relationships between them at a point of time.
Component Diagram

Component diagrams are used to represent how the physical components in a

system have been organized.

We use them for modelling implementation details.

Component Diagrams depict the structural relationship between software system

elements and help us in understanding if functional requirements have been
covered by planned development.

Component Diagrams become essential to use when we design and build complex
systems.

Interfaces are used by components of the system to communicate with each other.
Deployment Diagram

Deployment Diagrams are used to represent system hardware and its software.

It tells us what hardware components exist and what software components run on
them.

We illustrate system architecture as distribution of software artifacts over

distributed targets.

An artifact is the information that is generated by system software.

They are primarily used when a software is being used, distributed or deployed
over multiple machines with different configurations.
Package Diagram

We use Package Diagrams to depict how packages and their elements have been
organized.

A package diagram simply shows us the dependencies between different

packages and internal composition of packages.

Packages help us to organise UML diagrams into meaningful groups and make the
diagram easy to understand.

They are primarily used to organise class and use case diagrams.
Behavioral UML Diagrams

State Machine Diagrams

A state diagram is used to represent the condition of the system or part of the
system at finite instances of time.

It’s a behavioral diagram and it represents the behavior using finite state
transitions.
State diagrams are also referred to as State machines and State-chart Diagrams

These terms are often used interchangeably.

So simply, a state diagram is used to model the dynamic behavior of a class in

response to time and changing external stimuli.
Activity Diagrams

We use Activity Diagrams to illustrate the flow of control in a system.

We can also use an activity diagram to refer to the steps involved in the execution
of a use case.
We model sequential and concurrent activities using activity diagrams.

So, we basically depict workflows visually using an activity diagram.

An activity diagram focuses on condition of flow and the sequence in which it
happens.

We describe or depict what causes a particular event using an activity diagram.

Use Case Diagrams

Use Case Diagrams are used to depict the functionality of a system or a part of a
system.

They are widely used to illustrate the functional requirements of the system and
its interaction with external agents(actors).

A use case is basically a diagram representing different scenarios where the

system can be used.

A use case diagram gives us a high level view of what the system or a part of the
system does without going into implementation details.
Sequence Diagram

A sequence diagram simply depicts interaction between objects in a sequential

order i.e. the order in which these interactions take place.

We can also use the terms event diagrams or event scenarios to refer to a sequence
diagram.

Sequence diagrams describe how and in what order the objects in a system
function.

These diagrams are widely used by businessmen and software developers to

document and understand requirements for new and existing systems.
Communication Diagram
.

A Communication Diagram (known as Collaboration Diagram in UML 1.x) is

used to show sequenced messages exchanged between objects.

A communication diagram focuses primarily on objects and their relationships.

We can represent similar information using Sequence diagrams, however

communication diagrams represent objects and links in a free form.
Timing Diagram

Timing Diagram are a special form of Sequence diagrams which are used to
depict the behavior of objects over a time frame.

We use them to show time and duration constraints which govern changes in
states and behavior of objects.

Interaction Overview Diagram

An Interaction Overview Diagram models a sequence of actions and helps us

simplify complex interactions into simpler occurrences.
It is a mixture of activity and sequence diagrams.
Analysis Phase: Focuses on understanding the system's functionality
using use case and activity diagrams.

Understand and specify what the system should do without

considering how to implement it

Use Case Diagrams:

Purpose: Capture functional requirements.

Elements:

Actors: Represent users or external systems.

Use Cases: Represent functionalities or services provided by the
system.

Relationships: Associations, dependencies, and generalizations

between actors and use cases.

Example: A use case diagram for an online shopping system might

include actors like Customer and Admin, with use cases like "Browse
Products", "Add to Cart", and "Checkout".
Activity Diagrams:
Purpose: Show the flow of activities within a system.

Elements:
Activities: Tasks or functions.

Transitions: Arrows indicating the flow from one activity to another.

Decision Nodes: Represent points where decisions are made.

Swimlanes: Partitioning activities based on who performs them.

Example: An activity diagram for a purchase process could include

activities like "Select Product", "Enter Payment Details", and
"Confirm Purchase"
Design Phase
Details how the system will be structured and interact using class,
sequence, and component diagrams.

Define how the system will fulfill the requirements gathered during
the analysis phase.

Class Diagrams:

Purpose: Show the static structure of a system.

Elements:
Classes: Represent entities with attributes and methods.
Attributes: Properties or data.
Methods: Functions or operations.
Relationships: Associations, generalizations, dependencies, and
aggregations between classes.

Example: A class diagram for an e-commerce system might include

classes like Product, Order, and Customer, with appropriate
relationships.
Sequence Diagrams:

Purpose: Show how objects interact in a particular sequence.

Elements:
Objects/Participants: Entities involved in the interaction.
Lifelines: Vertical dashed lines representing the life of an object
during the sequence.
Messages: Horizontal arrows indicating communication between
objects.
Example: A sequence diagram for processing an order might show
interactions between Customer, Order System, Payment Gateway, and
Shipping Service.
Component Diagrams:
Purpose: Show the organization and dependencies among
components.

Elements:
Components: Modular parts of the system with provided and required
interfaces.

Interfaces: Define the ways components interact.

Relationships: Dependencies and associations between components.

Example: A component diagram for an online banking system might

include components like User Interface, Authentication Service, and
Account Management.
Implementation Phase
Deals with the physical realization of the system using deployment
and package diagrams.

Transform the design into code and complete the system.

Deployment Diagrams:

Purpose: Show the physical deployment of artifacts on nodes.

Elements:
Nodes: Physical hardware or software execution environments.
Artifacts: Deployable pieces of software.

Relationships: Associations and dependencies between nodes and

artifacts.

Example: A deployment diagram for a web application might show

nodes like Web Server, Application Server, and Database Server, with
artifacts like WAR files and database schemas.
Package Diagrams:

Purpose: Organize elements of the system into related groups.

Elements:

Packages: Groups of classes, components, or other UML elements.

Relationships: Dependencies and associations between packages.

Example: A package diagram for a software project might include

packages like UI, Business Logic, and Data Access.