Software Engineering

Unit 3
By
Shivani Aagarwal
 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: Modularity- 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 The pattern in the

means a repeated form design process means
or design in which the the repetition of a
same shape is repeated solution to a common
several times to form a recurring problem
pattern. 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

Preliminary
Architectura
or high-level
l Design
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 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.
 In software engineering, the coupling is the degree of interdependence between
Coupling
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.
 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 me 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

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 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 Coupling represents the relationships

within module. between modules.
Increasing in cohesion is good for Increasing in coupling is avoided for
software. software.
Cohesion represents the functional Coupling represents the independence
strength of modules. among modules.
Whereas loosely coupling gives the best
Highly cohesive gives the best software.
software.
In cohesion, module focuses on the In coupling, modules are connected to
single thing. the other modules.
 Top-down Design
A top down design approach starts by identifying the major modules of the system, decomposing them into
their lower level modules and iterating until the desired level of detail is achieved. This is stepwise
refinement; 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 and the design can be implemented directly

A top-down approach It is a stepwise Starting from an Suitable only if the It is a reasonable

starts by identifying refinement method. abstract design, in requirements are approach if a waterfall
the major components each step the design is clearly known and the type of process model
of the system, refined to a more system development is is being used.
decomposing them concrete level, until we from the scratch.
into their lower-level reach a level where no
components and more refinement is
iterating until the needed.
desired level of detail is
achieved.
 Top-down 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
• 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
• 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 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 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 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
• Symbols used in construction of structured chart
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.
2. Conditional Call
Structure Chart
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.
5. Control Flow
Structure Chart
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.
• Advantages of Pseudocode Pseudo Code
• 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.
 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 emphasizes on the use This programming paradigm is based on object
of functions where each function performs a specific oriented concept. Classes are used where instance of
task. objects are created
Fundamental elements used are variables and
Fundamental elements used are objects and
functions.The data in the functions are
methods and the data used here are mutable data.
immutable(cannot 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 need
The statements in this programming paradigm does
to follow a order i.e., bottom up approach while
not need to follow a particular order while execution.
execution.
Has three access specifiers namely, Public, Private
Does not have any access specifier.
and Protected.
Provides and easy way to add new data and
To add new data and functions is not so easy.
functions.
No data hiding is possible. Hence, Security is not Provides data hiding. Hence, secured programs are
 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.
 Metrics
• A metrics is a measurement of the level that any impute 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.
 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
 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 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 columnj .
 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
 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 * log n=42*4.25 =178.5
2
 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
 Cyclomatic Complexity
• Cyclomatic complexity is a source code complexity measurement that is being
correlated to a number of coding errors.
• It is calculated by developing a Control Flow Graph of the code that measures the
number of linearly-independent paths through a program module.
• Lower the Program's cyclomatic complexity, lower the risk to modify and easier to
understand. It can be represented using the below formula:
cyclomatic complexity is 8 - 7 + 2 = 3
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
 Consider a software project with the following functional units:
User input = 35, User output = 15, User Enquiries = 10, User Files = 6, External Interfaces = 7.
Assume complexity adjustment factors are essential and weighting factors are average. Calculate the functional
point for the project.
 Consider a software project with the following functional units:
User input = 55, User output = 35, User Enquiries = 40, User Files = 8, External Interfaces = 5.
Assume complexity adjustment factors are significantly complex and weighting factors are high. Calculate the
functional point for the project.