UNIT 1

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
Identifying the Pieces of UML

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 Design and Implementation
The figure shows 6 possible scenarios when developing the system
Software Life Cycle Model

Waterfall Model
Software Life Cycle Model

The Spiral Model

Software Life Cycle Model

The Iterative Model

Understanding the Unified Modeling Process

The Unified Process (UP) is a software development framework used for object-
oriented modeling. The framework is also known as Rational Unified Process
(RUP) and the Open Unified Process (Open UP).

Some of the key features of this process include:

• It defines the order of phases.

• It is component-based, meaning a software system is built as a set of software
components. There must be well-defined interfaces between the components for
smooth communication.
• It follows an iterative, incremental, architecture-centric, and use-case driven
approach
Understanding the Unified Modeling Process

It can be represented as a series of cycles.

Each cycle ends with the release of a new system version for the customers.

Four phases in every cycle:

• Inception
• Elaboration
• Construction
• Transition
Understanding the Unified Modeling Process

Inception

The main goal of this phase involves delimiting the project scope. This is where
we define why we are making this product in the first place. It should have the
following:
• What are the key features?
• How does this benefit the customers?
• Which methodology will we follow?
• What are the risks involved in executing the project?
• Schedule and cost estimates.
Understanding the Unified Modeling Process

Elaboration
We build the system , given the requirements, cost, and time constraints and all the
risks involved.

It should include the following:

• Develop with the majority of the functional requirements implemented.
• Finalize the methodology to be used.
• Deal with the significant risks involved.

Construction
This phase is where the development, integration, and testing take place. We build
the complete architecture in this phase and hand the final documentation to the
client.
Understanding the Unified Modeling Process

Transition

This phase involves the deployment, multiple iterations, beta releases, and
improvements of the software. The users will test the software, which may raise
potential issues. The development team will then fix those errors.
Available UML Modeling Tools

Rational Rose

Visio

StarUML

StarUML is an open-source software modeling tool, which is provided by MKLab.

• It let you create Object, Use case, Deployment, Sequence, Collaboration,
Activity, and Profile diagrams.
• It is a UML 2.x standard compliant.
• It offers multiplatform support (MacOS, Windows, and Linux).
Available UML Modeling Tools

Umbrello

Umbrello is a Unified Modeling language tool, which is based on KDE

technology. It supports both reverse engineering and code generation for C+
+ and Java.

Features:
• It implements both structural and behavioral diagrams.
• It imports C++ and can export up to a wider range of languages.
Available UML Modeling Tools

UML Designer Tool

The UML designer tool helps in modifying and envisioning UML2.5 models. It
allows you to create all of the UML diagrams.

Features:
• It provides transparency to work on DSL as well as UML models.
• With the UML designer tool, the user can reuse the provided presentations.
• It implements Component, Class, and Composite structure diagrams.
• To start working with DSL, you can use UML legacy models.
Available UML Modeling Tools

Umple

Umple is an object-oriented and modeling language that textually supports state

diagrams and class diagrams. It adapts JAVA, C++, and PHP, which results in
more readable and short lines of code.

Features:
• It includes Singleton pattern, keys, immutability, mixins, and aspect-oriented
code injection, which makes UML more understandable to the users.
• It enforces referential integrity by supporting UML multiplicity.

• And ofcourse Whiteboard, Pen and Paper

Identify the Notational Components of a Use Case Diagram

A Use Case Diagram is a type of Unified Modeling Language (UML) diagram that
represents the interaction between actors (users or external systems) and a system under
consideration to accomplish specific goals. It provides a high-level view of the system’s
functionality by illustrating the various ways users can interact with it.
Use Case Diagram Notations
UML notations provide a visual language that enables software developers, designers, and
other stakeholders to communicate and document system designs, architectures, and
behaviors in a consistent and understandable manner.
1.1. Actors
Actors are external entities that interact with the system. These can include users, other
systems, or hardware devices. In the context of a Use Case Diagram, actors initiate use
cases and receive the outcomes. Proper identification and understanding of actors are
crucial for accurately modeling system behavior.
Use Cases
Use cases are like scenes in the play. They represent specific things your system can do.
In the online shopping system, examples of use cases could be “Place Order,” “Track
Delivery,” or “Update Product Information”. Use cases are represented by ovals.
System Boundary
The system boundary is a visual representation of the scope or limits of the system you
are modeling. It defines what is inside the system and what is outside. The boundary
helps to establish a clear distinction between the elements that are part of the system and
those that are external to it. The system boundary is typically represented by a rectangular
box that surrounds all the use cases of the system.

Purpose of System Boundary:

Scope Definition: It clearly outlines the boundaries of the system, indicating which
components are internal to the system and which are external actors or entities interacting
with the system.

Focus on Relevance: By delineating the system’s scope, the diagram can focus on
illustrating the essential functionalities provided by the system without unnecessary
details about external entities.
Use Case Diagram Relationships

In a Use Case Diagram, relationships play a crucial role in depicting the interactions
between actors and use cases.

These relationships provide a comprehensive view of the system’s functionality and its
various scenarios.

Let’s delve into the key types of relationships and explore examples to illustrate their
usage.

Association Relationship
The Association Relationship represents a communication or interaction between an actor
and a use case.

It is depicted by a line connecting the actor to the use case. This relationship signifies that
the actor is involved in the functionality described by the use case.
Example: Online Banking System
Actor: Customer
Use Case: Transfer Funds
Association: A line connecting the “Customer” actor to the “Transfer Funds” use case,
indicating the customer’s involvement in the funds transfer process.
Include Relationship
The Include Relationship indicates that a use case includes the functionality of another
use case. It is denoted by a dashed arrow pointing from the including use case to the
included use case. This relationship promotes modular and reusable design.
Example: Social Media Posting
Use Cases: Compose Post, Add Image
Include Relationship: The “Compose Post” use case includes the functionality of “Add
Image.” Therefore, composing a post includes the action of adding an image.
Extend Relationship
The Extend Relationship illustrates that a use case can be extended by another use case
under specific conditions. It is represented by a dashed arrow with the keyword “extend.”
This relationship is useful for handling optional or exceptional behavior.
Example: Flight Booking System
Use Cases: Book Flight, Select Seat
Extend Relationship: The “Select Seat” use case may extend the “Book Flight” use case
when the user wants to choose a specific seat, but it is an optional step.
Generalization Relationship
The Generalization Relationship establishes an “is-a” connection between two use cases,
indicating that one use case is a specialized version of another. It is represented by an
arrow pointing from the specialized use case to the general use case.
Example: Vehicle Rental System
Use Cases: Rent Car, Rent Bike
Generalization Relationship: Both “Rent Car” and “Rent Bike” are specialized versions
of the general use case “Rent Vehicle.”
Use Case to Use Case Relationship
Each of the new use cases are child of the original parent use case.

Their notation that relates to each other is called generalization.

The below shows the generalization can be further broken down to more than two
children.
Generalization can be even hierarchical
Example
Actor to Actor Relationship
How to Create a Use Case Diagram

The steps involved in creating use cases

Identifying Actors

Identifying Use Cases

Look for Common Functionality to Reuse

Is it Possible to Generalize Actors and Use Cases

Optional Functions or Additional Functions

Validate and Refine the Diagram

Identifying Actors

Actors are external entities that interact with your system.

It can be a person, another system or an organization.

In a banking system, the most obvious actor is the customer.

Other actors can be bank employee or cashier depending on the role you’re trying to show
in the use case.

An example of an external organization can be the tax authority or the central bank.

The loan processor is a good example of an external system associated as an actor.

Identifying Use Case:

Identify what the actors need from the system.

In a banking system, a customer will need to open accounts, deposit and withdraw funds,
request check books and similar functions. So all of these can be considered as use cases.

Top level use cases should always provide a complete function required by an actor.

Extend or include use cases depending on the complexity of the system.

Identify the actors and the top level use case to have a basic idea of the system.

Fine tune it and add extra layers of detail to it.

Look for Common Functionality to Use ‘Include’

Look for common functionality that can be reused across the system.

If there are two or more use cases that share common functionality , extract the common
functions and add it to a separate use case.

Connect it via the include relationship to show that it’s always called when the original
use case is executed.
Is it Possible to Generalize Actors and Use Cases

There may be instances where actors are associated with similar use cases while
triggering a few use cases unique only to them.

In such instances, generalize the actor to show the inheritance of functions.

One of the best examples of this is “Make Payment” use case in a payment system.

It can be further generalized it to “Pay by Credit Card”, “Pay by Cash”, “Pay by Check”
etc.

All of them have the attributes and the functionality of payment with special scenarios
unique to them.
Optional Functions or Additional Functions

There are some functions that are triggered optionally.

In such cases, the extend relationship is used and attach an extension rule to it.

In the below banking system example “Calculate Bonus” is optional and only triggers
when a certain condition is matched.

Extend doesn’t always mean it’s optional.

Sometimes the use case connected by extending can supplement the base use case.

The thing to remember is that the base use case should be able to perform a function on
its own even if the extending use case is not called.
Let’s understand how to draw a Use Case diagram with the help of an Online
Shopping System:

1. Actors:
Customer
Admin

2. Use Cases:
Browse Products
Add to Cart
Checkout
Manage Inventory (Admin)

3. Relations:
The Customer can browse products, add to the cart, and complete the checkout.
The Admin can manage the inventory.