Metrics for the Design Model

Metrics for the Design Model

• Metrics can provide insight into structural data and system complexity
associated with architectural design.

• Architectural Design Metrics

• Metrics for Object-Oriented Design

• Class-Oriented Metrics

• Component-Level Design Metrics

• Interface Design Metrics

• Design Metrics for WebApps

 Architectural Design Metrics
• Architectural design metrics focus on characteristics of the program architecture with
an emphasis on the architectural structure and the effectiveness of modules.

• These metrics are black box in the sense that they do not require any knowledge of the
inner workings of a particular software component.

Software Design Complexity Measures

• Structural complexity

• Data complexity

• System complexity
 Architectural Design Metrics Cont’d
Structural Complexity
• Measures of structural complexity are internal attributes i.e., they are specific to the
software code artifact.

The structural complexity of module i is defined in the following manner:

where fout(i) is the fan-out of module i.

• Fan-out is defined as the number of modules immediately subordinate to
module i; that is, the number of modules that are directly invoked by
module i.
 Architectural Design Metrics Cont’d
Data complexity
Data complexity provides an indication of the complexity in the internal
interface for a module i

• where v(i) is the number of input and output variables that are passed to
and from module i.
 Architectural Design Metrics Cont’d
System complexity

• System complexity is defined as the sum of structural and data complexity

• As each of these complexity values increases, the overall architectural

complexity of the system also increases.

• This leads to a greater likelihood that integration and testing effort will
also increase.
 Architectural Design Metrics Cont’d
Henry-Kafura Metric (HKM)
• An earlier high-level architectural design metric proposed by Henry and
Kafura also makes use the fan-in and fan-out.

• Fan-in is a measure of the number of process or functions that call some

other function or process (say X).
• Fan-out is the number of functions that are known by function X.

• A high value for fan-in means that X is tightly coupled to the rest of the design and
alters to X will have extensive knock-on effects.

• A high value for fan-out suggests that the overall difficulty of X may be high because of
the difficulty of the control logic required to coordinate the called components.
 Architectural Design Metrics Cont’d
Henry-Kafura Metric (HKM) Cont’d

HKM = length(i) x [ fin(i) + fout(i)]2

where length(i) is the number of programming language statements in a module i and fin(i)
is the fan-in of a module i.

To compute HKM during design, the procedural design may be used to estimate the number
of programming language statements for module.
 Architectural Design Metrics Cont’d
Morphology Metrics
• Fenton suggests a number of simple morphology (i.e., shape) metrics that
enable different program architectures to be compared using a set of
straightforward dimensions.
Size = n + a
where n is the number of nodes and a is the number of arcs.
 Architectural Design Metrics Cont’d
Morphology Metrics Example

Size = 17 +18 = 35

Depth longest path from the root (top) node to a leaf node. Depth 4.
Width maximum number of nodes at any one level of the architecture. Width =6.
The arc-to-node ratio, r = a/n, measures the connectivity density of the architecture and may provide a
simple indication of the coupling of the architecture.
 Architectural Design Metrics Cont’d
Design Structure Quality Index (DSQI)

• DSQI is an architectural design metric used to evaluate a computer

program's design structure and the efficiency of its modules.

• The metric was developed by the United States Air Force Systems Command.

• The result of DSQI calculations is a number between 0 and 1. The closer to 1,

the higher the quality.

• It is best used on a comparison basis, i.e., with previous successful projects.

 Architectural Design Metrics Cont’d
Design Structure Quality Index (DSQI) Cont’d
First Following Factors are checked and calculate their values:

S1 = The total number of modules defined in the Program Architecture.

S2 = The number of modules whose correct function depends on the source of data input or that produce
data to be used elsewhere.

S3 = The number of modules whose correct function depends on prior processing.

S4 = The number of database items (includes data objects and all attributes that define objects).

S5 = The total number of unique database items.

S6 = The number of database segments (different records or individual objects).

S7 = The number of modules with a single entry and exit (exception processing is not considered to be
multiple exits).
 Architectural Design Metrics Cont’d
Once values s1 through s7 are determined for a computer program, the following intermediate values
can be computed:

D1-Program structure:
If the architectural design was developed using a distinct method (e.g., data flow-oriented design or
object-oriented design), then D1 = 1, otherwise D1 = 0.

D2-Module independence: D2 = 1 - (S2/S1)

D3-Modules not dependent on prior processing: D3=1-(s3/s1)

D4-Database size: D4=1-(s5/s4)

D5-Database compartmentalization: D5=1-(s6/s4)

D6-Module entrance/exit characteristic: D6 = 1 - (s7/s1)

 Architectural Design Metrics Cont’d
With these intermediate values determined, the DSQI is computed in the following manner:

DSQI=SUM(wiDi)

where i = 1 to 6, wi is the relative weighting of the importance of each of the intermediate

values, and S wi = 1 (if all Di are weighted equally, then wi = 0.167).

• The value of DSQI for past designs can be determined and compared to a design that is currently
under development.

• If the DSQI is significantly lower than average, further design work and review are indicated.

• If major changes are to be made to an existing design, the effect of those changes on DSQI can
be calculated.
 Metrics for Object-Oriented Design
Measurable Characteristics of an OO Design

Size
Volatility Complexity

Similarity
Object-Oriented Coupling
Design

Primitiveness
Sufficiency

Cohesion Completeness
 Metrics for Object-Oriented Design
• Size : Size is defined in terms of four views: population, volume, length, and
functionality.

• Complexity: The structural characteristics by examining how classes of an

OO design are interrelated to one another.

• Coupling: The physical connections between elements of the OO design

(e.g., the number of collaborations between classes or the number of
messages passed between objects) represent coupling within an OO system
 Metrics for Object-Oriented Design
• Sufficiency: The degree to which a design component possesses features in its
abstraction, from the point of view of the current application.

• Complexity: Completeness considers multiple points of view.

• Cohesion: The cohesiveness of a class is determined by examining the degree to

which “the set of properties it possesses is part of the problem or design domain”.

• Primitiveness: A characteristic that is similar to simplicity.

• Similarity: The degree to which two or more classes are similar in terms of their
structure, function, behavior, or purpose is indicated by this measure.

• Volatility: The volatility of an OO design component measures the likelihood that a

change will occur.
 Class-Oriented Metrics

• The class is the fundamental unit of an OO system.

• Measures and metrics for an individual class, the class hierarchy, and class
collaborations will be invaluable when you are required to assess OO design
quality.

• Chidamber and Kemerer Metrics Suite (or) The CK Metrics Suite

• The MOOD Metrics Suite

• OO Metrics Proposed by Lorenz and Kidd

 Class-Oriented Metrics Cont’d
• The CK Metrics Suite
• - this author proposed six class-based design metrics.

• Weighted methods per class (WMC).

• Depth of the inheritance tree (DIT).

• Number of children (NOC).

• Coupling between object classes (CBO).

• Response for a class (RFC).

• Lack of cohesion in methods (LCOM).

 Class-Oriented Metrics Cont’d
The CK Metrics Suite Cont’d

1. Weighted methods per class (WMC)

- WMC is simply the method count for a class.

WMC = number of methods defined in class

Note:

• Keep WMC low otherwise, A high WMC has been found to lead to more faults.

• WMC is a predictor of how much time and effort is required to develop and maintain the
class.

• What is a good WMC? Different limits have been defined

One way is to limit the number of methods in a class to, say, 20 or 50. Another way is to specify
that a maximum of 10% of classes can have more than 24 methods.
 Class-Oriented Metrics Cont’d
The CK Metrics Suite Cont’d

2. Depth of Inheritance Tree (DIT):

The deeper a class is in the hierarchy, the more methods and
variables it is likely to inherit, making it more complex.

DIT = maximum inheritance path from the class to the root class

• Deep trees as such indicate greater design complexity.

• Inheritance is a tool to manage complexity, really, not to increase it.
• As a positive factor, deep trees promote reuse because of method
inheritance.
 Class-Oriented Metrics Cont’d
The CK Metrics Suite Cont’d

2. Depth of Inheritance Tree (DIT):

• A high DIT has been found to increase faults

• A recommended DIT is 5 or less

 Class-Oriented Metrics Cont’d
The CK Metrics Suite Cont’d

3. Number of Children(NOC):
NOC equals the number of immediate child classes derived
from a base class
NOC = number of immediate sub-classes of a class

• NOC measures the breadth of a class hierarchy, where maximum DIT measures the
depth.
• Depth is generally better than breadth, since it promotes reuse of methods through
inheritance.
• NOC and DIT are closely related. Inheritance levels can be added to increase the
depth and reduce the breadth.
 Class-Oriented Metrics Cont’d
3. Number of Children(NOC) Cont’d

A high NOC, a large number of child classes, can indicate several things:

• High reuse of base class. Inheritance is a form of reuse.

• Base class may require more testing.

• Improper abstraction of the parent class.

• Misuse of sub-classing. In such a case, it may be necessary to group

related classes and introduce another level of inheritance.
 Class-Oriented Metrics Cont’d
The CK Metrics Suite Cont’d

4. Coupling between Object Classes (CBO)

• Two classes are coupled when methods declared in one class use methods
or instance variables defined by the other class.

• CBO is the number of collaborations listed for a class on its CRC index
card.

• CRC index cards are developed manually, completeness and consistency

must be assessed before

• CBO can be determined reliably.

 Class-Oriented Metrics Cont’d
The CK Metrics Suite Cont’d

Coupling between Object Classes (CBO) (cont’d)

• High CBO is undesirable.

• Excessive coupling between object classes is detrimental to modular design and

prevents reuse.

• The more independent a class is, the easier it is to reuse it in another application.

• A high coupling has been found to indicate fault-proneness.

• CBO>14 is too high

 Class-Oriented Metrics Cont’d
5. Response for a Class (RFC)
• The response set of a class is a set of methods that can potentially be executed in
response to a message received by an object of that class.
• RFC is simply the number of methods in the set.

RFC = M + R (First-step measure)

RFC’ = M + R’ (Full measure)

• M = number of methods in the class

• R = number of remote methods directly called by methods of the class

• R’ = number of remote methods called, recursively through the entire call tree

• RFC is the original definition of the measure. It counts only the first level of calls outside of
the class.
 Class-Oriented Metrics Cont’d
The CK Metrics Suite Cont’d
6. Lack of cohesion in methods (LCOM)

• LCOM is the number of methods that access one or more of the same attributes.

• If no methods access the same attributes, then LCOM = 0.

• The LCOM metric provides useful insight in some situations, but it can be misleading in
others.

• For example, keeping coupling encapsulated within a class increases the cohesion of the
system as a whole.

• Therefore in at least one important sense, higher LCOM actually suggests that a class may
have higher cohesion, not lower.
 Class-Oriented Metrics Cont’d
The MOOD Metrics Suite
• These metrics are useful for projects with heavy use of object-oriented
programming.

• Method inheritance factor (MIF)

• Coupling factor (CF)

• Polymorphism Factor
 Class-Oriented Metrics Cont’d
The MOOD Metrics Suite Cont’d
1. Method inheritance factor (MIF) , Attribute Inheritance Factor (AIF)

MIF = inherited methods / total methods available in classes

AIF = inherited attributes / total attributes available in classes

• A class that inherits lots of methods (attributes) from its ancestor classes contributes to a
high MIF (AIF).

• A child class that redefines its ancestors' methods (attributes) and adds new ones
contributes to a lower MIF (AIF).

• An independent class that does not inherit and has no children contributes to a lower MIF
(AIF).
 Class-Oriented Metrics Cont’d
The MOOD Metrics Suite Cont’d

2. Coupling factor (CF)

• Coupling Factor (CF alias COF) measures the actual couplings among classes in relation to the
maximum number of possible couplings.

CF = Actual couplings / Maximum possible couplings

• Class A is coupled to class B if A calls methods or accesses variables of B.

In turn, B is coupled to A only if B calls methods or accesses variables of A. B is not
coupled to A if there is no call/access from B to A.
• Maximum possible couplings happen when all classes are coupled to (and from) all other
classes.
• If no classes are coupled, CF = 0%. If all classes are coupled to all other classes, CF=100%.
 Class-Oriented Metrics Cont’d
The MOOD Metrics Suite Cont’d

2. Polymorphism Factor(PF)

• Polymorphism Factor (PF alias POF) measures the degree of method overriding in
the class inheritance tree. It equals the number of actual method overrides
divided by the maximum number of possible method overrides.

PF = overrides / sum for each class(new methods * descendants)

• A call to an object’s method can be statically or dynamically bound to a named

method implementation. The latter can have as many shapes as the number of
times the method is overridden in that class’s descendants.
 OO Metrics Proposed by Lorenz and Kidd

Class size (CS). The overall size of a class can be determined

using the following measures:
• The total number of operations (both inherited and private instance
operations) that are encapsulated within the class.

• The number of attributes (both inherited and private instance

attributes) that are encapsulated by the class.
 Component-Level Design Metrics
Component-Level Design Metrics
• Component-level design metrics for conventional software components focus on
the internal characteristics of a software component.
• It measures the module cohesion, coupling, and complexity
1. Cohesion metrics.
• Data slice - The data slice is a concept for protecting the main data of a planning-relevant
InfoProvider against changes.

• Data tokens - The variables defined for a module can be defined as data tokens for the module.

• Glue tokens -This set of data tokens lies on one or more data slice.

• Superglue tokens - These data tokens are common to every data slice in a module.

• Stickiness - The relative stickiness of a glue token is directly proportional to the number of data slices
that it binds.
 Component-Level Design Metrics Cont’d

2. Coupling metrics
• Module coupling provides an indication of the “connectedness” of a module to
other modules, global data, and the outside environment.

• Encompasses data

• Control flow coupling

• Global coupling

• Environmental coupling
 Component-Level Design Metrics Cont’d
2. Coupling metrics cont’d
• Data and control flow coupling
• di - number of input data parameters
• ci - number of input control parameters
• do - number of output data parameters
• co - number of output control parameters
• Global coupling,
• gd - number of global variables used as data
• gc - number of global variables used as control

• Environmental coupling,
• w - number of modules called (fan-out)
• r - number of modules calling the module under consideration (fan-in)
 Component-Level Design Metrics Cont’d
2. Coupling metrics cont’d

Module coupling indicator mc

where k is a proportionality constant and

Values for k, a , b, and c must be derived empirically.

• As the value for mc increases, the overall module coupling decreases.

Coupling Metric

where the degree of coupling increases as the value of M increases.

 Component-Level Design Metrics Cont’d
3. Complexity metrics
• The variety of software metrics can be computed to determine the
complexity of program control flow. Many of these are based on the flow
graph (Cyclomatic Complexity).
 Operation-Oriented Metrics

• Average operation size (OSavg) - number of lines of code or the number

of messages sent by the operation within a class

• Operation complexity (OC) - can be computed using any of the

complexity metrics proposed for conventional software

• Average number of parameters per operation (NPavg)

 User Interface Design Metrics
• Layout appropriateness (LA) is a worthwhile design metric for human/computer
interfaces.
• A typical GUI uses layout entities—graphic icons, text, menus, windows, and the like—to
assist the user in completing tasks.

The cost can be assigned to each sequence of actions according to the following
relationship:
cost = [frequency of transition(k) x cost of transition(k)]

Layout appropriateness is defined as

LA = 100 x [(cost of LA - optimal layout)/(cost of proposed layout)]

 Design Metrics For Webapps

Design Metrics For

Webapps

Interface metrics Graphic design Content metrics Navigation metrics

 Design Metrics For Webapps

Layout appropriateness (LA) Content acquisition time

Aesthetics
Memory Load
Metrics For Webapps
Usability
Recognition time

User effort
Page/Window waiting time
 Design Metrics For Webapps
1. Interface metrics
Suggested Metric Description
 Design Metrics For Webapps
2. Aesthetic (graphic design) metrics
Suggested Metric Description
 Design Metrics For Webapps
3. Content metrics
Suggested Metric Description
 Design Metrics For Webapps
4. Navigation metrics
Suggested Metric Description
 Metrics for Source Code
Halstead’s theory
• A computer program is an implementation of an algorithm considered to be a collection of
tokens that can be classified as either operators or operand.

• A computer program is considered to be a collection of tokens, which may be classified as

either operators or operands. All software science metrics can be defined in terms of these
basic symbols. These symbols are called a token.

The basic measures are

• n1 = count of unique operands.

• n2 = count of unique operators.

• N1 = count of total occurrence of operands.

• N2 = count of total occurrences of operators.

 Metrics for Source Code
Halstead’s theory Cont’d
From these numbers, five measures are derived:
Measure Symbol Formula
Program vocabulary n n = n1 + n2
Program length N N = N1 + N2
Volume V V = N * (log2 n)
Difficulty D D = (n1 / 2) * (N2 / 2)
Effort E E=D*V

Errors B B=Volume / 3000

Testing time T Time = Efforts / S, where S=18 seconds.

Estimated length = n1 log n1 + n2 log n2

• V will vary with a programming language and represents the volume of information (in bits) required to
specify a program.
 Metrics for Source Code
Halstead’s theory Cont’d
Guideline for calculating operands and operators
1. All the variables and constants are considered operands.
2. Local variables with the same name, if occurring in different functions are counted as a unique
operand.
3. Function calls are considered operators.
4. The looping statements, do … while, while, for, are operators. The statements if, if … else, are
operators. The switch … case statements are considered operators.
5. The reserve worlds, returns, default, continue, break, and sizeof are all operators.
6. The brackets, commas, and semicolons, are operators.
7. The unary and binary operators are considered operators. The & is considered as operator.
8. In arrays, array name and index are considered operands and [ ] is considered as an operator.
9. All hash directives can be ignored.
10. Comments are not considered.
11. In the Goto statement, goto is considered an operator and label as operand.
 Metrics for Source Code
Halstead’s theory Cont’d
Example:
Void swap (int a[ ], Operands Occurrences Operators Occurrences
int i) swap 1 () 1
{ a 5 {} 1
int temp;
i 5 void 1
Temp = a[i];
a[i] = a[i+1]; temp 3 int 3
a[i+1] = temp; 1 2 [] 5
} , 1
; 4
= 3
+ 2
n1 = 5 N1 = 16 n2 = 9 N2 = 21
 Metrics for Source Code
Halstead’s theory Cont’d
Measure Symbol Formula
Program vocabulary n = n1 + n2 5 + 9 = 14
Program length N = N1 + N2 16 +21 = 37
Estimated length n1 log n1 + n2 log n2 5 log 5 + 9 log 9 = 31.37
Volume V = N * (log2 n) =37 * log (14)
37 * 2.63 = 97.64
Difficulty D = (n1 / 2) * (N2 / 2) =(5/2)*(21/2)=26.25
Effort E=D*V =97.64*26.25=2563.5
Errors B=Volume / 3000 97.64/3000=.03255
Testing time Time = Efforts / S, where S=18 2563.5/18=142.41
seconds.
 Metrics for Source Code
Halstead’s theory Cont’d
• Halstead defines a volume ratio L as the ratio of the volume of the most compact form of a
program to the volume of the actual program.

L must always be less than 1.

 Metrics for Testing
• Halstead’s Metrics for Testing

Testing effort, e = V / PL

• where V is the volume of the program (as defined in slide

number 51) the program level, PL = 1 / (n1/2 x N2/n2)
Product Quality Metrics