Hindustan Institute of Management and Computer Studies

Department of Computer Application

MCA 3 Sem

KCA302: Software Engineering

Unit-3

Software Design: Basic Concept of Software Design, Architectural Design, Low

Level Design: Modularization, Design Structure Charts, Pseudo Codes, Flow
Charts, Coupling and Cohesion Measures, Design Strategies: Function Oriented
Design, Object Oriented Design, Top-Down and Bottom-Up Design. Software
Measurement and Metrics: Various Size Oriented Measures: Halestead’s Software
Science, Function Point (FP) Based Measures, Cyclomatic Complexity Measures:
Control Flow Graphs.

Basic Concept of Software Design

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. Flexibility:
A good software design should have the ability to adapt and accommodate changes
easily. It includes designing the software in a way, that allows for modifications,
enhancements, and scalability without requiring significant rework or causing major
disruptions to the existing functionality.
4. Understandability:
A good design should be easily understandable, for which it should be modular and
all the modules are arranged in layers.
5. Completeness:
The design should have all the components like data structures, modules, and external
interfaces, etc.
6. Maintainability:
A good software design aims to create a system that is easy to understand, modify,
and maintain over time. This involves using modular and well-structured design
principles eg.(employing appropriate naming conventions and providing clear
documentation). Maintainability in software Design also enables developers to fix
 bugs, enhance features, and adapt the software to changing requirements without
excessive effort or introducing new issues.

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 uses 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:

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 or low-level 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.

Sn Comparison Basis HLD LLD

1. Stands for It stands for High-Level Design. It stands for Low-Level Design.

2. Definition It is the general system design, It is like describing high-level design,

which means it signifies the overall which means it signifies the procedure
system design. of the component-level design.

3. Purpose The HLD states the concise LLD states the particular efficient logic
functionality of each component. of the component.

4. Also, known as HLD is also called a System or LLD is also called details or micro-
macro-level design. level design.

5. Developed by Solution Architect prepares the Designer and developer prepare the
High-Level Design. Low-Level Design.

6. Sequential order It is developed first in sequential It is developed after High-level design.

in the design phase order, which implies that the HLD is
created before the LLD.
7. Target Audience It is used by management, program, It is used by designers, operation teams,
and solution teams. and implementers.

8. Conversion The HLD changes the client or The LLD changes the high-level
business requirement into a high- solution to a comprehensive solution.
level solution.

9. Probable output The high-level design is necessary to A low-level design is required for
understand the flow across several creating the configurations and
system objects. troubleshooting inputs.

10. Input Criteria The input measure in high-level The input measure in low-level design
design is SRS (Software is the reviewed HLD (High- Level
Requirement Specification). Design).

11. Output Criteria The output measures in the HLD are The output bases in the low-level
functional design, database design, design are the unit test plan and
and review record. program specification.

Modularization
Modularization is a technique to divide a software system into multiple discrete and
independent modules, which are expected to be capable of carrying out task(s)
independently. These modules may work as basic constructs for the entire software.
Designers tend to design modules such that they can be executed and/or compiled separately
and independently.

Modular design unintentionally follows the rules of ‘divide and conquer’ problem-solving
strategy this is because there are many other benefits attached with the modular design of a
software.

Advantage of modularization:
 Smaller components are easier to maintain
 Program can be divided based on functional aspects
 Desired level of abstraction can be brought in the program
 Components with high cohesion can be re-used again
 Concurrent execution can be made possible
 Desired from security aspect

Design Structure Charts

Structure Chart represents hierarchical structure of modules. It breaks down the entire
system into lowest functional modules; describe functions and sub-functions of each
module of a system to a greater detail. Structure Chart partitions the system into black
boxes (functionality of the system is known to the users but inner details are unknown).
Inputs are given to the black boxes and appropriate outputs are generated.
Modules at top level called modules at low level. Components are read from top to bottom
and left to right. When a module calls another, it views the called module as black box,
passing required parameters and receiving results.

Symbols used in construction of structured chart:

Module
It represents the process or task of the system. It is of three types.
 Control Module
A control module branches to more than one sub module.
 Sub Module
Sub Module is a module which is the part (Child) of another module.
  Library Module
Library Module are reusable and invokable from any module.
Conditional Call
It represents that control module can select any of the sub module on the basis of some
condition.
Loop (Repetitive call of module)
It represents the repetitive execution of module by the sub module.
A curved arrow represents loop in the module. All the sub modules cover by the loop
repeat execution of module.
Data Flow
It represents the flow of data between the modules. It is represented by directed arrow
with empty circle at the end.
Control Flow
It represents the flow of control between the modules. It is represented by directed arrow
with filled circle at the end.
Physical Storage
Physical Storage is that where all the information are to be stored.

Example: Structure chart for an Email server

Types of Structure Chart:

1. Transform Centered Structure:
These type of structure chart are designed for the systems that receives an input which
is transformed by a sequence of operations being carried out by one module.
2. Transaction Centered Structure:
These structure describes a system that processes a number of different types of
transaction.

Pseudocode and Flowcharts

Good, logical programming is developed through good pre-code planning and organization.
This is assisted by the use of pseudocode and program flowcharts.

Flowcharts are written with program flow from the top of a page to the bottom. Each
command is placed in a box of the appropriate shape, and arrows are used to direct program
flow. The following shapes are often used in flowcharts:
Pseudocode is a method of describing computer algorithms using a combination of natural
language and programming language. It is essentially an intermittent step towards the
development of the actual code. It allows the programmer to formulate their thoughts on the
organization and sequence of a computer algorithm without the need for actually following
the exact coding syntax. Pseudo-code notations can be used in both the preliminary and
detailed design phases. Using pseudo-code, the designer describes system characteristics
using short, concise, English Language phases that are structured by keywords such as If-
Then-Else, While-Do, and End. Although pseudocode is frequently used there are no set of
rules for its exact implementation. In general, here are some rules that are frequently
followed when writing pseudocode:
 The usual symobols are used for arithmetic operations (+, -, *, / , **).
 Symbolic names are used to indicate the quantities being processed.
 Indentation should be used to indicate branches and loops of instruction.

Example- For a given value, Limit, what is the smallest positive integer Number for which
the sum is greater than Limit. Where ‘Sum = 1 + 2 + ... + Number’ and What is the value for
this Sum?

Pseudocode:
Input: An integer Limit
Ouput: Two integers: Number and Sum
1. Enter Limit
2. Set Number = 0.
3. Set Sum = 0.
4. Repeat the following:
a. If Sum > Limit, terminate the repitition, otherwise.
b. Increment Number by one.
 c. Add Number to Sum and set equal to Sum.
5. Print Number and Sum.

FlowChart:

Coupling and Cohesion Measures

Coupling and cohesion are attributes that sum- marizes the degree of interdependence or
connectivity among subsystems and within subsystems, respectively. When used in
conjunction with measures of other at- tributes, coupling and cohesion can contribute to an
assessment or prediction of software quality.

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.

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.

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.

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-Module Cohesion is also called Intra-Module

Binding. Binding.
Coupling shows the relationships between Cohesion shows the relationship within the
modules. module.
Coupling shows the Cohesion shows the module's
relative independence between the modules. relative functional strength.
While creating, you should aim for low While creating you should aim for high
coupling, i.e., dependency among modules cohesion, i.e., a cohesive component/
should be less. module focuses on a single function (i.e.,
single-mindedness) with little interaction
with other modules of the system.
In coupling, modules are linked to the other In cohesion, the module focuses on a single
modules. thing.

Advantages of low coupling:

  Improved maintainability: Low coupling reduces the impact of changes in one module
on other modules, making it easier to modify or replace individual components
without affecting the entire system.
 Enhanced modularity: Low coupling allows modules to be developed and tested in
isolation, improving the modularity and reusability of code.
 Better scalability: Low coupling facilitates the addition of new modules and the
removal of existing ones, making it easier to scale the system as needed.

Advantages of high cohesion:

 Improved readability and understandability. High cohesion results in clear, focused
modules with a single, well-defined purpose, making it easier for developers to
understand the code and make changes.
 Better error isolation: High cohesion reduces the likelihood that a change in one part
of a module will affect other parts, making it easier to
 Isolate and fix errors. Improved reliability: High cohesion leads to modules that are
less prone to errors and that function more consistently,
 Leading to an overall improvement in the reliability of the system.

Design Strategies
Design strategy is a systematic and intentional approach to creating solutions that meet
specific objectives.

Function Oriented Design and Object Oriented Design

1. Function Oriented Design:
Function oriented design is the result of focusing attention to the function of the program.
This is based on the stepwise refinement. Stepwise refinement is based on the iterative
procedural decomposition. Stepwise refinement is a top-down strategy where a program is
refined as a hierarchy of increasing levels of details.
We start with a high level description of what the program does. Then, in each step, we
take one part of our high level description and refine it. Refinement is actually a process
of elaboration. The process should proceed from a highly conceptual model to lower level
details. The refinement of each module is done until we reach the statement level of our
programming language.
2. Object Oriented Design:
Object oriented design is the result of focusing attention not on the function performed by
the program, but instead on the data that are to be manipulated by the program. Thus, it is
orthogonal to function -oriented design. Object-oriented design begins with an
examination of the real world “things”. These things are characteristics individually in
terms of their attributes and behavior.
Objects are independent entities that may readily be changed because all state and
representation information is held within the object itself. Object may be distributed and
may execute sequentially or in parallel. Object oriented technology contains following
three keywords –
1. Objects – Software package are designed and developed to correspond with real world
entities that contain all the data and services to function as their associated entities
messages.
2. Communication – Communication mechanisms are established that provide the means
by which object work together.
3. Methods – Methods are services that objects perform to satisfy the functional
requirements of the problem domain. Objects request services of the other objects
through messages.
Difference between Function Oriented Design and Object Oriented Design:
COMPARISON FUNCTION ORIENTED
OBJECT ORIENTED DESIGN
FACTORS DESIGN

The basic abstractions are not the real

The basic abstractions, which
world functions but are the data
Abstraction are given to the user, are real
abstraction where the real world
world functions.
entities are represented.

Function are grouped together on the

Functions are grouped together
basis of the data they operate since
Function by which a higher level function
the classes are associated with their
is obtained.
methods.

carried out using structured

execute analysis and structured design Carried out using UML
i.e, data flow diagram

In this approach the state information

In this approach the state is not represented in a centralized
State
information is often represented memory but is implemented or
information
in a centralized shared memory. distributed among the objects of the
system.

Approach It is a top down approach. It is a bottom up approach.

Begins by considering the use

Begins by identifying objects and
Begins basis case diagrams and the
classes.
scenarios.

In function oriented design we

Decompose decompose in We decompose in class level.
function/procedure level.

This approach is mainly used This approach is mainly used for

Use for computation sensitive evolving system which mimics a
application. business or business case.

Top-Down and Bottom-Up Design

Top-Down Design Model:
In the top-down model, an overview of the system is formulated without going into detail
for any part of it. Each part of it then refined into more details, defining it in yet more
details until the entire specification is detailed enough to validate the model. if we glance
at a haul as a full, it’s going to appear not possible as a result of it’s so complicated For
example: Writing a University system program, writing a word processor. Complicated
issues may be resolved victimization high down style, conjointly referred to as Stepwise
refinement where,
1. We break the problem into parts,
2. Then break the parts into parts soon and now each of parts will be easy to do.

Advantages:
 Breaking problems into parts help us to identify what needs to be done.
  At each step of refinement, new parts will become less complex and therefore easier
to solve.
 Parts of the solution may turn out to be reusable.
 Breaking problems into parts allows more than one person to solve the problem.

Bottom-Up Design Model:

In this design, individual parts of the system are specified in detail. The parts are linked to
form larger components, which are in turn linked until a complete system is formed.
Object-oriented language such as C++ or java uses a bottom-up approach where each
object is identified first.
Advantage:
 Make decisions about reusable low-level utilities then decide how there will be put
together to create high-level construct.

Contrast between Top-down design and bottom-up design

S.
No. TOP DOWN APPROACH BOTTOM UP APPROACH

In this approach We focus on In bottom up approach, we solve smaller

1. breaking up the problem into smaller problems and integrate it as whole and
parts. complete the solution.

Mainly used by structured

Mainly used by object oriented programming
2. programming language such as
language such as C++, C#, Python.
COBOL, Fortran, C, etc.

Each part is programmed separately Redundancy is minimized by using data

3.
therefore contain redundancy. encapsulation and data hiding.

In this the communications is less

4. In this module must have communication.
among modules.

It is used in debugging, module

5. It is basically used in testing.
documentation, etc.

In top down approach, In bottom up approach composition takes

6.
decomposition takes place. place.

In this top function of system might In this sometimes we can not build a
7.
be hard to identify. program from the piece we have started.

In this implementation details may

8. This is not natural for people to assemble.
differ.

Pros-
 Easier isolation of interface errors Pros-
 It benefits in the case error occurs  Easy to create test conditions
9. towards the top of the program.  Test results are easy to observe
 Defects in design get detected  It is suited if defects occur at the bottom
early and can be corrected as an of the program.
early working module of the
S.
No. TOP DOWN APPROACH BOTTOM UP APPROACH

program is available.

Cons-
Cons-
 There is no representation of the working
 Difficulty in observing the output
model once several modules have been
of test case.
constructed.
 Stub writing is quite crucial as it
 There is no existence of the program as an
leads to setting of output
10. entity without the addition of the last
parameters.
module.
 When stubs are located far from
 From a partially integrated system, test
the top level module, choosing test
engineers cannot observe system-level
cases and designing stubs become
functions. It can be possible only with the
more challenging.
installation of the top-level test driver.

Software Measurement and Metrics

Software Measurement: A measurement is a manifestation of the size, quantity, amount,
or dimension of a particular attribute of a product or process. Software measurement is a
titrate impute of a characteristic of a software product or the software process. It is an
authority within software engineering. The software measurement process is defined and
governed by ISO Standard.

Software Measurement Principles:

The software measurement process can be characterized by five activities-
1. Formulation: The derivation of software measures and metrics appropriate for the
representation of the software that is being considered.
2. Collection: The mechanism used to accumulate data required to derive the formulated
metrics.
3. Analysis: The computation of metrics and the application of mathematical tools.
4. Interpretation: The evaluation of metrics results in insight into the quality of the
representation.
5. Feedback: Recommendation derived from the interpretation of product metrics
transmitted to the software team.

Need for Software Measurement:

Software is measured to:
 Create the quality of the current product or process.
 Anticipate future qualities of the product or process.
 Enhance the quality of a product or process.
 Regulate the state of the project concerning budget and schedule.
 Enable data-driven decision-making in project planning and control.
 Identify bottlenecks and areas for improvement to drive process improvement
activities.
 Ensure that industry standards and regulations are followed.
 Give software products and processes a quantitative basis for evaluation.
 Enable the ongoing improvement of software development practices.

Classification of Software Measurement:

There are 2 types of software measurement:
 1. Direct Measurement: In direct measurement, the product, process, or thing is
measured directly using a standard scale.
2. Indirect Measurement: In indirect measurement, the quantity or quality to be
measured is measured using related parameters i.e. by use of reference.

Software Metrics:
A metric is a measurement of the level at which any attribute belongs to a system product
or process. Software metrics is a quantifiable or countable assessment of the attributes of a
software product. There are 4 functions related to software metrics:
1. Planning
2. Organizing
3. Controlling
4. Improving

Characteristics of software Metrics:

1. Quantitative: Metrics must possess quantitative nature. It means metrics can be
expressed in numerical values.
2. Understandable: Metric computation should be easily understood, and the method of
computing metrics should be clearly defined.
3. Applicability: Metrics should be applicable in the initial phases of the development
of the software.
4. Repeatable: When measured repeatedly, the metric values should be the same and
consistent in nature.
5. Economical: The computation of metrics should be economical.
6. Language Independent: Metrics should not depend on any programming language.

Classification of Software Metrics:

There are 3 types of software metrics:
1. Product Metrics: Product metrics are used to evaluate the state of the product,
tracing risks and undercover prospective problem areas. The ability of the team to
control quality is evaluated. Examples include lines of code, cyclomatic complexity,
code coverage, defect density, and code maintainability index.
2. Process Metrics: Process metrics pay particular attention to enhancing the long-term
process of the team or organization. These metrics are used to optimize the
development process and maintenance activities of software. Examples include effort
variance, schedule variance, defect injection rate, and lead time.
3. Project Metrics: The project metrics describes the characteristic and execution of a
project. Examples include effort estimation accuracy, schedule deviation, cost
variance, and productivity. Usually measures-
 Number of software developer
 Staffing patterns over the life cycle of software
 Cost and schedule
 Productivity

Advantages of Software Metrics:

1. Reduction in cost or budget.
2. It helps to identify the particular area for improvising.
3. It helps to increase the product quality.
4. Managing the workloads and teams.
5. Reduction in overall time to produce the product,.
6. It helps to determine the complexity of the code and to test the code with resources.
7. It helps in providing effective planning, controlling and managing of the entire
product.
Disadvantages of Software Metrics:
1. It is expensive and difficult to implement the metrics in some cases.
2. Performance of the entire team or an individual from the team can’t be determined.
Only the performance of the product is determined.
3. Sometimes the quality of the product is not met with the expectation.
4. It leads to measure the unwanted data which is wastage of time.
5. Measuring the incorrect data leads to make wrong decision making.

Scope of Software Metrics

Software metrics contains many activities which include the following −
 Cost and effort estimation
 Productivity measures and model
 Data collection
 Quantity models and measures
 Reliability models
 Performance and evaluation models
 Structural and complexity metrics
 Capability – maturity assessment
 Management by metrics
 Evaluation of methods and tools

Software measurement is a diverse collection of these activities that range from models
predicting software project costs at a specific stage to measures of program structure.

Various Size Oriented Measures

Size-oriented metrics play a fundamental role in software development by measuring and
comparing software project sizes based on various factors.

Lines of Code (LOC)

A line of code (LOC) is any line of text in a code that is not a comment or blank line, and
also header lines, in any case of the number of statements or fragments of statements on
the line. LOC clearly consists of all lines containing the declaration of any variable, and
executable and non-executable statements. As Lines of Code (LOC) only counts the
volume of code, you can only use it to compare or estimate projects that use the same
language and are coded using the same coding standards.

Features:
 Variations such as “source lines of code”, are used to set out a codebase.
 LOC is frequently used in some kinds of arguments.
 They are used in assessing a project’s performance or efficiency.
 LOC method of measurement does not apply to projects that deal with visual (GUI-
based) programming. As already explained, Graphical User Interfaces (GUIs) use
forms basically. LOC metric is not applicable here.
 Productivity is defined as KLOC / EFFORT, where effort is measured in person-
months.

Advantages:
 Most used metric in cost estimation.
 Its alternates have many problems as compared to this metric.
 It is very easy in estimating the efforts.
Disadvantages:
 Very difficult to estimate the LOC of the final program from the problem
specification.
 It correlates poorly with quality and efficiency of code.
 It doesn’t consider complexity.
 It is language dependent.
 It takes no account of functionality.
 Bad software design may cause an excessive lines of code.

Research has shown a rough correlation between LOC and the overall cost and length of
developing a project/ product in Software Development, and between LOC and the
number of defects. This means the lower your LOC measurement is, the better off you
probably are in the development of your product.

Example
void selSort(int x[], int n) {
//Below function sorts an array in ascending order
int i, j, min, temp;
for (i = 0; i < n - 1; i++) {
min = i;
for (j = i + 1; j < n; j++)
if (x[j] < x[min])
min = j;
temp = x[i];
x[i] = x[min];
x[min] = temp;
}
}

So, now If LOC is simply a count of the number of lines then the above function shown
contains 13 lines of code (LOC). But when comments and blank lines are ignored, the
function shown above contains 12 lines of code (LOC).

Halstead’s Software Metrics

Halstead’s Software metrics are a set of measures proposed by Maurice Halstead to
evaluate the complexity of a software program. These metrics are based on the number of
distinct operators and operands in the program and are used to estimate the effort required
to develop and maintain the program.

Halstead’s software metrics can be used to estimate the size, complexity, and effort
required to develop and maintain a software program. However, they have some
limitations, such as the assumption that all operators and operands are equally important,
and the assumption that the same set of metrics can be used for different programming
languages and development environments.
Overall, Halstead’s software metrics can be a useful tool for software developers and
project managers to estimate the effort required to develop and maintain software
programs.

n1 = Number of distinct operators.

n2 = Number of distinct operands.
N1 = Total number of occurrences of operators.
N2 = Total number of occurrences of operands.
Field of Halstead Metrics:
 Halstead Program Length: The total number of operator occurrences and the total
number of operand occurrences.
N = N1 + N2
And estimated program length is, N^ = n1 log2 n1 + n2 log2 n2
Halstead Vocabulary: The total number of unique operators and unique operand
occurrences. n = n1 + n2
 Program Volume: Proportional to program size, represents the size, in bits, of space
necessary for storing the program. This parameter is dependent on specific algorithm
implementation. The properties V, N, and the number of lines in the code are shown
to be linearly connected and equally valid for measuring relative program size.
V = Size * (log2 vocabulary) = N * log2(n)
The unit of measurement of volume is the common unit for size “bits”. It is the actual
size of a program if a uniform binary encoding for the vocabulary is used.
And error = Volume / 3000
 Potential Minimum Volume: The potential minimum volume V* is defined as the
volume of the most succinct program in which a problem can be coded.
V* = (2 + n2*) * log2(2 + n2 *)
Here, n2 * is the count of unique input and output parameters
 Program Level: This is the ratio of the number of operator occurrences to the number
of operand occurrences in the program, i.e., L = n1/n2
To rank the programming languages, the level of abstraction provided by the
programming language, Program Level (L) is considered. The higher the level of a
language, the less effort it takes to develop a program using that language.
L = V* / V
The value of L ranges between zero and one, with L=1 representing a program written
at the highest possible level (i.e., with minimum size).
And estimated program level is L^ =2 * (n2) / (n1)(N2)
 Program Difficulty: This parameter shows how difficult to handle the program is.
D = (n1 / 2) * (N2 / n2)
D=1/L
As the volume of the implementation of a program increases, the program level
decreases and the difficulty increases. Thus, programming practices such as redundant
usage of operands, or the failure to use higher-level control constructs will tend to
increase the volume as well as the difficulty.
 Programming Effort: Measures the amount of mental activity needed to translate the
existing algorithm into implementation in the specified program language.
E = V / L = D * V = Difficulty * Volume
 Language Level: Shows the algorithm implementation program language level. The
same algorithm demands additional effort if it is written in a low-level program
language. For example, it is easier to program in Pascal than in Assembler.
L’ = V / D / D
lambda = L * V* = L2 * V
 Intelligence Content: Determines the amount of intelligence presented (stated) in the
program. This parameter provides a measurement of program complexity,
independently of the programming language in which it was implemented.
I=V/D
 Programming Time: Shows time (in minutes) needed to translate the existing
algorithm into implementation in the specified program language.
T = E / (f * S)
The concept of the processing rate of the human brain, developed by psychologist
John Stroud, is also used. Stoud defined a moment as the time required by the human
brain requires to carry out the most elementary decision. The Stoud number S is
therefore Stoud’s moments per second with:
 5 <= S <= 20. Halstead uses 18. The value of S has been empirically developed from
psychological reasoning, and its recommended value for programming applications is
18.
Stroud number S = 18 moments / second
seconds-to-minutes factor f = 60

Counting Rules for C Language

1. Comments are not considered.
2. The identifier and function declarations are not considered
3. All the variables and constants are considered operands.
4. Global variables used in different modules of the same program are counted as
multiple occurrences of the same variable.
5. Local variables with the same name in different functions are counted as unique
operands.
6. Functions calls are considered operators.
7. All looping statements e.g., do {…} while ( ), while ( ) {…}, for ( ) {…}, all control
statements e.g., if ( ) {…}, if ( ) {…} else {…}, etc. are considered as operators.
8. In control construct switch ( ) {case:…}, switch as well as all the case statements are
considered as operators.
9. The reserve words like return, default, continue, break, size, etc., are considered
operators.
10. All the brackets, commas, and terminators are considered operators.
11. GOTO is counted as an operator and the label is counted as an operand.
12. The unary and binary occurrences of “+” and “-” are dealt with separately. Similarly
“*” (multiplication operator) is dealt with separately.
13. In the array variables such as “array-name [index]” “array-name” and “index” are
considered as operands and [ ] is considered as operator.
14. In the structure variables such as “struct-name, member-name” or “struct-name ->
member-name”, struct-name, and member-name are taken as operands, and ‘.’, ‘->’
are taken as operators. Some names of member elements in different structure
variables are counted as unique operands.
15. All the hash directives are ignored.

Example – List out the operators and operands and also calculate the values of software
science measures like
int sort (int x[ ], int n)
{
int i, j, save, im1;
/*This function sorts array x in ascending order */
If (n< 2) return 1;
for (i=2; i< =n; i++)
{
im1=i-1;
for (j=1; j< =im1; j++)
if (x[i] < x[j])
{
Save = x[i];
x[i] = x[j];
x[j] = save;
}
}
return 0;
}
Explanation
Operators Occurrences Operands Occurrences

int 4 sort 1

() 5 X 7

, 4 N 3

[] 7 I 8

if 2 J 7

< 2 save 3

; 11 im1 3

for 2 2 2

= 6 1 3

– 1 0 1

<= 2 – –

++ 2 – –

return 2 – –

{} 3 – –

n1 =14 N1=53 n2 =10 N2=38

Therefore,
N = 91
n = 24
V = 417.23 bits
N^ = 86.51
n2 * = 3 (x: array holding integer to be sorted. This is used both as input and output)
V* = 11.6
L = 0.027
D = 37.03
L^ = 0.038
T = 610 seconds

Advantages of Halstead Metrics

 It is simple to calculate.
 It measures the overall quality of the programs.
 It predicts the rate of error.
 It predicts maintenance effort.
 It does not require a full analysis of the programming structure.
 It is useful in scheduling and reporting projects.
  It can be used for any programming language.
 Easy to use: The metrics are simple and easy to understand and can be calculated
quickly using automated tools.
 Quantitative measure: The metrics provide a quantitative measure of the complexity
and effort required to develop and maintain a software program, which can be useful
for project planning and estimation.
 Language independent: The metrics can be used for different programming languages
and development environments.
 Standardization: The metrics provide a standardized way to compare and evaluate
different software programs.

Disadvantages of Halstead Metrics

 It depends on the complete code.
 It has no use as a predictive estimating model.
 Limited scope: The metrics focus only on the complexity and effort required to
develop and maintain a software program, and do not take into account other
important factors such as reliability, maintainability, and usability.
 Limited applicability: The metrics may not be applicable to all types of software
programs, such as those with a high degree of interactivity or real-time requirements.
 Limited accuracy: The metrics are based on a number of assumptions and
simplifications, which may limit their accuracy in certain situations.

Functional Point (FP) Analysis

Allan J. Albrecht initially developed function Point Analysis in 1979 at IBM and it has been
further modified by the International Function Point Users Group (IFPUG). FPA is used to
make estimate of the software project, including its testing in terms of functionality or
function size of the software product. However, functional point analysis may be used for
the test estimation of the product. The functional size of the product is measured in terms of
the function point, which is a standard of measurement to measure the software application.

Objectives of FPA
The basic and primary purpose of the functional point analysis is to measure and provide the
software application functional size to the client, customer, and the stakeholder on their
request. Further, it is used to measure the software project development along with its
maintenance, consistently throughout the project irrespective of the tools and the
technologies.

Following are the points regarding FPs

1. FPs of an application is found out by counting the number and types of functions used in
the applications. Various functions used in an application can be put under five types, as
shown in Table:
Types of FP Attributes
Measurements Parameters Examples

1. Number of External Inputs(EI) Input screen and tables

2. Number of External Output (EO) Output screens and reports
3. Number of external inquiries (EQ) Prompts and interrupts.
4. Number of internal files (ILF) Databases and directories
5. Number of external interfaces (EIF) Shared databases and shared routines.
All these parameters are then individually assessed for complexity.

The FPA functional units are shown in Fig:

2. FP characterizes the complexity of the software system and hence can be used to depict
the project time and the manpower requirement.
3. The effort required to develop the project depends on what the software does.
4. FP is programming language independent.
5. FP method is used for data processing systems, business systems like information
systems.
6. The five parameters mentioned above are also known as information domain
characteristics.
7. All the parameters mentioned above are assigned some weights that have been
experimentally determined and are shown in Table

Weights of 5-FP Attributes

Measurement Parameter Low Average High

1. Number of external inputs (EI) 7 10 15

2. Number of external outputs (EO) 5 7 10
3. Number of external inquiries (EQ) 3 4 6
4. Number of internal files (ILF) 4 5 7
5. Number of external interfaces (EIF) 3 4 6

The functional complexities are multiplied with the corresponding weights against each
function, and the values are added up to determine the UFP (Unadjusted Function Point) of
the subsystem.
Here that weighing factor will be simple, average, or complex for a measurement parameter
type.

The Function Point (FP) is thus calculated with the following formula.
FP = Count-total * [0.65 + 0.01 * ∑(fi)] = Count-total * CAF

where Count-total is obtained from the above Table.

CAF = [0.65 + 0.01 *∑(fi)]
and ∑(fi) is the sum of all 14 questionnaires and show the complexity adjustment value/
factor-CAF (where i ranges from 1 to 14). Usually, a student is provided with the value of
∑(fi)

Also note that ∑(fi) ranges from 0 to 70, i.e., 0 <= ∑(fi) <=70
and CAF ranges from 0.65 to 1.35 because
a. When ∑(fi) = 0 then CAF = 0.65
b. When ∑(fi) = 70 then CAF = 0.65 + (0.01 * 70) = 0.65 + 0.7 = 1.35

Based on the FP measure of software many other metrics can be computed:

a. Errors/FP
b. $/FP.
c. Defects/FP
d. Pages of documentation/FP
e. Errors/PM.
f. Productivity = FP/PM (effort is measured in person-months).
g. $/Page of Documentation.

8. LOCs of an application can be estimated from FPs. That is, they are
interconvertible. This process is known as backfiring. For example, 1 FP is equal to
about 100 lines of COBOL code.
9. FP metrics is used mostly for measuring the size of Management Information System
(MIS) software.
10. But the function points obtained above are unadjusted function points (UFPs). These
(UFPs) of a subsystem are further adjusted by considering some more General System
Characteristics (GSCs). It is a set of 14 GSCs that need to be considered. The procedure
for adjusting UFPs is as follows:
 Degree of Influence (DI) for each of these 14 GSCs is assessed on a scale of 0 to 5.
(b) If a particular GSC has no influence, then its weight is taken as 0 and if it has a
strong influence then its weight is 5.
 The score of all 14 GSCs is totaled to determine Total Degree of Influence (TDI).
  Then Value Adjustment Factor (VAF) is computed from TDI by using the
formula: VAF = (TDI * 0.01) + 0.65

Remember that the value of VAF lies within 0.65 to 1.35 because
a. When TDI = 0, VAF = 0.65
b. When TDI = 70, VAF = 1.35
c. VAF is then multiplied with the UFP to get the final FP count: FP = VAF * UFP

Example: Compute the function point, productivity, documentation, cost per function for
the following data:
1. Number of user inputs = 24
2. Number of user outputs = 46
3. Number of inquiries = 8
4. Number of files = 4
5. Number of external interfaces = 2
6. Effort = 36.9 p-m
7. Technical documents = 265 pages
8. User documents = 122 pages
9. Cost = $7744/ month

Various processing complexity factors are: 4, 1, 0, 3, 3, 5, 4, 4, 3, 3, 2, 2, 4, 5.

Solution:
Measurement Parameter Count Weighing
factor

1. Number of external inputs (EI) 24 * 4 = 96

2. Number of external outputs (EO) 46 * 4 = 184
3. Number of external inquiries (EQ) 8 * 6 = 48
4. Number of internal files (ILF) 4 * 10 = 40
5. Number of external interfaces (EIF) Count- 2 * 5 = 10
total → 378

So sum of all fi (i ← 1 to 14) = 4 + 1 + 0 + 3 + 5 + 4 + 4 + 3 + 3 + 2 + 2 + 4 + 5 = 43

FP = Count-total * [0.65 + 0.01 *∑(fi)]
= 378 * [0.65 + 0.01 * 43]
= 378 * [0.65 + 0.43]
= 378 * 1.08 = 408

Total pages of documentation = technical document + user document

= 265 + 122 = 387pages
Documentation = Pages of documentation/FP
= 387/408 = 0.94
Differentiate between FP and LOC
FP LOC

1. FP is specification based. 1. LOC is an analogy based.

2. FP is language independent. 2. LOC is language dependent.

3. FP is user-oriented. 3. LOC is design-oriented.

4. It is extendible to LOC. 4. It is convertible to FP (backfiring)

Cyclomatic Complexity Measures

The cyclomatic complexity of a code section is the quantitative measure of the number
of linearly independent paths in it. It is a software metric used to indicate the complexity of
a program. It is computed using the Control Flow Graph of the program. The nodes in the
graph indicate the smallest group of commands of a program, and a directed edge in it
connects the two nodes i.e. if the second command might immediately follow the first
command.
For example, if the source code contains no control flow statement then its cyclomatic
complexity will be 1, and the source code contains a single path in it. Similarly, if the
source code contains one if condition then cyclomatic complexity will be 2 because there
will be two paths one for true and the other for false.
Mathematically, for a structured program, the directed graph inside the control flow is the
edge joining two basic blocks of the program as control may pass from first to second.

So, cyclomatic complexity M would be defined as,

M = E – N + 2P
where E = the number of edges in the control flow graph
N = the number of nodes in the control flow graph
P = the number of connected components

In case, when exit point is directly connected back to the entry point. Here, the graph is
strongly connected, and cyclometric complexity is defined as
M=E–N+P
where E = the number of edges in the control flow graph
N = the number of nodes in the control flow graph
P = the number of connected components

In the case of a single method, P is equal to 1. So, for a single subroutine, the formula can
be defined as
M=E–N+2
where E = the number of edges in the control flow graph
N = the number of nodes in the control flow graph
P = the number of connected components

Calculation of Cyclomatic Complexity

Steps that should be followed in calculating cyclomatic complexity and test cases design
are:
Construction of graph with nodes and edges from code.
 Identification of independent paths.
 Cyclomatic Complexity Calculation
 Design of Test Cases
Let a section of code as such:
A = 10
IF B > C THEN
A=B
ELSE
A=C
ENDIF
Print A
Print B
Print C

Control Flow Graph of the above code

The cyclomatic complexity calculated for the above code will be from the control flow
graph. The graph shows seven shapes (nodes), and seven lines (edges), hence cyclomatic
complexity is 7-7+2 = 2.

Use of Cyclomatic Complexity

 Determining the independent path executions thus proven to be very helpful for
Developers and Testers.
 It can make sure that every path has been tested at least once.
 Thus help to focus more on uncovered paths.
 Code coverage can be improved.
 Risks associated with the program can be evaluated.
 These metrics being used earlier in the program help in reducing the risks.

Advantages of Cyclomatic Complexity

 It can be used as a quality metric, given the relative complexity of various designs.
 It is able to compute faster than Halstead’s metrics.
 It is used to measure the minimum effort and best areas of concentration for testing.
 It is able to guide the testing process.
 It is easy to apply.

Disadvantages of Cyclomatic Complexity

 It is the measure of the program’s control complexity and not the data complexity.
  In this, nested conditional structures are harder to understand than non-nested
structures.
 In the case of simple comparisons and decision structures, it may give a misleading
figure.

Control Flow Graphs

A Control Flow Graph (CFG) is the graphical representation of control flow
or computation during the execution of programs or applications. Control flow graphs are
mostly used in static analysis as well as compiler applications, as they can accurately
represent the flow inside of a program unit. The control flow graph was originally
developed by Frances E. Allen.

Characteristics of Control Flow Graph:

 Control flow graph is process oriented.
 Control flow graph shows all the paths that can be traversed during a program
execution.
 Control flow graph is a directed graph.
 Edges in CFG portray control flow paths and the nodes in CFG portray basic blocks.

There exist 2 designated blocks in Control Flow Graph:

1. Entry Block:
Entry block allows the control to enter into the control flow graph.
2. Exit Block:
Control flow leaves through the exit block.
Hence, the control flow graph is comprised of all the building blocks involved in a flow
diagram such as the start node, end node and flows between the nodes.
General Control Flow Graphs:
Control Flow Graph is represented differently for all statements and loops. Following
images describe it:
1. If-else: 2. while: 3. do-while: 4. for:

Example:
if A = 10 then
if B > C
A=B
else A = C
endif
endif
print A, B, C

Flowchart of above example will be:

Control Flow Graph of above example will be:

Advantage of CFG:
There are many advantages of a control flow graph. It can easily encapsulate the
information per each basic block. It can easily locate inaccessible codes of a program and
syntactic structures such as loops are easy to find in a control flow graph.
Master Software Testing and Automation in an efficient and time-bound manner by
mentors with real-time industry experience.