Unified Modeling Language

Unified Modeling Language

• The UML stands for Unified modeling language,
• is a standardized general-purpose visual modeling
language in the field of Software Engineering.
• It is used for specifying, visualizing, constructing, and
documenting the primary artifacts of the software system.
• It helps in designing and characterizing, especially those
software systems that incorporate the concept of Object
orientation.
• It describes the working of both the software and hardware
systems.
GOALS OF UML
• Since it is a general-purpose modeling language, it can be
utilized by all the modelers.
• UML came into existence after the introduction of object-oriented
concepts to systemize and consolidate the object-oriented
development, due to the absence of standard methods at that
time.
• The UML diagrams are made for business users, developers,
ordinary people, or anyone who is looking forward to understand
the system, such that the system can be software or non-
software.
• Thus it can be concluded that the UML is a simple modeling
approach that is used to model all the practical systems.
CHARACTERISTICS OF UML
The UML has the following features:
• It is a generalized modeling language.
• It is distinct from other programming languages like C+
+, Python, etc.
• It is interrelated to object-oriented analysis and design.
• It is used to visualize the workflow of the system.
• It is a pictorial language, used to generate powerful
modeling artifacts.
CONCEPTUAL MODELING
• Before moving ahead with the concept of UML, we should
first understand the basics of the conceptual model.
• A conceptual model is composed of several interrelated
concepts.
• It makes it easy to understand the objects and how they
interact with each other.
• This is the first step before drawing UML diagrams.
CONCEPTUAL MODELING
Following are some object-oriented concepts that are
needed to begin with UML:
• Object: An object is a real world entity. There are many
objects present within a single system. It is a fundamental
building block of UML.
CONCEPTUAL MODELING
• Class: A class is a software blueprint for objects, which
means that it defines the variables and methods common
to all the objects of a particular type.
• Abstraction: Abstraction is the process of portraying the
essential characteristics of an object to the users while
hiding the irrelevant information. Basically, it is used to
envision the functioning of an object.
• Inheritance: Inheritance is the process of deriving a new
class from the existing ones.
• Polymorphism: It is a mechanism of representing objects
having multiple forms used for different purposes.
• Encapsulation: It binds the data and the object together
as a single unit, enabling tight coupling between them.
• Tight coupling refers to a situation where two or
more software components are closely connected and
depend on each other to function properly.

• Loose coupling, on the other hand, means that the

components are less dependent on each other and can
operate more independently.
UML- BUILDING BLOCKS
UML is composed of three main building blocks, i.e.,
things, relationships, and diagrams.
Building blocks generate one complete UML model
diagram by rotating around several different blocks.
It plays an essential role in developing UML diagrams.
The basic UML building blocks are enlisted below:
1.Things
2.Relationships
3.Diagrams
THINGS
• Anything that is a real world entity or object is termed as
things. It can be divided into several different categories:

• Structural things

• Behavioral things

• Grouping things

• Annotational things
STRUCTURAL THINGS
• Nouns that depicts the static behavior of a model is
termed as structural things.
• They display the physical and conceptual
components.
• They include class, object, interface, node,
collaboration, component, and a use case.
STRUCTURAL THINGS
• Class: A Class is a set of identical things
that outlines the functionality and properties
of an object.
• It also represents the abstract class whose
functionalities are not defined.
 STRUCTURAL THINGS
• Object: An individual that describes
the behavior and the functions of a
system.
• The notation of the object is similar
to that of the class;
• the only difference is that the object
name is always underlined.
• Interface: A set of operations that describes the
functionality of a class, which is implemented whenever
an interface is implemented.

• Collaboration: It represents the interaction between

things that is done to meet the goal. It is symbolized as
a dotted ellipse with its name written inside it.
• Use case: Use case is the core concept of object-oriented
modeling. It portrays a set of actions executed by a system
to achieve the goal.

• Actor: It comes under the use case diagrams. It is an

object that interacts with the system, for example, a user.
• Component: It represents the physical part of the
system.

• Node: A physical element that exists at run time.

BEHAVORIAL THINGS
• They are the verbs that encompass the dynamic parts
of a model. It depicts the behavior of a system.
• They involve state machine, activity diagram,
interaction diagram, grouping things, annotation things
• State Machine: It defines a sequence of states that an
entity goes through in the software development
lifecycle. It keeps a record of several distinct states of a
system component.
BEHAVORIAL THINGS
• Activity Diagram: It portrays all the
activities accomplished by different
entities of a system.
• It is represented the same as that of
a state machine diagram.
• It consists of an initial state, final
state, a decision box, and an action
notation.
• Interaction Diagram: It is used to envision the flow of
messages between several components in a system.
GROUPING THINGS
• It is a method that together binds the elements of the
UML model. In UML, the package is the only thing, which
is used for grouping.
• Package: Package is the only thing that is available for
grouping behavioral and structural things.
ANNOTATION THINGS
• It is a mechanism that captures the remarks, descriptions,
and comments of UML model elements. In UML, a note is
the only Annotational thing.
• Note: It is used to attach the constraints, comments, and
rules to the elements of the model. It is a kind of yellow
sticky note.
RELATIONSHIPS
• It illustrates the meaningful connections between things.
• It shows the association between the entities and defines
the functionality of an application.
• There are four types of relationships given below:
• Dependency
• Association
• Generalization
• Realization
 RELATIONSHIPS
• Dependency: Dependency is a kind of relationship in which
a change in target element affects the source element, or
simply we can say the source element is dependent on the
target element.
• It is one of the most important notations in UML.
• It depicts the dependency from one entity to another.
• It is denoted by a dotted line followed by an arrow at one
side as shown below
• Association: A set of links that associates the entities to
the UML model.
• It tells how many elements are actually taking part in
forming that relationship.
• It is denoted by a dotted line with arrowheads on both
sides to describe the relationship with the element on both
sides.
• Generalization: It portrays the relationship between a
general thing (a parent class or superclass) and a specific
kind of that thing (a child class or subclass).

• It is used to describe the concept of inheritance.

• It is denoted by a straight line followed by an empty

arrowhead at one side.
• Realization: It is a semantic kind of relationship
between two things, where one defines the behavior to
be carried out, and the other one implements the
mentioned behavior.
• It exists in interfaces.
• It is denoted by a dotted line with an empty arrowhead at
one side.
 DIAGRAMS
• The diagrams are the graphical implementation of the models
that incorporate symbols and text.
• Each symbol has a different meaning in the context of the UML
diagram.
• There are thirteen different types of UML diagrams that are
available in UML 2.0, such that each diagram has its own set of a
symbol.
• And each diagram manifests a different dimension, perspective,
and view of the system.
 DIAGRAMS
• UML diagrams are classified into three categories that are given
below:
1.Structural Diagram
2.Behavioral Diagram
3.Interaction Diagram
• Structural Diagram: It represents the static view of a
system by portraying the structure of a system.
• It shows several objects residing in the system.
• Following are the structural diagrams given below:
• Class diagram
• Object diagram
• Package diagram
• Component diagram
• Deployment diagram
• Behavioral Diagram: It depicts the behavioral
features of a system.

• It deals with dynamic parts of the system.

It encompasses the following diagrams:

• Activity diagram

• State machine diagram

• Use case diagram

• Interaction diagram: It is a subset of behavioral
diagrams. It depicts the interaction between two objects
and the data flow between them.

• Following are the several interaction diagrams in UML:

• Timing diagram

• Sequence diagram

• Collaboration diagram
UML Use Case Diagram
A UML USE CASE DIAGRAM
• A use case diagram is used to represent the
dynamic behavior of a system.
• It encapsulates the system's functionality by
incorporating use cases, actors, and their
relationships.
• It models the tasks, services, and functions
required by a system/subsystem of an application.
• It depicts the high-level functionality of a system
and also tells how the user handles a system.
Purpose of Use Case Diagram
• The main purpose of a use case diagram is to portray the
dynamic aspect of a system.
• It accumulates the system's requirement, which includes
both internal as well as external influences.
• It invokes persons, use cases, and several things that
invoke the actors and elements accountable for the
implementation of use case diagrams.
• It represents how an entity from the external environment
can interact with a part of the system.
Purpose of Use Case Diagram
Following are the purposes of a use case diagram given
below:
1. It gathers the system's needs.
2. It depicts the external view of the system.
3. It recognizes the internal as well as external factors that
influence the system.
4. It represents the interaction between the actors.
How To Use a Use Case Diagram
• It is essential to analyze the whole system before starting
with drawing a use case diagram, and then the system's
functionalities are found.
• And once every single functionality is identified, they are
then transformed into the use cases to be used in the use
case diagram.
• After that, enlist the actors that will interact with the
system.
• The actors are the person or a thing that invokes the
functionality of a system.
• It may be a system or a private entity, such that it requires
an entity to be pertinent to the functionalities of the system
• The View Items is further extended by several use cases
such as; Search Items, Browse Items, View
Recommended Items, Add to Shopping Cart, Add to
Wish list.
• All of these extended use cases provide some functions to
customers, which allows them to search for an item.
• Both View Recommended Item and Add to Wish List include
the Customer Authentication use case, as they necessitate
authenticated customers, and simultaneously item can be
added to the shopping cart without any user authentication.
• Similarly, the Checkout use case also includes the following
use cases, as shown below.
• It requires an authenticated Web Customer, which can be
done by login page, user authentication cookie
("Remember me"), or Single Sign-On (SSO).
• SSO needs an external identity provider's participation,
while Web site authentication service is utilized in all these
use cases.
• The Checkout use case involves Payment use case that can
be done either by the credit card and external credit
payment services or with PayPal.
IMPORTANCE OF USE CASE DIAGRAM
Following are some important tips that are to be kept in
mind while drawing a use case diagram:
1.A simple and complete use case diagram should be
articulated.
2.A use case diagram should represent the most
significant interaction among the multiple interactions.
3.At least one module of a system should be represented
by the use case diagram.
4.If the use case diagram is large and more complex, then
it should be drawn more generalized.