An Analysis and Enhancements To MOOD Metrics

“An Analysis and Enhancements to MOOD metrics”
Abstract
Modern society uses Object Oriented approach in developing systems. It is very useful to having
a good knowledge about object oriented metrics. When it becomes to object oriented metrics,
MOOD metrics plays a main role in today’s software environment.
Our goal is to write a report on the topic “An Analysis and Enhancements to MOOD metrics”
which is relevant to Software Engineering Tools and Metrics module. This report will provide a
clear idea about Metrics for Object Oriented Design (MOOD) and its advantages, and further
enhancements.
In here we have provided clear examples regarding calculation of original MOOD metrics. Our
expectation is to make the reader comfortable with MOOD metrics and improve his knowledge
about MOOD metrics.
1
Table of Contents
List of Figures and Tables…………………………………………………………………………6
1. Introduction………………………………………………………………………………..7
2. Background study…………………………………………………………………………8
2.1 Software complexity…………………………………………………………………..8
2.2 Reasons for proposing OO complexity metrics and their evolving up to now....…......9
3. Description about the metric……………………………………………………..………11
3.1 MOOD metrics………………………………………………………………………11
3.1.1 MHF (Method Hiding Factor)…………………………..…………………11
3.1.2 AHF (Attribute Hiding Factor)…………………………………………….12
3.1.3 MIF (Method Inheritance Factor)….............................................................12
3.1.4 AIF (Attribute Inheritance Factor)………………………………………....13
3.1.5 POF (Polymorphism Factor)……………………………………………….13
3.1.6 CF (Coupling Factor)……………...……………………………………….14
4. Discussion………………………………………………………………………………..15
4.1 Analysis of metrics and further enhancements……………………………………...15
4.1.1 Encapsulation………………………………………….…………………...16
4.1.1.1 Attribute Hiding Factor (AHF)…………………………….…….17
4.1.1.1.1 Proposed extension for AHF…………………………...17
4.1.1.2 Method Hiding Factor (MHF)…………………………………...19
2
4.1.1.2.1 Proposed extension for MHF…………………………..19
4.1.2 Inheritance………………………………………………………………….21
4.1.2.1 Attribute Inheritance Factor (AIF)……………………………….21
4.1.2.1.1 Proposed extension for AIF……………………………22
4.1.2.2 Method Inheritance Factor (MIF)………………………………..23
4.1.2.2.1 Proposed extension for MIF……………………………23
4.1.3 Polymorphism……………………………………………………………...25
4.1.3.1 Polymorphism Factor (PF)……………………………………….25
4.1.4 Coupling……………………………………………………………………26
4.1.4.1Coupling Factor (CF)…………………………………………......26
4.2 Advantages of the MOOD metric……………………………………………………27
4.2.1 Low coupling………………………………………………………………27
4.2.2 High cohesion……………………………………………………………...27
4.2.3 Lower Cyclomatic Complexity…………………………………………….27
4.2.4 Higher Encapsulation……………………………………………………....27
4.2.5 Low Depth of Inheritance Tree (DIT)……………………………………..27
4.2.6 Low Number of Children (NOC)…………………………………………..28
4.2.7 Lower value of weighted methods per class (WMC)…………………...…28
4.2.8 Lower value of Lines of code (LOC)………………………………………28
4.3 Drawbacks of the MOOD metric…………………………………………………….28
3
5. Conclusion……………………………………………………………………………….29
References………………………………………………………………………………………..30
4
List of Figures and Tables
Figures
Figure 2.1.a – Software complexity diagram
Figure 3.1.1.a - Equation for calculating the MHF (Method Hiding Factor)
Figure 3.1.2.a - Equation for calculating the AHF (Attribute Hiding Factor)
Figure 3.1.3.a- Equation for calculating the MIF (Method Inheritance Factor)
Figure 3.1.4.a- Equation for calculating the AIF (Attribute Inheritance Factor)
Figure 3.1.5.a- Equation for calculating the POF (Polymorphism Factor)
Figure 3.1.6.a- Equation for calculating the CF (Coupling Factor)
Figure 4.1.1.a- Encapsulation examples
Figure 4.1.1.b- Encapsulation examples
Figure 4.1.1.c- Encapsulation examples
Figure 4.1.1.1.a- Attribute Hiding Factor (AHF) examples
Figure 4.1.1.1.1.a- Equation for calculating the Extended AHF (Attribute Hiding Factor)
Figure 4.1.1.2.a- Method Hiding Factor (MHF) examples
Figure 4.1.1.2.1.a- Equation for calculating the Extended MHF (Method Hiding Factor)
Figure 4.1.2.a- Inheritance examples
Figure 4.1.2.1.1.a- Equation for calculating the Extended AIF (Attribute Inheritance Factor)
Figure 4.1.2.2.1.a- Equation for calculating the Extended MIF (Method Inheritance Factor)
Figure 4.1.3.1.a- Polymorphism examples
Tables
Table 4.1.2.1.1- Attribute Inheritance Factor (AIF) example
Table 4.1.2.2.1- Method Inheritance Factor (MIF) example
Table 4.1.3.1.1- Polymorphism Factor (PF) example
5
1. Introduction
Object Oriented Design and development acts an important role in todays’ software development
environment. It is confirmed that object oriented development uses a different kind of thinking
style when compare with traditional structured development. There are two main advantages in
object oriented design. They are modularity and reusability. Properties of object oriented designs
are measured using object oriented metrics.
Metrics are used to get more accurate estimations when reaching project milestones. Those metrics
help to develop and maintain software systems with less no of faults. When comes to types of
metrics, design basic metrics give an idea about complexity and size of object oriented systems
and represent design performance.
There are several issues of conventional metrics.
1) Doesn’t provide an enough sound theoretical foundation.

2) Experimentally validating enough sound theoretical foundation.
3) Experimentally validating the new measures is not enough.
4) Doesn’t properly ensuring that metrics are actually helpful to software engineers and
project managers.
To overcome above issues, MOOD metrics are introduced. The report is mainly based according
to following ways.
6
2. Background study
2.1 Software complexity and its usages.
Software complexity is introduced as a natural result of the functional complexity. Software

complexity considers about the measurement of things that affect the cost when developing and
working on software [7]. In modern people find many difficulties when creating and maintaining
applications. This happens because the code is too hard to maintain and understand.
Usually these measures are about the program code, doesn’t consider about the comments,
indentation and naming conventions. Measures normally based on program size (LOC), control
structures and interface nature. For an example, assume there are two programs called P1 and P2,
each of them has same number of lines (LOC). But P1 has both control structures, one “if” and one
“for” since P2 has only one “if” as a control structure. Although the number of lines is same P1 and
P2 have two different complexities.
Software complexity measures fall in to two sub categories. They are computational and
psychological. Computational complexity indicates the efficiency of an algorithm and the usage
of resources of the machine [7]. Psychological complexity indicates the ability of a programmer
to create, modify software to effective use.
Psychological complexity has three types. They are problem complexity, system design
complexity and procedural complexity. Problem complexity indicates a function of the problem
domain [7].It simply says complex problem spaces are hard than simple problem spaces for a
programmer [7]. System design complexity indicates that converting a problem space in to a given
representation [7].There is two types. They are structural and data. Structural complexity indicates
the coupling concept. Coupling is module interdependency. It means how modules are
communicating each other via an interface. Data complexity indicates about the cohesion.
Cohesion is talking about the functional strength. Procedural complexity means the complexity of
the logical structure of a program.
7
Figure 2.1.a
2.2 Reasons for proposing OO complexity metrics and their evolving up to

now
Since most of the programmers are interested in using Object Oriented Design concepts today than
using traditional development concepts, there are some questions arising regarding the
effectiveness when applying traditional software metrics to Object Oriented systems. Some of
them are as follows.
 “Assumptions relating program size and program productivity in structured systems do not
apply directly to OO systems” [7].
 Traditional software metrics do not applicable for structural aspects of Object Oriented
systems [7].
 Calculating the system’s complexity as the sum of the complexity of components is not
suitable for Object Oriented systems [7].
To overcome from those above problems Object Oriented Complexity metrics are introduced.
8
The MOOD metrics, was first proposed in 1994 by the MOOD project team.
The MOOD metrics are designed to satisfy a relevant set of criteria proposed by the
MOOD project team.
Those are the proposed criteria:
1. Metrics determination should be defined.
2. Non-size metrics should be system size independent.
3. Metrics should be dimensionless or expressed in some consistent
unit system.
4. Metrics should be obtainable early in the life-cycle.
5. Metrics should be down-scalable.
6. Metrics should be easily computable.
7. Metrics should be language independent.
The MOOD metrics are called as the system-wide measurements. Each MOOD metric is a
quotient of where the numerator is the use of a relevant mechanism in the system which is
measured and the nominator is concern as the maximum possible use of that particular mechanism.
The value for each metric should be in the range of 0-1. And the definition of the metric is mention
in a mathematical expression. The original set of metric is interact with the attributes of
inheritance, visibility, coupling factor, clustering, polymorphism mechanism and reuse.
MOOD metrics should be improving and testing before using to apply them to the real life
systems.
9
3. Description about the metric
3.1 MOOD metrics
Metrics for Object Oriented Design (MOOD) are useful when that the projects use Object Oriented
programming heavily. There are 6 metrics in original MOOD metrics. They are as follows.
 Encapsulation
 MHF(Method Hiding Factor)
 AHF(Attribute Hiding Factor)
 Inheritance
 MIF(Method Inheritance Factor)
 AIF(Attribute Inheritance Factor)
 Polymorphism
 POF(Polymorphism Factor)
 Coupling
 CF(Coupling Factor)
3.1.1 MHF (Method Hiding Factor)
It measures the sum of the invisibilities of all methods in all classes [2].
Figure 3.1.1.a
10
When MHF value is high (100%), it indicates that all the methods are private and have limited
functionality. When MHF value is low (0%), it says that all the methods are public and
unprotected. (Anyone can access)
3.1.2 AHF (Attribute Hiding Factor)
It measures the sum of the invisibilities of all methods in all classes [2].
Figure 3.1.2.a
When AHF value is high (100%), it indicates that all the attributes are private and have limited
functionality. When AHF value is low (0%), it says that all the attributes are public.
3.1.3 MIF (Method Inheritance Factor)
It measures the sum of inherited methods in all classes [2].
Figure 3.1.3.a
11
Acceptable range for MIF is 20%-80 %( 0.2-0.8). It highly subsists of the design pattern that we
follow. High value of MIF signifies high level inheritance and low MIF signifies lack of
inheritance.
3.1.4 AIF (Attribute Inheritance Factor)
It measures the ratio of the sum of inherited attributes in all classes.
Figure 3.1.4.a
Measuring AIF margin level is roughly around 50 %( 0.5). Higher values of AIF signify high
inheritance level and it will lead to greater coupling and reduce the possibility of reuse.
3.1.5 POF (Polymorphism Factor)
It expresses the actual number of possible different polymorphic situations [2].
Figure 3.1.5.a
When POF value is 0%, it means this system doesn’t use polymorphism. If POF value is 100%, it
means all the methods in this system are overridden in all derived classes [2].
12
3.1.6 CF (Coupling Factor)
It expresses the actual couplings through classes relative to the highest amount of coupling that
are possible (Simply CF means Actual Couplings/Maximum possible couplings).
Figure 3.1.6.a
When CF value is 0%, it means no classes are coupled in this system. If CF value is 100%, it means
all classes in this system are coupled with all other classes [2].
13
4. Discussion
4.1 Analysis of metrics and further enhancements
4.1.1 Encapsulation
Figure 4.1.1.a [3]
14
Figure 4.1.1.b [3]
Figure 4.1.1.c [3]
15
4.1.1.1 Attribute Hiding Factor (AHF)
Figure 4.1.1.1.a [3]
Here we consider the attributes of Account_bank class named as balance_amt and acc_no. Let’s
take balance_amt attribute. It is a public attribute and therefore it can be accessed by rest of the
two classes (Interest_Account_bank, Account). Using AHF equation visibility of balance_amt is
2/ (3-1) =1. And value of (1-V (balance_amt)) is 0. Considering attribute of Interest_Account_bank
class and both attributes are private. So any other classes can’t access those attributes. Visibility is
0 for both the attributes.
AHF = (0+0+1+1)/ 4
= 0.5
4.1.1.1.1 Proposed extension for AHF
Here we checks whether actually class has accessed/ referenced attribute or not. It also checks
attributes of a class should be accessed by the methods within the class only. The extend AHF
equation given below.
16
Figure 4.1.1.1.1.a [3]
We calculate extend AHF using above equation. Account_bank class has balance_amt and acc_no
two attributes. And they actually referenced by the Interest_Account_bank class. So only one class
can access those two attributes. Visibility of these two attributes are 1/ (3-1) = 0.5. 1-V (Aex) is
0.5. Similarly we can compute values for other attributes. [3]
AHF extend = (0.5+0.5+1+1) /4
= 0.75
So the higher value of extended AHF shows us that attributes are not actually referenced, and
thereby giving a “Private” attribute behavior to them. Visibility of attributes is not properly used
in this system.
17
4.1.1.2 Method Hiding Factor (MHF)
Figure 4.1.1.2.a [3]
When considering the methods of Account_bank class which contain three public methods
(initialize_data(), deposit_bank(), withdraw_bank()). So these methods can be accessed by rest of
the other two classes. Therefore using MHF equation the visibility of all three methods is 2/(3-
1)=1. Value of (1-V(mi)) is 0 for all three methods. If we consider Interest_Account_bank class,
it has initialize_interest, add_interest_monthly and get_balance. Get_balance is a private method.
So it cannot be accessed by outside classes. So its visibility is 0 and (1-V(Mmi)) is 1.
MHF = (0+0+0+0+0+1)/6
= 0.17
4.1.1.2.1 Proposed extension for MHF
Here we check whether actually class has accessed/ referenced method or not. It also check
methods of a class should be accessed within the class only. The extend MHF equation given
below.
18
Figure 4.1.1.2.1.a [3]
We calculate extend MHF using above equation. For the methods deposit_bank, withdraw_bank
of Account_bank class have been actually referenced by the Interest_Account_bank class. So only
one class can access those two methods. Visibility of these two methods are 1/ (3-1) = 0.5. 1-V
(Aex) is 0.5. Similarly we can compute values for other attributes.
MHF extend = (0.5+0.5+0.5+1+1+1) /6
= 0.75
So the higher value of extended AHF shows us that methods are not actually referenced. Visibility
of attributes is not properly used by outside classes.
19
4.1.2 Inheritance
Figure 4.1.2.a
4.1.2.1 Attribute Inheritance Factor (AIF)
Table 4.1.2.1.1
Classes AIF Extended AIF

value for each class value for each class
Person 0.00 0.00

Doctor 0.36 0.67
Consultant 0.54 0.86
Medical_Officer 0.54 0.86
Patient 0.36 0.67
OPD_Patient 0.45 0.83
Addmitted_Patient 0.45 0.83
Total AIF value for the system,
AIF= (0+4+6+6+4+5+5)/ (11+11+11+11+11+11+11) = 0.39
20
The numerator of this equation is the number of attributes inherited from parent/ ancestor classes
for each class. “Person” is the base class. So it does not inherit any attribute. “Doctor” class inherits
four attributes. ” Consultant” class inherits six attributes from “Doctor” & “Person” classes. ”
Medical_Officer” class also inherits six attributes. For the rest of the classes of the above
inheritance tree, this formula is applied.
The Denominator of this equation is the total number of attributes that are used in each class. So
denominator is 11 for each class.
4.1.2.1.1 Proposed extension for AIF
Here we modify the denominator of AIF equation to that “Total No of attributes that a class Ci can
reference”. So the equation is modified as follow.
Figure 4.1.2.1.1.a
We calculate AIF extend using above equation. The numerator remains the same. But the
denominator change as we consider the attributes of parent/ancestor classes of class Ci the
attributes that are inside the Ci class only.
“Person” is the root class and we consider only four attributes created inside it. “Doctor” class
inherits four attributes from “Person” class and two attributes created inside it. The no of attributes
that take in to consideration is six. Similarly denominators are determined for other classes.
Extended AIF = (0+4+6+6+4+5+5)/ (4+6+7+7+5+6+6)
21
= 0.73
Here extended AIF value is given clear idea about that inheritance level of the system is not
acceptable because it is greater than 0.5.
4.1.2.2 Method Inheritance Factor (MIF)
Table 4.1.2.2.1
Classes MIF value for each class Extended MIF value for each
class
Person 0.00 0.00

Doctor 0.14 0.50
Consultant 0.29 0.67
Medical_Officer 0.29 0.67
Patient 0.14 0.50
OPD_Patient 0.29 0.67
Addmitted_Patient 0.29 0.67
Total MIF value for the system,
MIF= (0+2+4+4+2+4+4)/ (14+14+14+14+14+14+14)
= 0.18
The numerator of this equation is the number of methods inherited from parent/ancestor classes
for each class. The Denominator of this equation is the total number methods that are used in each
class. So denominator is 14 for each class.
4.1.2.2.1 Proposed extension for MIF
Here we modify the denominator of MIF equation to that “Total No of methods that a class Ci can
reference”. So the equation is modified as follow.
22
Figure 4.1.2.2.1.a
We calculate MIF extend using above equation. The numerator remains the same. But the
denominator change as we consider the methods of parent/ancestor classes of class Ci the methods
that are inside the Ci class only.
“Person” is the root class and we consider only two methods owns it. “Doctor” class inherits two
methods from “Person” class and two methods created inside it. The no of attributes that take in
to consideration is four. Similarly denominators are determined for other classes.
Extended MIF = (0+4+6+6+4+5+5)/ (2+4+6+6+4+6+6)
= 0.57
Here extended MIF value is given clear idea about that inheritance level of the system is not
acceptable because it is between range 0.2 and 0.8.
23
4.1.3 Polymorphism
4.1.3.1 Polymorphism Factor (PF)
Figure 4.1.3.1.a
Table 4.1.3.1.1
Class Name Overrides(M0) New Methods(Mn) Decendents(Dc)

Mammal 0 3 2
Reptile 0 2 2
Dog 1 1 0
Primate 2 0 0
Snake 1 1 0
Turtle 0 2 0
PF = overrides/ Sum for each class (new methods*descendants)
PF = 4/ (6+4)
= 4/(3*2)+(2*2)+(1*0)+(0*0)+(1*0)+(2*0)
= 0.4*100%
= 40%
24
4.1.4 Coupling
4.1.4.1Coupling Factor (CF)
CF= Actual number of couplings/ Maximum possible number of couplings in the system
E.g. Class X is coupled to class Y if X calls methods or accesses variables of class

B.
In other way round, class Y is coupled to class X only if Y calls or accesses
Variables of X.
Y is not coupled to X if there is no calls/access from Y to X.
When all classes are coupled to (and from) all other classes, maximum possible couplings are
happened.
If all classes are coupled to all other classes, CF=100%. If no classes are coupled, CF=0%.
Coupling relations increase complexity. Its decrease encapsulation and potential reuse, and limit
understandability and reusability. Very high values of CF should be avoided. However classes
cooperate somehow, and CF is expected to be lower bounded. It has been suggest that CF should
not exceed 12%. But we can’t comment that is a viable upper limits for all systems.
The definition of coupling for CF equals to the definition used for CBO. But there are some
differences.
 In CF, access to both shared and non-shared variables are counted. In CBO, access to
shared variables are not counted.
 Coupling is counted in both directions. If class X calls Y, and Y calls X in turn, it counts
as 2 coupling. For CBO this count is consider as one coupling.
 Couplings due to the use of the Inherits statement are not included in CF, but they are
included in CBO.
25
4.2 Advantages of the MOOD metric
4.2.1 Low coupling
Coupling measures the module interdependence. It indicates how closely a module is tied to other
modules. If modules are tightly coupled they can’t easily understand in isolation, so the reusability
is reduced. For an accurate metrics it should have low coupling. [2]
In Object Oriented design metrics, low coupling is one of its advantages.
4.2.2 High cohesion
Cohesion indicates about the functional strength of a module. It further explains how it can perform
a single function well and how it operates independently. Cohesion reduces generating errors and
it leads to reuse. It reduces the complexity because modules can understand in isolation. Therefore
lack of cohesion of methods (LCOM) should be low. [2]
In Object oriented design metrics, low LCOM is one of its advantages.
4.2.3 Lower Cyclomatic Complexity
Cyclomatic complexity (Vg) measures no of linearly independent paths in a program. When Vg is

too high it is difficult to maintain a code. [2]
In Object Oriented design metrics, lower Cyclomatic complexity is one of its advantages.
4.2.4 Higher Encapsulation
Encapsulation indicates information hiding. In encapsulation the user can only refer the interface
of an object. The implementation part is hidden from the user. There are two sub parts in
encapsulation. They are, Attribute hiding factor and method hiding factor. [2]
In Object Oriented design metrics, both above two factors are high is one of its advantages.
4.2.5 Low Depth of Inheritance Tree (DIT)
DIT is the maximum length from root to leaf class. It measures how many super-classes can be
affecting a class. DIT increases the reusability. [2]
26
In Object Oriented design metrics, lower value of DIT is one of its advantages.
4.2.6 Low Number of Children (NOC)
It indicates no of subclasses of each main class. When increasing no of subclasses it is difficult to

maintain and to test the software. The changes that are done to the parent class are affecting to the
child class as well. Therefore the maintainability is low. [2]
In Object Oriented design metrics, lower NOC is one of its advantages.
4.2.7 Lower value of weighted methods per class (WMC)
Individual class’s complexity is measured by WMC. When a class consists of more number of
functions, then it increases its complexity. Therefore where there are more complexity,
propagation of errors are high. Less number of methods make better for reusability and usability.
[2]
In Object Oriented design metrics, lower WMC is one of its advantages.
4.2.8 Lower value of Lines of code (LOC)
Projects that have fewer lines of code need less maintainable. [2]
In Object Oriented design metrics, lower LOC value is one of its advantages.
4.3 Drawbacks of the MOOD metric
 Support only for Object Oriented paradigm.

 Lack automation.
 No conversion criteria between Object Oriented metrics and any other.
 Doesn’t deal with full life-cycle issues.
27
5. Conclusion
After considering about all of the above factors in this research we suggest our detailed analysis
of the MOOD metrics can use in organizations. The MOOD metrics are considered as a good
metrics. And also MOOD metrics are among the best of the many metrics currently available.
MOOD metric data supplies a fast and quick feedback for software managers and software
designers. Throughout collecting, analyzing and measuring data we can foretell the software
design quality. MOOD metrics can leads to a noticeable reduction in cost of the product
implementation and product quality improvements. These fats acts a very important role in
measuring complexity and this will provide more accurate results. And these factors are very
important when selecting this metric. So according to our opinion, this metric is motivating the
software developers to get feedbacks about the quality in design and the implementation of the
developing product. This gives an ability to improve the quality of the product so early.
In object oriented systems MOOD metrics are very important. Therefore MOOD metrics
would matches for all the languages in all kind of development environments. And also for
different kind of application domains .MOOD metric is the guideline which is giving an idea of
the progress of the project and the quality of the design.
28
References
 [1] “SETM”, SLIIT [2015], [HTML].

Available:http://courseweb.sliit.lk/course/view.php?id=70
 [2]“An Introduction to Object-Oriented Metrics”,
Available: http://agile.csc.ncsu.edu/SEMaterials/OOMetrics.htm
 [3] Shreya Gupta, Ratna Sanyal,” Advanced Object Oriented Metrics for Process
Measurement”, ICSEA 2011
 [4] Dr. Linda H. Rosenberg, “Applying and Interpreting Object Oriented Metrics”
 [5] “MOOD and MOOD2 metrics”, Available: http://www.aivosto.com/project/help/pm-

oo-mood.html, [Accessed: November 11, 2015]
 [6] Muktamyee Sarker, Jürgen Börstler(Supervisor),” An overview of Object Oriented
Design Metrics”,Master Thesis, Department of Computer Science, Umeå University,
Sweden, June 23, 2005.
 [7] David P. Tegarden,Steven D. Sheetz, David E. Monarchi,”Effectiveness of
Traditional Software Metrics for Object-Oriented Systems”
 [8] Capers Jones, Chief Scientist Emeritus,“STRENGTHS AND WEAKNESSES OF

SOFTWARE METRICS”, March 22, 2006, Version 5
29

An Analysis and Enhancements To MOOD Metrics

Enviado por

Dados do documento

Descrição original:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

An Analysis and Enhancements To MOOD Metrics

Enviado por

Direitos autorais:

Formatos disponíveis

“An Analysis and Enhancements to MOOD metrics”

List of Figures and Tables…………………………………………………………………………6

2.1 Software complexity…………………………………………………………………..8

3. Description about the metric……………………………………………………..………11

3.1 MOOD metrics………………………………………………………………………11

3.1.1 MHF (Method Hiding Factor)…………………………..…………………11

3.1.2 AHF (Attribute Hiding Factor)…………………………………………….12

3.1.3 MIF (Method Inheritance Factor)….............................................................12

3.1.4 AIF (Attribute Inheritance Factor)………………………………………....13

3.1.5 POF (Polymorphism Factor)……………………………………………….13

3.1.6 CF (Coupling Factor)……………...……………………………………….14

4.1 Analysis of metrics and further enhancements……………………………………...15

4.1.1.1 Attribute Hiding Factor (AHF)…………………………….…….17

4.1.1.1.1 Proposed extension for AHF…………………………...17

4.1.1.2 Method Hiding Factor (MHF)…………………………………...19

4.1.1.2.1 Proposed extension for MHF…………………………..19

4.1.2.1 Attribute Inheritance Factor (AIF)……………………………….21

4.1.2.1.1 Proposed extension for AIF……………………………22

4.1.2.2 Method Inheritance Factor (MIF)………………………………..23

4.1.2.2.1 Proposed extension for MIF……………………………23

4.1.3.1 Polymorphism Factor (PF)……………………………………….25

4.2 Advantages of the MOOD metric……………………………………………………27

4.2.1 Low coupling………………………………………………………………27

4.2.2 High cohesion……………………………………………………………...27

4.2.3 Lower Cyclomatic Complexity…………………………………………….27

4.2.4 Higher Encapsulation……………………………………………………....27

4.2.5 Low Depth of Inheritance Tree (DIT)……………………………………..27

4.2.6 Low Number of Children (NOC)…………………………………………..28

4.2.7 Lower value of weighted methods per class (WMC)…………………...…28

4.2.8 Lower value of Lines of code (LOC)………………………………………28

4.3 Drawbacks of the MOOD metric…………………………………………………….28

List of Figures and Tables

Figure 3.1.5.a- Equation for calculating the POF (Polymorphism Factor)

Figure 3.1.6.a- Equation for calculating the CF (Coupling Factor)

Figure 4.1.1.a- Encapsulation examples

Figure 4.1.1.b- Encapsulation examples

Figure 4.1.1.c- Encapsulation examples

Figure 4.1.1.1.a- Attribute Hiding Factor (AHF) examples

Figure 4.1.1.2.a- Method Hiding Factor (MHF) examples

Figure 4.1.2.a- Inheritance examples

Figure 4.1.3.1.a- Polymorphism examples

Table 4.1.2.2.1- Method Inheritance Factor (MIF) example

Table 4.1.3.1.1- Polymorphism Factor (PF) example

There are several issues of conventional metrics.

1) Doesn’t provide an enough sound theoretical foundation.

2.1 Software complexity and its usages.

Software complexity is introduced as a natural result of the functional complexity. Software

2.2 Reasons for proposing OO complexity metrics and their evolving up to

3. Description about the metric

3.1 MOOD metrics

3.1.1 MHF (Method Hiding Factor)

3.1.2 AHF (Attribute Hiding Factor)

3.1.3 MIF (Method Inheritance Factor)

It measures the sum of inherited methods in all classes [2].

3.1.4 AIF (Attribute Inheritance Factor)

It measures the ratio of the sum of inherited attributes in all classes.

3.1.5 POF (Polymorphism Factor)

It expresses the actual number of possible different polymorphic situations [2].

3.1.6 CF (Coupling Factor)

4.1 Analysis of metrics and further enhancements

Figure 4.1.1.a [3]

Figure 4.1.1.b [3]