Object-Oriented Design Quality Models

A Survey and Comparison

Mohamed El-Wakil
Ali El-Bastawisi
Mokhtar Boshra
Information Systems Department
{Mohamed.elwakil@acm.org,
ali.elbastawisi@link.net,
mbriad@cu.edu.eg}

Ali Fahmy
Computer Science Department
afahmy@mailer.eun.eg

Faculty of Computers and Information,

Cairo University,
Cairo, Egypt

Abstract
Since 1994, many Object-Oriented Design (OOD) quality models had appeared. OOD
quality models aim is assessing OOD quality characteristics, such as maintainability, in a
quantitative way through establishing relationships between OOD quality characteristics,
and metrics computable from OOD diagrams, such as Depth of Inheritance Tree (DIT). This
paper presents the results of our survey of the major OOD quality models appeared in
literature since the MOOSE model in 1994, till the QMOOD model in 2002, then it proposes
a set of desirable properties that should be possessed by OOD quality models and a
comparison among the presented models with respect to the proposed desirable properties
set
Keywords: Information Systems quality, Object-Oriented Information Systems, ObjectOriented metrics, Object-Oriented quality models, quality assessment, UML.
1 Introduction
Since the famous statement "What is not measurable make measurable" of Galileo Galilei
(1564 - 1642) it has been a major goal in science to quantify observations as a way to
understand and control the underlying causes. One of the important observations that needs
quantification in the Information Systems discipline is the quality of Information Systems.
Producing a high quality information system (IS) is a goal required by all the stakeholders
involved in any IS project. A major prerequisite to attain a high quality IS, is the continuous
and early assessment of its quality. Assessing the IS quality in the early stages of its
development life cycle signals any omissions or weaknesses that need to be addressed, and
allows taking the necessarily measures to deviate such deficiencies as early as possible, thus,
reducing the overall cost of IS development process, and increasing the IS quality level.
Quality, as it applies to IS and the process of IS development, has two views; namely: the use
view and the production view. The use view of IS quality is concerned with the extent to
which the IS meets its intended organizational requirements; how much added-value the IS
gives to its users, and how much it is easy to use and learn. The production view of IS quality
is concerned with the IS software component quality.

The quality of the software component, of any computerized information system, influences
the IS quality, as a whole, up to a very large extent. Analogously, software design quality
affects the software end product (i.e. implemented applications) quality extensively. So, there
is an intense need to guarantee the quality of the design. To achieve a high quality design
there must be means to judge designs against established desirable attributes (e.g.
maintainability). This judgment should be quantitative and objective to be applicable.
Fortunately, information systems development projects that adhere to Object-oriented
Analysis and Design (OOAD) approach tend to have many design documents available at
early stages of the Software Development Life Cycle (SDLC). Over and above, design
documents (e.g. class diagrams) produced by pursuing OOAD are likely to contain much
information that facilitates assessing the design.
Object-oriented design quality models are means for judging Object-oriented Designs. OOD
quality models work by establishing relationships between desirable design attributes, such as
maintainability and reusability and reckonable OOD metrics, such as depth of inheritance
tree.
Another prominent benefit of utilizing object-oriented design quality models is predicting
estimations about the quality of the information system software component as a whole.
In general, quality models consist of four parts:
1. Objectives: which are the quality characteristics that the model claims to assess. (e.g.
maintainability)
2. Metrics: which is a set of quantitative design properties, that should be computable
from a given design diagram. (e.g. Depth of Inheritance Tree DIT)
3. Relationships: Ways to express the association between Objectives and Metrics. (e.g.
classes deep in the classes hierarchy are harder to maintain)
4. (Optional) Thresholds: that set upper/lower limits for metrics to fall within, to
express a given trait. (e.g. For better maintainability the DIT should not exceed 6)
In the next section, the first object-oriented quality model (MOOSE) is presented, followed
by the Lorenz and Kidd metrics suite in section 3. In section 4, MOOD model is introduced,
followed by QMOOD model in section 5. In section 6, we introduce six desirable properties
that quality models should possess, and then, assess the presented quality models against
these desirable properties.
2 MOOSE
When Chidamber and Kemmerer Introduced the MOOSE (Metrics for Object-Oriented
Software Engineering) metrics suite [1], also known as C.K. metrics suite, they inaugurated a
plethora of Object-Oriented design metrics suits. Since 1994, many other OOD metrics suites
[18,22,11,5] were presented; most of them are built upon the original C.K. metrics suite.
Also, much effort [1,6] was devoted for empirically validating the original C.K. metrics and
linking them to OOD quality attributes. Brito [7] published a formalization of C.K metrics
based on the Object Constraint Language OCL.
The C.K. metrics suite consists of six metrics that assess different characteristics of the OOD:

1. The Weighted Method Per Class (WMC) assesses complexity of a class through
aggregating a complexity measure of its methods. Chidamber and Kemerer did not state,
deliberately, a complexity measure to use, leaving the matter as an implementation detail.
Given that the WMC is computed after the design phase, and before the implementation
phase, it is not possible to use traditional code-based complexity measures such as
McCabe Cyclomatic Complexity (CC) [9]. A viable assessment for methods complexity
would be based on the methods attributes complexity. Another commonly used solution,
is to consider the complexities of all methods as unity, in this case, the WMC would be a
count for the number of methods in a class, and then, considered as a measure of the size,
not the complexity [9]
2. The Depth of Inheritance Tree (DIT) assess how deep, in a class hierarchy, a class is.
This metric assesses the potential of reuse of a class and its probable ease of
maintenance. A class with small DIT, has much potential for reuse. (i.e. it tends to be a
general abstract class). On the other side, as a class gets deeper into a class hierarchy, it
becomes more difficult to maintain, due to the increased mental burden needed to capture
its functionally.
3. The Number Of Children (NOC) is a simple measure of the number of classes associated
with a given class using an inheritance relationship. It could be used to assess the
potential influence a class has on the overall design. God classes [10] (i.e. classes with
many children) are considered a bad design habit that occurs frequently. NOC helps
detecting such classes.
4. The Coupling Between Object Classes (CBO) of a class is defined as the number of
other classes to which it is coupled. A class A is coupled to another class B , if A uses
methods or attributes of class B. The information available in a typical class diagram
dose not allow determining the methods usage part of CBO (i.e. whether class A uses
method X in class B), but it is possible to determine whether a class A is using an
attribute Y in class B or not (if attribute Y is a parameter of a method in class A). CBO is
beneficial in judging how complex the testing of various parts of a design are likely to
be [1]. A modular and encapsulated design shall yield a low CBO, and this is a desired
situation. The more independent the class is, the easier to test and/or reuse it.
5. The Response For a Class (RFC) is defined as a count of the set of methods that can be
potentially executed in response to a message received by an instance of the class.
6. The Lack of COhesion in Methods (LCOM) is the difference between the number of
methods whose similarity is zero and the number of methods whose similarity is not
zero. The similarity of two methods is the number of attributes used in common. LCOM
can judge cohesiveness among class methods. Low LCOM indicates high cohesiveness,
and vice versa. High LCOM indicates a class that shall be considered for splitting into
two or more classes. However, a LCOM measure of zero is not a strong evidence that a
class enjoys cohesiveness.
3 Lorenz and Kidd Object-Oriented Metrics
In their fundamental book about software quality [5] Lorenz and Kidd introduced many
metrics to quantify software quality assessment. Lorenz and Kidd metrics were accompanied
by a justification for being considered as metrics. Eleven metrics introduced by Lorenz and

Kidd are applicable to class diagrams. A description of these metrics and the rationale behind
them is given; they are classified into three metrics categories:
1. Class size metrics, which deal with quantifying an individual class:
a. Number of Public Methods (NPM). This is a count of the number of public
methods in a class. It is used to help estimating the amount of work to develop
a class.
b. Number of Methods (NM). The total number of methods in a class counts all
public, private and protected methods. This metric is a useful indication of the
classes which may be trying to do too much work themselves; i.e., they
provide too much functionality.
c. Number of Public Variables per class (NPV). This metric counts the number
of public variables in a class. Lorenz and Kidd consider the number of
variables in a class to be one measure of its size. The fact that one class has
more public variables than another might imply that the class has more
relationships with other objects and, as such, is more likely to be a key class.
d. Number of Variables per class (NV). The total number of variables including
public, private and protected variables.
e. Number of Class Variables (NCV)
f. Number of Class Methods (NCM)
2. Class Inheritance metrics, which look at the quality of the classes use of inheritance:
a. Number of Methods Inherited (NMI). This metric measures the number of
methods inherited by a subclass. No mention is made as to whether that
inheritance is public or private.
b. Number of Methods Overridden (NMO). A large number of overridden
methods indicates a design problem, indicating that those methods were
overridden as a design afterthought. It is suggested that a subclass should
really be a specialization of its super classes, resulting in new unique names
for methods.
c. Number of New Methods (NNA). The normal expectation for a subclass is
that it will further specialize (or add) methods to the super class object. A
method is defined as an added method in a subclass if there is no method of
the same name in any of its super classes.
3. Class Internals metrics, which look at general characteristics of classes.
a. Average parameters per Method (APM) which is defined as Total Number
Parameters in a class / Total number of methods. Lorenz and Kidd argue that
APM should not exceed 0.7
b. Specialization Index: (SIX) is calculated as (NMO*DIT)/NM This metric
looks at the quality of the classes use of inheritance. The specialization index
measures to what extent subclasses redefine the behavior of their super
classes.
4 MOOD
Metrics for Object-Oriented Design (MOOD) suite was
Rogerio Carpuca in 1994 [11], embedded in a quality
validated in 1996 [13], a newer version (MOOD2) and
automation tool, were introduced in 1998 [14]. A formal
metrics using OCL [17] appeared in 2003.

proposed by Fernando Brito and

model in 1995 [12] empirically
MOODKIT, a metrics collection
method for representing MOOD2

MOOD objective was to enable identifying quality Object-Oriented designs by means of

quantitative evaluation (i.e. metrics) of the object-oriented paradigm abstractions (e.g.
encapsulation) that are supposed to be responsible for internal quality, and to be able to
express external quality attributes (e.g. defect density) as functions of these metrics. The
original MOOD set consisted of eight metrics: Method Inheritance Factor (MIF), Attribute
Inheritance Factor (AIF), Coupling Factor (CF), Polymorphism Factor (PF) , Method Hiding
Factor (MHF), Attribute Hiding Factor (AHF), Clustering Factor (CLF) and Reuse Factor
(RF). These factors are percentages that measure the presence degree of OOD desired
attributes. Hence their values are ranges from 0 to one.
1. The Method Hiding Factor (MHF) of a class diagram represents the percentage of
invisibilities of methods in a class diagram (degree of methods encapsulation). The MHF
is computed by dividing the number of all visible methods in all classes by the number of
all methods in all classes.
2. The Attribute Hiding Factor (AHF) of a class diagram represents the percentage of
invisibilities of attributes in a class diagram (degree of attributes encapsulation). The
AHF is computed by dividing the number of visible attributes in a class diagram by the
number of all attributes in a class diagram.
3. The Method Inheritance Factor (MIF) of a class diagram represents the percentage of
effective inheritance of methods. The MIF is computed by dividing the number of all
inherited methods in all classes by the sum of all methods available (inherited and locally
defined) of all classes.
4. The Attribute Inheritance Factor (AIF) of a class diagram the percentage of effective
inheritance of attributes. The AIF is computed by dividing the number of all inherited
attribute in all classes by the sum of all attributes available (inherited and locally defined)
of all classes.
5. The Polymorphism Factor (PF) represents the actual number of possible different
polymorphic situations with respect to the maximum number of possible distinct
polymorphic situations. The PF is computed by dividing the total number of overridden
methods in all classes by the result of multiplying the number of new methods times the
number of descendants for all classes, respectively.
6. The Coupling Factor (CF) of a class diagram represents the percentage of couplings
among classes, not imputable to inheritance, with respect to the maximum possible
number of couplings in the class diagram. The CF is computed by dividing the number
of associations , not related to inheritance, between all classes by the number of classes
squared minus the number of classes.
7. The Clustering Factor (CLF) of a class diagram represents percentage of actual number
of standalone class hierarchies (clusters) with respect to the maximum possible number
of class clusters, in a class diagram. The CLF is computed by dividing the number of
class clusters in by the number of classes in a class diagram.
8. The Reuse Factor (RF) of a class diagram represents the percentage of classes that are
specializations (children) of previously defined classes. The parent classes may be
external to the class diagram (from a library such as MFC or OWL) or internal from
super classes. Computing RF precisely is not possible with class diagrams solely, unless
they are augmented by external libraries usage information.
Brito and others in [14] proposed MOODKIT G2, depicted below in Figure 1, which is a tool
that consists of two tiers. Tier 1 is a collection of parsers that accept input from different
OOD formalisms such as OMT, Fusion, C++ and Java, then outputs the OOD constructs,

inputted earlier, represented using a proposed OOD specification language (Generic ObjectOriented Design Language? Yes! GOODLY). The second tier processes GOODLY
specifications to verify its completeness and correctness, and then extract MOOD metrics to
be stored in a repository for later utilization. Such an architecture will be helpful in situations
when different object-oriented formalisms are used to design/develop different parts of the
same system. (e.g. systems with parts developed using Java and other parts developed using
C++)

Figure 1: MOODKIT G2 Architecture [14]

The MOOD2 set, referenced in [14], added many metrics to the MOOD set, however, the
definitions of MOOD2 metrics are detailed in an internal report [16] that is not available in
public.
In [17] Brito and others introduced FLAME -a Formal Library for Aiding Metrics
Extraction- that defined OOD metrics extractable from UML class diagrams in terms of the
Object Constraint Language (OCL). However, OCL seems to be ineffective for such a
purpose, since it is not rich enough to represent computationally complex metrics.
5 QMOOD
The QMOOD [18] (Quality Model for Object-Oriented Design) is a comprehensive quality
model that establishes a clearly defined and empirically validated model to assess OOD
quality attributes such as understandability and reusability, and relates it through
mathematical formulas, with structural OOD properties such as encapsulation and coupling.
Also, it presents the OOD metrics needed to quantify these OOD properties.

The QMOOD model consists of six equations that establish relationship between six OOD
quality attributes (reusability, flexibility, understandability, functionality, extendibility, and
effectiveness) and eleven design properties (see Figure 2 below) . How to measure these
design properties is also a part of QMOOD.
For example, reusability is a function of the coupling measure, cohesion measure, messaging
measure, and the design size. The coupling measure is quantified using Direct Class Coupling
(DCC) metric. The cohesion measure is quantified using Cohesion Among Methods in a
Class (CAM) metric. The Messaging metric is quantified by Class Interface Size (CIS)
metric. Finally, design size is quantified by Design Size in Classes (DSC) metric. All these
are measurable directly from class diagrams, and applicable to UML class diagrams.

Figure 2: QMOOD quality attributes, design properties and design metrics [18]
6 Desirable properties of OOD quality models
Based on our survey of the existing OOD quality models, we propose a set of properties
that should be exhibited by any OOD quality model to be of practical use. Lacking any of
these properties will result in an inapplicable quality model.
1. Depend on high level design features only. High level design features are those
design models available early in software development life cycle, such as abstract
class diagrams (i.e. without implementation). Depending on high level design features
allow assessing the design in its early stages.
2. The model objectives, quality characteristics to be assessed, should be stated
explicitly. Some models [19, 20, 5, and 21] just introduce metrics without stating how
these metrics could be used to assess quality.
3. The metrics should be precisely defined. Ambiguity in metrics definitions allows
many interpretations for the same metric, for example, in [1] the Weighted Method
per Class metric does not state clearly what methods are to be considered. Are
inherited methods considered? Are overridden methods included? What about
overloaded methods? Does visibility affect the counting? These and other question
will arise when it comes to applying the model.

4. The models should express the relationships between the characteristics and
design metrics in a clear, preferably, formal manner. Just stating that a given set
of metrics affect fault-proneness, is not enough. A formal expression that involves
metrics and how they coincide to the assessed characteristic is very important. This
formal expression could be in the form of a mathematical equation [18] or a set of
thresholds within which the metrics should lay for the design to be considered
adhering to desired design characteristic. Some other formal methods are possible:
Genero in [22] uses fuzzy classification and regression trees to classify design
diagrams with respect to their ease of maintainability into one of seven levels.
5. There should be an interpretation of the results. The famous Lord Kevin quote
The degree to which you can express something in numbers is the degree to which
you really understand it [24] is overly exaggerated. Numbers are no more than
numbers! They do not have a meaning by their own. Till the values produced by a
model are given interpretations that could be used in making decisions, there is no
extra understanding is gained.
6. Models should be validated empirically. Quality models could be developed based
on a persons own expertise. However, a proof of the validity of any proposed model
is a strong support to its thesis. Empirical validation of proposed models received a
great attention in the literature [23,3,8,15]. Empirical validation works, in general, by
assessing the quality characteristics of a given design in two ways, one way using the
proposed model, the other way using human judgment. The confidence we can put on
the proposed model, depends on the degree of coincidence between the human
assessment and the model assessment. Models without validation are always in doubt
concerning their correctness. Hence, only validated models were considered in this
paper and in our work in general.
The results of assessing the presented OOD quality models against our proposed OOD
quality desirable properties are summarized in table 1:
Property
Dependence on high
level design
characteristics only
Explicit quality
characteristics

MOOSE
NO 1

LK OO Metrics
YES

MOOD
YES

QMOOD
YES

NO 2

NO 3

Error Density, Fault

Density and
Normalized Rework

Precise metrics
definitions
Formal relationships

Yes, except the

WMC
NO 2

YES

YES

Reusability,
Flexibility,
Understandability,
Extendibility, and
Effectiveness
YES

NO

YES (Pearson r
YES (Equations)
correlation
coefficients)
NO
YES
YES
NO 2
Results interpretation
Validated
NO
Validated [13]
Validated [11]
Empirical validation
Table 1: Assessment of the four major OOD quality models against our proposed OOD
quality models desirable properties.

Chidamber and Kemmerer metric set focuses on class level metrics and that several of them
are highly dependent on low level metrics for their derivation, and as such are not ideally
suited to early stage design analysis.
2

The original MOOSE suite did not refer to any quality characteristic, however, later
experiments linked the MOOSE with maintenance effort [4] and fault proneness [3]
3

Lorenz and Kidd metrics are criticized [2] for being mere counts of class properties such as
the number of public methods, the number of all instance methods, the number of all class
methods and so.
7 Conclusion
In this paper, we have surveyed four object-oriented design quality models. The work of
Chidamber and Kemerer has been seminal in defining, and validating quality models. Lorenz
and Kidd metrics are criticized for not being a part of a quality model, however, they have the
advantages of being well-defined, easy to collect, and could be computed in the early phases
of design. MOOD model is as a very well-defined, through mathematical formulas and OCL
statements, empirically validated, supported by a tool, and most importantly provides
thresholds that could be used to judge the metrics collected from a given design. The
QMOOD model enjoys similar properties as the MOOD model of being well-defined,
empirically validated and supported by a tool. QMOOD distinguishes itself by providing
mathematical formulas that links design quality attributes with design metrics. This allowed
computing a Total Quality Index (TQI), which was already used by [18] authors to compare
fourteen class diagrams.
We proposed a group of desirable properties for OOD quality models, and then we used them
to compare the presented OOD quality models. Based on this comparison, we conclude that
the QMOOD suite is the most complete, comprehensive, and supported suite.

References
[1] Shyam R. Chidamber and Chris F. Kemerer,1994,A METRICS SUITE FOR OBJECT
ORIENTED DESIGN , IEEE Transactions on Software Engineering, Vol. 20, No. 6, June
1994, pp. 476-493.
[2] R. Harrison, S. Counsell, and R. Nithi,1997,An Overview of Object-Oriented Design
Metrics,Proceedings of the 8th International Workshop on Software Technology and
Engineering Practice (STEP '97).
[3] Victor R. Basili , Lionel C. Brian and Walchlio L. Melo ,1996 ,Validation of ObjectOriented Design Metrics as Quality Indicators, IEEE TRANSACTIONS ON SOFTWARE
ENGINEERING, VOL. 22, NO. 10, OCTOBER 1996.
[4] Li, W. and Henry, S.,1993,Object-Oriented Metrics that predict Maintainability,
Journal of Systems and Software, 23(2), pages 111-122.
[5] Mark Lorenz, Jeff Kidd,1994,Object-Oriented Software Metrics, Prentice Hall; ISBN:
013179292X.
[6] Giancarlo Succi , Witold Pedrycz, Milorad Stefanovic, and James Miller,2003, Practical
assessment of the models for identification of defect-prone classes in object-oriented
commercial systems using design metrics, The Journal of Systems and Software 65 (2003)
112.
[7] Aline Lcia Baroni, and Fernando Brito e Abreu,2003,An OCL-Based Formalization of
the MOOSE Metric Suite, 7th ECOOP Workshop on Quantitative Approaches in ObjectOriented Software Engineering.
[8] Marcela Genero, Jos Olivas, Mario Piattini, and Francisco Romero,2001,Using metrics
to predict OO information systems maintainability,13th International Conference Advanced
Information Systems Engineering.
[9] McCabe, Thomas J. & Butler, and Charles W,1989,Design Complexity Measurement
and Testing,Communications of the ACM 32, 12 (December 1989): 1415-1425.
[10] Alexander Chatzigeorgiou,2003,Mathematical Assessment of Object-Oriented Design
Quality,IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 29, NO. 11,
NOVEMBER 2003.
[11] Fernando Brito e Abreu and Rogrio Carapua,1994,Object-Oriented Software
Engineering: Measuring and Controlling the Development Process, 4th Int. Conf. on
Software Quality, McLean, VA, USA, 3-5 October 1994.
[12] Fernando Brito e Abreu Miguel Goulo, Rita Esteves,1995 ,Toward the Design Quality
Evaluation of Object-Oriented Software Systems ,5th International Conference on Software
Quality, Austin, Texas, 23 to 26 October 1995.
[13] Fernando Brito e Abreu and Walclio Melo,1996,Evaluating the Impact of ObjectOriented Design on Software Quality,3rd Intl S/W Metrics Symposium, March 1996,
Berlin, Germany.

10

[14] Fernando Brito e Abreu and Luis Ochoa, Miguel Goulo,1999,The GOODLY Design
Language for MOOD Metrics Collection, International Workshop on Quantitative
Approaches in Object-Oriented Software Engineering.
[15] Marcela Genero, and Mario Piattini, Empirical validation of measures for class diagram
structural complexity through controlled experiments, 5th International ECOOP Workshop
on Quantitative Approaches in Object-Oriented Software Engineering.
[16] Abreu, F. Brito,1998,The MOOD2 Metrics Set ,INESC/ISEG internal report, April
1998.
[17] Aline Lcia Baroni, and Fernando Brito e Abreu,2003,A Formal Library for Aiding
Metrics Extraction ,4th International Workshop on OO Reengineering.
[18] Jagdish Bansiya, and Carl G. Davis,2002,A Hierarchical Model for Object-Oriented
Design Quality Assessment ,IEEE TRANSACTIONS ON SOFTWARE ENGINEERING,
VOL. 28, NO. 1, JANUARY 2002.
[19] Hyoseob Kim1 and Cornelia Boldyreff,2002,Developing Software Metrics Applicable
to UML Models ,6th ECOOP Workshop on Quantitative Approaches in Object-Oriented
Software Engineering.
[20] Michele Marchesi,1998,OOA Metrics for the Unified Modeling Language
,Proceedings of the 2nd Euromicro Conference on Software Maintenance and Reengineering.
[21] Michele Lanza and Stephane Ducasse,2002,Beyond Language Independent Object
Oriented Metrics: Model Independent Metrics , 6th International Workshop on Quantitative
Approaches in Object-Oriented Software Engineering.
[22] Marcela Genero, Mario Piattini and Coral Calero , 2000, Early measures for UML class
diagrams , L' Objet. Volume 6 No. 4/2000.
[23] Khaled El Emam, Saida Beniarbi, Nishith Goel, and Shesh Rai, 1999,A Validation of
Object-oriented Metrics ,National Research Council Canada Internal Report No. 43607.
[24] Kelvin, W. T. Popular Lectures and Addresses.

11