Software Design: Basic Concept of Software Design

Software design is a mechanism to transform user requirements into some suitable form, which helps the
programmer in software coding and implementation. It deals with representing the client's requirement, as
described in SRS (Software Requirement Specification) document, into a form, i.e., easily implementable using
programming language.

The software design phase is the first step in SDLC (Software Design Life Cycle), which moves the concentration
from the problem domain to the solution domain. In software design, we consider the system to be a set of
components or modules with clearly defined behaviors & boundaries.

Objectives of Software Design

1.Correctness: Software design should be correct as per requirement.

2.Completeness: The design should have all components like data structures, modules, and external interfaces, etc.
3.Efficiency: Resources should be used efficiently by the program.
4.Flexibility: Able to modify on changing needs.
5.Consistency: There should not be any inconsistency in the design.
6.Maintainability: The design should be so simple so that it can be easily maintainable by other designers.
UNIT-3
Software Design Concepts:

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.

Abstraction Refactoring

Modularity

Software Design Information

Concepts hiding
Architecture

pattern
Refinement
 Following points should be considered while designing a Software:
UNIT-3
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 broadways 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 to divide the system or project into smaller parts to reduce the complexity of the
system or project. In the same way, modularity in design means to subdivide 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 is design has now become a trend and is also important.
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.
UNIT-3
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 it cant be accessed by any other modules.
7. Refactoring- reconstruct something
Refactoring simply means to reconstruct something in such a way that it does not affect the behavior or any
other features. Refactoring in software design means to reconstruct 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 interna
structure”.
 Software Design Principles
Software design principles are concerned with providing means to handle the complexity of the design
process effectively. Effectively managing the complexity will not only reduce the effort needed for design but
can also reduce the scope of introducing errors during design.

Following are the principles of Software Design

Problem Partitioning
For small problem, we can handle the entire problem at once but for the significant problem, divide the problems
and conquer the problem it means to divide the problem into smaller pieces so that each piece can be captured
separately.
For software design, the goal is to divide the problem into manageable pieces .
Benefits of Problem Partitioning
1.Software is easy to understand
2.Software becomes simple
3.Software is easy to test
4.Software is easy to modify
5.Software is easy to maintain
6.Software is easy to expand
These pieces cannot be entirely independent of each other as they together form the system. They have to cooperate
 UNIT-3

Abstraction
An abstraction is a tool that enables a designer to consider a component at an abstract level without bothering about
the internal details of the implementation. Abstraction can be used for existing element as well as the component
being designed.
Here, there are two common abstraction mechanisms
1.Functional Abstraction
2.Data Abstraction
Functional Abstraction
i.A module is specified by the method it performs.
ii.The details of the algorithm to accomplish the functions are not visible to the user of the function.
Functional abstraction forms the basis for Function oriented design approaches.
Data Abstraction
Details of the data elements are not visible to the users of data. Data Abstraction forms the basis for Object
Oriented design approaches.
 UNIT-3

Modularity
Modularity specifies to the division of software into separate modules which are differently named and addressed
and are integrated later on in to obtain the completely functional software. It is the only property that allows a
program to be intellectually manageable. Single large programs are difficult to understand and read due to a large
number of reference variables, control paths, global variables, etc .
The desirable properties of a modular system are:
•Each module is a well-defined system that can be used with other applications.
•Each module has single specified objectives.
•Modules can be separately compiled and saved in the library.
•Modules should be easier to use than to build.
•Modules are simpler from outside than inside
 UNIT-3
Advantages and Disadvantages of Modularity
In this topic, we will discuss various advantage and disadvantage of Modularity.

Advantages of Modularity
There are several advantages of Modularity
•It allows large programs to be written by several or different people
•It encourages the creation of commonly used routines to be placed in the library and used by other programs.
•It simplifies the overlay procedure of loading a large program into main storage.
•It provides more checkpoints to measure progress.
•It provides a framework for complete testing, more accessible to test
•It produced the well designed and more readable program.
Disadvantages of Modularity
There are several disadvantages of Modularity
• Execution time maybe, but not certainly, longer
• Storage size perhaps, but is not certainly, increased
• Compilation and loading time may be longer
• Inter-module communication problems may be increased
• More linkage required, run-time may be longer, more source lines must be written, and more documentation
has to be done
+UNIT-3
Modular Design
Modular design reduces the design complexity and results in easier and faster implementation by allowing parallel
development of various parts of a system. We discuss a different section of modular design in detail in this section:

1. 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.
2. Information hiding: The fundamental of Information hiding suggests that modules can be characterized
by the design decisions that protect from the others, i.e., In other words, modules should be specified that data
include within a module is inaccessible to other modules that do not need for such information.
The use of information hiding as design criteria for modular system provides the most significant benefits when
modifications are required during testing's and later during software maintenance. This is because as most data
and procedures are hidden from other parts of the software, inadvertent errors introduced during modifications
are less likely to propagate to different locations within the software.
 Data which is passed via one function to another, and not
+UNIT-3 otherwise used by the first

Coupling: Coupling is the measure of the degree of interdependence between the modules. A good software
will have low coupling.
Best
Data Coupling
•Data Coupling: If the dependency between the modules is based on the fact
that they communicate by passing only data, then the modules are said to be
Stamp Coupling
data coupled. In data coupling, the components are independent to each other
and communicating through data. Module communications don’t contain
Control Coupling
tramp data. Example-customer billing system.
•Stamp Coupling In stamp coupling, the complete data structure is passed
from one module to another module. Therefore, it involves tramp data. It may External Coupling
be necessary due to efficiency factors- this choice made by the insightful
designer, not a lazy programmer. Common Coupling
•Control Coupling: If the modules communicate by passing control
information, then they are said to be control coupled. It can be bad if
Content Coupling
parameters indicate completely different behavior and good if parameters Worst
allow factoring and reuse of functionality. Example- sort function that takes
comparison function as an argument.
 +UNIT-3
•External Coupling: In external coupling, the modules depend on other modules, external to the software being
developed or to a particular type of hardware. Ex- protocol, external file, device format, etc.
• Common Coupling: The modules have shared data such as global data structures. The changes in global data
mean tracing back to all modules which access that data to evaluate the effect of the change. So it has got
disadvantages like difficulty in reusing modules, reduced ability to control data accesses and reduced
maintainability.
•Content Coupling: In a content coupling, one module can modify the data of another module or control flow is
passed from one module to the other module. This is the worst form of coupling and should be avoided.

Cohesion: ( With in the module)

Cohesion is a measure of the degree to which the elements of the module are functionally related. It is the
degree to which all elements directed towards performing a single task are contained in the component.
Basically, cohesion is the internal glue that keeps the module together. A good software design will have high
cohesion.
+UNIT-3 1.Functional Cohesion: Functional Cohesion is said to
exist if the different elements of a module, cooperate to
achieve a single function. And its an ideal situation
Functional Cohesion Best 2.Sequential Cohesion: A module is said to possess
sequential cohesion if the element of a module form the
Sequential Cohesion components of the sequence, where the output from one
component of the sequence is input to the next. It occurs
naturally in functional programming languages
Communicational
3.Communicational Cohesion: A module is said to have
Cohesion
communicational cohesion, if all tasks of the module refer
to or update the same data structure, e.g., the set of
Procedural Cohesion functions defined on an array or a stack. Example- update
record int the database and send it to the printer.
4.Procedural Cohesion: A module is said to be
Temporal Cohesion
procedural cohesion if the set of purpose of the module
are all parts of a procedure in which particular sequence
Logical Cohesion of steps has to be carried out for achieving a goal, e.g., the
algorithm for decoding a message.
Coincidental Cohesion Worst
 +UNIT-3
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 Binding. Cohesion is also called Intra-Module Binding.
Coupling shows the relationships between modules. Cohesion shows the relationship within the module.
Coupling shows the relative independence between the Cohesion shows the module's relative functional strength.
modules.
While creating, you should aim for low coupling, i.e., While creating you should aim for high cohesion, i.e., a
dependency among modules should be less. cohesive component/ 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 modules. In cohesion, the module focuses on a single thing.
 Design Tools

Structure Charts
Structure chart is a chart derived from Data Flow Diagram. It represents the system in more detail than DFD. It breaks down the
entire system into lowest functional modules, describes functions and sub-functions of each module of the system to a greater
detail than DFD.
Structure chart represents hierarchical structure of modules. At each layer a specific task is performed.

Symbols used in construction of structured chart

Here are the symbols used in construction of structure charts -
1.Module
It represents the process or task of the system. It is of three types.
1. Control Module
A control module branches to more than one sub module.
2. Sub Module
Sub Module is a module which is the part (Child) of another module.
3. Library Module
Library Module are reusable and invokable from any module.
Condition - It is represented by small diamond at the base of module.
It depicts that control module can select any of sub-routine based on
some condition.

Jump - An arrow is shown pointing inside the module

to depict that the control will jump in the middle of the
sub-module.

Loop - A curved arrow represents loop in the module. All

sub-modules covered by loop repeat execution of module.
 Data flow - A directed arrow with empty circle at the end
represents data flow.

Control flow - A directed arrow with filled circle at the end

represents control flow

Pseudo-Code
Pseudo code is written more close to programming language. It may be considered as augmented programming
language, full of comments and descriptions.
Pseudo code avoids variable declaration but they are written using some actual programming language’s
constructs, like C, Fortran, Pascal etc.
Pseudo code contains more programming details than Structured English. It provides a method to perform the task,
as if a computer is executing the code.
Advantages of Pseudocode
• Improves the readability of any approach. It’s one of the best approaches to start implementation of an
algorithm.
• Acts as a bridge between the program and the algorithm or flowchart. Also works as a rough
documentation, so the program of one developer can be understood easily when a pseudo code is written
out. In industries, the approach of documentation is essential. And that’s where a pseudo-code proves vital.
• The main goal of a pseudo code is to explain what exactly each line of a program should do, hence making
the code construction phase easier for the programmer.
Disadvantages of Pseudocode
• Pseudocode does not provide a visual representation of the logic of programming.
• There are no proper format for writing the for pseudocode.
• In Pseudocode their is extra need of maintain documentation.
• In Pseudocode their is no proper standard very company follow their own standard for writing the
pseudocode.
Example
Program to print Fibonacci up to n numbers.
void function Fibonacci
Get value of n;
Set value of a to 1;
Set value of b to 1;
Initialize I to 0
for (i=0; i< n; i++)
{
if a greater than b
{
Increase b by a;
Print b;
} else if b greater than a
{
increase a by b;
print a;
}
}
UNIT-3 Software Design Process

The design phase of software development deals with transforming the customer requirements as described in
the SRS documents into a form implementable using a programming language.
The software design process can be divided into the following three levels of phases of design:
1.Interface Design Analyze the
2.Architectural Design Problem
3.Detailed Design
Document

Generate the Generate the Generate the

System interface Architecture Detailed Design
Document Document Document

Evaluate the
Evaluate the Evaluate the Detailed Design
System Document Architecture Document
Document Document
Review The
design
 UNIT-3
Interface Design:
Interface design is the specification of the interaction between a system and its environment. this phase proceeds at
a high level of abstraction with respect to the inner workings of the system i.e, during interface design, the internal
of the systems are completely ignored and the system is treated as a black box. Attention is focussed on the
dialogue between the target system and the users, devices, and other systems with which it interacts. The design
problem statement produced during the problem analysis step should identify the people, other systems, and
devices which are collectively called agents.
Interface design should include the following details:
•Precise description of events in the environment, or messages from agents to which the system must respond.
•Precise description of the events or messages that the system must produce.
•Specification on the data, and the formats of the data coming into and going out of the system.
•Specification of the ordering and timing relationships between incoming events or messages, and outgoing
events or outputs.

Architectural Design:
Architectural design is the specification of the major components of a system, their responsibilities, properties, interfaces,
and the relationships and interactions between them. In architectural design, the overall structure of the system is chosen, but
the internal details of major components are ignored.
 UNIT-3
Issues in architectural design includes:
•Gross decomposition of the systems into major components.
•Allocation of functional responsibilities to components.
•Component Interfaces
•Component scaling and performance properties, resource consumption properties, reliability properties, and so
forth.
•Communication and interaction between components.
The architectural design adds important details ignored during the interface design. Design of the internals of the
major components is ignored until the last phase of the design.
Detailed Design:
Design is the specification of the internal elements of all major system components, their properties, relationships,
processing, and often their algorithms and the data structures.
The detailed design may include:
•Decomposition of major system components into program units.
•Allocation of functional responsibilities to units.
•User interfaces
•Unit states and state changes
•Data and control interaction between units
•Data packaging and implementation, including issues of scope and visibility of program elements
UNIT-3
Architectural Design

Introduction: The software needs the architectural design to represents the design of softwar
IEEE defines architectural design as “the process of defining a collection of hardware and
software components and their interfaces to establish the framework for the development of a
computer system.” The software that is built for computer-based systems can exhibit one of
these many architectural styles.

Each style will describe a system category that consists of :

•A set of components(eg: a database, computational modules) that will perform a function
required by the system.
•The set of connectors will help in coordination, communication, and cooperation between the
components.
•Conditions that how components can be integrated to form the system.
•Semantic models that help the designer to understand the overall properties of the system.
UNIT-3
Taxonomy of Architectural styles:
1.Data centred architectures:
1. A data store will reside at the center of this architecture and is accessed frequently by the other components
that update, add, delete or modify the data present within the store.
2. The figure illustrates a typical data centered style. The client software access a central repository. Variation
of this approach are used to transform the repository into a blackboard when data related to client or data of
interest for the client change the notifications to client software.
3. This data-centered architecture will promote integrability. This means that the existing components can be
changed and new client components can be added to the architecture without the permission or concern of
other clients.
4. Data can be passed among clients using blackboard mechanism.
2. Data flow architectures: This kind of architecture is used when input data to be transformed into output data
through a series of computational manipulative components.
•The figure represents pipe-and-filter architecture since it uses both pipe and filter and it has a set of
components called filters connected by pipes.
•Pipes are used to transmit data from one component to the next.
•Each filter will work independently and is designed to take data input of a certain form and produces data
output to the next filter of a specified form. The filters don’t require any knowledge of the working of
neighboring filters.
•If the data flow degenerates into a single line of transforms, then it is termed as batch sequential. This
structure accepts the batch of data and then applies a series of sequential components to transform it.
 UNIT-3 Filter Filter
Pipe

Filter Filter Filter Filter

Filter Filter Filter

Filter

3. Call and Return architectures:

•It is used to create a program that is easy to scale and modify. Many sub-styles exist within this category. Two of
them are explained below.
•Remote procedure call architecture: This components is used to present in a main program or sub program
architecture distributed among multiple computers on a network.
•Main program or Subprogram architectures: The main program structure decomposes into number of
subprograms or function into a control hierarchy. Main program contains number of subprograms that can invoke
other components.
 UNIT-3

4. Object Oriented architecture: The components of a system encapsulate data and the operations that must be
applied to manipulate the data. The coordination and communication between the components are established
via the message passing.
5.Layered architecture:
1. A number of different layers are defined with each layer performing a well-defined set of operations. Each
layer will do some operations that becomes closer to machine instruction set progressively.
2. At the outer layer, components will receive the user interface operations and at the inner layers, components
will perform the operating system interfacing(communication and coordination with OS)
3. Intermediate layers to utility services and application software functions.
 , Design Strategies:
UNIT-3 For a function-oriented design, the design can be
Function Oriented Design : represented graphically or mathematically by the
In function-oriented design, the system is comprised of many following:
smaller sub-systems known as functions. These functions are
capable of performing significant task in the system. The system
Data Flow
is considered as top view of all functions.
Diagram
Function oriented design inherits some properties of structured
design where divide and conquer methodology is used.
This design mechanism divides the whole system into smaller
functions, which provides means of abstraction by concealing the Data
information and their operation.. These functional modules can Dictionaries
share information among themselves by means of information
passing and using information available globally.
Another characteristic of functions is that when a program calls a Structured
function, the function changes the state of the program, which Charts
sometimes is not acceptable by other modules. Function oriented
design works well where the system state does not matter and
program/functions work on input rather than on a state.
Pseudocode
UNIT-3
Object-Oriented Design
In the object-oriented design method, the system is viewed as a collection of objects (i.e., entities). The state is
distributed among the objects, and each object handles its state data. For example, in a Library Automation
Software, each library representative may be a separate object with its data and functions to operate on these
data. The tasks defined for one purpose cannot refer or change data of other objects. Objects have their
internal data which represent their state. Similar objects create a class. In other words, each object is a member
of some class. Classes may inherit features from the superclass.

The different terms related to object design are:

Objects Classes Messages Abstraction

Encapsulation Inheritance
Polymorphism
 UNIT-3
1.Objects: All entities involved in the solution design are known as objects. For example, person, banks, company, and
users are considered as objects. Every entity has some attributes associated with it and has some methods to perform on
the attributes.
2.Classes: A class is a generalized description of an object. An object is an instance of a class. A class defines all the
attributes, which an object can have and methods, which represents the functionality of the object.
3.Messages: Objects communicate by message passing. Messages consist of the integrity of the target object, the name of
the requested operation, and any other action needed to perform the function. Messages are often implemented as
procedure or function calls.
4.Abstraction In object-oriented design, complexity is handled using abstraction. Abstraction is the removal of the
irrelevant and the amplification of the essentials.
5.Encapsulation: Encapsulation is also called an information hiding concept. The data and operations are linked to a
single unit. Encapsulation not only bundles essential information of an object together but also restricts access to the data
and methods from the outside world.
6.Inheritance: OOD allows similar classes to stack up in a hierarchical manner where the lower or sub-classes can
import, implement, and re-use allowed variables and functions from their immediate superclasses.This property of OOD is
called an inheritance. This makes it easier to define a specific class and to create generalized classes from specific ones.
7.Polymorphism: OOD languages provide a mechanism where methods performing similar tasks but vary in arguments,
can be assigned the same name. This is known as polymorphism, which allows a single interface is performing functions
for different types. Depending upon how the service is invoked, the respective portion of the code gets executed.
UNIT-3

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:
1. Breaking problems into parts help us to identify what needs to be done.
2. At each step of refinement, new parts will become less complex and therefore easier to solve.
3. Parts of the solution may turn out to be reusable.
4. Breaking problems into parts allows more than one person to solve the problem.

Disadvantages:
1. Project and system boundaries tends to be application specification-oriented. Thus it is more likely that
advantages of component reuse will be missed.
2. The system is likely to miss, the benefits of a well-structured, simple architecture.
UNIT-3
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:
1. Make decisions about reusable low-level utilities then decide how there will be put together to create
high-level construct. ,
2. The contrast between Top-down design and bottom-up design.

Disadvantages:
1. It is not so closely related to the structure of the problem.
2. High quality bottom-up solutions are very hard to construct.
3. It leads to proliferation of ‘potentially useful’ functions rather than most appropriate ones.
 UNIT-3

S.No Top Down Approach Bottom Up Approach

In this approach We focus on breaking up the problem In bottom up approach, we solve smaller problems and integrate
1.
into smaller parts. it as whole and complete the solution.
Mainly used by structured programming language such Mainly used by object oriented programming language such as
2.
as COBOL, Fortran, C, etc. C++, C#, Python.
Each part is programmed separately therefore contain Redundancy is minimized by using data encapsulation and data
3.
redundancy. hiding.

4. In this the communications is less among modules. In this module must have communication.

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

6. In top down approach, decomposition takes place. In bottom up approach composition takes place.

In this sometimes we can not build a program from the piece we

7. In this top function of system might be hard to identify.
have started.
8. In this implementation details may differ. This is not natural for people to assemble.
 Software Measurement and Metrics
UNIT-3
Software Measurement: A measurement is an demonstration of the size, quantity, amount or dimension of a
particular attributes 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. Software measurement
process is defined and governed by ISO Standard.
Need of Software Measurement:
Software is measured to:
1.Create the quality of the current product or process.
2.Anticipate future qualities of the product or process.
3.Enhance the quality of a product or process.
4.Regulate the state of the project in relation to budget and schedule.

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 standard scale.
2.Indirect Measurement:
In indirect measurement the quantity or quality to be measured is measured using related parameter i.e. by use of
reference.
UNIT-3
Direct Measurement
These are the measurements that can be measured without the involvement of any other entity or attribute.
The following direct measures are commonly used in software engineering.
•Length of source code by LOC
•Duration of testing purpose by elapsed time
•Number of defects discovered during the testing process by counting defects
•The time a programmer spends on a program
UNIT-3 Software Metrics

Software metrics can be defined as “The continuous application of measurement based

techniques to the software development process and its products to supply meaningful and
timely management information, together with the use of those techniques to improve that
process and its products”.

A software metric is a measure of software characteristics which are measurable or countable.

Software metrics are valuable for many reasons, including measuring software performance,
planning work items, measuring productivity, and many other uses.
Within the software development process, many metrics are that are all connected. Software
metrics are similar to the four functions of management:
1. Planning
2. Organization
3. Control
4. Improvement.
UNIT-3

Characteristics of software Metrics:

1. Quantitative:
Metrics must possess quantitative nature. It means metrics can be expressed in values.
2. Understandable:
Metric computation should be easily understood ,the method of computing metric should be
clearly defined.
3. Applicability:
Metrics should be applicable in the initial phases of development of the software.
4. Repeatable:
The metric values should be same when measured repeatedly and consistent in nature.
5. Economical:
Computation of metric should be economical.
6. Language Independent:
Metrics should not depend on any programming language.
UNIT-3
Classification of Software Metrics: 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 undercovering prospective
Product Metrics Process Metrics Project Metrics
problem areas. The ability of team to control quality is
evaluated.
describe the characteristics of the product such as size,
complexity, design features, performance, efficiency,
reliability, portability, etc
2. Process Metrics:
Process metrics pay particular attention on enhancing the long term process of the team or
organisation.
describe the effectiveness and quality of the processes that produce the software product. Examples are:
• effort required in the process
• time to produce the product
• effectiveness of defect removal during development
• number of defects found during testing
• maturity of the process
UNIT-3 3. Project metrics:
describe the project characteristics and execution. Examples are :
• number of software developers
• staffing pattern over the life cycle of the software
• cost and schedule
• productivity

Types of Metrics

Internal metrics: Internal metrics are the metrics used for measuring properties that are viewed to be of
greater importance to a software developer. For example, Lines of Code (LOC) measure.
External metrics: External metrics are the metrics used for measuring properties that are viewed to be of
greater importance to the user, e.g., portability, reliability, functionality, usability, etc.
Hybrid metrics: Hybrid metrics are the metrics that combine product, process, and resource metrics. For
example, cost per FP where FP stands for Function Point Metric.
Project metrics: Project metrics are the metrics used by the project manager to check the project's
progress. Data from the past projects are used to collect various metrics, like time and cost; these estimates
are used as a base of new software
UNIT-3
Advantage of Software Metrics
Comparative study of various design methodology of software systems.
For analysis, comparison, and critical study of different programming language concerning their
characteristics.
1. In comparing and evaluating the capabilities and productivity of people involved in software
development.
2. In the preparation of software quality specifications.
3. In the verification of compliance of software systems requirements and specifications.
4. In making inference about the effort to be put in the design and development of the software systems.
5. In getting an idea about the complexity of the code.
6. In taking decisions regarding further division of a complex module is to be done or not.
7. In guiding resource manager for their proper utilization.
8. In comparison and making design tradeoffs between software development and maintenance cost.
9. In providing feedback to software managers about the progress and quality during various phases of the
software development life cycle.
10.In the allocation of testing resources for testing the code.
UNIT-3

Disadvantage of Software Metrics

1.The application of software metrics is not always easy, and in some cases, it is difficult and costly.
2.The verification and justification of software metrics are based on historical/empirical data whose validity is
difficult to verify.
3.These are useful for managing software products but not for evaluating the performance of the technical
staff.
4.The definition and derivation of Software metrics are usually based on assuming which are not standardized
and may depend upon tools available and working environment.
5.Most of the predictive models rely on estimates of certain variables which are often not known precisely.
UNIT-3
Size-Oriented Metrics

Size Oriented Metrics derived by normalizing quality and productivity Point Metrics measures by considering
size of the software that has been produced. The organization builds a simple record of size measure for the
software projects. It is built on past experiences of organizations. It is a direct measure of software.
This metrics is one of simplest and earliest metrics that is used for computer program to measure size. Size
Oriented Metrics are also used for measuring and comparing productivity of programmers. It is a direct measure
of a Software. The size measurement is based on lines of code computation. The lines of code are defined as one
line of text in a source file.

While counting lines of code, simplest standard is:

•Don’t count blank lines
•Don’t count comments
•Count everything else
•The size-oriented measure is not a universally accepted method.
 UNIT-3
Simple set of size measure that can be developed is as given below:
• Size = Kilo Lines of Code (KLOC)
• Effort = Person / month
• Productivity = KLOC / person-month
• Quality = Number of faults / KLOC
• Cost = $ / KLOC
• Documentation = Pages of documentation / KLOC
Example –
For a size oriented metrics, software organization maintains records in tabular form. The typical table entries are:
Project Name, LOC, Efforts, Pages of documents, Errors, Defects, Total number of people working on it .

Doc.
Project Name LOC Effort Cost ($) Errors Defects People
(pages)
ABC 12 100 24 168 365 134 29 3

PQR 20, 000 60 300 1000 129 32 6

XYZ 20,200 43 314 1050 256 64 9

……..
UNIT-3
In order to develop metrics that can be assimilated with similar metrics from other projects , we
consider LOC ( Line of Code) as our normalization value .

LOC Metrics
It is one of the earliest and simpler metrics for calculating the size of the computer program. It is generally used
in calculating and comparing the productivity of programmers. These metrics are derived by normalizing the
quality and productivity measures by considering the size of the product as a metric.

Following are the points regarding LOC measures:

1. In size-oriented metrics, LOC is considered to be the normalization value.
2. It is an older method that was developed when FORTRAN and COBOL programming were very popular.
3. Productivity is defined as KLOC / EFFORT, where effort is measured in person-months.
4. Size-oriented metrics depend on the programming language used.
5. As productivity depends on KLOC, so assembly language code will have more productivity.
6. LOC measure requires a level of detail which may not be practically achievable.
7. The more expressive is the programming language, the lower is the productivity.
8. 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.
9. It requires that all organizations must use the same method for counting LOC. This is so because some organizations
use only executable statements, some useful comments, and some do not. Thus, the standard needs to be established.
10. These metrics are not universally accepted.
UNIT-3 Based on the LOC/KLOC count of software, many other metrics can be computed:
1.Errors/KLOC.
2.$/ KLOC.
3.Defects/KLOC.
4.Pages of documentation/KLOC.
5.Errors/PM.
6.Productivity = KLOC/PM (effort is measured in person-months).
7.$/ Page of documentation.

Advantages :
• Using these metrics, it is very simple to measure size.
• Artifact of Software development which is easily counted.
• LOC is used by many methods that are already existing as a key input.
• A large body of literature and data based on LOC already exists.
Disadvantages :
• This measure is dependent upon programming language.
• This method is well designed upon programming language.
• It does not accommodate non-procedural languages.
• Sometimes, it is very difficult to estimate LOC in early stage of development.
• Though it is simple to measure but it is very hard to understand it for users.
• It cannot measure size of specification as it is defined on code.
UNIT-3

Halstead's Software Metrics

According to Halstead's "A computer program is an implementation of an algorithm considered to be a
collection of tokens which can be classified as either operators or operand."

Token Count
In these metrics, a computer program is considered to be a collection of tokens, which may be classified as
either operators or operands. All software science metrics can be defined in terms of these basic symbols. These
symbols are called as a token.
The basic measures are
n1 = Count of unique operators
n2 = Count of unique operands
N1 = Count of total occurrences of operators
N2 = Count of total occurrence of operands

In terms of the total tokens used, the size of the program can be expressed as N = N1 + N2.
UNIT-3 Halstead metrics are:
Program Volume (V)
The unit of measurement of volume is the standard unit for
size "bits." It is the actual size of a program if a uniform
binary encoding for the vocabulary is used.
V=N*log2n
Program Level (L)
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).
L=V*/V
Program Difficulty
The difficulty level or error-proneness (D) of the program
is proportional to the number of the unique operator in the
program.
D= (n1/2) * (N2/n2)
Programming Effort (E)
The unit of measurement of E is elementary mental
discriminations.
E=V/L=D*V
UNIT-3
Estimated Program Length
According to Halstead, The first Hypothesis of software science is that the length of a well-
structured program is a function only of the number of unique operators and operands.
N=N1+N2
And estimated program length is denoted by N^
N^ = n1log2n1 + n2log2n2
Potential Minimum Volume
The potential minimum volume V* is defined as the volume of
Size of Vocabulary (n)
the most short program in which a problem can be coded.
The size of the vocabulary of a program,
V* = (2 + n2*) * log2 (2 + n2*)
which consists of the number of unique
Here, n2* is the count of unique input and output parameters
tokens used to build a program, is defined
as:
n=n1+n2 Language Level - Shows the algorithm implementation
where program language level. The same algorithm demands
n=vocabulary of a program additional effort if it is written in a low-level program
n1=number of unique operators language. For example, it is easier to program in Pascal
n2=number of unique operands than in Assembler.
L' = V / D / D
lambda = L * V* = L2 * V
UNIT-3

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 as 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, sizeof, etc., are considered as operators.
10. All the brackets, commas, and terminators are considered as operators.
11. GOTO is counted as an operator, and the label is counted as an operand.
12. The unary and binary occurrence of "+" and "-" are dealt with separately. Similarly "*" (multiplication operator) are dealt
separately.
13. In the structure variables such as "struct-name, member-name" or "struct-name -> member-name," struct-name, member-
name are considered as operands and '.', '->' are taken as operators. Some names of member elements in different structure
variables are counted as unique operands.
14. All the hash directive is ignored.
UNIT-3
Example: Consider the sorting program as shown in fig: List out the operators and operands and also calculate
the value of software science measure like n, N, V, E, λ ,etc.
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
UNIT-3

Here N1=53 and N2=38. The program length N=N1+N253+38=91

Vocabulary of the program n=n1+n214+10=24
Volume V= N * log2N=91 * log2 24=417 bits.
The estimate program length N of the program
= 14 log214+10 log2)10
= 14 * 3.81+10 * 3.32
= 53.34+33.2=86.45
Conceptually unique input and output parameters are represented by n2*.
n2*=3 {x: array holding the integer to be sorted. This is used as both input and output}
{N: the size of the array to be sorted}
The Potential Volume V*=5log25=11.6
+ UNIT-3
Since L=V*/V

We may the another formula

V^=V x L^= 417 x 0.038=15.67
E^=V/L^=D^ x V

Therefore, 10974 elementary mental discrimination is

required to construct the program.
 + UNIT-3 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.
+ UNIT-3

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.

+ UNIT-3 The FPA functional units are shown in Fig:
User

Inquiries

ILF Other applications

Input EIF
User System
Output IFL : Internal Logical Files
EIF : External Logical Files

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.
 + UNIT-3
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.
 Software Project Planning
Table 2: UFP calculation table
Functional Count Complexity Functional
Units Complexity Totals Unit Totals
External Low x 3 =
Inputs Average x 4 =
(EIs) High x 6 =
External Low x 4 =
Outputs Average x 5 =
(EOs) High x 7 =
External Low x 3 =
Inquiries Average x 4 =
(EQs) High x 6 =
External Low x 7 =
logical Average x 10 =
Files (ILFs) High x 15 =
External Low x 5 =
Interface Average x 7 =
Files (EIFs) High x 10 =

Total Unadjusted Function Point Count

+ UNIT-3

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
+ UNIT-3

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

1.Errors/FP
2.$/FP.
3.Defects/FP
4.Pages of documentation/FP
5.Errors/PM.
6.Productivity = FP/PM (effort is measured in person-months).
7.$/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.
+ UNIT-3

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:
a) 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.
b) The score of all 14 GSCs is totaled to determine Total Degree of Influence (TDI).
c) 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
 Software Project Planning
Table 3 : Computing function points.
Rate each factor on a scale of 0 to 5.
0 1 2 3 4 5

No Incidental Moderate Average Significant Essential

Influence
Number of factors considered ( Fi )
1. Does the system require reliable backup and recovery ?
2. Is data communication required ?
3. Are there distributed processing functions ?
4. Is performance critical ?
5. Will the system run in an existing heavily utilized operational environment ?
6. Does the system require on line data entry ?
7. Does the on line data entry require the input transaction to be built over multiple screens or
operations ?
8. Are the master files updated on line ?
9. Is the inputs, outputs, files, or inquiries complex ?
10. Is the internal processing complex ?
11. Is the code designed to be reusable ?
12. Are conversion and installation included in the design ?
13. Is the system designed for multiple installations in different organizations ?
14. Is the application designed to facilitate change and ease of use by the user ?
59
 + UNIT-3
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) 2 * 5 = 10
Count-total → 378
+ UNIT-3
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
Differentiate between FP and LOC

FP LOC
Total pages of documentation =
technical document + user document 1. FP is specification based. 1. LOC is an analogy based.
= 265 + 122 = 387pages 2. FP is language independent. 2. LOC is language dependent.
3. FP is user-oriented. 3. LOC is design-oriented.
Documentation = Pages of documentation/FP
= 387/408 = 0.94 4. It is extendible to LOC. 4. It is convertible to FP
(backfiring)
 + UNIT-3 Cyclomatic Complexity

Cyclomatic complexity is a software metric used to measure the complexity of a program. Thomas J. McCabe
developed this metric in 1976.McCabe interprets a computer program as a set of a strongly connected directed graph.
Nodes represent parts of the source code having no branches and arcs represent possible control flow transfers
during program execution. The notion of program graph has been used for this measure, and it is used to measure
and control the number of paths through a program.

How to Calculate Cyclomatic Complexity?

McCabe proposed the cyclomatic number, V (G) of graph theory as an indicator of software complexity. The
cyclomatic number is equal to the number of linearly independent paths through a program in its graphs
representation. For a program control graph G, cyclomatic number, V (G), is given as:
V (G) = E - N + 2 * P
E = The number of edges in graphs G
N = The number of nodes in graphs G
P = The number of connected components in graph G.
+ UNIT-3
A=10
Example :
No Yes
IF A = 10 THEN B>C
IF B > C THEN
A= B
A=C A=B
ELSE
A=C
ENDIF
ENDIF
Print A ENDIF
Print B
Print C
ENDIF
The Cyclomatic complexity is calculated using the above
control flow diagram that shows
seven nodes(shapes G) and PRINT A,B,C
eight edges (lines E),
hence the cyclomatic complexity is
8-7+2=3
+ UNIT-3

Properties of Cyclomatic complexity:

Following are the properties of Cyclomatic complexity:
1. V (G) is the maximum number of independent paths in the
graph
2. V (G) >=1
3. G will have one path if V (G) = 1
4. Minimize complexity to 10

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 have been tested at least once.
• Thus help to focus more on uncovered paths.
• Code coverage can be improved.
• Risk associated with program can be evaluated.
• These metrics being used earlier in the program helps in reducing the risks.
 + UNIT-3

Advantages of Cyclomatic Complexity:.

• It can be used as a quality metric, gives relative complexity of various designs.
• It is able to compute faster than the 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 programs’s control complexity and not the data the data complexity.
• In this, nested conditional structures are harder to understand than non-nested structures.
• In case of simple comparisons and decision strucures, it may give a misleading figure.
+ UNIT-3

Case Tools For Software Metrics

Many CASE tools (Computer Aided Software Engineering tools) exist for measuring software. They
are either open source or are paid tools. Some of them are listed below:
1.Analyst4j tool is based on the Eclipse platform and available as a stand-alone Rich Client
Application or as an Eclipse IDE plug-in. It features search, metrics, analyzing quality, and report
generation for Java programs.
2.CCCC is an open source command-line tool. It analyzes C++ and Java lines and generates reports
on various metrics, including Lines of Code and metrics proposed by Chidamber & Kemerer and Henry
& Kafura.
3.Chidamber & Kemerer Java Metrics is an open source command-line tool. It calculates the C&K
object-oriented metrics by processing the byte-code of compiled Java.
+ UNIT-3

4. Dependency Finder is an open source. It is a suite of tools for analyzing compiled Java code.
Its core is a dependency analysis application that extracts dependency graphs and mines them
for useful information. This application comes as a command-line tool, a Swing-based
application, and a web application.
5. Eclipse Metrics Plug-in 1.3.6 by Frank Sauer is an open source metrics calculation and
dependency analyzer plugin for the Eclipse IDE. It measures various metrics and detects
cycles in package and type dependencies.
6. Eclipse Metrics Plug-in 3.4 by Lance Walton is open source. It calculates various metrics
during build cycles and warns, via the problems view, of metrics 'range violations'.
7. OOMeter is an experimental software metrics tool developed by Alghamdi. It accepts
Java/C# source code and UML models in XMI and calculates various metrics.
8. Semmle is an Eclipse plug-in. It provides an SQL like querying language for object-oriented
code, which allows searching for bugs, measure code metrics, etc.
+ UNIT-3 Control Flow Graph (CFG)

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.
+ UNIT-3
General Control Flow Graphs:
Control Flow Graph is represented differently for all
statements and loops. Following images describe it:

3. do-
while:

1. If-else:

2. while:

4. for:
+ UNIT-3
Flowchart of above example will be: Control Flow Graph of above example will be:

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