UML

What is UML
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.

The UML was developed in 1994-95 by Grady Booch, Ivar Jacobson, and James Rumbaugh at
the Rational Software. In 1997, it got adopted as a standard by the Object Management Group
(OMG).

Goals of UML
o Since it is a general-purpose modeling language, it can be utilized by all the modelers.
o 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.
o 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.
o 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:

o It is a generalized modeling language.

o It is distinct from other programming languages like C++, Python, etc.
o It is interrelated to object-oriented analysis and design.
o It is used to visualize the workflow of the system.
o It is a pictorial language, used to generate powerful modeling artifacts.
Do we really 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 essential requirements, functionalities and processes of the
system.
 A lot of time is saved down the line when teams are able to visualize processes, user
interactions and static structure of the system.

Object Oriented Concepts Used in UML –

1. Class – A class defines the blue print i.e. structure and functions of an object.
2. Objects – Objects help us to decompose large systems and help us to modularize
our system. Modularity helps to divide our system into understandable components
so that we can build our system piece by piece. An object is the fundamental unit
(building block) of a system which is used to depict an entity.
3. Inheritance – Inheritance is a mechanism by which child classes inherit the
properties of their parent classes.
4. Abstraction – Abstraction in UML refers to the process of emphasizing the
essential aspects of a system or object while disregarding irrelevant details. By
abstracting away unnecessary complexities, abstraction facilitates a clearer
understanding and communication among stakeholders.
5. Encapsulation – Binding data together and protecting it from the outer world is
referred to as encapsulation.
6. Polymorphism – Mechanism by which functions or entities are able to exist in
different forms.

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:

o Structural things
o Behavioral things
o Grouping things
o 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.

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. Its notation is as
follows;

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 and
its notation is given below;
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.

Behavioral 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.
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: 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. And each diagram
manifests a different dimension, perspective, and view of the system.

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:

o Class diagram
o Object diagram
o Package diagram
o Component diagram
o 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:

o Activity diagram
o State machine diagram
o 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:

o Timing diagram
o Sequence diagram
o Collaboration diagram
The image below shows the hierarchy of diagrams according to UML:

Structural UML Diagrams –

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.
6. 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.

Behavior Diagrams –

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.
6. 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.
7. 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.

UML- Architecture
Software architecture is all about how a software system is built at its highest level. It is needed
to think big from multiple perspectives with quality and design in mind. The software team is
tied to many practical concerns, such as:

o The structure of the development team.

o The needs of the business.
o Development cycle.
o The intent of the structure itself.

Software architecture provides a basic design of a complete software system. It defines the
elements included in the system, the functions each element has, and how each element relates to
one another. In short, it is a big picture or overall structure of the whole system, how everything
works together.
To form an architecture, the software architect will take several factors into consideration:

o What will the system be used for?

o Who will be using the system?
o What quality matters to them?
o Where will the system run?

The architect plans the structure of the system to meet the needs like these. It is essential to have
proper software architecture, mainly for a large software system. Having a clear design of a
complete system as a starting point provides a solid basis for developers to follow.

Each developer will know what needs to be implemented and how things relate to meet the
desired needs efficiently. One of the main advantages of software architecture is that it provides
high productivity to the software team. The software development becomes more effective as it
comes up with an explained structure in place to coordinate work, implement individual features,
or ground discussions on potential issues. With a lucid architecture, it is easier to know where the
key responsibilities are residing in the system and where to make changes to add new
requirements or simply fixing the failures.

In addition, a clear architecture will help to achieve quality in the software with a well-designed
structure using principles like separation of concerns; the system becomes easier to maintain,
reuse, and adapt. The software architecture is useful to people such as software developers, the
project manager, the client, and the end-user. Each one will have different perspectives to view
the system and will bring different agendas to a project. Also, it provides a collection of several
views. It can be best understood as a collection of five views:

1. Use case view

2. Design view
3. Implementation view
4. Process view
5. Development view

Use case view

o It is a view that shows the functionality of the system as perceived by external actors.
o It reveals the requirements of the system.
 o With UML, it is easy to capture the static aspects of this view in the use case diagrams, whereas
its dynamic aspects are captured in interaction diagrams, state chart diagrams, and activity
diagrams.

Design View

o It is a view that shows how the functionality is designed inside the system in terms of static
structure and dynamic behavior.
o It captures the vocabulary of the problem space and solution space.
o With UML, it represents the static aspects of this view in class and object diagrams, whereas its
dynamic aspects are captured in interaction diagrams, state chart diagrams, and activity diagrams.

Implementation View

o It is the view that represents the organization of the core components and files.
o It primarily addresses the configuration management of the system?s releases.
o With UML, its static aspects are expressed in component diagrams, and the dynamic aspects are
captured in interaction diagrams, state chart diagrams, and activity diagrams.

Process View

o It is the view that demonstrates the concurrency of the system.

o It incorporates the threads and processes that make concurrent system and synchronized
mechanisms.
o It primarily addresses the system's scalability, throughput, and performance.
o Its static and dynamic aspects are expressed the same way as the design view but focus more on
the active classes that represent these threads and processes.

Deployment View

o It is the view that shows the deployment of the system in terms of physical architecture.
o It includes the nodes, which form the system hardware topology where the system will be
executed.
o It primarily addresses the distribution, delivery, and installation of the parts that build the
physical system.