Software Design

Design Concepts, Design Strategies: Function Oriented Design, Object

Oriented Design, Top-Down and Bottom-Up Design
Effective modular design: Functional independence, Cohesion, Coupling,
Design documentation
UML Diagrams and Tools: Introduction to UML Diagrams, Use Case, Object
and Class, Interaction diagram: Sequence & Collaboration ,Introduction to
Rational Rose tool

Software Design is the process to transform the user requirements into some
suitable form, which helps the programmer in software coding and
implementation. During the software design phase, the design document is
produced, based on the customer requirements as documented in the SRS
document. Hence the aim of this phase is to transform the SRS document into
the design document.
The following items are designed and documented during the design phase:

● Different modules required.

● Control relationships among modules.
● Interface among different modules.
● Data structure among the different modules.
● Algorithms required to implement among the individual modules.

Objectives of Software Design:

1. Correctness:
A good design should be correct i.e. it should correctly implement all
the functionalities of the system.
 2. Efficiency:
A good software design should address the resources, time, and cost
optimization issues.
3. Understandability:
A good design should be easily understandable, for which it should be
modular and all the modules are arranged in layers.
4. Completeness:
The design should have all the components like data structures,
modules, and external interfaces, etc.
5. Maintainability:
A good software design should be easily amenable to change
whenever a change request is made from the customer side.

Software Design Concepts:

Concepts are defined as a principal idea or invention that comes into our mind or
in thought to understand something. The software design concept simply
means the idea or principle behind the design. It describes how you plan to solve
the problem of designing software, the logic, or thinking behind how you will
design software. It allows the software engineer to create the model of the
system or software or product that is to be developed or built. The software
design concept provides a supporting and essential structure or model for
developing the right software. There are many concepts of software design and
some of them are given below:
The following points should be considered while designing Software:

1. Abstraction- hide Irrelevant data

Abstraction simply means to hide the details to reduce complexity and
increases efficiency or quality. Different levels of Abstraction are
necessary and must be applied at each stage of the design process so
that any error that is present can be removed to increase the efficiency
of the software solution and to refine the software solution. The solution
should be described in broad ways that cover a wide range of different
things at a higher level of abstraction and a more detailed description of
a solution of software should be given at the lower level of abstraction.
2. Modularity- subdivide the system
Modularity simply means dividing the system or project into smaller
parts to reduce the complexity of the system or project. In the same
way, modularity in design means subdividing a system into smaller
parts so that these parts can be created independently and then use
 these parts in different systems to perform different functions. It is
necessary to divide the software into components known as modules
because nowadays there are different software available like Monolithic
software that is hard to grasp for software engineers. So, modularity in
design has now become a trend and is also important. If the system
contains fewer components then it would mean the system is complex
which requires a lot of effort (cost) but if we are able to divide the
system into components then the cost would be small.
3. Architecture- design a structure of something
Architecture simply means a technique to design a structure of
something. Architecture in designing software is a concept that focuses
on various elements and the data of the structure. These components
interact with each other and use the data of the structure in
architecture.
4. Refinement- removes impurities
Refinement simply means to refine something to remove any impurities
if present and increase the quality. The refinement concept of software
design is actually a process of developing or presenting the software or
system in a detailed manner that means to elaborate a system or
software. Refinement is very necessary to find out any error if present
and then to reduce it.
5. Pattern- a repeated form
The pattern simply means a repeated form or design in which the same
shape is repeated several times to form a pattern. The pattern in the
design process means the repetition of a solution to a common
recurring problem within a certain context.
 6. Information Hiding- hide the information
Information hiding simply means to hide the information so that it
cannot be accessed by an unwanted party. In software design,
information hiding is achieved by designing the modules in a manner
that the information gathered or contained in one module is hidden and
can’t be accessed by any other modules.
7. Refactoring- reconstruct something
Refactoring simply means reconstructing something in such a way that
it does not affect the behavior of any other features. Refactoring in
software design means reconstructing the design to reduce complexity
and simplify it without affecting the behavior or its functions. Fowler has
defined refactoring as “the process of changing a software system in a
way that it won’t affect the behavior of the design and improves the
internal structure”.

Different levels of Software Design:

There are three different levels of software design. They are:

1. Architectural Design:
The architecture of a system can be viewed as the overall structure of
the system & the way in which structure provides conceptual integrity of
the system. The architectural design identifies the software as a system
with many components interacting with each other. At this level, the
designers get the idea of the proposed solution domain.

2. Preliminary or high-level design:

Here the problem is decomposed into a set of modules, the control
 relationship among various modules identified, and also the interfaces
among various modules are identified. The outcome of this stage is
called the program architecture. Design representation techniques used
in this stage are structure chart and UML.

3. Detailed design:
Once the high-level design is complete, a detailed design is
undertaken. In detailed design, each module is examined carefully to
design the data structure and algorithms. The stage outcome is
documented in the form of a module specification document.

Design Strategies
A good system design is to organize the program modules in such a way
that are easy to develop and change. Structured design techniques help
developers to deal with the size and complexity of programs. Analysts
create instructions for the developers about how code should be written
and how pieces of code should fit together to form a program.
Importance :

1. If any pre-existing code needs to be understood, organized, and

pieced together.
2. It is common for the project team to have to write some code and
produce original programs that support the application logic of the
system.

There are many strategies or techniques for performing system design.

They are:
 ● Bottom-up approach:
The design starts with the lowest level components and
subsystems. By using these components, the next immediate
higher-level components and subsystems are created or
composed. The process is continued till all the components and
subsystems are composed into a single component, which is
considered as the complete system. The amount of abstraction
grows high as the design moves to more high levels.
By using the basic information existing system, when a new
system needs to be created, the bottom-up strategy suits the
purpose.

Advantages:
● The economics can result when general solutions can be reused.
● It can be used to hide the low-level details of implementation and
be merged with the top-down technique.
Disadvantages:
● It is not so closely related to the structure of the problem.
● High-quality bottom-up solutions are very hard to construct.
● It leads to the proliferation of ‘potentially useful’ functions rather
than the most appropriate ones.
● Top-down approach:
Each system is divided into several subsystems and components.
Each of the subsystems is further divided into a set of subsystems
and components. This process of division facilitates in forming a
system hierarchy structure. The complete software system is
considered as a single entity and in relation to the characteristics,
the system is split into sub-system and component. The same is
done with each of the sub-systems.
This process is continued until the lowest level of the system is
reached. The design is started initially by defining the system as a
whole and then keeps on adding definitions of the subsystems
and components. When all the definitions are combined together,
it turns out to be a complete system.
For the solutions of the software that need to be developed from
the ground level, top-down design best suits the purpose.
Advantages:
● The main advantage of the top-down approach is that its strong
focus on requirements helps to make a design responsive
according to its requirements.

Disadvantages:
● Project and system boundaries tend to be application
specification-oriented. Thus it is more likely that advantages of
component reuse will be missed.
● The system is likely to miss, the benefits of a well-structured,
simple architecture.
● Hybrid Design:
It is a combination of both the top-down and bottom-up design
strategies. In this, we can reuse the modules.
Functional Independence: Functional independence is achieved by developing
functions that perform only one kind of task and do not excessively interact with other
modules. Independence is important because it makes implementation more
accessible and faster. The independent modules are easier to maintain, test, and
reduce error propagation and can be reused in other programs as well. Thus,
functional independence is a good design feature which ensures software quality.

It is measured using two criteria:

● Cohesion: It measures the relative function strength of a module.

● Coupling: It measures the relative interdependence among modules.

Coupling and Cohesion

Module Coupling

In software engineering, the coupling is the degree of interdependence between

software modules. Two modules that are tightly coupled are strongly dependent on
each other. However, two modules that are loosely coupled are not dependent on each
other. Uncoupled modules have no interdependence at all within them.

The various types of coupling techniques are shown in fig:

A good design is the one that has low coupling. Coupling is measured by the number
of relations between the modules. That is, the coupling increases as the number of
calls between modules increase or the amount of shared data is large. Thus, it can be
said that a design with high coupling will have more errors.

Types of Module Coupling

1. No Direct Coupling: There is no direct coupling between M1 and M2.

17.6M
352

History of Java

In this case, modules are subordinates to different modules. Therefore, no direct

coupling.
2. Data Coupling: When data of one module is passed to another module, this is called
data coupling.

3. Stamp Coupling: Two modules are stamp coupled if they communicate using
composite data items such as structure, objects, etc. When the module passes non-
global data structure or entire structure to another module, they are said to be stamp
coupled. For example, passing structure variable in C or object in C++ language to a
module.

4. Control Coupling: Control Coupling exists among two modules if data from one
module is used to direct the structure of instruction execution in another.

5. External Coupling: External Coupling arises when two modules share an externally
imposed data format, communication protocols, or device interface. This is related to
communication to external tools and devices.

6. Common Coupling: Two modules are common coupled if they share information
through some global data items.

7. Content Coupling: Content Coupling exists among two modules if they share code,
e.g., a branch from one module into another module.
Module Cohesion
In computer programming, cohesion defines to the degree to which the elements of a
module belong together. Thus, cohesion measures the strength of relationships
between pieces of functionality within a given module. For example, in highly cohesive
systems, functionality is strongly related.

Cohesion is an ordinal type of measurement and is generally described as "high

cohesion" or "low cohesion."

Types of Modules Cohesion

1. Functional Cohesion: Functional Cohesion is said to exist if the different
elements of a module, cooperate to achieve a single function.

2. Sequential Cohesion: A module is said to possess sequential cohesion if the

element of a module form the components of the sequence, where the output
from one component of the sequence is input to the next.

3. Communicational Cohesion: A module is said to have communicational

cohesion, if all tasks of the module refer to or update the same data structure,
e.g., the set of functions defined on an array or a stack.

4. Procedural Cohesion: A module is said to be procedural cohesion if the set of

purpose of the module are all parts of a procedure in which particular sequence
 of steps has to be carried out for achieving a goal, e.g., the algorithm for
decoding a message.

5. Temporal Cohesion: When a module includes functions that are associated by

the fact that all the methods must be executed in the same time, the module is
said to exhibit temporal cohesion.

6. Logical Cohesion: A module is said to be logically cohesive if all the elements of

the module perform a similar operation. For example Error handling, data input
and data output, etc.

7. Coincidental Cohesion: A module is said to have coincidental cohesion if it

performs a set of tasks that are associated with each other very loosely, if at all.

Differentiate between Coupling and Cohesion

Coupling Cohesion

Coupling is also called Inter- Cohesion is also called Intra-Module Binding.

Module Binding.

Coupling shows the relationships Cohesion shows the relationship within the
between modules. module.

Coupling shows the relative Cohesion shows the module's relative

independence between the functional strength.
modules.

While creating, you should aim for While creating you should aim for high
low coupling, i.e., dependency cohesion, i.e., a cohesive component/ module
among modules should be less. focuses on a single function (i.e., single-
 mindedness) with little interaction with other
modules of the system.

In coupling, modules are linked to In cohesion, the module focuses on a single

the other modules. thing.

Software Design Documentation (SDD)

IEEE defines software design documentation as ‘a description of software
created to facilitate analysis, planning, implementation, and decision-making.
This design description is -used as a medium for communicating software
design information and can be considered as a blueprint or model of the system.
While developing SDD, the design should be described up to the refinement level
that is sufficient for explaining every task including inter-task communications,
data structures, and databases. No refinement of any task should be left to be
made during the coding phase.
The information that the software design document should describe depends on
various factors including the type of software being developed and the approach
used in its development. A number of standards have been suggested to develop
a software design document. However, the most widely used standard is by
IEEE, which acts as a general framework. This general framework can be
customized and adapted to meet the needs of a particular organization. This
template consists of several sections, which are listed below.
■ Scope: Identifies the release or version of the system being designed.
The system is divided into modules; the relationship between them
and functionalities will be defined. Every iteration of the SDD
document describes and identifies the software modules to be added
or changed in a release.
■ References: Lists references (both hardware and software documents
and manuals) used in the creation of the SDD that may be of use to
the designer, programmer, user, or management personnel. This
document is also considered useful for the readers of the document.
In this section, any references made to the other documents including
references to related project documents, especially the SRS are also
listed. The existing software documentation (if any) is also listed.
■ Definition: Provides a glossary of technical terms used in the
document along with their definitions.
 ■ Purpose: States the purpose of this document and its intended
audience. This is meant primarily for individuals who will be
implementing the system.
■ Design description information content: Consists of the following
subsections.
.
■ Introduction: Since SDD represents the software design that is to be
implemented, it should describe the design entities into which the
system has been partitioned along with their significant properties
and relationships.
■ Design entity: It is a software design component that is different from
other design entities in terms of structure and function. The objective
of creating design entities is to partition the system into a set of
components that can be implemented and modified independently.
Note that each design entity is assigned with a unique name and
serves a specific purpose and function but all possess some common
characteristics.
■ Design entity attributes: They are properties of the design entity and
provide some factual information regarding the entity. Every attribute
has an attached description, which includes references and design
considerations. The attributes and their associated information are
listed in Table.
Table Attributes and Description

Attributes Description
Identification Identifies name of the entity. All the
entities have a unique name.

Type Describes the kind of entity. This

specifies the nature of the entity.

Purpose Specifies why the entity exists.

Function Specifies what the entity does.

Subordinates Identifies sub-ordinate entity of an entity.

Dependencies Describes relationships that exist

between one entity and other entities.

Interface Describes how entities interact among

themselves.

Resources Describes elements used by the entity

that are external to the design.

Processing Specifies rules used to achieve the

specified functions.

Data Identifies data elements that form part of

the internal entity.

6. Design description organization: Consists of the following subsection.

7. Design views: They describe the software design in a comprehensive manner
so that the process of information access and integration is simplified. The
design of software can be viewed in multiple ways and each design view
describes a distinct aspect of the system. Table lists various design views and
their attributes.
Table Design Views and their Description

Design View Description Attribute

Decomposition Partitions the system Identification, type,
description into design entities. purpose, function, and
subordinate

Dependency description Describes relationships Identification, type,

between entities. purpose,
dependencies, and
resources

Interface description Consists of list that is Identification, function

required by the and
stakeholders (designers,
interfaces
developers, and testers)
in order to design
entities.

Detail description Describes internal Identification,

details of the design processing, and data
entity.

Unified Modeling Language (UML) | An

Introduction
● Unified Modeling Language (UML) is a general purpose modelling
language. The main aim of UML is to define a standard way to visualize
the way a system has been designed. 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 modelling, design and analysis. The Object
Management Group (OMG) adopted Unified Modelling Language as a
standard in 1997. Its been managed by OMG ever since. International
Organization for Standardization (ISO) published UML as an approved
standard in 2005. UML has been revised over the years and is
reviewed periodically.
UML is not a programming laDo we really need?

● 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.

UML is linked with object oriented design and analysis. UML makes the use of
elements and forms associations between them to form diagrams. Diagrams in
UML can be broadly classified as:

1. Structural Diagrams – Capture static aspects or structure of a system.

Structural Diagrams include: Component Diagrams, Object Diagrams,
Class Diagrams and Deployment Diagrams.
2. Behavior Diagrams – Capture dynamic aspects or behavior of the
system. Behavior diagrams include: Use Case Diagrams, State
Diagrams, Activity Diagrams and Interaction Diagrams.

The image below shows the hierarchy of diagrams according to UML 2.2
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 – Mechanism by which implementation details are hidden
from user.
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.

Additions in UML 2.0 –

● Software development methodologies like agile have been

incorporated and scope of original UML specification has been
broadened.
● Originally UML specified 9 diagrams. UML 2.x has increased the
number of diagrams from 9 to 13. The four diagrams that were added
are : timing diagram, communication diagram, interaction overview
diagram and composite structure diagram. UML 2.x renamed
statechart diagrams to state machine diagrams.
● UML 2.x added the ability to decompose software system into
components and sub-components.

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 the
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 Diagrams 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.

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 Diagrams

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.
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 draw 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.

25.4M
566

C++ vs Java

After that, we will 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 to which it is going to interact.

Once both the actors and use cases are enlisted, the relation between the actor and
use case/ system is inspected. It identifies the no of times an actor communicates
with the system. Basically, an actor can interact multiple times with a use case or
system at a particular instance of time.

Following are some rules that must be followed while drawing a use case diagram:

1. A pertinent and meaningful name should be assigned to the actor or a use case
of a system.
 2. The communication of an actor with a use case must be defined in an
understandable way.

3. Specified notations to be used as and when required.

4. The most significant interactions should be represented among the multiple no

of interactions between the use case and actors.

Example of a Use Case Diagram

A use case diagram depicting the Online Shopping website is given below.

Here the Web Customer actor makes use of any online shopping website to purchase
online. The top-level uses are as follows; View Items, Make Purchase, Checkout, Client
Register. The View Items use case is utilized by the customer who searches and view
products. The Client Register use case allows the customer to register itself with the
website for availing gift vouchers, coupons, or getting a private sale invitation. It is to
be noted that the Checkout is an included use case, which is part of Making Purchase,
and it is not available by itself.
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. 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.
Important tips for drawing a Use Case diagram
Following are some important tips that are to be kept in mind while drawing a use case
diagram:

7. A simple and complete use case diagram should be articulated.

8. A use case diagram should represent the most significant interaction among
the multiple interactions.

9. At least one module of a system should be represented by the use case

diagram.
 10. If the use case diagram is large and more complex, then it should be
drawn more generalized.

UML Class Diagram

The class diagram depicts a static view of an application. It represents the types of
objects residing in the system and the relationships between them. A class consists of
its objects, and also it may inherit from other classes. A class diagram is used to
visualize, describe, document various different aspects of the system, and also
construct executable software code.

It shows the attributes, classes, functions, and relationships to give an overview of the
software system. It constitutes class names, attributes, and functions in a separate
compartment that helps in software development. Since it is a collection of classes,
interfaces, associations, collaborations, and constraints, it is termed as a structural
diagram.

Purpose of Class Diagrams

The main purpose of class diagrams is to build a static view of an application. It is the
only diagram that is widely used for construction, and it can be mapped with object-
oriented languages. It is one of the most popular UML diagrams. Following are the
purpose of class diagrams given below:

1. It analyses and designs a static view of an application.

2. It describes the major responsibilities of a system.

3. It is a base for component and deployment diagrams.

4. It incorporates forward and reverse engineering.

Benefits of Class Diagrams

 1. It can represent the object model for complex systems.

2. It reduces the maintenance time by providing an overview of how an application

is structured before coding.

3. It provides a general schematic of an application for better understanding.

4. It represents a detailed chart by highlighting the desired code, which is to be

programmed.

5. It is helpful for the stakeholders and the developers.

Vital components of a Class Diagram

The class diagram is made up of three sections:

● Upper Section: The upper section encompasses the name of the class. A class
is a representation of similar objects that shares the same relationships,
attributes, operations, and semantics. Some of the following rules that should
be taken into account while representing a class are given below:

a. Capitalize the initial letter of the class name.

b. Place the class name in the center of the upper section.

c. A class name must be written in bold format.

d. The name of the abstract class should be written in italics format.

● Middle Section: The middle section constitutes the attributes, which describe
the quality of the class. The attributes have the following characteristics:

a. The attributes are written along with its visibility factors, which are public
(+), private (-), protected (#), and package (~).

b. The accessibility of an attribute class is illustrated by the visibility

factors.

c. A meaningful name should be assigned to the attribute, which will

explain its usage inside the class.
 ● Lower Section: The lower section contain methods or operations. The methods
are represented in the form of a list, where each method is written in a single
line. It demonstrates how a class interacts with data.

Relationships
In UML, relationships are of three types:

● Dependency: A dependency is a semantic relationship between two or more

classes where a change in one class cause changes in another class. It forms a
weaker relationship.
In the following example, Student_Name is dependent on the Student_Id.
 ● Generalization: A generalization is a relationship between a parent class
(superclass) and a child class (subclass). In this, the child class is inherited
from the parent class.
For example, The Current Account, Saving Account, and Credit Account are the
generalized form of Bank Account.

● Association: It describes a static or physical connection between two or more

objects. It depicts how many objects are there in the relationship.
For example, a department is associated with the college.

Multiplicity: It defines a specific range of allowable instances of attributes. In case if a

range is not specified, one is considered as a default multiplicity.

For example, multiple patients are admitted to one hospital.

Aggregation: An aggregation is a subset of association, which represents has a
relationship. It is more specific then association. It defines a part-whole or part-of
relationship. In this kind of relationship, the child class can exist independently of its
parent class.

The company encompasses a number of employees, and even if one employee

resigns, the company still exists.

Composition: The composition is a subset of aggregation. It portrays the dependency

between the parent and its child, which means if one part is deleted, then the other
part also gets discarded. It represents a whole-part relationship.
A contact book consists of multiple contacts, and if you delete the contact book, all
the contacts will be lost.

Abstract Classes
In the abstract class, no objects can be a direct entity of the abstract class. The
abstract class can neither be declared nor be instantiated. It is used to find the
functionalities across the classes. The notation of the abstract class is similar to that
of class; the only difference is that the name of the class is written in italics. Since it
does not involve any implementation for a given function, it is best to use the abstract
class with multiple objects.

Let us assume that we have an abstract class named displacement with a method
declared inside it, and that method will be called as a drive (). Now, this abstract class
method can be implemented by any object, for example, car, bike, scooter, cycle, etc.

How to draw a Class Diagram?

The class diagram is used most widely to construct software applications. It not only
represents a static view of the system but also all the major aspects of an application.
A collection of class diagrams as a whole represents a system.

Some key points that are needed to keep in mind while drawing a class diagram are
given below:

1. To describe a complete aspect of the system, it is suggested to give a

meaningful name to the class diagram.

2. The objects and their relationships should be acknowledged in advance.

3. The attributes and methods (responsibilities) of each class must be known.

4. A minimum number of desired properties should be specified as more number

of the unwanted property will lead to a complex diagram.

5. Notes can be used as and when required by the developer to describe the
aspects of a diagram.

6. The diagrams should be redrawn and reworked as many times to make it

correct before producing its final version.

Class Diagram Example

A class diagram describing the sales order system is given below.
Usage of Class diagrams
The class diagram is used to represent a static view of the system. It plays an
essential role in the establishment of the component and deployment diagrams. It
helps to construct an executable code to perform forward and backward engineering
for any system, or we can say it is mainly used for construction. It represents the
mapping with object-oriented languages that are C++, Java, etc. Class diagrams can
be used for the following purposes:

11. To describe the static view of a system.

12. To show the collaboration among every instance in the static view.

13. To describe the functionalities performed by the system.

 14. To construct the software application using object-oriented languages.

UML Object Diagram

Object diagrams are dependent on the class diagram as they are derived from the
class diagram. It represents an instance of a class diagram. The objects help in
portraying a static view of an object-oriented system at a specific instant.

Both the object and class diagram are similar to some extent; the only difference is
that the class diagram provides an abstract view of a system. It helps in visualizing a
particular functionality of a system.

Notation of an Object Diagram

Purpose of Object Diagram

The object diagram holds the same purpose as that of a class diagram. The class
diagram provides an abstract view which comprises of classes and their relationships,
whereas the object diagram represents an instance at a particular point of time.

The object diagram is actually similar to the concrete (actual) system behavior. The
main purpose is to depict a static view of a system.
 Exception Handling in Java - Javatpoint

Following are the purposes enlisted below:

● It is used to perform forward and reverse engineering.

● It is used to understand object behavior and their relationships practically.

● It is used to get a static view of a system.

● It is used to represent an instance of a system.

Example of Object Diagram

How to draw an Object Diagram?

1. All the objects present in the system should be examined before start drawing
the object diagram.

2. Before creating the object diagram, the relation between the objects must be
acknowledged.

3. The association relationship among the entities must be cleared already.

4. To represent the functionality of an object, a proper meaningful name should be

assigned.

5. The objects are to be examined to understand its functionality.

Applications of Object diagrams
The following are the application areas where the object diagrams can be used.

1. To build a prototype of a system.

2. To model complex data structures.

3. To perceive the system from a practical perspective.

4. Reverse engineering.

Class vs. Object diagram

Serial Class Diagram Object Diagram

No.

1. It depicts the static view of a system. It portrays the real-time

behavior of a system.

2. Dynamic changes are not included in Dynamic changes are captured

the class diagram. in the object diagram.
 3. The data values and attributes of an It incorporates data values and
instance are not involved here. attributes of an entity.

4. The object behavior is manipulated in Objects are the instances of a

the class diagram. class.

UML Interaction Diagram

As the name suggests, the interaction diagram portrays the interactions between
distinct entities present in the model. It amalgamates both the activity and sequence
diagrams. The communication is nothing but units of the behavior of a classifier that
provides context for interactions.

A set of messages that are interchanged between the entities to achieve certain
specified tasks in the system is termed as interaction. It may incorporate any feature
of the classifier of which it has access. In the interaction diagram, the critical
component is the messages and the lifeline.

In UML, the interaction overview diagram initiates the interaction between the objects
utilizing message passing. While drawing an interaction diagram, the entire focus is to
represent the relationship among different objects which are available within the
system boundary and the message exchanged by them to communicate with each
other.

The message exchanged among objects is either to pass some information or to

request some information. And based on the information, the interaction diagram is
categorized into the sequence diagram, collaboration diagram, and timing diagram.

Competitive questions on Structures in Hindi

Keep Watching

The sequence diagram envisions the order of the flow of messages inside the system
by depicting the communication between two lifelines, just like a time-ordered
sequence of events.

The collaboration diagram, which is also known as the communication diagram,

represents how lifelines connect within the system, whereas the timing diagram
focuses on that instant when a message is passed from one element to the other.

Notation of an Interaction Diagram

Purpose of an Interaction Diagram

The interaction diagram helps to envision the interactive (dynamic) behavior of any
system. It portrays how objects residing in the system communicates and connects to
each other. It also provides us with a context of communication between the lifelines
inside the system.

Following are the purpose of an interaction diagram given below:

 1. To visualize the dynamic behavior of the system.

2. To envision the interaction and the message flow in the system.

3. To portray the structural aspects of the entities within the system.

4. To represent the order of the sequenced interaction in the system.

5. To visualize the real-time data and represent the architecture of an object-

oriented system.

How to draw an Interaction Diagram?

Since the main purpose of an interaction diagram is to visualize the dynamic behavior
of the system, it is important to understand what a dynamic aspect really is and how
we can visualize it. The dynamic aspect is nothing but a screenshot of the system at
the run time.

Before drawing an interaction diagram, the first step is to discover the scenario for
which the diagram will be made. Next, we will identify various lifelines that will be
invoked in the communication, and then we will classify each lifeline. After that, the
connections are investigated and how the lifelines are interrelated to each other.

Following are some things that are needed:

1. A total no of lifeline which will take part in the communication.

2. The sequence of the message flow among several entities within the system.

3. No operators used to ease out the functionality of the diagram.

4. Several distinct messages that depict the interactions in a precise and clear
way.

5. The organization and structure of a system.

6. The order of the sequence of the flow of messages.

7. Total no of time constructs of an object.

Use of an Interaction Diagram

The interaction diagram can be used for:

1. The sequence diagram is employed to investigate a new application.

2. The interaction diagram explores and compares the use of the collaboration
diagram sequence diagram and the timing diagram.

3. The interaction diagram represents the interactive (dynamic) behavior of the

system.

4. The sequence diagram portrays the order of control flow from one element to
the other elements inside the system, whereas the collaboration diagrams are
employed to get an overview of the object architecture of the system.

5. The interaction diagram models the system as a time-ordered sequence of a

system.

6. The interaction diagram models the system as a time-ordered sequence of a

system.

7. The interaction diagram systemizes the structure of the interactive elements.

UML Collaboration Diagram

The collaboration diagram is used to show the relationship between the objects in a
system. Both the sequence and the collaboration diagrams represent the same
information but differently. Instead of showing the flow of messages, it depicts the
architecture of the object residing in the system as it is based on object-oriented
programming. An object consists of several features. Multiple objects present in the
system are connected to each other. The collaboration diagram, which is also known
as a communication diagram, is used to portray the object's architecture in the
system.

Notations of a Collaboration Diagram

Following are the components of a component diagram that are enlisted below:
1. Objects: The representation of an object is done by an object symbol with its
name and class underlined, separated by a colon.
In the collaboration diagram, objects are utilized in the following ways:

○ The object is represented by specifying their name and class.

○ It is not mandatory for every class to appear.

○ A class may constitute more than one object.

○ In the collaboration diagram, firstly, the object is created, and then its
class is specified.

○ To differentiate one object from another object, it is necessary to name

them.

2. Actors: In the collaboration diagram, the actor plays the main role as it invokes
the interaction. Each actor has its respective role and name. In this, one actor
initiates the use case.

3. Links: The link is an instance of association, which associates the objects and
actors. It portrays a relationship between the objects through which the
messages are sent. It is represented by a solid line. The link helps an object to
connect with or navigate to another object, such that the message flows are
attached to links.

4. Messages: It is a communication between objects which carries information

and includes a sequence number, so that the activity may take place. It is
represented by a labeled arrow, which is placed near a link. The messages are
sent from the sender to the receiver, and the direction must be navigable in that
particular direction. The receiver must understand the message.
When to use a Collaboration Diagram?
The collaborations are used when it is essential to depict the relationship between the
object. Both the sequence and collaboration diagrams represent the same information,
but the way of portraying it quite different. The collaboration diagrams are best suited
for analyzing use cases.

Following are some of the use cases enlisted below for which the collaboration
diagram is implemented:

1. To model collaboration among the objects or roles that carry the functionalities
of use cases and operations.

2. To model the mechanism inside the architectural design of the system.

3. To capture the interactions that represent the flow of messages between the
objects and the roles inside the collaboration.

4. To model different scenarios within the use case or operation, involving a

collaboration of several objects and interactions.
 5. To support the identification of objects participating in the use case.

6. In the collaboration diagram, each message constitutes a sequence number,

such that the top-level message is marked as one and so on. The messages
sent during the same call are denoted with the same decimal prefix, but with
different suffixes of 1, 2, etc. as per their occurrence.

Steps for creating a Collaboration Diagram

1. Determine the behavior for which the realization and implementation are
specified.

2. Discover the structural elements that are class roles, objects, and subsystems
for performing the functionality of collaboration.

○ Choose the context of an interaction: system, subsystem, use case, and

operation.

3. Think through alternative situations that may be involved.

○ Implementation of a collaboration diagram at an instance level, if

needed.

○ A specification level diagram may be made in the instance level

sequence diagram for summarizing alternative situations.

Example of a Collaboration Diagram

Benefits of a Collaboration Diagram

1. The collaboration diagram is also known as Communication Diagram.

2. It mainly puts emphasis on the structural aspect of an interaction diagram, i.e.,

how lifelines are connected.

3. The syntax of a collaboration diagram is similar to the sequence diagram; just

the difference is that the lifeline does not consist of tails.

4. The messages transmitted over sequencing is represented by numbering each

individual message.

5. The collaboration diagram is semantically weak in comparison to the sequence

diagram.

6. The special case of a collaboration diagram is the object diagram.

7. It focuses on the elements and not the message flow, like sequence diagrams.

8. Since the collaboration diagrams are not that expensive, the sequence diagram
can be directly converted to the collaboration diagram.
 9. There may be a chance of losing some amount of information while
implementing a collaboration diagram with respect to the sequence diagram.

The drawback of a Collaboration Diagram

1. Multiple objects residing in the system can make a complex collaboration

diagram, as it becomes quite hard to explore the objects.

2. It is a time-consuming diagram.

3. After the program terminates, the object is destroyed.

4. As the object state changes momentarily, it becomes difficult to keep an eye on

every single that has occurred inside the object of a system.

What Does Rational Rose Mean?

Rational Rose is an object-oriented programming (OOP) and unified
modeling language (UML) tool to design enterprise-level software
applications and components. It creates visual software application
models under object-oriented principles. Example application
models include the creation of actors, use cases, relationships,
objects, entities, etc. Rational Rose uses classical UML concepts to
graphically model software applications. This facilitates
documenting the environment, requirements and overall design.

Unit 4 Software Testing

A Fundamental of testing: Objectives, principles, myths and facts,
Error, Mistake, Bug, Fault and Failure, limitations of testing
B Levels of testing: Unit Testing, Integration Testing, System
 Testing, Acceptance Testing: Alpha & Beta Testing, Integration
techniques
C White Box Testing, Black Box Testing, Verification and
Validation, Test case designing, Coding Guidelines, Debugging

Software testing can be stated as the process of verifying and validating

that software or application is bug-free, meets the technical requirements
as guided by its design and development, and meets the user requirements
effectively and efficiently with handling all the exceptional and boundary
cases.
The process of software testing aims not only at finding faults in the
existing software but also at finding measures to improve the software in
terms of efficiency, accuracy, and usability. It mainly aims at measuring the
specification, functionality, and performance of a software program or
application.

The main objectives of software testing

To find any defects or bugs that may have been created when the software was being
developed
To increase confidence in the quality of the software
To prevent defects in the final product
To ensure the end product meets customer requirements as well as the company
specifications
To provide customers with a quality product and increase their confidence in the
company

Principles

There are seven principles in software testing:

1. Testing shows the presence of defects

2. Exhaustive testing is not possible
3. Early testing
4. Defect clustering
5. Pesticide paradox
6. Testing is context-dependent
7. Absence of errors fallacy
● Testing shows the presence of defects: The goal of software
testing is to make the software fail. Software testing reduces the
presence of defects. Software testing talks about the presence of
defects and doesn’t talk about the absence of defects. Software
testing can ensure that defects are present but it can not prove
that software is defect-free. Even multiple testing can never ensure
that software is 100% bug-free. Testing can reduce the number of
defects but not removes all defects.
● Exhaustive testing is not possible: It is the process of testing the
functionality of the software in all possible inputs (valid or invalid)
and pre-conditions is known as exhaustive testing. Exhaustive
testing is impossible means the software can never test at every
test case. It can test only some test cases and assume that the
software is correct and it will produce the correct output in every
test case. If the software will test every test case then it will take
more cost, effort, etc., and which is impractical.
● Early Testing: To find the defect in the software, early test activity
shall be started. The defect detected in the early phases of SDLC
will be very less expensive. For better performance of software,
software testing will start at the initial phase i.e. testing will
perform at the requirement analysis phase.
 ● Defect clustering: In a project, a small number of the module can
contain most of the defects. Pareto Principle to software testing
state that 80% of software defect comes from 20% of modules.
● Pesticide paradox: Repeating the same test cases, again and
again, will not find new bugs. So it is necessary to review the test
cases and add or update test cases to find new bugs.
● Testing is context-dependent: The testing approach depends on
the context of the software developed. Different types of software
need to perform different types of testing. For example, The
testing of the e-commerce site is different from the testing of the
Android application.
● Absence of errors fallacy: If a built software is 99% bug-free but it
does not follow the user requirement then it is unusable. It is not
only necessary that software is 99% bug-free but it is also
mandatory to fulfill all the customer requirements.

Myths about Software Testing

● Last Updated : 19 Feb, 2021

There are many myths and false assumptions that continue to loom around
Software Testing. There are also lots of myths out there that prevent fully
testing the software application that can lead to producing an insecure and
less productive software application. Software testing not only provides
security to the system or software application but also concentrates on
fulfilling the requirements of the end-users.
Following are the myths that need to be challenged for the purpose of good
software quality:

● Testing expenditure is unnecessary:

Often people think that too much money expenditure on testing is
unworthy but the reality is that if testing is done in a proper way then
there will be a lot more savings on the further maintenance of the
software. Repeatedly software maintenance cost is a lot more than
one-time testing cost.

● Testing takes a lot of time:

It is often a talk around that testing consumes a lot of time but the
fact is that testing is not a time-consuming process. Although
debugging takes more time as fixing the bugs are complicated.

● Perfect Testing is possible:

Often a client thinks that if the software application is tested then it a
perfect product but the fact is something else. There might exist
some vulnerabilities that can’t be executed during the testing process
and it creates problems once the product is launched.

● Only completely developed products are tested:

It is always a consideration that once the software product is fully
developed only then it is tested. But the fact is that after each
functionality addition or removal software product is tested. If
 testing is carried out only after full development it might create
chaos and may take a lot of effort to fix it.

● Tested software defects less:

Software can’t be 100% defect less even after thousands of testing
processes. Often the clients and also developers think that if the
software is tested in multiple levels then it has zero bugs but it is only
a myth while the fact is a software can’t be 100% defectless.

● Automation testing consumes less time:

It is true that automation testing consumes less time but automation
testing can’t be performed at every stage of the software
development and also automation testing is only performed after the
manual testing. There are also some testing which is only performed
only in a manual way.

● Software testing is a cakewalk:

Often people outside the testing team think that testing can be done
by a person with less experience and less knowledge. The reality is
that testing is done by testing experts that are experienced and
knowledge full personnel in order to get productive software.

● Testing is all about finding bugs:

It is true that finding bugs is one of the prominent objectives of the
testing but it is not the only objective. Besides finding bugs there are
several areas that are checked during the testing process. Software
 functional and non-functional requirements are checked during the
testing process.

Testing Limitations

● You cannot test a program completely

● We can only test against system requirements

● Exhaustive (total) testing is impossible in the present scenario.

● Time and budget constraints normally require very careful planning of the testing

effort.

● Compromise between thoroughness and budget.

● Test results are used to make business decisions for release dates.

● Even if you do find the last bug, you’ll never know it

● You will run out of time before you run out of test cases

● You cannot test every path

● You cannot test every valid input

● You cannot test every invalid input

Fault :
It is an incorrect step in any process and data definition in computer
program which is responsible of the unintended behavior of any program
in the computer. Faults or bugs in a hardware or software may cause
errors. An error can be defined as a part of the system which will lead to
the failure of the system. Basically an error in a program is an indication
that failure occurs or has tp occurred.
If there are multiple components of the system, errors in that system will
lead to component failure. As there are many component in the system that
interact with each other, failure of one component might be responsible to
introduce one or more faults in the system. Following cycle show the
behavior of the fault.
 Figure: Fault Behavior

Types of fault :
In software products, different types of fault can be occurred. In order to
remove the fault, we have to know what type of fault which is facing by our
program. So the following are the types of faults :

Figure: Types of Faults

1. Algorithm Fault :
This type of fault occurs when the component algorithm or logic
does not provide the proper result for the given input due to wrong
processing steps. It can be easily removed by reading the program
i.e. disk checking.
2. Computational Fault :
This type of fault occur when a fault disk implementation is wrong
or not capable of calculating the desired result e.g. combining
integer and floating point variables may produce unexpected
result.
3. Syntax Fault :
This type of fault occur due the use of wrong syntax in the
program. We have to use the proper syntax for the programming
language which we are using.
4. Documentation Fault :
The documentation in the program tells what the program actually
does. Thus it can occur when program does not match with the
documentation.
5. Overload Fault :
For memory purpose we used data structures like array, queue
and stack etc. in our programs. When they are filled with their
given capacity and we are using them beyond their capacity, then
overload fault occurs in our program.
6. Timing Fault :
When the system is not responding after the failure occurs in the
program then this type of fault is referred as the timing fault.
 7. Hardware Fault :
This type of failure occur when the specified hardware for the
given software does not work properly. Basically, it is due to the
problem in the continuation of the hardware that is not specified in
the specification.
8. Software Fault :
It can occur when the specified software is not properly working or
not supporting the platform used or we can say operating system.
9. Omission Fault :
It ca occur when the key aspect is missing in the program e.g.
when the initialization of a variable is not done in the program.
10. Commission Fault :
It can occur when the statement of expression is wrong i.e. integer
is initialized with float.

Fault Avoidance :
Fault in the program can be avoid by using techniques and procedures
which aims to avoid the introduction of the fault during any phase of the
safety lifecycle of the safety related system.
Fault Tolerance :
It is ability of the functional unit to continue to perform a required function
even in the presence of the fault.

Levels of Testing
In this section, we are going to understand the various levels of software testing.

As we learned in the earlier section of the software testing tutorial that testing any
application or software, the test engineer needs to follow multiple testing techniques.
In order to detect an error, we will implement software testing; therefore, all the errors
can be removed to find a product with more excellent quality.

What are the levels of Software Testing?

Testing levels are the procedure for finding the missing areas and avoiding
overlapping and repetition between the development life cycle stages. We have
already seen the various phases such as Requirement collection, designing, coding
testing, deployment, and maintenance of SDLC (Software Development Life Cycle)

.
26.3M
608

Features of Java - Javatpoint

Next

Stay

In order to test any application, we need to go through all the above phases of SDLC.
Like SDLC, we have multiple levels of testing, which help us maintain the quality of the
software.

Different Levels of Testing

The levels of software testing involve the different methodologies, which can be used
while we are performing the software testing.

In software testing

, we have four different levels of testing, which are as discussed below:

1. Unit Testing

2. Integration Testing

3. System Testing

4. Acceptance Testing
As we can see in the above image that all of these testing levels have a specific
objective which specifies the value to the software development lifecycle.

For our better understanding, let's see them one by one:

Level1: Unit Testing

Unit testing is the first level of software testing, which is used to test if software
modules are satisfying the given requirement or not.

The first level of testing involves analyzing each unit or an individual component of the
software application.

Unit testing is also the first level of functional testing

. The primary purpose of executing unit testing is to validate unit

components with their performance.

A unit component is an individual function or regulation of the application, or we can

say that it is the smallest testable part of the software. The reason of performing the
unit testing is to test the correctness of inaccessible code.

Unit testing will help the test engineer and developers in order to understand the base
of code that makes them able to change defect causing code quickly. The developers
implement the unit.
Level2: Integration Testing

The second level of software testing is the integration testing. The integration testing
process comes after unit testing.

It is mainly used to test the data flow from one module or component to other
modules.

In integration testing, the test engineer tests the units or separate components or
modules of the software in a group.

The primary purpose of executing the integration testing is to identify the defects at
the interaction between integrated components or units.

When each component or module works separately, we need to check the data flow
between the dependent modules, and this process is known as integration testing.

We only go for the integration testing when the functional testing has been completed
successfully on each application module.

In simple words, we can say that integration testing aims to evaluate the accuracy of
communication among all the modules.

For more information on integration testing, refers to the following link:

Level3: System Testing

The third level of software testing is system testing, which is used to test the
software's functional and nonfunctional requirements.

It is end-to-end testing where the testing environment is parallel to the production

environment. In the third level of software testing, we will test the application as a
whole system.

To check the end-to-end flow of an application or the software as a user is known as

System testing.

In system testing, we will go through all the necessary modules of an application and
test if the end features or the end business works fine, and test the product as a
complete system.

In simple words, we can say that System testing is a sequence of different types of
tests to implement and examine the entire working of an integrated software computer
system against requirements.

For more information on System testing, refers to the following link:

https://www.javatpoint.com/system-testing

Level4: Acceptance Testing

The last and fourth level of software testing is acceptance testing, which is used to
evaluate whether a specification or the requirements are met as per its delivery.

The software has passed through three testing levels (Unit Testing, Integration
Testing, System Testing). Some minor errors can still be identified when the end-user
uses the system in the actual scenario.

In simple words, we can say that Acceptance testing is the squeezing of all the testing
processes that are previously done.

The acceptance testing is also known as User acceptance testing (UAT) and is done by
the customer before accepting the final product.

Usually, UAT is done by the domain expert (customer) for their satisfaction and checks
whether the application is working according to given business scenarios and real-
time scenarios.

Alpha Testing Introduction

Alpha testing is conducted in the organization and tested by a representative group of

end-users at the developer's side and sometimes by an independent team of testers.

Alpha testing is simulated or real operational testing at an in-house site. It comes after
the unit testing, integration testing, etc. Alpha testing used after all the testing are
executed.
It can be a white box, or Black-box testing depends on the requirements - particular
lab environment and simulation of the actual environment required for this testing.

What is the alpha testing process?

Alpha testing follows the following process:

26.6M
507

Difference between JDK, JRE, and JVM

 1. Requirement Review: Review the design of the specification and functional
requirement

2. Test Development: Test development is base on the outcome of the

requirement review. Develop the test cases and test plan.

3. Test case design: Execute the test plan and test cases.

4. Logging Defects: Logging the identified and detected bug found in the
application.

5. Bug Fixation: When all the bugs are identified and logged, then there is a need
to fix the bug.

6. Retesting: When all the issues are solved, and fixed retesting is done.

What are the phases of alpha testing?

Alpha testing ensures that the software performs flawlessly and does not impact the
reputation of the organization; the company implements final testing in the form of
alpha testing. This testing executed into two phases.
There are two phases of alpha testing.

First Phase: In-house developers of software engineers do the first phase of testing. In
this phase, the tester used hardware debugger or hardware aided debugger to catches
the bugs quickly. During the alpha testing, a tester finds a lot of bugs, crashes, missing
features, and docs.

Second Phase: The second phase involves the quality assurance staff performs the
alpha testing by involving black box and white box techniques.

When to perform alpha testing?

Alpha testing is user acceptance testing. Alpha testing performed once the product
has gone through stages of testing and prepared for release. It is executing before
beta testing, which is also a part of acceptance testing and can define as field testing.
During this testing, we can make changes in the software to improve its quality and
functionality. Alpha testing done from the developer's site where independent
developers can monitor and record user experience and make necessary changes to
enhance the performance.

What are the reasons to perform Alpha Testing?

Alpha testing is the final stage of the testing. Alpha testing is an essential and popular
testing technique that helps the team to deliver quality and useful software. This
testing performed before the release of the product. Alpha testing can define as the
first round of independent testing that ensures that the software run as per the
requirement plan.

Reasons for alpha testing are:

 ● Refines the software product by finding and rectifying bugs that weren't
discovered through previous tests.

● Alpha testing allows the team to test the software in a real-world environment.

● One of the reasons to do alpha testing is to ensure the success of the software
product.

● Alpha testing validates the quality, functionality of the software, and

effectiveness of the software before it released in the real world.

What are the features of Alpha Testing?

● Alpha testing is a type of acceptance testing.

● Alpha testing is happening at the stage of the completion of the software

product.

● Alpha testing is in the labs where we provide a specific and controlled

environment.

● Alpha testing is in-house testing, which is performed by the internal developers

and testers within the organization.

● There is not any involvement of the public.

● Alpha testing helps to gain confidence in the user acceptance of the software
product.

● With the help of black box and white box technique, we can achieve the alpha
testing.

● Alpha testing ensures the maximum possible quality of the software before
releasing it to market or client for beta testing.

● Developers perform alpha testing at developer's site; it enables the developer to

record the error with the ease to resolve found bugs quickly.
 ● Alpha testing is doing after the unit testing, integration testing, system testing
but before the beta testing.

● Alpha testing is for testing the software application, products, and projects.

What are the advantages of Alpha Testing?

Advantages of alpha testing are:

● One of the benefits of alpha testing is it reduces the delivery time of the project.

● It provides a complete test plan and test cases.

● Free the team member for another project.

● Every feedback helps to improve software quality.

● It provides a better observation of the software's reliability and accountability.

What are the disadvantages of Alpha Testing?

Disadvantages of alpha testing are:

● Alpha testing does not involve in-depth testing of the software.

● The difference between the tester's tests the data for testing the software and
the customer's data from their perspective may result in the discrepancy in the
software functioning.

● The lab environment is used to simulate the real environment. But still, the lab
cannot furnish all the requirement of the real environment such as multiple
conditions, factors, and circumstances.

Wrap Up:
Every software product needs to undergo a vital methodology before going into a
highly competitive market. Alpha testing is one of the vital testing. It needs to be
considered by going through the functionality of the software and achieve the
confidence in its user acceptance for the real environment, before releasing it into the
market.

What is Beta Testing?

Beta testing is a type of User Acceptance Testing among the most crucial testing,
which performed before the release of the software. Beta Testing is a type of Field
Test. This testing performs at the end of the software testing life cycle. This type of
testing can be considered as external user acceptance testing. It is a type of salient
testing. Real users perform this testing. This testing executed after the alpha testing.
In this the new version, beta testing is released to a limited audience to check the
accessibility, usability, and functionality, and more.

● Beta testing is the last phase of the testing, which is carried out at the client's or
customer's site.

What are the features of beta testing?

Testing of the product performs by the real users of the software application in the
real environment. Beta version of the software is released to a restricted number of
end-users to obtain the feedback of the product quality. Beta testing reduces the risk
of failure and provides the quality of the product through customer validation. It is the
final testing before shipping the product to the customers. Beta testing obtains direct
feedback from the customers. It helps in testing to test the product in the customer's
environment.

Features of beta testing are:

 12.3M
201

Triggers in SQL (Hindi)

● Beta testing used in a real environment at the user's site. Beta testing helps in
providing the actual position of the quality.

● Testing performed by the client, stakeholder, and end-user.

● Beta testing always is done after the alpha testing, and before releasing it into
the market.

● Beta testing is black-box testing.

● Beta testing performs in the absence of tester and the presence of real users

● Beta testing is performed after alpha testing and before the release of the final
product.

● Beta testing generally is done for testing software products like utilities,
operating systems, and applications, etc.

What is a beta version of the software?

The beta version of the software is delivered to a restricted number of users to accept
their feedback and suggestions on quality improvement. Hence, there are two types of
beta version:

1) Closed beta version: Closed beta version, also known as a private beta, it is released
to a group of selected and invited people. Those people will test the software and
evaluate their features and specifications. This beta version represents the software
which is capable of delivering value, but it is not ready to be used by everyone.
Because it shows the issues like lack of documentation or missing vital features.
2) Open beta version: Open beta is also known as a public beta. The open beta opened
to the public. Any user as a tester can assess the beta version to provide the relevant
feedback and reviews. Open beta version improves the quality of the final release. This
version helps to find the various undetected errors and issues.
The beta testing process orients this beta version.

What is the lifecycle of Beta Testing?

A group of end-users performs beta testing. This process can't execute without any
strategy or test plan. Before the testers, the end-user executes this type of testing.

The process of beta testing follows the following steps:

1. Planning: Like another testing process, beta testing also supports proper
planning. In this stage, the team prepares a testing strategy and defines the
goal of testing. In this case, the team establishes the need of users for testing,
duration, and necessary details related to the process.

2. Participant Recruitment: This is the second stage of the beta process in which
the team recruits a group of selected end-users for testing. This group can
change as per the requirement of the organization and the product.

3. Product Launch: When a team of users (testers) recruited. The beta version of
the product is launched or installed at the client or user side, and users will test
the product for quality assurance.

4. Collect and Evaluate Feedback: When the testing finished, developers will
collect the feedback provided by the testers and evaluate it. In the end, based
on the feedback, issues, and bugs are fixed and resolved by the responsible
individual team.

5. Closure: When all the problems fixed and the organization meets the exit
criteria, beta testing achieved, and the rewards offered to the testing team.

What are the types of beta testing?

Beta testing has six types. Each type has different aspects of the software. All these
help developers to improve the quality of the software and allow them to deliver a
product that offers excellent user experience. Here are the different types of beta
testing:

1. Open Beta Testing: Open beta testing involves testing the software product by a
large number of people before the final release. The organization decides to
make a software product open to the public before releasing the product. Open
Beta includes the extensive participation of the public to use and evaluate
software product accordingly.
Users report the bug to the organization, along with a suggestion to improve the
quality of the software.

2. Closed Beta Testing: Opposite to the open beta testing. Closed beta testing
performed by the selective and limited number of persons. The organization
recruits these. In this testing software product is not open to the public.

3. Traditional Beta Testing: In this testing, a software product delivered to the

target market, and the feedback from the users collected. This type of testing
assistance the beta testing, the quality of the software is improved, and
developers can make the changes.

4. Public Beta Testing: This type of testing is similar to open testing. Public beta
testing also allows the product is delivering to the end-users worldwide, with
the aid of various online channels available in the world. From this, the
feedback and evaluated data also collected and based on the requirement
changes, and the development team implements modifications.

5. Technical Beta Testing: Technical beta testing is also an essential type of beta
testing. This testing involves delivering the software product to the internal
groups of the organization. However, the data and feedback provided by the
employees of the organization.

6. Focused Beta Testing: This type of testing focused on monitoring and

evaluating a specific feature or component of the software. In focused beta
 testing, the software released to the market and user's experience assessed
and collected to make the required changes.

7. Post-Release Beta Testing: In this testing, the product delivered to the market
for the use of the end-users. Their feedback, reactions, and experience are
collect for the future release of the software.

When to perform Beta Testing?

Acceptance testing is the final phase of the testing, which combines both alpha and
beta testing to ensure that the product released flawlessly. Beta testing performed at
the user's end. This testing always performed after the alpha testing, but before the
product released to the market. In this stage, the product is expected to be 90% to 95%
completed.

Any product undergoing to beta test should be reviewed for the entire checklist before
launching it.

Some of them are:

● All the component of the product is ready to start this testing.

● Documentation which is going to end-user should be kept ready - Setup,

installation, usage, Uninstallation should be in detail.

● The product management team should review that all the functionality is in
good condition.

● Procedure to collect bugs, feedback, etc. should be identified before publishing

it.

What are the stakeholders and participants in the Beta

Testing?
The product management, quality management, and user experience teams are the
stakeholder in beta testing, and they closely monitor every move of the phase.

The real users who use the product are the participants.

Beta test strategy

● Business objective for the product.

● Beta test plan

● The testing approach followed by participants.

● Tools used to detect bugs, measure productivity, collect feedback.

● When and how to end this testing phase?

What is a Beta Test plan?

A beta test plan can be written in many ways,

Objective: We should have to mention the aim of the project why there is a need for
beta testing even after performing the internal testing.

Scope: In this plan, we should mention the areas to be tested or not.

Test Approach: We should have to mention clearly that the testing is in the deep, what
to focus on - functionality, UI, response, etc.

Schedule: We have to specify, clearly the start and ending date with time, number of
cycles, and duration per cycle.

Tools: Bug logging tools and the usage of the machines should identify.

Budget: Incentive of the bugs based on the severity.

Feedback: Collecting feedback and evaluating methods.

● Identify and review the entry and exit criteria.

What are the entry criteria for Beta Testing?

 ● Sign off the document from alpha testing.

● Beta version of the software should ready.

● The environment should be ready to release the software application to the

public.

● To capture the real-time faults environment should be ready.

What are the exit criteria for Beta Testing?

● All the major and minor issues resolved.

● The feedback report should prepare.

● The delivery of beta test summary report.

What are the advantages of Beta Testing?

Beta testing performed at the end of the software testing lifecycle. Beta testing offers
numerous benefits to testers, software developer, as well as the users. In the
assistance of this type of testing, it enables developers, testers to test the product
before its release in the market. The

1. Beta testing focuses on the customer's satisfaction.

2. It helps to reduce the risk of product failure via user validations.

3. Beta testing helps to get direct feedback from users.

4. It helps to detect the defect and issues in the system, which is overlooked and
undetected by the team of software testers.

5. Beta testing helps the user to install, test, and send feedback regarding the
developed software.
What are the disadvantages of Beta Testing?
Disadvantages of beta testing is:

1. In this type of testing, a software engineer has no control over the process of
the testing, as the users in the real-world environment perform it.

2. This testing can be a time-consuming process and can delay the final release of
the product.

3. Beta testing does not test the functionality of the software in depth as software
still in development.

4. It is a waste of time and money to work on the feedback of the users who do not
use the software themselves properly.

Wrap Up
Keeping in mind the characteristics of beta testing can be concluded that beta testing
may be considered desirable for the organization. Beta testing provides the feedback
of the real-users, which helps improve the software quality before the product
released in the market.

White box Testing

White box testing techniques analyze the internal structures the used data
structures, internal design, code structure and the working of the software
rather than just the functionality as in black box testing. It is also called glass
box testing or clear box testing or structural testing.
Working process of white box testing:

● Input: Requirements, Functional specifications, design documents,

source code.
● Processing: Performing risk analysis for guiding through the entire
process.
● Proper test planning: Designing test cases so as to cover entire code.
Execute rinse-repeat until error-free software is reached. Also, the
results are communicated.
● Output: Preparing final report of the entire testing process.

Testing techniques:

● Statement coverage: In this technique, the aim is to traverse all

statement at least once. Hence, each line of code is tested. In case of a
flowchart, every node must be traversed at least once. Since all lines
of code are covered, helps in pointing out faulty code.
 Statement Coverage Example

● Branch Coverge: In this technique, test cases are designed so that

each branch from all decision points are traversed at least once. In a
flowchart, all edges must be traversed at least once.

4 test cases required such that all branches of all decisions are covered, i.e, all edges of flowchart are
covered
● Condition Coverage: In this technique, all individual conditions must
be covered as shown in the following example:
1. READ X, Y
2. IF(X == 0 || Y == 0)
3. PRINT ‘0’
● In this example, there are 2 conditions: X == 0 and Y == 0. Now, test
these conditions get TRUE and FALSE as their values. One possible
example would be:
1. #TC1 – X = 0, Y = 55
2. #TC2 – X = 5, Y = 0
● Multiple Condition Coverage: In this technique, all the possible
combinations of the possible outcomes of conditions are tested at
least once. Let’s consider the following example:
1. READ X, Y
2. IF(X == 0 || Y == 0)
3. PRINT ‘0’
4. #TC1: X = 0, Y = 0
5. #TC2: X = 0, Y = 5
6. #TC3: X = 55, Y = 0
7. #TC4: X = 55, Y = 5
● Hence, four test cases required for two individual conditions.
Similarly, if there are n conditions then 2n test cases would be
required.
● Basis Path Testing: In this technique, control flow graphs are made
from code or flowchart and then Cyclomatic complexity is calculated
which defines the number of independent paths so that the minimal
 number of test cases can be designed for each independent path.
Steps:
1. Make the corresponding control flow graph
2. Calculate the cyclomatic complexity
3. Find the independent paths
4. Design test cases corresponding to each independent path
● Flow graph notation: It is a directed graph consisting of nodes and
edges. Each node represents a sequence of statements, or a decision
point. A predicate node is the one that represents a decision point
that contains a condition after which the graph splits. Regions are
bounded by nodes and edges.

Cyclomatic Complexity: It is a measure of the logical complexity of

the software and is used to define the number of independent paths.
For a graph G, V(G) is its cyclomatic complexity.
Calculating V(G):
1. V(G) = P + 1, where P is the number of predicate nodes in
the flow graph
2. V(G) = E – N + 2, where E is the number of edges and N is the
total number of nodes
3. V(G) = Number of non-overlapping regions in the graph
● Example:

V(G) = 4 (Using any of the above formulae)

No of independent paths = 4
1. #P1: 1 – 2 – 4 – 7 – 8
2. #P2: 1 – 2 – 3 – 5 – 7 – 8
3. #P3: 1 – 2 – 3 – 6 – 7 – 8
4. #P4: 1 – 2 – 4 – 7 – 1 – . . . – 7 – 8
● Loop Testing: Loops are widely used and these are fundamental to
many algorithms hence, their testing is very important. Errors often
occur at the beginnings and ends of loops.
1. Simple loops: For simple loops of size n, test cases are
designed that:
■ Skip the loop entirely
■ Only one pass through the loop
■ 2 passes
■ m passes, where m < n
■ n-1 ans n+1 passes
 2. Nested loops: For nested loops, all the loops are set to their
minimum count and we start from the innermost loop.
Simple loop tests are conducted for the innermost loop and
this is worked outwards till all the loops have been tested.
3. Concatenated loops: Independent loops, one after another.
Simple loop tests are applied for each.
If they’re not independent, treat them like nesting.

Advantages:

1. White box testing is very thorough as the entire code and structures
are tested.
2. It results in the optimization of code removing error and helps in
removing extra lines of code.
3. It can start at an earlier stage as it doesn’t require any interface as in
case of black box testing.
4. Easy to automate.

Disadvantages:

1. Main disadvantage is that it is very expensive.

2. Redesign of code and rewriting code needs test cases to be written
again.
 3. Testers are required to have in-depth knowledge of the code and
programming language as opposed to black box testing.
4. Missing functionalities cannot be detected as the code that exists is
tested.
5. Very complex and at times not realistic.

Black box testing

Black box testing is a technique of software testing which examines the functionality
of software without peering into its internal structure or coding. The primary source of
black box testing is a specification of requirements that is stated by the customer.

In this method, tester selects a function and gives input value to examine its
functionality, and checks whether the function is giving expected output or not. If the
function produces correct output, then it is passed in testing, otherwise failed. The
test team reports the result to the development team and then tests the next function.
After completing testing of all functions if there are severe problems, then it is given
back to the development team for correction.

Generic steps of black box testing

● The black box test is based on the specification of requirements, so it is

examined in the beginning.

● In the second step, the tester creates a positive test scenario and an adverse
test scenario by selecting valid and invalid input values to check that the
software is processing them correctly or incorrectly.
 ● In the third step, the tester develops various test cases such as decision table,
all pairs test, equivalent division, error estimation, cause-effect graph, etc.

● The fourth phase includes the execution of all test cases.

● In the fifth step, the tester compares the expected output against the actual
output.

● In the sixth and final step, if there is any flaw in the software, then it is cured
and tested again.

Test procedure
The test procedure of black box testing is a kind of process in which the tester has
specific knowledge about the software's work, and it develops test cases to check the
accuracy of the software's functionality.

It does not require programming knowledge of the software. All test cases are
designed by considering the input and output of a particular function.A tester knows
about the definite output of a particular input, but not about how the result is arising.
There are various techniques used in black box testing for testing like decision table
technique, boundary value analysis technique, state transition, All-pair testing, cause-
effect graph technique, equivalence partitioning technique, error guessing technique,
use case technique and user story technique. All these techniques have been
explained in detail within the tutorial.

26.8M
607

Exception Handling in Java - Javatpoint

Test cases
Test cases are created considering the specification of the requirements. These test
cases are generally created from working descriptions of the software including
requirements, design parameters, and other specifications. For the testing, the test
designer selects both positive test scenario by taking valid input values and adverse
test scenario by taking invalid input values to determine the correct output. Test cases
are mainly designed for functional testing but can also be used for non-functional
testing. Test cases are designed by the testing team, there is not any involvement of
the development team of software.
Techniques Used in Black Box Testing
Decision Decision Table Technique is a systematic approach where various
Table input combinations and their respective system behavior are
Technique captured in a tabular form. It is appropriate for the functions that
have a logical relationship between two and more than two inputs.

Boundary Boundary Value Technique is used to test boundary values,

Value boundary values are those that contain the upper and lower limit of
Technique a variable. It tests, while entering boundary value whether the
software is producing correct output or not.

State State Transition Technique is used to capture the behavior of the

Transition software application when different input values are given to the
Technique same function. This applies to those types of applications that
provide the specific number of attempts to access the application.

All-pair All-pair testing Technique is used to test all the possible discrete
Testing combinations of values. This combinational method is used for
Technique testing the application that uses checkbox input, radio button input,
list box, text box, etc.

Cause-Effect Cause-Effect Technique underlines the relationship between a given

Technique result and all the factors affecting the result.It is based on a
collection of requirements.

Equivalence Equivalence partitioning is a technique of software testing in which

Partitioning input data divided into partitions of valid and invalid values, and it is
Technique mandatory that all partitions must exhibit the same behavior.
 Error Error guessing is a technique in which there is no specific method
Guessing for identifying the error. It is based on the experience of the test
Technique analyst, where the tester uses the experience to guess the
problematic areas of the software.

Use Case Use case Technique used to identify the test cases from the
Technique beginning to the end of the system as per the usage of the system.
By using this technique, the test team creates a test scenario that
can exercise the entire software based on the functionality of each
function from start to end.

Verification is the process of checking that a software achieves its goal

without any bugs. It is the process to ensure whether the product that is
developed is right or not. It verifies whether the developed product fulfills
the requirements that we have. Verification is static testing.
Verification means Are we building the product right?
Validation is the process of checking whether the software product is up to
the mark or in other words product has high level requirements. It is the
process of checking the validation of product i.e. it checks what we are
developing is the right product. it is validation of actual and expected
product. Validation is the dynamic testing.
Validation means Are we building the right product?
The difference between Verification and Validation is as follow:

Verification Validation
It includes checking documents, It includes testing and validating
design, codes and programs. the actual product.

Verification is the static testing. Validation is the dynamic testing.

It does not include the execution of It includes the execution of the

the code. code.

Methods used in verification are Methods used in validation are

reviews, walkthroughs, inspections Black Box Testing, White Box
and desk-checking. Testing and non-functional testing.

It checks whether the software

It checks whether the software
meets the requirements and
conforms to specifications or not.
expectations of a customer or not.

It can only find the bugs that could

It can find the bugs in the early
not be found by the verification
stage of the development.
process.

The goal of verification is The goal of validation is an actual

application and software
architecture and specification.
 product.

Quality assurance team does Validation is executed on software

verification. code with the help of testing team.

It comes before validation. It comes after verification.

It consists of checking of
It consists of execution of program
documents/files and is performed
and is performed by computer.
by human.