0% found this document useful (0 votes)
100 views32 pages

Structural Complexity of A Software Product

The document discusses various software metrics for measuring internal attributes like structural complexity, including metrics for control flow structure like cyclomatic complexity, data flow structure using information flow complexity, and data structure organization. It also covers concepts like coupling between modules and the goal of achieving loose coupling for improved evolvability. Measurement of morphology and different types of module dependencies are presented.

Uploaded by

hantamu esubalew
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
100 views32 pages

Structural Complexity of A Software Product

The document discusses various software metrics for measuring internal attributes like structural complexity, including metrics for control flow structure like cyclomatic complexity, data flow structure using information flow complexity, and data structure organization. It also covers concepts like coupling between modules and the goal of achieving loose coupling for improved evolvability. Measurement of morphology and different types of module dependencies are presented.

Uploaded by

hantamu esubalew
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 32

Course Name:-Software Metrics

Chapter 6:
Measuring Internal
Product Attributes:
Structural Complexity
compiled by Samuel Ashagrre

SOFTWARE METRICS 1
Software Complexity Metrics
How to Represent Program
Structure?
Software structure can have 3 attributes:
• Control-flow structure: Sequence of
execution of instructions of the program.

 Flowgraph (model)

 Metric ( McCabe’s complexity)


How to Represent Program
Structure?
• Data flow: Keeping track of data as it is created
or handled by the program.
 Structure Charts (model)
 Metric -Information Flow Complexity (Henry-
Kafura)
 Data structure: The organization of data itself
independent of the program.
Goal & Questions ...
• Q1: How to represent “structure” of a program?
• A1: Control-flow diagram
• Q2: How to define “complexity” in terms of the structure?
• A2: Cyclomatic complexity; depth of nesting
Cyclomatic Complexity
 A program’s complexity can be measured by the cyclomatic
number of the program flow graph.

 The cyclomatic number can be calculated in 2 different


ways:
 Flow graph-based
 Code-based
Cyclomatic Complexity /1
 For a program with the program flow graph G, the
cyclomatic complexity v(G) is measured as:
v(G) = e - n + 2p
■ e : number of edges
■ Representing branches and cycles
■ n : number of nodes
■ Representing block of sequential code
■ p : number of connected components
■ For a single component, p=1
Cyclomatic Complexity / 2
 For a program with the program flow graph G, the
cyclomatic complexity v(G) is measured as:
v(G) = 1 + d
■ d: number of predicate nodes (i.e., nodes with out-degree
other than 1)
■ d represents number of loops in the graph
■ or number of decision points in the program
Cyclomatic Complexity: Example
v(G) = e - n + 2p
v(G) = 7 -6 + 2 x 1
v(G) = 3 Predicate
nodes
(decision
Or points)

v(G) = 1 + d

v(G) = 1 + 2 = 3
Example: Graph Based

v(G) = 16 -13 + 2 = 5

or

v(G) = 4 +1 = 5
Example 2
■ Determine cyclomatic
complexity for the
following flow diagram:
v = 1+d
v = 1+2 = 3
or
v=e-n+2
v = 11 -10 + 2 = 3
Example 3A
■ Two functionally equivalent programs that are
coded differently could have different complexities

 There is always a trade-off between control-flow and data


structure.
 Programs with higher cyclomatic complexity usually have less
complex data structure.
Applications
 One of McCabe's original applications was to limit
the complexity of routines during program
development; he recommended that
programmers should count the complexity of the
modules they are developing, and split them into
smaller modules whenever the cyclomatic
complexity of the module exceeded 10.
 This practice was adopted by the NIST Structured
Testing methodology, with an observation that
since McCabe's original publication, the figure of
10 had received substantial corroborating
evidence, but that in some circumstances it may
be appropriate to relax the restriction and permit
modules with a complexity as high as 15
Applications….
 Another application of cyclomatic complexity is
in determining the number of test cases that are
necessary to achieve thorough test coverage of a
particular module.
 A number of studies have investigated the
correlation between McCabe's cyclomatic
complexity number with the frequency of
defects occurring in a function or method.
 Some studies find a positive correlation between
cyclomatic complexity and defects: functions
and methods that have the highest complexity
tend to also contain the most defects.
Applications….
 Cyclomatic complexity may also be used for the
evaluation of the semantic complexity of
artificial intelligence programs.
 Cyclomatic complexity has proven useful in
geographical and landscape-ecological analysis,
after it was shown that it can be implemented
on graphs of ultrametric distances
Cyclomatic Complexity: Critics
■ Advantages:
■ Objective measurement of complexity
■ Disadvantages:
■ Can only be used at the component level
■ Two programs having the same cyclomatic complexity
number may need different programming effort
■ Same requirements can be programmed in various ways
with different cyclomatic complexities
■ Requires complete design or code visibility
Software Architecture /1
A software system can be

represented by a graph,
S = {N, R}

■ Each node n in the set of nodes


(N) corresponds to a subsystem.
Each edge r in the set of relations

(R) indicates a relation (e.g.,
function call, etc.) between two
subsystems.
Morphology
■ Morphology refers to the overall shape of
the software system architecture.
■ It is characterized by:
■ Size: number of nodes and edges
■ Depth: longest path from the root to a leaf node
■ Width: number of nodes at any level
■ Edge-to-node ratio: connectivity density
measure
Data Structure Metrics
 Essentially the need for software development
and other activities are to process data.
 Some data is input to a system, program or
module; some data may be used internally,
and
 some data is the output from a system,
program, or module.
 That's why an important set of metrics which
capture in the amount of data input, processed
in an output form software. A count of this data
structure is called Data Structured Metrics. In
these concentrations is on variables (and given
constant) within each module & ignores the
input-output dependencies.
Data Structure Metrics
Data Structure Metrics
 There are some Data Structure metrics to
compute the effort and time required to
complete the project. There metrics are:
 The Amount of Data.
 The Usage of data within a Module.
 Program weakness.
 The sharing of Data among Modules.
Information Flow Metrics
 The other set of metrics we would live to
consider are known as Information Flow
Metrics.
 The basis of information flow metrics is found
upon the following concept the simplest system
consists of the component, and it is the work
that these components do and how they are
fitted together that identify the complexity of
the system.
Information Flow Metrics
 The following are the working definitions that
are used in Information flow:
 Component: Any element identified by
decomposing a (software) system into it's
constituent's parts.
 Cohesion: The degree to which a component
performs a single function.
 Coupling: The term used to describe the
degree of linkage between one component
to others in the same system.
Information Flow Metrics
 Information Flow metrics deal with this type of
complexity by observing the flow of information
among system components or modules. This
metrics is given by Henry and Kafura. So it is
also known as Henry and Kafura's Metric.
Complexity Measures:
Coupling
Concept: Coupling
 Coupling describes how strongly one element relates to
another element
 The goal is to achieve “loose coupling”

 Loose coupling between classes is small, direct, visible,


and has flexible relations with other classes
Concept: Coupling
 An architecture that accomplishes loose coupling
has several advantages, for instance: Loosely
coupled services increase the evolvability,
encourage multiple changes, and new solutions,
especially in situations in which the system should
be able to adjust to environmental changes.
Concept: Coupling
Coupling: Package Dependencies
 Packages should not be
cross-coupled
 Packages in lower layers
should not be dependent
upon packages in upper
layers
 dependencies should not skip
layers (unless specified by
the architecture)

X = coupling violation
Coupling: Class Relationships

■ Strive for the loosest coupling possible

Strong Coupling Loose Coupling


Coupling /1
■ Coupling is the degree of interdependence among modules
Various types of coupling (5 types):

■ ■ R0: independence: modules have no communication

■ R1: data coupling: modules communicate by parameters


■ R2: stamp coupling: modules accept the same record type
■ R3: control coupling: x passes the parameters to y and the parameter
passed is a flag to control the behavior of y.
■ R4: content coupling: x refers to inside of y; branches into or changes
data in y.
Coupling 12
■ No coupling: R0
■ Loose coupling: R1 and R2
■ Tight coupling: R3 and R4

■ There is no standard measurement


for coupling!

You might also like