SOFTWARE ENGINEERING

(KDS 063)

Lecture Notes

UNIT III – SOFTWARE DESIGN

By
Ms. Pallavi Shukla
U.C.E.R.

SOFTWARE ENGINEERING CHAPTER 3 BY – PALLAVI SHUKLA

 Syllabus as per AKTU:

SOFTWARE DESIGN –
Software design is the practice of taking a specification of externally observable behavior and adding
details needed for actual computer system implementation , including human interaction, task
management , and data management details.

Software design is a kind of problem solving. Thinking about design as problem solving has many
advantages.

First it suggests that information may be partitioned between the problem and the solution.

A second advantage of thinking about design as problem solving is the perspective it gives on the design
activity.

A third advantage of thinking about design as problem solving is that it suggests the use of time
honoured general problem solving techniques in design.

SOFTWARE DESIGN PROBLEM SOLVING TECHNIQUES:

1. Changing the Problem technique

2. Trial and Error Techniques.

3. Brainstorming Technique

4. Abstraction Technique – In this case some details of thing are ignored in favor of others.

Abstraction is an important problem solving technique for the following three reasons:

First ignoring non essential aspects of a problem simplifies it and makes the problem easier to
solve.

Second important use of abstraction in design is as a means of structuring design problem

solving.

Third important use of abstraction in design is as the basis for modeling.

SOFTWRAE DESIGN MODELS-

Software design problems and solutions are often complex, and many aspects of software systems must
be modelled.

Software design models may be divided into two broad classes:

SOFTWARE ENGINEERING CHAPTER 3 BY – PALLAVI SHUKLA

Static Models-

These models represent aspects of software systems that do not change during execution.

These models represent software components , their characteristics and unvarying relationships between
software components.

Examples – object and class diagrams, use case diagrams, data structure pictures, implementation
diagrams.

Dynamic Model -

These models show what happens during software execution.

Examples – interaction diagrams, state charts, DFDs, decision trees and tables, mini specs.

GENERAL DESIGN PROCESS –

- Analyze the problem

- Generate /Refine the problem

- Evaluate the design

- Review the design

SOFTWARE DESIGN PROCESS –

The software design process can be decomposed mainly into the following three levels of design:

a) Interface Design

b) Architecture Design

c) Detailed Design

Interface Design -

Interface design is the specification of the interaction between a system its environment.

This phase proceeds at a high level of abstraction with respect to inner workings of the system.

Attention is focused on the dialogues between target system and the users, devices, and other systems
with which interacts.

They should usually include the following details –

• Precise description of events in the environment , or messages from agents , to which the
system must respond.

• Precise description of the events or messages that the system must produce.

• Specification of the data, and the formats of the data, coming into and going out of the system.

SOFTWARE ENGINEERING CHAPTER 3 BY – PALLAVI SHUKLA

 • Specification of the ordering and timing relationships, between incoming events or messages,
and outgoing events or outputs

User Interface Design –

• Specification of user inputs

• User Outputs

• Valid sequences

ARCHITECTURAL DESIGN –

It is the specification of the major components of a system, their responsibilities , properties , interfaces
and the relationships and interactions between them.

Issues in architectural design include:

• Gross decomposition of the system into major components.

• Allocation of functional responsibilities to components.

• Component interfaces.

• Component scaling and performance properties, resource consumption properties, reliability

properties.

• Communication and interaction between components.

DETAILED DESIGN-

It is the specification of the internal elements of all major system components, their structure properties,
relationships, processing and other their algorithms and data structures.

Detailed design may include:

• Decomposition of major system components into program units.

• Allocation of functional responsibilities to units.

• Unit interfaces

• Unit states and state changes

• Data and control Interactions between units

• Unit packaging and implementation , including issues of scope and visibility of program
elements.

• Algorithms and data structures.

GOOD DESIGN VS BAD DESIGN

SOFTWARE ENGINEERING CHAPTER 3 BY – PALLAVI SHUKLA

 Characteristic Good Design Bad Design

Change Change in one part of system doesn’t always One conceptual change requires
require a change in another part of the system. changes to many parts of the
system.

Logic Every piece of logic has one and one home Logic has to be duplicated.

Nature Simple Complex

Cost Small Very High

Extension System can be extended with changes in only System cannot be extended so
one place easily.

MODULE –

Module is a software components with parts , at any level of abstraction.

A system id modular if it is composed of well defined, conceptually simple and independent units
interacting through well defined interfaces.

Advantages of Modularity –

• Modular systems are easier to understand and explain because their parts make sense and can
stand on their own.

• They are easier to document because each part can be documented as an independent unit.

• Programming individual modules is easier because the programmer can focus on just one
small, simple problem rather than a large complex problem.

• Testing and debugging individual modules is easier.

• Bugs are easier to isolate and understand

• Well composed modules are more reusable because they are more likely to comprise part of a
solutions to many problems.

MODULE COUPLING –
The extent to which modules are independent is called Coupling. It is also called Inter Module
Coupling.

Ideally interdependence amongst modules should be minimized.

When there is little interaction between two modules, the modules are described as loosely coupled,

SOFTWARE ENGINEERING CHAPTER 3 BY – PALLAVI SHUKLA

When there is a high degree of interaction, the modules are described as tightly coupled.

In good software systems, modules are kept as independent as possible.

Types of Module Coupling –

1. No direct Coupling

2. Data Coupling

3. Stamp Coupling

4. Control Coupling

5. Common Coupling

6. Content Coupling

No Direct Coupling – The modules are independent of each other and so are not really components of
a single system.

Data Coupling – It occurs when module passes non global variable to another module.

Stamp Coupling –

It occurs when module passes non global data structure or entire structure to another module.

Here modules are more dependent on each other.

Control Coupling –

It occur when module passes control flags or switches to another module.

Sending module must know a great deal about the inner workings of the receiving module.

Common Coupling -

It 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.

Content Coupling -
It occurs when one module directly refer to the inner workings od another module.

Modules are highly interdependent to each other.

MODULE COHESION –
Cohesion is the measure of strength of the association of elements within a module. The extent to which
all instructions in a module relate to a single function is called cohesion.

Cohesion is a property or characteristic of an individual module.

SOFTWARE ENGINEERING CHAPTER 3 BY – PALLAVI SHUKLA

Cohesion in modules should be maximized.

Module Cohesion is determined by the following considerations:

• Cohesion is highest in modules that have a single, clear, logically independent responsibility or
role.

• Cohesion degrades as unrelated responsibilities or tasks are added to a module.

• One practical and long standing practice for achieving cohesion is to form modules that
implement data types.

TYPES OF MODULE COHESION –

There are seven types of cohesion –

1) Functional Cohesion –

All statements are based on one function.

It is the best cohesion as the module perform a single specific function.

2) Sequential Cohesion –

The instruction inside a modules are related to each other through the input data.

The first instruction acts on the data that are passed into the module , the second instruction use
the output of the first instruction as its input and so on.

3) Communicational Cohesion -

The activities are related to each other by the data that the modules uses.

Each instruction acts on the same input data or is concerned with the same output data.

Sequence is not important.

4) Procedural Cohesion –

The instruction in a module are related to each other through flow of control.

The instruction are grouped together because of a particular procedural order

Sequence is important

The instruction are more related to other modules than they are to each other

5) Temporal Cohesion –

one function

6) Logical Cohesion -

The instructions are hardly related to each other at all.

The instructions are grouped together due to certain classes or activities.

SOFTWARE ENGINEERING CHAPTER 3 BY – PALLAVI SHUKLA

 A flag that is passed from outside will determine which set of instruction is to be executed.

7) Coincidental Cohesion –

The instructions have no relationship to each other at all, they just coincidental fall in the same
module.

It is worst type of cohesion.

SOFTWARE DESIGN PRINCIPLES -

• Design must specify systems that satisfy product requirements in accord with design
constraints.

• Designs must specify systems that can be constructed on time and within budget

• Designs that specify systems that are easy to change are better.

• Modules should not be too big

• Modules should hide private information

• Modules should not have access to unneeded resources.

• Module coupling should be minimized.

• Module Cohesion should be maximized.

• Simpler designs are better.

• Systems should be designed to reuse existing assets as much as possible.

• Beautiful (simple and powerful) designs are better.

SOFTWARE DESIGN STRATEGIES AND METHODS –

Software design is the first of three technical activities – design , code generation and testing-

There are mainly two strategies sued for software design –

• Top Down Design

• Bottom Up Design

TOP DOWN DESIGN STRATEGY –

Top design is an informal design strategy for breaking problems into smaller problems

SOFTWARE ENGINEERING CHAPTER 3 BY – PALLAVI SHUKLA

 Top down design has the following objectives –

- To systematize the design process

- To produce modular program design

- To provide a framework in which problem solving can more effectively proceed.

A software project is decomposed into subprojects , an this procedure is repeated until the
subtasks have become so simple that an algorithm can be formulated as a solution

Advantages –

- Strong focus on specific requirements helps to make a design responsive to its requirement.

Disadvantages –

- Project and system boundaries tend to be application or specification oriented.

- System is likely to miss the benefits of a well structured , simple architecture.

BOTTOM UP DESIGN STRATEGY -

It is becoming more important as software grows in complexity.

In this, the approach is to start “at the bottom” with problems that you already know how
to solve. From there you can work upwards towards a solution to the overall problem.

Code produced by this strategy is more maintainable

Advantages –

- Can be used to hide the low level details of implementation and be merged with a top
design technique.

Disadvantages –

- It is not so closely related to the structure of the problem.

- Its focus is not on specific requirements and thus its results may not fit a given need.

- High quality bottom up solutions prove very hard to construct and thus most
frameworks are to some substantial degree undersigned.

- It leads to proliferation of “potentially useful” functions rather than the most

appropriate ones.

SOFTWARE DESIGN DEOMPOSITION TECHNIQUES-

The software design process is influenced not only by the design approach but also by the
criteria used to decompose a system. The following decomposition techniques –

SOFTWARE ENGINEERING CHAPTER 3 BY – PALLAVI SHUKLA

 - Function oriented decomposition

- Data oriented decomposition

- Object Oriented decomposition

Algorithm and Its Characteristics –

An Algorithm is a sequence of computational steps that transform the input into
the output.
The algorithm describes a specific computational procedure for achieving that
input/output describes a specific computational procedure for achieving that
input/ output relationship.
Characteristics of Algorithm –
Correctness – an Algorithm is said to be correct if, for every input instance, it
halts with correct output.
Running time – This characteristics should be independent of computers and the
programming languages.
Space Usage – a program will require storage space for instructions , constants
and variables for manipulating data, and for storing information to carry out
computation.
Simplicity – The simplest and most straightforward way may not be the most
efficient.
ALGORITHM DESIGN DOCUMENTATION TOOLS –
The documentation tools used for an algorithm design include the following :
• Flowcharts
• Nassi Shneiderman Charts
• Pseudocode

FLOWCHARTS – They are tools used to describe or show the logical sequences and steps
that occur in process or decision making situation. The art of developing flowcharts is called
Flowcharting.

SOFTWARE ENGINEERING CHAPTER 3 BY – PALLAVI SHUKLA

NASSI SHNEIDERMAN CHARTS –

They are also referred ads Program structure diagram

They illustrates algorithms and program functions as a flowchart, the main purpose of a NS
diagram is to create a logical structure for the program.

Nassi - Shneiderman Notations –

SOFTWARE ENGINEERING CHAPTER 3 BY – PALLAVI SHUKLA

PSEUDO CODES-

It is short, English phrases used to explain tasks within a program’s algorithm.

It should not include keywords in any specific computer languages.
Indentation can be used to show grouping or logical order as well.

USER INTERFACE DESIGN –

User interface can take on many forms but always accomplishes two fundamental tasks:
• Communicating information from machine to the user
• Communicating information from the user to the machine.

User Interface Design Principles -

• Know your user first.

• Borrow behaviour from systems familiar to your users.
• Let the user see clearly what functions are available.
• The behaviour of the program should be coherent, i.e internally and externally consistent
• Changes in behaviour should be reflected in the appearance of the program.
• Provide both concrete and abstract ways of getting a task done.
• Some aspects of the User Interfaces attract attention more then others do
• A user interface is a kind of language – know what the rules are
• Understand the different kinds of help a user needs.
• Let the user develop confidence by providing a safety net.
• Limit user activity to one well defined context unless there’s a good reason not to do so.
• Create a program of beauty.
• Recruit help in spotting the inevitable defects in your design
• Listen to what ordinary people have to say.

SOFTWARE ENGINEERING CHAPTER 3 BY – PALLAVI SHUKLA

 SOFTWARE MEASUREMENT AND METRICES

MEASUREMENTS –
It is the process by which numbers or symbols are assigned to attributes of entities in
the real world in such a way as to describe them according to clearly defined rules.
Direct Measurement – Direct measurement of an attribute of an entity involved no other
attribute or entity.
It is assessment of something existing.
Indirect Measurement - It means calculation involving other attributes or entities by using
some mathematical model.
MODEL -
It is an abstraction of reality , allowing us to strip away detail and view an entity or concept from a
particular perspective,

PREDICTION SYSTEM –

It consists of mathematical model together with a set of prediction procedures for determining
unknown parameters & interpreting results.

PROCESSES – They are collections of software related activities.

PRODUCTS – They are artifacts , deliverables or documents that result from a process activity.

RESOURCES – They are entities required by a process activity.

SOFTWARE METRICES –
It is an attribute (a quality, property or characteristics of an object) of the software
development environment attributes if software objects.
It is a term used to refer to measures of software items.
Software items might be –
i) Software product or partial product
ii) Software process such as coding or specifying an event such as a product failure.
iii) A person involved in software production or use such as a designer or project
managers.
iv) An organisation such as a data processing department or a software house.

NEEDS FOR SOFTWARE METRICES –

1) Software metrices can help to fully understand both the design and architecture
information of the software system.

SOFTWARE ENGINEERING CHAPTER 3 BY – PALLAVI SHUKLA

 2) These can help to understand the process of development by applying the process
evaluation in the activity of software development.
3) Software design metrices can aid to discover the underlying errors in the software
design at the early stage of software development life cycle.
4) Software Metrices can also assist the task of software test.
5) Software metrices can evaluate the quality of the software & provide cost estimation
of software project.
6) Software metrices can help to determine the effect of object technology , especially
reuse technology applied in the software development according to some quantitative
evaluation such as productivity, quality, maintainability, reusability etc.

SOFTWARE METRICES CLASSIFICATION –

• Product Metrices
• Process Metrices
• People Metrices

PRODUCT METRICES –
• Product are those used to build artifacts (SRS, System design, documents) of a
software system.
• Product metrices quantify useful attributes of the software products, including those
for internal consumption.
• These metrices help in assessment if the product is good enough through reports on
attributes like usability, reliability , maintainability & portability.

PROCESS METRICES -
• It quantify useful attributes of the software development process & its environment.
• The goal of process metrices is to do the right job on first time through the process.

PEOPLE METRICES –
• It quantify useful attributes of those generating the products using the available
processes , methods & tools.
• Goal is to keep staff happy, motivated & focused on the task at hand.

SOFTWARE ENGINEERING CHAPTER 3 BY – PALLAVI SHUKLA

PRODUCT METRICES & CLASSIFICATION –

1. Size Metrices
a. Lines of code
b. Token Metrices
c. Function Metrices
d. Bang Metrices

2. Control Complexity Metrices –

a. Mc – Cabe’s Cyclomatic Complexity
b. Extension to V(g)
c. Knots Metric
d. Temporal Metric
e. Information Flow

3. Composite Flow

4. Halsted’s Software Science Metrices

5. Object Oriented Metrices

6. Quality Metrices
a. Defect Metrices
b. Reliability Metrices
c. Maintainability Metrices

SOFTWARE ENGINEERING CHAPTER 3 BY – PALLAVI SHUKLA

LINES OF CODES(LOC) -

• LOC Measure is used to measure size of software

• LOC is used as DSI (Delivered Source Instructions)
• LOC is used as KDSI (Thousands of Delivered Source Instructions)
• DSI is defined as follows –
• Only source lines that are delivered as part of product are included test drivers &
other support software is excluded.
• Source lines are created by the project staff code created by applications generators
is excluded.
• One instruction is one line of code or card image.
• Declarations are counted as instructions.
• Comments are not counted as instructions.

Advantages of LOC –
• Simple to measure

Drawbacks of LOC –
• It is defined on code.
• It characterise only one specific view of size, namely length , it takes
no account of functionally or complexity.
• Bad s/w design may cause excessive line of code
• It is language dependent
• Users cannot easily understand it.

TOKEN METRICES –
It is calculated by counting tokens in the code of a system, program or program unit.
A token is a simple entity that makes up a program.
Ex- if , for , usr_name

BANG METRICES –
Bang as a function metric, indicative of the size of the system , in effect it measures the total
functionality of the software system delivered to the user.
Bang can be calculated from certain algorithm and data primitives available from certain
form a set of formal specifications for the software,

FUNCTION POINTS-
Function Points are basic idea from which productivity metrices could be compared –
FP data is used two ways –

SOFTWARE ENGINEERING CHAPTER 3 BY – PALLAVI SHUKLA

 • As an estimation variable that is used to “size” each element of the software.
• As baseline metrices collected from past projects and used in conjunction with
estimation variables to develop cost and effort projections.
The approach is to identify and count a number of unique function types –

• External inputs (Eg. File names)

• External outputs (Eg. Reports, Messages)
• Queries (Interactive inputs needing a response)
• External files (Files shared with other software systems)
• Internal files (Invisible outside the system)
Unidentified Function Points(UFP) is calculated as follows –
Albretcht’s original method classified the weightings as shown –

Function Type Low Average High

External Input 3 4 6
External Output 4 5 7
Logical Internal File 7 10 15
External Interface File 5 7 10
External Inquiry 3 4 6

In order to find adjusted FP, UFP is multiplied by technical complexity factor (TCF) which
can be calculated
TCF = 0.65 + (sum of factors) /100
There are 14 technical complexity factors. Each complexity factor is rated on the basis of its
degree of influence, from no influence to very influential.
1. Data Communication
2. Distributed Data Processing
3. Performance Criteria
4. Heavily Utilized Hardware
5. High transaction rates
6. Online Data Entry
7. Online updating
8. End user Efficiency
9. Complex complexity
10. Reusability
11. Ease of Installation
12. Ease of Operation
13. Portability
14. Maintainability

FP = UFP X TCF

SOFTWARE ENGINEERING CHAPTER 3 BY – PALLAVI SHUKLA

On the basis of function points, several other metrices could be computed as follows:
Productivity = Function points / Person – months
Quality = Number of defects / Function Points
Documentation = Number of pages of documentation per Function Points.
Advantages of Function Point –
1. It is not restricted to code
2. Language Independent
3. The necessary data is available early in project and thus only a detailed specification
is needed.
4. More accurate than estimated LOC

Drawbacks of FP -
1. Subjective Counting
2. Hard to automate and difficult to compute
3. Ignores quality of output
4. Oriented to traditional data processing applications

2 user inputs : document file name, personal dictionary name

(average)
3 user outputs: fault report, word count, misspelled error count (average)
2 user request : # treated words? , # found errors?(average)

SOFTWARE ENGINEERING CHAPTER 3 BY – PALLAVI SHUKLA

 1 internal file : dictionary (average)
2 external file: document file, personal dictionary (av)
UFP = 4 X 2 + 5 X 3 + 4 X 2 + 10 X1 + 7 X 2 = 55
Now Technical Complexity Factors:
1. Data Communication 3
2. Distributed Data Processing 0
3. Performance Criteria 4
4. Heavily Utilized Hardware 0
5. High transaction rates 3
6. Online Data Entry 3
7. Online updating 3
8. End user Efficiency 3
9. Complex complexity 0
10. Reusability 3
11. Ease of Installation 3
12. Ease of Operation 5
13. Portability 3
14. Maintainability 3

DI = 36 (Degree of Influence)
Function Points
FP=UFP*(0.65+0.01*DI)= 55*(0.65+0.01*36)= 56.01
FP=56.01

Relation between LOC and FP

• Relationship:
– LOC = Language Factor * FP
– where
• LOC (Lines of Code)
• FP (Function Points)

Assuming LOC’s per FP for:

Java = 53,

SOFTWARE ENGINEERING CHAPTER 3 BY – PALLAVI SHUKLA

 C++ = 64
aKLOC = FP * LOC_per_FP / 1000
It means for the SpellChecker Example: (Java)
LOC=56.01*53= 2968.53 LOC or 2.96 KLOC

HALSTEAD’S SOFTWARE SCIENCE METRICES –

• Program may be considered as a collection of Lexical Tokens , each of which can be
classified as operator or operand.
• Operands are that tokens which have value.
• Data variables and constants therefore constitute the operands.
• Operators are Commas, Parenthesis, Keywords, Arithmetic Operators, Functions.
The measurable and countable properties are :
ⴄ1 = number of unique or distinct operators appearing in that implementation
ⴄ2 = number of unique or distinct operands appearing in that implementation
N1 = total usage of all of the operators appearing in that implementation
N2 = Total usage of all the operands appearing in that implementation

From these metrices Halsted defines :

Vocabulary ⴄ = ⴄ1 + ⴄ2
Length of Program (N) = N1 + N2
Estimated Program Length N in terms of tokens is given by –

Ň = ⴄ1 log2 ⴄ1 + ⴄ2 log 2 ⴄ2
Volume (V) = Number of bits required to encode the program being
measured
V = N log 2 (ⴄ)
= N log 2 (ⴄ1 + ⴄ2)
Effort (E) – Required to implement the program as

E = (ⴄ1 N2)/ 2 ⴄ2) (N Log2 ⴄ)

Time(T) – Time Required to implement the program

SOFTWARE ENGINEERING CHAPTER 3 BY – PALLAVI SHUKLA

 T = (E /18) seconds

Ex – Consider the program code

int sum, i ;
sum = 0;
for( i = 1 ; i < = 20; i++)
sum = sum + i;
printf(sum);
Compute Halsted software Science Metrics –
Operators Operands
int = 1 sum = 5
; = 6 i=5
==3 0=1
() = 2 1=1
<= = 1 20 = 1
++ = 1
For = 1
+=1
printf = 1
,=1
Number of distinct operators (ⴄ1) = 10
Number of distinct operands (ⴄ2) = 5
Total number of operators Occurrences (N1) = 18
Total number of operands Occurrences (N2) = 13

Vocabulary ⴄ = ⴄ1 + ⴄ2
= 10 + 5 =15

SOFTWARE ENGINEERING CHAPTER 3 BY – PALLAVI SHUKLA

Length of program(N) = N1 + N2
= 18 + 13 = 31
Estimated Program Length N in terms of tokens is given by –

Ň = ⴄ1 log2 ⴄ1 + ⴄ2 log 2 ⴄ2

= 10 log 2 10 + 5 log 2 5
= 10 (3.32) + 5 (2.32)
= 44.8

Volume V = N log 2 (ⴄ)

= 31 log 2 (15)

= 31 * 3.91 = 121.21 bits

Effort E = (ⴄ1 N2)/ 2 ⴄ2) (N Log2 ⴄ)

= (10 x 130/ (2 x5) (31 log 2 15)
= 403 log 2 15 = 403 x 3.93 = 1583.79 emd

Time T = (E /18) seconds

= 1583.79 / 18 = 87.89 Seconds

Here 18 is called STROUD’S NUMBER

STROUD defined a moment as the time required by the brain to perform the
most elementary discrimination.

Advantages of Halstead Metrics –

a) Do not require in depth analysis of programming.
b) Predicts rate of error.
c) Predicts maintenance effort.
d) Useful in scheduling & reporting projects.
e) Measure overall quality of programs.
f) Simple to calculate.
g) Can be used for any programming language.
h) Numerous industry studies support the use of Halsted in predicting programming
bugs.

Drawbacks of Halstead Metrics –

SOFTWARE ENGINEERING CHAPTER 3 BY – PALLAVI SHUKLA

 a) Depends on completed code.
b) It has little or no use as a predictive estimating model.

Control Flow Graph –

A flow graph consists of a number of nodes represented a circles connected by directed
arcs.

Construction of flowgraph from flowchart –

While transforming a flow chart into a flow graph sequence of processing boxes and
diamond box can map into a single node.
A node that contains a condition is called Predicate Node.
Construction of flow graph from source code :
1. main( ) {
2. int num_student, marks , subject, total ;
3. float average;
4. num_student = 1;
5. while(num_student <=25) {
6. total = 0;
7. subject = 1;
8. while(subject <=5) {
9. scanf(“enter marks out of 100 %d /n”,& marks);
10. total = total + marks;
11. subject ++:
12. }

SOFTWARE ENGINEERING CHAPTER 3 BY – PALLAVI SHUKLA

 13. Average = total /5;
14. If (average >=50)
15. printf(“Pass : Average marks are %f \n”, average);
16. else
17. printf(“Fail: …………..%f\n”,average);
18. num_student ++;
19. }
20. printf(“end of program\n”);
21. }
Steps 2 -4 → a steps 13-14 → f
Step 5 → b steps 15 → g
Step 6-7 → c steps 16- 17 → h
Step 8 → d steps 18 → i
Step 9- 12 → e steps 19 → j
steps 20 → k

SOFTWARE ENGINEERING CHAPTER 3 BY – PALLAVI SHUKLA

CYCLOMATIC COMPLEXITY -
It is a metric to measure logical complexity of the program.
This values defines the number of independent paths in the program to be executed in
order to ensure that all statements in the program are executed at least once.
C(g) = Number of regions in the flow Graph
Regions are the areas bounded by nodes & edges in a flow graph.
While counting regions , area outside the graph is also counted as one region.
C(G) = E – N + 2P
E = No. of edges in the flow graph
N = no of flow graph nodes
P = Total number of strongly connected components
Now according to C(g) = E – N +2P
E = 13, N= 11
C(G) = (13- 11) +2
=4
Advantages of McCabes Cyclomatic Complexity –
1) It can be used as an ease of maintenance metric
2) Used as a quality metric, gives relative complexity of various designs.
3) It can be computed early in life cycle than of Halsted’s Metrics.
4) Measures the minimum effort & bets areas of concentration for testing.
5) It guides the testing process by limiting the program logic during development.
6) Its easy to apply

Drawbacks Of Cyclomatic Complexity –

1) It is measure of the program’s control complexity not the data complexity.

2) Same weight is placed on nested & non nested loops however deeply nested
conditional structure are harder to understand than non nested structures,
3) It may give a misleading figure with regard to a lot of simple comparisons & decision
structures.

SOFTWARE ENGINEERING CHAPTER 3 BY – PALLAVI SHUKLA