Page 161 - DCAP305_PRINCIPLES_OF_SOFTWARE_ENGINEERING

Unit 7: Introduction to Verification

that can be affected by change in a module are the modules that invoke the module or share Notes
global data (or files) with the module. Any other module will clearly not be affected by change
in a module. The potential ripple effect is defined as the total number of assumptions made by
other modules regarding the module being changed. Hence, counting the number of assumptions
made by other modules is central to determining the stability of a module. As at design time
only the interfaces of modules are known and not their internals, for calculating design stability
only the assumptions made about the interfaces need be considered. The interface of a module
consists of all elements, through which this module can be affected by other modules, i.e., through
which this module can be coupled with other modules. Hence, it consists of the parameters of
the modules and the global data the module uses. Once the interface is identified, the structure
of each element of the interface is examined to determine all the minimal entities in this element
for which assumptions can be made. The minimal entities generally are the constituents of the
interface element. For example, a record is broken into its respective fields as a calling module
can make assumptions about a particular field. For each minimal entity at least two categories
of assumptions can be made—about the type of the entity and about the value of the entity.
(The assumption about the type is typically checked by a compiler if the programming language
supports strong typing.) Each minimal entity in the interface is considered as contributing one
assumption in each category. In this formulation, the effect of a change in a module i on another
module j is represented as a probability. For the entire system, the effect of change is captured
by the probability of change metrics C. An element C[i, j] of the matrix represents the probability
that a change in module i will result in a change in module j. With this matrix the ripple effect of
a change in a module can also be easily computed. This can then be used to model the stability
of the system. The main problem with this metric is to estimate the elements of the matrix.
7.2.3 Information Flow Metrics

The network metrics of graph impurity had the basis that as the graph impurity increases, the
coupling increases. However, it is not a very good approximation for coupling, as coupling of a
module increases with the complexity of the interface and the total number of modules a module
is coupled with, whether it is the caller or the callee. So, if we want a metric that is better at
quantifying coupling between modules, it should handle these. The information flow metrics
attempt to define the complexity in terms of the total information flowing through a module.
In one of the earliest work on information flow metrics, the complexity of a module is considered
as depending on the intramodule complexity and the intermodule complexity. The intramodule
complexity is approximated by the size of the module in lines of code (which is actually the
estimated size at design time). The intermodule complexity of a module depends on the total
information flowing in the module (inflow) and the total information flowing out of the module
(outflow). The inflow of a module is the total number of abstract data elements flowing in the
module (i.e., whose values are used by the module), and the outflow is the total number of
abstract data elements that are flowing out of the module (i.e., whose values are defined by this
module and used by other modules). The module design complexity, Dc, is defined as:
Dc, = size * (inflow * out flow)
2
The term (inflow * outflow) refers to the total number of combinations of input source and output
destination. This term is squared, as the interconnection between the modules is considered a
more important factor (compared to the internal complexity) determining the complexity of a
module. This is based on the common experience that the modules with more interconnections
are harder to test or modify compared to other similar-size modules with fewer interconnections.
The metric defined earlier defines the complexity of a module purely in terms of the total amount
of data flowing in and out of the module and the module size. A variant of this was proposed
based on the hypothesis that the module complexity depends not only on the information flowing
in and out, but also on the number of modules to or from which it is flowing. The module size
is considered an insignificant factor, and complexity D, for a module is defined as:
D c , = fan_in * fan_out + inflow * outflow

LOVELY PROFESSIONAL UNIVERSITY 155