SOFTWARE DESIGN

SOFTWARE DESIGN: NEED/IMPORTANCE

• Basis of Development phase

• Purpose: transforming the customer requirements
into a set of documents that are suitable for
implementation in a programming language.
• “SRS tells us WHAT a system do, DESIGN tells us HOW
a system works”
• Input to Design phase: SRS Document
• Output : SDD (Software Design Document)
• More creative process then Analysis
• Analysis is correct or wrong but Design is Good or
Bad
• Work miraculously in large projects by bridging the
gap between specifications(SRS) and Coding.
Software Design
• Software Design is the process to transform the user requirements into some suitable form,
which helps the programmer in software coding and implementation.
• During the software design phase, the design document is produced, based on the customer
requirements as documented in the SRS document. Hence the aim of this phase is to transform
the SRS document into the design document.
• The following items are designed and documented during the design phase:
• Different modules required.
• Control relationships among modules.
• Interface among different modules.
• Data structure among the different modules.
• Algorithms required to implement among the individual modules.
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.
• The software design concept provides a supporting and essential structure or model for
developing the right software. There are many concepts of software design and some of them are
given below:
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.
• 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.
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 and 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/ Conceptual
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 less 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.
• As 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.
Control Coupling
• Occurs when module passes control flags or switches to another
modules.
• The sending module must know a great deal of about the inner
workings of the receiving 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
• All elements of the module will contribute to the execution of one and only one problem related
task(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
A
ELSE
IF PRODUCT_PRICE <100 THEN
SALES_TAX = PRODUCT_PRICE * 0.25 B
ENDIF
ENDIF
• A and B are contributing to same functional task
 Sequential Cohesion
• The instruction inside a module are related to each other through 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

Ex- VALIDATE_PRODUCT_REC
IF TRANS_TYPE NOT = ‘0’ THEN
WRITE _ERR_REPORT
ENDIF
IF CUST_NO NOT NUMERIC THEN
WRITE_ERR_REPORT
ENDIF
IF PRODUCT_NO = BLANKS
WRITE_ERR_REPORT
ENDIF
END
 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(with regard to time) 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. It can be more economic 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 designers 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 an 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 called modules at low level. Components are read from top to bottom and
left to right.
• When a module calls another, it views the called module as black box, passing required
parameters and receiving results.
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 by the sub 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
Fundamental elements used are objects and methods and
functions.The data in the functions are immutable(cannot
the data used here are mutable data.
be changed after creation).
Importance is not given to data but to functions. Importance is given to data rather than procedures.

It follows declarative programming model. It follows imperative programming model.

It uses recursion for iteration. It uses loops for iteration.

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 not possible.
possible.
Software Measurement which is done by
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.

Here we will read three types:

Size oriented measures: LOC (Halstead’s Software Metrics)
Function Point Measures: FP Metrics
Cyclomatic Complexity measures: Control Flow Graphs
Metrics
• Metrics: A scale to measure a software.
• A metrics is a measurement of the level that any attribute
belongs to a system product or process. There are 4 functions
related to software metrics:
1.Planning
2.Organizing
3.Controlling
4.Improving
Characteristics of Software Metrics
1. Quantitative:
Metrics must possess quantitative nature. It means metrics can be expressed in 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.
3. Project Metrics: Describes project characteristics and execution process. Eg: No of S/W
developers, Staffing Pattern, Cost and schedule 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. To be able to predict the LOC count for the various
leaf-level modules sufficiently
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 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 penalises use of higher-level programming languages and code reuse: Effort
cannot be measured by mangers on Line of code because if programmer choose object oriented
approach which encourage reuse of components
LOC: Disadvantages
• LOC metric measures the lexical complexity of a program and 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 in 1983. 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 to developed is 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: 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
• 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 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
• 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.
▪ N1: Total number of occurrences of operators.
▪ N2: Total number of occurrences of operands.
▪ 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 (for 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 : 1 for the name of the function
and 1 to serve as an assignment or grouping symbol, and 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 (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
• 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
• 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
Introduction: Control Flow Graphs
• Within an imperative programming language, a control flow
statement is a statement that results in a choice being made
as to which of two or more paths to follow. ... At the level of
machine language or assembly language, control
flow instructions usually work by altering the program counter.
• A graph representing this statement is CONTROL FLOW GRAPH
• The nodes in the graph indicate the smallest group of
commands of a program, and a directed edge in it connects the
two nodes i.e. if second command might immediately follow
the first command.
Introduction: Cyclomatic Complexity
• Cyclomatic complexity is a software metric used to indicate
the complexity of a program. It is a quantitative measure of the number of
linearly independent paths through a program's source code. It was
developed by Thomas J. McCabe, Sr.
• Cyclomatic complexity of a code section is the quantitative measure of the
number of linearly independent paths in it.
• It is computed using the Control Flow Graph of the program.
• If source code contains no control flow statement then its cyclomatic
complexity will be 1 and source code contains a single path in it.
• Similarly, if the source code contains one if condition then cyclomatic
complexity will be 2 because there will be two paths one for true and the
other for false.
Definition: Cyclomatic Complexity
How to calculate cyclomatic complexity
• Predicate nodes are the conditional nodes. They give rise to two
branches in the control flow graph.
• No of regions= no of independent paths