Độ đo phần

Lecture 2: Software Metrics mềm

IT4501
Bùi Thị Mai Anh ([email protected])
Bộ môn Công nghệ phần mềm
Viện công nghệ thông tin và truyền thông
Contents of the lecture 2

• Motivation of Software Metrics

• Lines of code
• Halstead’s metrics
• McCabe Cyclomatic Number
• Maintainability Index (MI)
• OOP Software metrics

IT4501 - Software Engineering Department - SoICT/HUST 10/22/21

How to achieve a successful software project? 3

• In order to conduct a successful software project we must

understand
• the scope of work to be done
• the risks incurred
• the resources required
• the tasks to be accomplished
• the milestones to be tracked
• the cost
• the schedule to be followed

IT4501 - Software Engineering Department - SoICT/HUST 10/22/21

Project Management 4

• Before a project can be planned

• objectives and scope should be established
• alternative solutions should be considered
• technical and management constraints should be identified
• This information is required to estimate costs, tasks,
and a schedule

IT4501 - Software Engineering Department - SoICT/HUST 10/22/21

Software Metrics 5

• Metrics help us understand the technical process that is used

to develop a product
• The process is measured to improve it and the product is measured to
increase its quality
• Measuring software projects is still controversial
• Not yet clear which are the appropriate metrics for a software project
• whether people, processes or products can be compared using such
metrics

IT4501 - Software Engineering Department - SoICT/HUST 10/22/21

Why use metrics? 6

• Without measurements there is no real way to

determine if the process is improving
• They allow the establishment of meaningful goals for
improvement
• Metrics allow an organization to identify the causes of
defects that have the greatest effect on software
development

IT4501 - Software Engineering Department - SoICT/HUST 10/22/21

Applying metrics 7

• When metrics are applied to a product they help

identify
• which user requirements are likely to change
• which modules are most error prone
• how much testing should be planned for each module

IT4501 - Software Engineering Department - SoICT/HUST 10/22/21

Direct measurements 8

• Measurements can be either direct or indirect

• Direct measures are taken from a feature of an item
(e.g., length)
• Lines of code, execution speed, memory size, defects
reported

IT4501 - Software Engineering Department - SoICT/HUST 10/22/21

Indirect Measurements 9

• Indirect measurements associate a measure to a

feature of the object being measured (e.g., quality is
based upon counting rejects)
• functionality, quality, complexity, efficiency, reliability and
maintainability

IT4501 - Software Engineering Department - SoICT/HUST 10/22/21

Code Complexity Measurements
Các độ đo độ phức tạp mã nguồn 10

• Code complexity correlates with the defect rate and

robustness of the application program
• Code complexity measurement tools
• Testwell CMT++ for C, C++ and C#
• Testwell CMTJava for Java
• Code with good complexity
• contains less errors
• is easier to understand
• is easier to maintain
IT4501 - Software Engineering Department - SoICT/HUST 10/22/21
How to use code complexity measurements 11

• Code complexity metrics are used to locate complex code

• To obtain a high quality software with low cost of testing and
maintenance, the code complexity should be measured as early as
possible in coding --> developers can adapt their code when
recommended values are exceeded

IT4501 - Software Engineering Department - SoICT/HUST 10/22/21

Code complexity metrics 12

• Metrics shown by Testwell CMT++/CMTJava

• Lines of code metrics
• McCabe Cyclomatic number
• Halstead Metrics
• Maintainability Index

IT4501 - Software Engineering Department - SoICT/HUST 10/22/21

Lines of code metrics 13

• Most traditional measures used to quantify software complexity

• Simple, easy to count and very easy to understand
• Do not take into account the intelligence content and the layout of the
code
• Testwell CMT++/CMTJava calculates the following lines of code metrics
• LOCphy: number of physical lines
• LOCbl: number of blank lines (a blank line inside a comment block is
considered to be a comment line)
• LOCpro: number of program lines (declarations, definitions, directives and
code)
• LOCcom: number of comment lines

IT4501 - Software Engineering Department - SoICT/HUST 10/22/21

Lines of code metrics - Recommendations
Những giá trị khuyên dùng cho chiều dài mã nguồn 14

• Function length
• Function length should be 4 to 40 program lines
• A function definition contains at least a prototype, one line of code, a pair of
braces, which makes 4 lines
• A function longer than 40 program lines probably implements many
functions
• Exception: functions containing one selection statement with many
branches) --> decomposing them into smaller functions often decreases
readability

IT4501 - Software Engineering Department - SoICT/HUST 10/22/21

Lines of code metrics - Recommendations
Những giá trị khuyên dùng cho chiều dài mã nguồn 15

• File length
• File length should be 4 to 400 program lines
• The smallest entity that may reasonably occupy a whole
source file is a function and the minimum length of a
function is 4 lines
• Files longer than 400 program lines (10..40 functions) are
usually too long to be understood as a whole

IT4501 - Software Engineering Department - SoICT/HUST 10/22/21

Lines of code metrics - Recommendations
Những giá trị khuyên dùng cho chiều dài mã nguồn 16

• Comments
• At least 30% and at most 75% of a file should be comments
• If less than one third of a file is comments the file is either
very trivial or poorly explained
• If more than 75% of a file are comments, the file is not a
program but a document
• Exception: in a well-documented header file percentage of
comments may sometimes exceed 75%

IT4501 - Software Engineering Department - SoICT/HUST 10/22/21

Halstead's Metrics 17

• Developed by Maurice Halstead

• Introduced in 1977
• Used and experimented extensively since that time
• One of the oldest measures of program complexity
• Strong indicators of code complexity
• Often used as a maintenance metric

IT4501 - Software Engineering Department - SoICT/HUST 10/22/21

Halstead's Metrics (cont.) 18

• Based on interpreting the source code as a sequence of tokens and

classifying each token to be an operator or an operand
• Operator: toán tử – Operand: toán hạng
• Then is counted
• number of unique (distinct) operators (n1)
• number of unique (distinct) operands (n2)
• total number of operators (N1)
• total number of operands (N2)
• All other Halstead measures are derived from these four quantities with
certain fixed formulas as described later

IT4501 - Software Engineering Department - SoICT/HUST 10/22/21

Operators and Operands 19

• Operators
• traditional: +, -, *, /, ++, --, etc.
• keywords: return, if, continue, break, try, catch etc.
• Operands
• identifiers
• constants

IT4501 - Software Engineering Department - SoICT/HUST 10/22/21

Halstead’s Metrics
Một số độ đo của Halstead 20

• Program length (N): the program length is the sum of the total number
of operators and operands in the program:
• N = N1 + N2
• Vocabulary size (n): the vocabulary size is the sum of the number of
unique operators and operands
• n = n1 + n2
• Program volume (V): information content of the program
• V = N * log2(n)
• Halstead's volume describes the size of the implementation of an
algorithm
IT4501 - Software Engineering Department - SoICT/HUST 10/22/21
Halstead's metrics - Recommendations
Một số khuyến cáo về giá trị độ đo Halstead 21

• The volume of a function should be at least 20 and at

most 1000
• The volume of a parameterless one-line function that is not
empty is about 20
• A volume greater than 1000 tells that the function probably
does too many things
• The volume of a file should be at least 100 and at most 8000
• These limits are based on volumes measured for files whose
LOCpro and v(G) are near their recommended limits

IT4501 - Software Engineering Department - SoICT/HUST 10/22/21

Other Halstead’s metrics 22

• Difficulty level (D)

• The difficulty level or error proneness (D) of the program is proportional to
the number of unique operator in the program
• D is also proportional to the ration between the total number of operands
and the number of unique operands
• i.e., if the same operands are used many times in the program, it is more
prone to errors
• D = (n1/2) * (N2 / n2)
• Program level (L)
• The program level (L) is the inverse of the error proneness of the program
• i.e., A low level program is more prone to errors than a high level program
• L= 1/D
IT4501 - Software Engineering Department - SoICT/HUST 10/22/21
Other Halstead’s metrics 23

• Effort to implement (E)

• The effort to implement or understand a program is proportional to
the volume and to the difficulty level of the program
• E= V*D
• Time to implement (T)
• The time to implement or understand a program (T) is proportional to
the effort
• Halstead has found that dividing the effort by 18 give an
approximation for the time in seconds
• T = E / 18

IT4501 - Software Engineering Department - SoICT/HUST 10/22/21

Other Halstead’s metrics 24

• Number of delivered bugs (B)

• The number of delivered bugs (B) correlates with the overall complexity of
the software
• B = (E^2/3)/3000
• Estimates for the number of errors in the implementation
• Delivered bugs in a file should be less than 2
• Experiences have shown that when programming with C or C++, a source
file almost always contains more errors than B suggests
• B is an important metric for dynamic testing
• The number of delivered bugs approximates the number of errors in a
module
• As a goal at least that many errors should be found from the module in its
testing
IT4501 - Software Engineering Department - SoICT/HUST 10/22/21
 Halstead metrics: Example
Halstead’s metric Example void sort ( int *a, int n ) { • Ignore
Ví dụ về độ đo Halstead int i, j, t; • Count

if ( n < 2 ) return;
• Given a source code in C/C++ for ( i=0 ; i < n-1; i++ ) {
for ( j=i+1 ; j < n ; j++ ) {
• Calculate some basic metrics of
Halstead if ( a[i] > a[j] ) {
t = a[i];
• n1
a[i] = a[j];
• n2
a[j] = t;
• N1
}
• N2 } Oper
• What are the operators/operands in } Oper
this source code? } V = 80 log2(24) ≈ 392
/ SET / W&I Inside the boundaries [20;1000]
27-4-2011 PAGE 6

IT4501 - Software Engineering Department - SoICT/HUST 10/22/21 25

Halstead Example (cont.)

• Step 1:
• List all the operands
and operators in the
source file
• Count the number of
distinct operands and
distinct operators
• Step 2:
• Calculate V, D, E...

IT4501 - Software Engineering Department - SoICT/HUST 10/22/21 26

McCabe Cyclomatic Number
Chỉ số phức tạp của McCabe 27

• The cyclomatic complexity v(G) has been introduced by Thomas McCabe

in 1976
• Measures the number of linearly-independent paths through a program
module (Control Flow)
• The McCabe complexity is one of the more widely-accepted software
metrics, it is intended to be independent of language and language
format
• Considered as a broad measure of soundness and confidence for a
program

IT4501 - Software Engineering Department - SoICT/HUST 10/22/21

McCabe Cyclomatic Number – v(G) 28

• v(G) is the number of conditional branches

• v(G) = 1 for a program consisting of only sequential statements
• For a single function, v(G) is one less than the number of conditional
branching points in the function
• The greater the cyclomatic number is, the more execution paths there
are through the function, and the harder it is to understand

IT4501 - Software Engineering Department - SoICT/HUST 10/22/21

 McCabecomplexity
McCabe Cyclomatic Number
(1976)
Công thức tính chỉ số McCabe
n general
• Describes the structural complexity
• Control flow
v(G) =• #edges
Data flow - #vertices + 2
• Graph based metrics
• Number of vertices
For control flow graphs
• Number of edges
• Maximum length (depth of graph)
v(G)• In=general:
#binaryDecisions +
v(G) = #edges - #vertices + 2
1, or
v(G)• For
= control
#IFsflow + graphs
#LOOPs + 1
• v(G) = #binaryDecision + 1
• v(G) = #IFs + #LOOPs + 1

Number of paths in the control flow graph.

IT4501 - Software Engineering Department - SoICT/HUST 10/22/21 29
McCabe Cyclomatic Number
Ý nghĩa của chỉ số McCabe 30

• For dynamic testing, the cyclomatic number v(G) is one of the

most important complexity measures
• Because the cyclomatic complexity describes the control flow
complexity
• it is obvious that modules and functions having high cyclomatic
number need more test cases than modules having a lower
cyclomatic number
• Rule: each function should have at least as many test cases as
indicated by its cyclomatic number

IT4501 - Software Engineering Department - SoICT/HUST 10/22/21

 Halstead metrics: Example
void sort ( int *a, int n ) { • Ignore th
McCabe Cyclomatic int i, j, t; • Count op
Number - Example
if ( n < 2 ) return;
for ( i=0 ; i < n-1; i++ ) {
• Count IFs and LOOPs
for ( j=i+1 ; j < n ; j++ ) {
• IF: 2, LOOP: 2
if ( a[i] > a[j] ) {
• v(G) = 5
t = a[i];
a[i] = a[j];
a[j] = t;
}
} Operato
} Operan
} V = 80 log2(24) ≈ 392
/ SET / W&I Inside the boundaries [20;1000]
27-4-2011 PAGE 6
IT4501 - Software Engineering Department - SoICT/HUST 10/22/21 31
Other examples based on CFG 32
28

Calculate cyclomatic complexity

IT4501 - Software Engineering Department - SoICT/HUST 10/22/21

Other examples based on CFG 33
29

Calculate cyclomatic complexity

E=1 , N=2 , P=1 E=4 , N=4 , P=1 E=2 , N=4 , P=2

V =1 – 2 + 2*1= 1 V = 4 – 4 + 2 * 1= 2 V = 2 – 4 + 2*2 = 2

E=12 , N=7 , P=1

V = 12 – 7 + 2*1= 7

E=13, N=11 , P=3

V = 13 – 11 + 2*3 = 8

IT4501 - Software Engineering Department - SoICT/HUST 10/22/21

Other examples based on source code 34

IT4501 - Software Engineering Department - SoICT/HUST 10/22/21

Other examples based on source
code

IT4501 - Software Engineering Department - SoICT/HUST 10/22/21 35

Other examples based on source code 36

IT4501 - Software Engineering Department - SoICT/HUST 10/22/21

Other examples based on source
code

IT4501 - Software Engineering Department - SoICT/HUST 10/22/21 37

McCabe Cyclomatic Number – Recommendations
Khuyến cáo đối với chỉ số McCabe 38

• The cyclomatic number of a function should be less than

15.
• i.e., if a function has a cyclomatic number of 15, there are at
least 15 (but probably more) execution paths through it
• More than 15 paths are hard to identify and test
• Functions containing one selection statement with many
branches make up a exception
• A reasonable upper limit cyclomatic number of a file is 100

IT4501 - Software Engineering Department - SoICT/HUST 10/22/21

Maintainability Index (MI)
Chỉ số bảo trì được của chương trình 39

• Calculated with certain formulas from lines of code measures, McCabe

measure and Halstead measures
• Indicates when it becomes cheaper and/or less risky to rewrite the code
instead to change it
• Two variants of Maintainability Index:
• One that contains comments (MI) and one that does not contain comments
(MIwoc)
• Actually there are three measures:
• MIwoc: Maintainability Index without comments
• MIcw: Maintainability Index comment weight
• MI: Maintainability Index = MIwoc + MIcw
IT4501 - Software Engineering Department - SoICT/HUST 10/22/21
MI’s formula
Công thức tính chỉ số MI 40

• MIwoc = 171 - 5.2 * ln(aveV) - 0.23 * aveG - 16.2 *

ln(aveLOC)
• aveV = average Halstead Volume V per module
• aveG = average extended cyclomatic complexity v(G) per module
• aveLOC = average count of lines LOCphy per module
• perCM = average percent of lines of comments per module
• MIcw = 50 * sin(√2,4*perCM)

IT4501 - Software Engineering Department - SoICT/HUST 10/22/21

MI Recommendations
Các khuyến cáo đối với chỉ số MI 41

• Maintainability Index (MI, with comments) values:

• 85 and more: good maintainability
• 65-85: Moderate maintainability
• < 65: Difficult to maintain with really bad pieces of code
• big, uncommented, unstructured module can lead to a MI value
can be event negative

IT4501 - Software Engineering Department - SoICT/HUST 10/22/21

 Halstead metrics: Example
void sort ( int *a, int n ) { • Ignore th
Maintainability Index int i, j, t; • Count op
Example
if ( n < 2 ) return;
for ( i=0 ; i < n-1; i++ ) {
• Halstead's V = 392
for ( j=i+1 ; j < n ; j++ ) {
• McCabe's v(G) = 5
if ( a[i] > a[j] ) {
• LOC = 14
t = a[i];
• MI = 96 --> easy to a[i] = a[j];
maintain!
a[j] = t;
}
} Operato
} Operan
} V = 80 log2(24) ≈ 392
/ SET / W&I Inside the boundaries [20;1000]
27-4-2011 PAGE 6
IT4501 - Software Engineering Department - SoICT/HUST 10/22/21 42
Exercise: Calculate the MI 43

1. Draw the control

flow graph
2. Calculate McCabe
Cyclomatic
3. Calculate MI

IT4501 - Software Engineering Department - SoICT/HUST 10/22/21

 OOP Software Metrics 44

IT4501 - Software Engineering Department - SoICT/HUST 10/22/21

Objectives 45

• Primary objectives for object oriented metrics are no different than those
for metrics used for conventional software:
• To better understand the quality of the product
• To assess the effectiveness of the process
• To improve the quality of work performed at a project level

IT4501 - Software Engineering Department - SoICT/HUST 10/22/21

Characteristics of object oriented metrics 46

• Metrics for OO systems must be tuned to the characteristics that

distinguish OO from conventional software
• So there are five characteristics that lead to specialized metrics:
• Localization
• Encapsulation
• Information hiding
• Inheritance
• Object abstraction

IT4501 - Software Engineering Department - SoICT/HUST 10/22/21

Localization 47

• Localization is a characteristic of software that indicates the manner in

which information is concentrated within a program
• In the OO context, information is concentrated by summarize both data
and process within the bounds of a class or object
• Since the class is the basis unit of an OO system, localization is based on
objects
• Therefore metrics should apply to the class as a complete entity

IT4501 - Software Engineering Department - SoICT/HUST 10/22/21

Encapsulation 48

• Defines encapsulation as “the packaging (or binding together) of a

collection of items
• For example, at low level of code, encapsulation includes records and arrays
• For OO programs, encapsulation includes the responsibilities of a class including its
attributes and operations and the states of the class as defined by specific attribute
values

• Encapsulation influences metrics by changing the focus of measurement

from a single module to a package of data (attributes) and processing
modules (operations)

IT4501 - Software Engineering Department - SoICT/HUST 10/22/21

Information hiding 49

• Information hiding suppresses (or hides) the operational details of a

program component
• Only the information necessary to access the component is provided to
those other components that wish to access it
• A well-designed OO system should encourage information hiding
• An indication of the quality of the OO design

IT4501 - Software Engineering Department - SoICT/HUST 10/22/21

Inheritance 50

• Inheritance is a mechanism that enables the responsibilities of one object

to be propagated to other objects
• Inheritance occurs throughout all levels of a class hierarchy
• Because inheritance is a crucial characteristic in many OO systems, many
OO metrics focus on it

IT4501 - Software Engineering Department - SoICT/HUST 10/22/21

Abstraction 51

• Abstraction focuses on the essential details of a program component

(either data or process) with little concern for lower level details
• Abstraction is a relative concept. As we move to higher levels of
abstraction, we ignore more and more details
• Because a class is an abstraction that can be viewed at many different
levels of detail and in a number of different ways (e.g., a list of
operations, a sequence of states, a series of collaborations etc.)
• OO metrics represent abstraction in terms of measures of a class

IT4501 - Software Engineering Department - SoICT/HUST 10/22/21

Class oriented metrics 52

• To measure class OO metrics:

• Chidamber and Kemerer (CK) metrics suite
• Lorenz and Kidd (LK) metrics suite
• The Metrics for Object-Oriented Design (MOOD) Metrics Suite

IT4501 - Software Engineering Department - SoICT/HUST 10/22/21

What about modularity? What about modularity?
Thế nào là tính mô đun hoá
của chương trình Design A Design B • Cohesion: calls
inside the
module
• Generally, modularity is the • Coupling: calls
degree to which a system may between the
be separated and recombined modules
• High cohesion and Low A B
coupling is a good design Cohesion Lo Hi
Coupling Hi Lo
• Squares are modules, lines are calls,
ends of the lines are functions.
• Which design is better?

/ SET / W&I 27-4-2011 PAGE 20

IT4501 - Software Engineering Department - SoICT/HUST 10/22/21 53

Modularity metrics: Fan-in and Fan-out
Chỉ số về tính mô đun hoá 54

• Fan-in of M: number of modules calling functions in M

• Fan-out of M: number of modules called by M
• Modules with fan-in = 0
• deadcode
• outside of the system boundaries
• Henry and Kafura's information flow complexity
• Fan-in and fan-out can be defined for procedures and functions
• HK: take global data structures into account:
• fan-in: flow of information into procedures
• fan-out: flow of information out of procedures
• HK = SLOC x (fan-in x fan-out)^2
• SLOC: the length (in lines of code) of the procedure without comments and blank lines

IT4501 - Software Engineering Department - SoICT/HUST 10/22/21

Object-oriented metrics 55

• Object-oriented metrics measure the structure or behaviour of an object-

oriented system
• The system is viewed as a collection of objects rather than as
functions/procedures with messages passed from object to object
• Some traditional metrics can be adapted to work within the OO-domain:
• LOC, percentage of comments, Cyclomatic complexity
• These metrics are applied within methods

IT4501 - Software Engineering Department - SoICT/HUST 10/22/21

Chidamber and Kemerer's metrics
Độ đo của Chidamber và Kemerer 56

• Weighted methods per class (WMC)

• Response for a class (RFC)
• Lack of cohesion of methods (LCOM)
• Coupling between objects (CBO)
• Depth of inheritance tree (DIT)
• Number of children (NOC)

IT4501 - Software Engineering Department - SoICT/HUST 10/22/21

Weighted Methods per Class (WMC)
Phương thức trên một lớp 57

• WMC is a count of the methods implemented within a class or the sum of

the complexities of the methods
• method complexity is measured by cyclomatic complexity
• The number of methods and their complexity is a predictor of how much
time and effort is required to develop and maintain the class
• The larger the number of methods in class, the greater the potential
impact on children
• children inherit all of the methods defined in the parent class
• Classes with large number of methods are likely to be more application
specific, limiting the possibility of reuse

IT4501 - Software Engineering Department - SoICT/HUST 10/22/21

WMC formula 58

IT4501 - Software Engineering Department - SoICT/HUST 10/22/21

WMC - Example 59

IT4501 - Software Engineering Department - SoICT/HUST 10/22/21

Response for a Class (RFC)
Phản hồi của một lớp 60

• RFC is the number of distinct methods and constructors that

may be invoked in response to a class’s actions
• This includes all methods accessible within the class hierarchy
• The number of methods belonging to a class and its parent, as
well as those called on other classes,
• RFC indicates a degree of complexity for the class

IT4501 - Software Engineering Department - SoICT/HUST 10/22/21

Response for a Class (2) 61

• To find RFC:
• Determine all external methods called by class methods
• Take the union of that set and the set of class methods, called the response set (RS)
• RFC is simply the size of RS

• RS = Mc U Me, RFC = |RS|

• Mc is the set of class methods
• Me is the set of external methods called by class methods

IT4501 - Software Engineering Department - SoICT/HUST 10/22/21

Example 62

IT4501 - Software Engineering Department - SoICT/HUST 10/22/21

Response for a Class(3) 63

• RFC may be seen as a measure of object cohesion and coupling (or lack
of)
• High RFC could indicate high coupling or low cohesion
• Low RFC may indicate opposite
• High RFC may lead to:
• More extensive test sets
• More difficulty in understanding class
• Less reusability
• More time and effort needed to fix

IT4501 - Software Engineering Department - SoICT/HUST 10/22/21

Lack of cohesion (LCOM)
(Sự thiếu độ kết dính) 64

• LCOM measures the dissimilarity of methods in a class by instance

variables or attributes
• Connected methods are methods that refer to a same instance variables
• Show cohesion: operate on same data
• LCOM(C)=P-Q if P > Q and = 0 if otherwise
• P: #pairs of distinct methods in C that do not share variables
• Q: #pairs of distinct methods in C that share variables

IT4501 - Software Engineering Department - SoICT/HUST 10/22/21

Lack of Cohesion in Methods (LCOM) (2) 65

• A highly cohesive module should stand alone

• High cohesion indicates
• a good class subdivision
• simplicity and high reusability
• Lack of cohesion or low cohesion increases complexity, thereby
increasing the likelihood of errors during the development process
• Classes with low cohesion could probably be subdivided into two or more
subclasses with increased cohesion

IT4501 - Software Engineering Department - SoICT/HUST 10/22/21

Lack of Cohesion in Methods (LCOM) (3) 66

LCOM = 2 LCOM = 4

IT4501 - Software Engineering Department - SoICT/HUST 10/22/21

Lack of Cohesion in Methods (LCOM) (3) 67

• Class C with M1, M2, M3

• M1 = {a, b, c, d, e}
• M2 = {a, b, e}
• M3 = {x, y, z}
• P = {(M1, M3), (M2, M3)}
• Q = {(M1, M2)}
• LCOM = 1

IT4501 - Software Engineering Department - SoICT/HUST 10/22/21

Coupling between object classes (CBO)
Sự kết nối giữa các đối tượng của các lớp 68

• CBO is a count of the number of other classes to which a class is coupled

• measured by counting the number of distinct non-inheritance related class
hierarchies on which a class depends
• Goal: Lower CBO is better
• To promote modular design
• Reuse

IT4501 - Software Engineering Department - SoICT/HUST 10/22/21

Example 69

IT4501 - Software Engineering Department - SoICT/HUST 10/22/21

Coupling between object classes (CBO) 70

• Excessive coupling is detrimental to modular design and prevents reuse

• the more independent class is, the easier it is reused in another application
• The larger the number of couples, the higher the sensitivity to changes in
other parts of the design
• therefore maintenance is more difficult
• Strong coupling complicates a system since a class is harder to
understand, change or correct
• Complexity can be reduced by designing systems with the weakest
possible coupling between classes
• This improves modularity and promotes encapsulation

IT4501 - Software Engineering Department - SoICT/HUST 10/22/21

Depth of Inheritance Tree (DIT)
Độ sâu cây kế thừa 71

• The depth of a class within the inheritance hierarchy is the maximum

number of steps from the class node to the root of the tree and is
measured by the number of ancestor classes
• The deeper a class is within the hierarchy, the greater the number of
methods it is likely to inherit making it more complex to predict its
behavior
• Deeper trees constitute greater design complexity
• More methods and classes are involved
• But the greater the potential for reuse of inherited methods

IT4501 - Software Engineering Department - SoICT/HUST 10/22/21

Depth of Inheritance Tree - Example 72

IT4501 - Software Engineering Department - SoICT/HUST 10/22/21

DIT - Example 73

IT4501 - Software Engineering Department - SoICT/HUST 10/22/21

Number of Children (NOC)
Số lượng lớp con 74

• The number of children is the number of immediate subclasses

subordinate to a class in the hierarchy
• If a class has a large number of children, it may require more testing of
the methods of that class, thus increasing the testing time
• NOC is an indicator of the potential influence a class can have on the
system
• The greater the NOC, the greater the likelihood of improper abstraction of the
parent
• But the greater the NOC, the greater the reuse since inheritance is a form of reuse

IT4501 - Software Engineering Department - SoICT/HUST 10/22/21

Exercise

• Compute WMC, RFC,

CBO and LCOM
• Consider complexity to
be 1

IT4501 - Software Engineering Department - SoICT/HUST 10/22/21 75

Package-level Metrics
Các độ đo ở mức gói

• Proposed by Robert Cecil Martin (Uncle Bob)

Do you still remember?
• Focus on the relationship between packages in
the project
• Martin's metrics include • Many intra-package dependencies: high cohesion
• Efferent Coupling (Ce) Ai =
µi
or Ai =
µi
N i2 N i (N i − 1)
• Afferent Coupling (Ca) • Few inter-package dependencies: low coupling
• Instability (I) εi, j
Ei , j =
2Ni N j
• Abstractness (A) • Joint measure
k −1 k
1 k 2
• Normalized Distance from Main Sequence (D) MQ = ∑ i k (k − 1) ∑
k i =1
A − ∑ Ei , j k - Number o
i =1 j =i +1 packages
/ SET / W&I 27-4-2011 PAGE 21

IT4501 - Software Engineering Department - SoICT/HUST 10/22/21 76

Why Package? 77

• Grouping code into packages provides two benefits:

• Package coupling
• It allows us to reason about the design at a higher level of abstraction
• Package cohesion
• It helps us manage the development and distribution of the software

IT4501 - Software Engineering Department - SoICT/HUST 10/22/21

Case Study 78

IT4501 - Software Engineering Department - SoICT/HUST 10/22/21

Case study 79

IT4501 - Software Engineering Department - SoICT/HUST 10/22/21

Package Design Principles 80

• Package Cohesion
• Reuse-Release Equivalence Principle (REP)
• Common-Closure Principle (CCP)
• Common-Reuse Principle (CRP)
• Package Coupling
• Acyclic Dependencies Principle (ADP)
• Stable. Dependencies Principle (SDP)
• Stable-Abstractions Principle (SAP)

IT4501 - Software Engineering Department - SoICT/HUST 10/22/21

 Package Cohesion
Three principles of package cohesion provide guidance on how to partition classes into packages 81
10/22/21 IT4501 - Software Engineering Department - SoICT/HUST
Reuse-Release Equivalence Principle 82

• If a package contains software designed for reuse then it should not also
contain software designed not for reuse

• All software in a package should be reusable by the same audience

IT4501 - Software Engineering Department - SoICT/HUST 10/22/21

Stable Package 83

IT4501 - Software Engineering Department - SoICT/HUST 10/22/21

Instable Package 84

IT4501 - Software Engineering Department - SoICT/HUST 10/22/21

“
Depend in the direction of stability

Bob Martin
”
Stable-Dependencies Principle 85

IT4501 - Software Engineering Department - SoICT/HUST 10/22/21

Efferent Coupling (CE)
(outgoing dependencies)

• This metric is used to

measure interrelationship
between classes (outgoing
dependencies)
• It is a count for the number
of classes in a given • The high value of Ce indicates instability of a
package which depend on package
the classes of other
packages • change in any of the numerous external
classes can cause the need for changes
• An indicator of the to the package
package's responsibility
• Preferred values for Ce are in the range of 0
to 20
IT4501 - Software Engineering Department - SoICT/HUST 10/22/21 55
 Afferent Coupling (CA)
(incoming dependencies)

• Another type of
dependencies between
packages, i.e., incoming
dependencies
• It measures the number of • High values of Ca usually suggest high
classes and interfaces from component stability.
other packages that depend • Many other classes depend on the class
on classes in the analysed • This class can't be modified significantly
package because the probability of spreading such
changes increases
• Preferred values for Ca are in the range of 0
to 500
IT4501 - Software Engineering Department - SoICT/HUST 10/22/21 87
Instability (I) 88

• This metric is used to measure the relative susceptibility of class to

changes
• I = Ce / (Ce + Ca)
• On the basis of value of I, we can distinguish two types of components
• The ones having many outgoing dependencies and not many of incoming ones
(value of I is close to 1), which are rather unstable due to the possibility of easy
changes to these packages
• The ones having many incoming dependencies and not many of outgoing ones
(value of I is close to 0), therefore they are rather more difficult in modifying due to
their greater responsibility

IT4501 - Software Engineering Department - SoICT/HUST 10/22/21

Example 89

IT4501 - Software Engineering Department - SoICT/HUST 10/22/21

Stable-Dependencies Principle 90

• Change is inevitable
• Some packages should be instable
• Put the most volatile parts of your code in instable package
• High level architecture
• Should be nonvolatile
• Concentrated in the most stable packages

IT4501 - Software Engineering Department - SoICT/HUST 10/22/21

Example 91

IT4501 - Software Engineering Department - SoICT/HUST 10/22/21

“
A package should be as abstract as it is stable

Bob Martin
”
Stable Abstraction Principle 92

IT4501 - Software Engineering Department - SoICT/HUST 10/22/21

Abstractness (A) 93

• This metric is used to measure the degree of abstraction of the package

and is somewhat similar to the instability
• A = Ta / (Ta + Tc)
• Ta: number of abstract classes in a package
• Tc: number of concrete classes in this package
• Packages that are stable (metric I close to 0) should also be abstract
(metric A close to 1)
• Packages that are unstable (metric I close to 1) should consists of
concrete classes (metric A close to 0)

IT4501 - Software Engineering Department - SoICT/HUST 10/22/21

Example 94

IT4501 - Software Engineering Department - SoICT/HUST 10/22/21

Better Solution 95

IT4501 - Software Engineering Department - SoICT/HUST 10/22/21

Main Sequence
Đường trình tự chính 96

• Combining A and I formulates the

existence of main sequence
• Classes that were well designed
should group themselves around the
graph end points along the main
sequence

IT4501 - Software Engineering Department - SoICT/HUST 10/22/21

 Normalized distance
from main sequence (D)

• This metric is used to measure

the balance between stability
and abstractness and is
calculated using the following
formula
• D = | A + I - 1|
• If we put a given class on a
graph of the main
sequence, its distance from
the main sequence will be
proportional to the value of
D
IT4501 - Software Engineering Department - SoICT/HUST 10/22/21 97
Benefits of Normalized distance from main sequence (D)
Ý nghĩa của chỉ số D 98

• The value of D should be as low as possible so that the components were

located close to the main sequence
• A = 0 and I = 0, a package is extremely stable and concrete, the situation
is undesirable because the package is very stiff and cannot be extended
• A = 1 and I = 1, rather impossible situation because a completely abstract
package must have some connection to the outside, so that the instance
that implements the functionality defined in abstract classes contained in
this package could be created

IT4501 - Software Engineering Department - SoICT/HUST 10/22/21

Example 99

IT4501 - Software Engineering Department - SoICT/HUST 10/22/21

Track D

IT4501 - Software Engineering Department - SoICT/HUST 10/22/21 100

Summaries
Tổng kết 101

• Students must understand the motivation of using software metrics to

improve the quality of source code and also to improve the quality of
software systems
• Give a general perspective about software metrics that are commonly
used in software engineering
• General metrics of lines of code
• McCabe Cyclomatic Number
• Halstead’s metrics
• Maintainability Index
• OOP metrics

IT4501 - Software Engineering Department - SoICT/HUST 10/22/21