Software Engineering

Unit 3
 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.
• 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.
 Software Design Concepts

• The software design concept simply means the idea or principle behind
the design.
• 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 here.
Software Design Concepts: Abstraction-
HIDE DETAILS
• 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.
Software Design Concepts: 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.
Software Design Concepts: 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.
Software Design Concepts: 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 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.
Software Design Concepts: 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.
Software Design Concepts: 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
can't be accessed by any other modules.
Software Design Concepts: 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 the 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”.
 Levels of Software Design
• Architectural Design
• Preliminary or high-level design
• Detailed design
Levels of Software Design: 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.
Levels of Software Design: 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.
Levels of Software Design: Detailed Design

• Once the high-level design is complete, 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.
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.
 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.
 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.
• Good design requirement –
• Modules should loosely coupled. i.e. should kept as independent as possible.
Types of Coupling
Data Coupling
• Occurs when module passes non-global variable to another module.
• Two independent Modules can only communicate through passing data
elements example Customer billing System
Stamp Coupling

• Occurs when module passes non-global data structure or entire

structure to another module.
• Here, modules are more dependent on each other.
• Exposes modules to more data than they need.
• A change in data structure will affect all modules that use it.
• For example, passing structure variable in C or object in C++ language
to a module.
Control Coupling
• Occurs when module passes control flags or switches to another
modules.
• Data from one module is used to direct the order of instructions
executed in another.
• The sending module must know a great deal of about the inner
workings of the receiving module.
• Example of control coupling is a flag set in one module and tested in
another module.
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
• Occurs when modules refer to the same global data area or data
structure
• Modules that use the same area have quite high level of
interdependence.
• This is undesirable as errors can spread throughout the system.
Content Coupling
• Occurs when one module directly refer to the inner workings of
another module.
• Modules are highly interdependent to each other.
• One module can alter data in other module or change a statement
coded in other module.
Cohesion
• Cohesion is the measure of strength of the association of elements within a
module
• In other words, the extent to which all instructions in a module relate to a single
function.
• In a truly cohesive module, all of the instructions in the module pertain to
performing a single task.
• Cohesion in modules should be maximized.
Types of Cohesion
Functional cohesion
• The name of the module will indicate its function
• All statements within a module are based on one function.
• It is the best cohesion
• Functions like "compute square root" and "sort the array" are clear examples of functionally cohesive
modules.
• Ex- CALCULATE_SALES_TAX
IF PRODUCT IS SALES_TAX EXEMPT THEN
SALES_TAX = 0
ELSE
IF PRODUCT_PRICE <100 THEN
SALES_TAX = PRODUCT_PRICE * 0.25
ENDIF
ENDIF
 Sequential Cohesion
• The instruction inside a module are related to each other thorough the input
data.
• The output from first instruction becomes input to the second and so on.
• Sequence of events is very important.
Ex – TOTAL_PURCHASES =0
READ NO_OF_PURCHASES
DO LOOP_INDEX = 1 TO NO_OF_PURCHASES
GET PURCHASES
ADD PURCHASES TO TOTAL_PURCHASES
ENDDO
SALES_TAX = TOTAL_PURCHASES * SALES_TAX_PERCENTAGES
AMT_DUE = TOTAL_PURCHASES + SALES_TAX
END
 Communicational
Cohesion
• The activities are related to each other by the data that the modules uses.
• A module with communicational cohesion has elements that are related by a reference to the same
input or output data.
• That is, in a communicational bound module, the elements are together because they operate on the
same input or output data.
• Sequence is not important
 Procedural Cohesion
• A procedurally cohesive module contains elements that belong to a common procedural unit.
• For example, a loop or a sequence of decision statements in a module may be combined to form a
separate module.
• Procedurally cohesive modules often occur when modular structure is determined from some form
of flowchart.
• Procedural cohesion often cuts across functional hues.
• A module with only procedural cohesion may contain only part of a complete function or parts of
several functions.
Ex- READ_STUD_REC _AND_TOTAL_STUDENT _AGES
NO_OF_REC = 0
TOTAL_AGE = 0
READ STUD_REC
DO WHILE MORE_REC_EXIST
ADD AGE TO TOTAL_AGE
ADD 1 TO NO_OF_REC
READ STUD_REC
ENDDO
END
 Temporal Cohesion
• Modules that perform activities like "initialization," "clean-up," and "termination" are
usually temporally bound.
• Even though the elements in a temporally bound module are logically related, temporal
cohesion is higher than logical cohesion, because the elements are all executed together.
• This avoids the problem of passing the flag, and the code is usually simpler.
• – INITIALIZATION
OPEN TRANS_FILE
ISSUE PROMPT ‘ENTER DATE – DDMMYY’
READ TODAYS_DATE
SET TRANS_COUNT TO 0
SET REPORT_TOTAL TO 0
OPEN REPORT_FILE
END
 Logical Cohesion
• The instructions are hardly related to each other at all
• The instructions are grouped together due to certain classes or activities.
• A flag that is passed from outside will determine which set of instructions is to be executed.
Ex – READ_ALL_FILES
CASE OF FILE_CODE
1: READ CUST_TRAN_REC
IF NOT EOF
INCREMENT CUST_TRAN_COUNT
ENDIF
2: READ CUST_MASTER_REC
IF NOT EOF
INCREMENT CUST_MASTER_COUNT
ENDIF
END CASE
END
Coincidental Cohesion
• The instructions have no relationship to each other at all, it is just a coincidence they fall in the same
module.
• It is the worst type of cohesion.
Ex- FILE PROCESSING
OPEN EMPLOYEE_UPDATE FILE
READ EMPLOYEE REC
PRINT_PAGE_HEADING
OPEN MASTER FILE(EMPLOYEE)
SET PAGE_COUNT TO 1
SET ERR_FLAG TO FLASE
END
 Difference between Coupling and
Cohesion
COHESION COUPLING
Cohesion is the concept of intra module. Coupling is the concept of inter module.

Cohesion represents the relationship within Coupling represents the relationships

module. between modules.
Increasing in coupling is avoided for
Increasing in cohesion is good for software. software.
Cohesion represents the functional strength Coupling represents the independence
of modules. among modules.
Whereas loosely coupling gives the best
Highly cohesive gives the best software. software.
In cohesion, module focuses on the single In coupling, modules are connected to the
thing. other modules.
 Software Design
Strategies
• A good system design is to organize the program modules in such a way that are
easy to develop and change.
• Structured design techniques help developers to deal with the size and complexity
of programs.
• Analysts create instructions for the developers about how code should be written
and how pieces of code should fit together to form a program.
• Importance :
1.If any pre-existing code needs to be understood, organized and pieced together.
2.It is common for the project team to have to write some code and produce original
programs that support the application logic of the system.

There are mainly two strategies used

• Top-down design
• Bottom-up design
 Top-down Design (Function
Oriented Design)
• A top-down approach starts by identifying the major components of the
system, decomposing them into their lower-level components and iterating
until the desired level of detail is achieved.
• It is a stepwise refinement method.
• Starting from an abstract design, in each step the design is refined to a more
concrete level, until we reach a level where no more refinement is needed.
• Suitable only if the requirements are clearly known and the system
development is from the scratch.
• It is a reasonable approach if a waterfall type of process model is being used.
Top-down Design (Function
Oriented Design)
• Advantages:
1. The main advantage of top down approach is that its strong focus on requirements helps to
make a design responsive according to its requirements.
• 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.
Bottom-up Design (Object
Oriented Design)
• A bottom-up approach starts with the lowest level component of the
hierarchy and proceeds through progressively higher levels to the top level
component.
• Starts with the most basic or primitive components and proceeds to higher
level components that uses these lower level components.
• The amount of abstraction grows high as the design moves to
more high levels.
• If a system is to be built from an existing system , a bottom-up approach is
more suitable, as it starts with some existing components.
• If an iterative enhancement type of process is being followed, in later
iterations, the bottom-up approach could be more suitable.
Bottom-up Design (Object
Oriented Design)
• Advantages:
1. The economics can result when general solutions can be reused.
2. It can be used to hide the low-level details of implementation and be
merged with top-down technique.
• 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.
 Design Notifications and Specifications

• Design notations are used to represent design or design decisions.

• They are meant largely for designer so that he can quickly represent his
decision in a compact manner that he can evaluate and modify.
• The notations are frequently graphical.
• To specify the design, specification languages are used.
• Generally design specification uses textual structure
• Helps developers to implement the design in a easy manner.
Structure Chart
• Structure Chart represent 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 call 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.
Structure Chart
• Symbols used in construction of structured chart
1.Module
It represents the process or task of the system. It is of three types.
i. Control Module
A control module branches to more than one sub module.
ii. Sub Module
Sub Module is a module which is the part (Child) of another module.
iii. Library Module
Library Module are reusable and invokable from any module.
Structure Chart
2. Conditional Call
It represents that control module can select any of the sub module on the basis of some condition.
Structure Chart
3. Loop (Repetitive call of module)
It represents the repetitive execution of module. A curved arrow represents loop in the module.
Structure Chart
4. Data Flow
It represents the flow of data between the modules. It is represented by directed arrow with empty
circle at the end.
Structure Chart
5. Control Flow
It represents the flow of control between the modules. It is represented by
directed arrow with filled circle at the end.
Structure Chart
• Physical Storage
Physical Storage is that where all the information are to be stored.
Flowchart
• Flowchart is a graphical representation of an algorithm.
• Programmers often use it as a program-planning tool to solve a problem.
• It makes use of symbols which are connected among them to indicate the flow
of information and processing.
• The process of drawing a flowchart for an algorithm is known as
“flowcharting”.
Basic Symbols used in Flowchart
Designs
1.Terminal: The oval symbol indicates Start, Stop and Halt in a program’s logic
flow. A pause/halt is generally used in a program logic under some error
conditions. Terminal is the first and last symbols in the flowchart.

2. Input/Output: A parallelogram denotes any function of input/output type. Program

instructions that take input from input devices and display output on output devices are
indicated with parallelogram in a flowchart.
Basic Symbols used in Flowchart
Designs
3. Processing: A box represents arithmetic instructions. All arithmetic
processes such as adding, subtracting, multiplication and division are indicated
by action or process symbol.

4. Decision Diamond symbol represents a decision point. Decision based

operations such as yes/no question or true/false are indicated by diamond in
flowchart.
Basic Symbols used in Flowchart
Designs
5. Connectors: Whenever flowchart becomes complex or it spreads over more
than one page, it is useful to use connectors to avoid any confusions. It is
represented by a circle.

6. Flow lines: Flow lines indicate the exact sequence in which instructions are
executed. Arrows represent the direction of flow of control and relationship
among different symbols of flowchart.
Flowchart: Benefits
• Logic understanding
• Effective analysis
• Useful in coding
• Proper testing and debugging
• Appropriate documentation
Flowchart: Limitations
1. Complex
2. Costly
3. Difficult to modify
4. No update
Pseudo Code
• Pseudo code is a term which is often used in programming and algorithm-based
fields.
• It is a methodology that allows the programmer to represent the implementation
of an algorithm.
• It is the cooked-up representation of an algorithm.
• Often at times, algorithms are represented with the help of pseudo codes as they
can be interpreted by programmers no matter what their programming
background or knowledge is.
• It’s simply an implementation of an algorithm in the form of annotations and
informative text written in plain English. It has no syntax like any of the
programming language and thus can’t be compiled or interpreted by the
computer.
Pseudo 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.
Pseudo Code
Function Oriented Design
• The design process for software systems often has two levels. At the first level the focus is on
deciding which modules are needed for the system based on SRS (Software Requirement
Specification) and how the modules should be interconnected.
• Function Oriented Design is an approach to software design where the design is decomposed
into a set of interacting units where each unit has a clearly defined function.
• Generic Procedure: Start with a high-level description of what the software / program does.
Refine each part of the description one by one by specifying in greater details the functionality of
each part. These points lead to Top-Down Structure.
Function Oriented Design Strategies
1. Data Flow Diagram (DFD):
A data flow diagram (DFD) maps out the flow of information for any process or system. It uses
defined symbols like rectangles, circles and arrows, plus short text labels, to show data inputs,
outputs, storage points and the routes between each destination.
2. Data Dictionaries:
Data dictionaries are simply repositories to store information about all data items defined in
DFDs. At the requirement stage, data dictionaries contains data items. Data dictionaries include
Name of the item, Aliases (Other names for items), Description / purpose, Related data items,
Range of values, Data structure definition / form.
3. Structure Charts:
It is the hierarchical representation of system which partitions the system into black boxes
(functionality is known to users but inner details are unknown). 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.
4. Pseudo Code:
Pseudo Code is system description in short English like phrases describing the function. It use
keyword and indentation. Pseudo codes are used as replacement for flow charts. It decreases the
amount of documentation required.
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.
Object Oriented Design
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.
Object Oriented Design
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 super classes. 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.
 FUNCTIONAL PROGRAMMING OBJECT ORIENTED PROGRAMMING
This programming paradigm is based on object oriented
This programming paradigm emphasizes on the use of
concept. Classes are used where instance of objects are
functions where each function performs a specific task.
created
Fundamental elements used are variables and functions.
Fundamental elements used are objects and methods and
The data in the functions are immutable(cannot be
the data used here are mutable data.
changed after creation).
Importance is not given to data but to functions. Importance is given to data rather than procedures.
The statements in this programming paradigm does not The statements in this programming paradigm need to
need to follow a particular order while execution. follow a order i.e., bottom up approach while execution.
Has three access specifiers namely, Public, Private and
Does not have any access specifier.
Protected.
To add new data and functions is not so easy. Provides and easy way to add new data and functions.
Provides data hiding. Hence, secured programs are
No data hiding is possible. Hence, Security is limited.
possible.
Measurement and Metrics
• A measurement is a manifestation of the size, quantity, amount or
dimension of a particular attributes of a product or process.
• 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.
 Software Metrics
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.
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.
Classification of Software
Metrics
• There are 2 types of software metrics:
1. Product Metrics:
Product metrics are used to evaluate the state of the product, tracing risks and undercovering
prospective problem areas. The ability of team to control quality is evaluated. Size, Reliability,
Complexity etc
2. Process Metrics:
Process metrics pay particular attention on enhancing the long-term process of the team or
organization. Productivity, Quality, Efficiency etc.
Lines of Code (LOC)
• LOC is possibly the simplest among all metrics available to measure project size. Consequently,
this metric is extremely popular.
• This metric measures the size of a project by counting the number of source instructions in the
developed program.
• Obviously, while counting the number of source instructions, comment lines, and header lines
are ignored.
• Determining the LOC count at the end of a project is very simple.
• However, accurate estimation of LOC count at the beginning of a project is a very difficult task.
One can possibly estimate the LOC count at the starting of a project, only by using some form of
systematic guess work.
• Systematic guessing typically involves the following. The project manager divides the problem
into modules, and each module into sub-modules and so on, until the LOC of the leaf-level
modules are small enough to be predicted.
LOC: Disadvantages
• LOC is a measure of coding activity alone: A problem size measure should
consider the total effort of various life cycle activities (i.e. specification, design, code
and test etc.) However LOC completely focus on the coding activity alone. Sometimes,
for a small code, design and testing issues are complex.
• LOC count depends on the choice of specific instructions: Due to different
coding styles of programmers (e.g. one instruction may be written in multiple lines or
multiple instructions written in one line), It is difficult get accurate LOC. If we count the
language token even in this case, programmers can choose the different tokens for
instructions e.g. one can choose the if..else.. And another can do with switch etc.
• LOC measure correlates poorly with the quality and efficiency of the code: The
quality of code does not depend upon number of lines in code
• LOC metric penalizes use of higher-level programming languages and code
reuse: Effort cannot be measured by managers on Line of code because if programmer
choose object oriented approach which encourage reuse of components
LOC: Disadvantages
• LOC metric does not address the more important issues of logical and
structural complexities: The efforts of two programs cannot be same based on Lines
of Code. Because one program may use multiple loops while other is using sequence of
instructions.
• It is very difficult to accurately estimate LOC of the final program from
problem specification: This is not useful for project planning because it is difficult to
predict number of lines before development
 Function Point Metric
• Function point metric was proposed by Albrecht.
• This metric overcomes many of the shortcomings of the LOC metric. Since its
inception in late 1970s, function point metric has steadily gained popularity.
• One of the important advantages of the function point metric over the LOC
metric is that it can easily be computed from the problem specification
itself.
• The conceptual idea behind the function point metric is the following. The
size of a software product is directly dependent on the number of
different high-level functions or features it supports.
• Efforts needed to develop are considered by the function point metric by
counting the number of input and output data items and the number of files
accessed by the function.
• The implicit assumption made is that the more the number of data items
that a function reads from the user and outputs and the more the number of
files accessed, the higher is the complexity of the function.
Function Point Metric
• The computation of the number of input and output data items
would give a more accurate indication of the code size compared
to simply counting the number of high-level functions supported
by the system.
• Albrecht postulated that in addition to the number of basic
functions that a software performs, size also depends on the
number of files and the number of interfaces that are associated
with the software.
Function Point Metric Computation
• The principle of Albrecht’s FUNCTION POINT ANALYSIS (FPA) is that a
system is decomposed into functional units.
Function Point: Functional Unit
System
Function Point: Functional Unit
System
• The five functional units are divided in two categories:
(i) Data function types
• Internal Logical Files (ILF): A user identifiable group of logical related
data or control information maintained within the system.
• External Interface files (EIF): A user identifiable group of logically
related data or control information referenced by the system but
maintained within another system. This means that EIF counted for
one system, may be an ILF in another system
Function Point: Functional Unit
System
(ii) Transactional function types
• External Input (EI): An EI processes data or control information that
comes from outside the system. The EI is an elementary process,
which is the smallest unit of activity that is meaningful to the end user
in the business.
• External Output (EO): An EO is an elementary process that generate
data or control information to be sent outside the system.
• External Inquiry (EQ): An EQ is an elementary process that is made
up to an input-output combination that results in data retrieval.
 Function Point: Features
• Function point approach is independent of the language, tools, or
methodologies used for implementation; i.e. they do not take into
consideration programming languages, data base management systems,
processing hardware or any other data base technology.
• Function points can be estimated from requirement specification or
design specification, thus making it possible to estimate development
efforts in early phases of development.
• Function points are directly linked to the statement of requirements;
any change of requirements can easily be followed by a re-estimate.
• Function points are based on the system user’s external view of the
system, non-technical users of the software system have a better
understanding of what function points are measuring.
Function Point Metric Computation:
Unadjusted Function Point (UFP)

The weighting factors are identified for all functional units and multiplied with the
functional units accordingly.
 Function Point Metric Computation:
Unadjusted Function Point
• The procedure for the calculation of UFP in mathematical form is given below:

Where i indicate the row and j indicates the column of Table 1

wij : It is the entry of the ith row and jth column of the table 1

Zij : It is the count of the number of functional units of Type i that have been classified as having
the complexity corresponding to column j.
Function Point
• Organizations that use function point methods develop a criterion for
determining whether a particular entry is Low, Average or High.
• Nonetheless, the determination of complexity is somewhat subjective.

FP = UFP * CAF
• Where CAF is Complexity Adjustment Factor and is equal to [0.65 + 0.01 x Fi].
The Fi (i=1 to 14) are the degree of influence and are based on responses to
questions noted.
Function Point
• Functions points may compute the following important metrics:
• Productivity = FP / persons-months
• Quality = Defects / FP
• Cost = Rupees / FP
• Documentation = Pages of documentation per FP
• These metrics are controversial and are not universally acceptable.
• There are standards issued by the International Functions Point User
Group (IFPUG, covering the Albrecht method) and the United
Kingdom Function Point User Group (UFPGU, covering the MK11
method).
• An ISO standard for function point method is also being developed.
Example
• Consider a project with the following functional units:
• Number of user inputs = 50
• Number of user outputs = 40
• Number of user enquiries = 35
• Number of user files = 06
• Number of external interfaces = 04
• Assume all complexity adjustment factors and weighting factors are average.
Compute the function points for the project.
• UFP = 50 x 4 + 40 x 5 + 35 x 4 + 6 x 10 + 4 x 7
• = 200 + 200 + 140 + 60 + 28 = 628
• CAF = (0.65 + 0.01 Fi)
• = (0.65 + 0.01 (14 x 3)) = 0.65 + 0.42 = 1.07
• FP = UFP x CAF
• = 628 x 1.07 = 672
Question
• An application has the following:
10 low external inputs, 12 high external outputs, 20 low
internal logical files, 15 high external interface files, 12
average external inquiries, and a value of complexity
adjustment factor of 1.10.
• What are the unadjusted and adjusted function point
counts ?
Solution
 Halstead’s Software Metrics (TOKEN Count)
• A computer program is an implementation of an algorithm considered to be a collection of
tokens which can be classified as either operators or operands.
• Halstead’s metrics are included in a number of current commercial tools that count software
lines of code. By counting the tokens and determining which are operators and which are
operands, the following base measures can be collected :
 n1 : Number of distinct operators.
 n2: Number of distinct operands.
 n: Vocabulary of the Program (n1+n2)
 N1: Total number of occurrences of operators.
 N2: Total number of occurrences of operands.
 N: Length of the Program(N1+N2)
 In addition to the above, Halstead defines the following:
 n1*: Number of potential operators.
 n2*: Number of potential operands.
• Halstead refers to n1* and n2* as the minimum possible number of operators and operands for
a module and a program respectively.
Halstead’s Software Metrics
• This minimum number would be embodied in the programming
language itself, in which the required operation would already exist.
• Example, in C language, any program must contain at least the
definition of the function main()
• Possibly as a function or as a procedure:
n1* = 2, since at least 2 operators must appear for any function or
procedure
• 1st for the name of the function
• 2nd to serve as an assignment or grouping symbol
n2* represents the number of parameters, without repetition,
which would need to be passed on to the function or the
procedure.
 Halstead’s Metrics
Halstead's metrics are all defined based on its set of base quantities
i.e. (n1, n2, N1, N2, n1* and n2*).
• The length (N) of a program P is :
N = N1 + N2
• The vocabulary (n) of a program P is :
n = n1 + n2
• The volume (V) of a program P is defined as :
V = N * log2n
 Halstead’s Metrics
• Difficulty level (D) = ( n1 / 2 ) * ( N2 / n2 )
• Program level (L) = 1/D
• Effort to implement (E) = V*D
 Halstead’s Software Metrics features
• Comments are not considered.
• The identifier and function declarations are not considered
• All the variables and constants are considered operands.
• Global variables used in different modules of the same program are counted as multiple
occurrences of the same variable.
• Local variables with the same name in different functions are counted as unique operands.
• Functions calls are considered as operators.
• All looping statements e.g., do {…} while ( ), while ( ) {…}, for ( ) {…}, all control statements e.g., if
( ) {…}, if ( ) {…} else {…}, etc. are considered as operators.
• In control construct switch ( ) {case:…}, switch as well as all the case statements are considered
as operators.
• The reserve words like return, default, continue, break, sizeof, etc., are considered as operators.
Halstead’s Software Metrics
Features
• All the brackets, commas, and terminators are considered as operators.
• GOTO is counted as an operator and the label is counted as an operand.
• The unary and binary occurrence of “+” and “-” are dealt separately. Similarly “*”
(multiplication operator) are dealt separately.
• In the array variables such as “array-name [index]” “array-name” and “index” are
considered as operands and [ ] is considered as operator.
• In the structure variables such as “struct-name, member-name” or “struct-name ->
member-name”, struct-name, 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.
• All the hash directive are ignored.
 S.No. Operator Frequency Operand Frequency

1 main 1 a 3
2 () 4 b 3
3 int 1 c 3
4 {} 1 avg 3
5 , 7 “%d%d%d” 1
6 ; 4 3 1
7 scanf 1 “avg=%d” 1
8 printf 1
9 = 1
10 + 2
11 / 1
12 & 3
total 27 15
Halstead’s Software Metrics
 n1 : Number of distinct operators =12
 n2: Number of distinct operands =7
 N1: Total number of occurrences of operators =27
 N2: Total number of occurrences of operands=15
• The length (N) of a program P is :
• N = N1 + N2=27+15=42
• The vocabulary (n) of a program P is :
• n = n1 + n2=12+7=19
• The volume (V) of a program P is defined as :
• V = N * log2n=42*4.25 =178.5
Halstead’s Software Metrics
• Difficulty level (D) = ( n1 / 2 ) * ( N2 / n2 ) = (12/2)*(15/7)=12.85
• Program level (L) = 1/D=1/12.85=.077
• Effort to implement (E) = V * D =178.5*12.85=2293.75
int BinSearch (char *item, char *table[], int n)
{
int bot = 0;
int top = n - 1;
int mid, cmp;
while (bot <= top) {
mid = (bot + top) / 2;
if (table[mid] == item)
return mid;
else if (compare(table[mid], item) < 0)
top = mid - 1;
else
bot = mid + 1;}return -1; // not found}
operator occurrences operands occurrences

int 5 item 3
char* 2 table 2
BinSearch() 1 n 2
, 2 bot 4
[] 3 0 2
= 5 top 4
; 8 1 3
- 2 mid 6
while() 1 cmp 1
<= 1 -1 1
{} 1
+ 2
() 4
/ 1
if() elseif else 1
return 2
compare() 1
< 1
n1:18 N1:43 n2:10 N2:28
Measure N (Length of a program) : N = N1 + N2.
= 43 + 28
= 71

Measure n (Vocabulary): n = n1 + n2.

= 18 + 10
= 28

Measure V (Volume): V = (N1 + N2) log2 (n1 + n2)

V = N log2 (n).
= 71 log (28)
= 341.322205
Measure D (Difficulty): D = (n1*N2)/(2*n2)
= 18*28/2*10
= 25.2

Measure E (Effort): E=D*V

= 25.2*341.322205
= 8601.319566

Measure B (Bugs expected): B = E0.667/3000

= .14

Measure T (Time): T = E/18 seconds

= 478 seconds
 Control Flow Graph (CFG)

• A control flow graph (or flow graph) G is defined

as a finite set N of nodes and a finite set E of edges.

• An edge (i, j) in E connects two nodes n i and nj in

N.
• We often write G= (N, E) to denote a flow graph G
with nodes given by N and edges by E.
Control Flow Graph (CFG)

In a flow graph of a program, each basic block becomes a node

and edges are used to indicate the flow of control between
blocks.

An edge (i, j) connecting basic blocks bi and bj implies that

control can go from block bi to block bj.

We also assume that there is a node labeled Start in N that has no

incoming edge, and another node labeled End, also in N, that has
no outgoing edge.
CFG Example

N={Start, 1, 2, 3, 4, 5, 6, 7,
8, 9, End}

E={(Start,1), (1, 2), (1, 3), (2,4),

(3, 4), (4, 5), (5, 6), (6, 5),
(5, 7), (7, 8), (7, 9), (9, End)}
 CFG Example

Same CFG with statements

removed.

N={Start, 1, 2, 3, 4, 5, 6, 7,
8, 9, End}
E={(Start,1), (1, 2), (1, 3), (2,4),
(3, 4), (4, 5), (5, 6), (6, 5),
(5, 7), (7, 8), (7, 9), (9, End)}
 Cyclomatic Complexity
A software metric used to measure the complexity of software
Developed by Thomas McCabe

Cyclomatic Complexity may be defined as-

• It is a software metric that measures the logical complexity of
the program code.
• It counts the number of decisions in the given program code.
• It measures the number of linearly independent paths through
the program code.
Importance of Cyclomatic Complexity-

•It helps in determining the software quality.

•It is an important indicator of program code’s readability,
maintainability and portability.
•It helps the developers and testers to determine independent
path executions.
•It helps to focus more on the uncovered paths.
•It evaluates the risk associated with the application or program.
•It provides assurance to the developers that all the paths have
been tested at least once.
Properties of Cyclomatic Complexity-

•It is the maximum number of independent paths through the

program code.
•It depends only on the number of decisions in the program
code.
•Insertion or deletion of functional statements from the code
does not affect its cyclomatic complexity.
•It is always greater than or equal to 1.
Calculating Cyclomatic Complexity-

Cyclomatic complexity is calculated using the control flow

representation of the program code.
In control flow representation of the program code,
•Nodes represent parts of the code having no branches.
•Edges represent possible control flow transfers during program
execution
There are 3 commonly used methods for calculating the cyclomatic
complexity-

Method-01:

Cyclomatic Complexity = Total number of closed regions in the

control flow graph + 1
Method-02:
Cyclomatic Complexity = E – N + 2
Here-
•E = Total number of edges in the control flow graph
•N = Total number of nodes in the control flow graph

Method-03:
Cyclomatic Complexity = P + 1
Here,
P = Total number of predicate nodes contained in the control flow graph

Note-

•Predicate nodes are the conditional nodes.

•They give rise to branches in the control flow graph.
Calculate cyclomatic complexity for the
given code-
IF A = 354
THEN IF B > C
THEN A = B
ELSE A = C
END IF
END IF
PRINT A
Method-01:

Cyclomatic Complexity
= Total number of closed regions in the control flow graph + 1
=2+1
=3

Method-02:

Cyclomatic Complexity
=E–N+2
=8–7+2
=3

Method-03:

Cyclomatic Complexity
=P+1
=2+1
=3