Existing classification framework for OO software metrics
Existing classification framework for OO software metrics
Metrics are key components of any engineering discipline, software engineering is no
exception. Software metrics is often used to refer to broad range of measurements for
computer software. Since the 1950s (???) when software engineering were greatly
researched on, software metrics were developed continuously and became an important
research area in the field of software engineering. The need for software metrics is now
fully recognized by the software engineering community and included in standards like
In recent years, OO technologies have emerged as a dominant software engineering
practice and are often heralded as the silver bullet for solving software problems. OO
development has proved its value for systems that must be maintained and modified. OO
software engineering adopts a systemic life cycle where system development is divided
into 4 main phrases, (1) Analysis, (2) Design, (3) Implementation and (4) Testing.
As OO technologies has some new characteristics, such as data abstraction,
encapsulation, inheritance, polymorphism, information hiding and reuse, traditional
software metrics do not readily lend themselves to the OO notions. Therefore, new ways
of measuring OO software are largely researched on.
After many years of research, many OO metrics are proposed, each targeting at a specific
phrase of the OO development life cycle. In the following subsections, some of the more
established metric suites for each of the OO phrases are briefly discussed.
2.1 Analysis Phrase
In Object Oriented Analysis, use case models are often employed to capture the
functional requirements of a software project. There is a fair amount of work on
describing and formalizing use cases, but there is a lot less on deriving metrics from use
cases. The aim and objective of measuring use cases is not to determine the quality and
design of the use case model, but as a guide for estimation of the resources that might be
needed for the software project. This information is important for project manager to plan
ahead the amount of man-power and system resource that is needed. Effective software
project estimation is one of the most challenging and important activity in software
One example of better known estimation metrics for the Analysis Phrase is development
by Gustav Karner of Objectory AB(now known as Rational Software) in 1993, known as
the “use case points method of software estimation”[?]. It uses use case model,
accompanied with environment and technical factors, to estimate the resources that is
needed for the software project. The results of use case points method indicates that it has
potential to be a reliable source of estimation, and it can have a strong impact on
estimating the size of software development projects.
Use case point is used to estimate the size and schedule of software development
projects. Early estimate of effort based on use cases can be made when there is some
understanding of the problem domain, system size and architecture at the stage at which
the estimate is made. As estimation of a project is important, this information can help
project managers to estimate the resources like software developers, testers that are
needed the project during the early phrases.
At present, the industry does not have a standard and systematic way of measuring use
cases. There are several difficulties why we are not able to get precise and accurate
values from measuring use cases:
1) Variations – There are many variations of use case specification styles and
formalities which make it very difficult to define metrics.
2) Complexity – Use cases can differ in complexity, both explicitly as written, and
implicitly in the required realization
3) Behavior – Describing behavior from the actor’s point of view can be complex,
especially if the system has states.
Karner is one of the better use case metrics, but the values generated are estimated and
only serves as a guide. Even though, it is difficult to derive a precise and accurate use
case metrics, we should not avoid use cases for estimation and rely instead on the
analysis and design realization that emerges, because relying on design and
implementation phrase metrics would delay the ability to make early estimates and will
not be satisfactory for a project manager. It is better for the project manager to obtain
estimates early for their planning purposes, and then refine them at the later phrases.
2.1.1 Summary of Use Case Points by Gustav Karner
In the implementation of “use case points” by Gustav Karner, degree of complexity of
use case and actors as well as technical and environmental factors are taken into
consideration to produce estimate for the resources needed for the project.
Firstly, the number and type of actors in the system has to be determined and referred to
as the Unadjusted Actor Weights (UAW). Actors are external to the system and
interface with it. Actors are classified as simple, average and complex with weights of 1,
2 and 3 respectively.
Secondly, the number and type of use cases in the system has to be determined which is
referred to as the Unadjusted Use Case Weight (UUCW). The use cases should be
assigned weights depending on the number of transaction, scenarios and/or classes
required to implement the use case. They are classified as Simple, Average and Complex
with weights of 5, 10 and 15 respectively. The sum of the use case weight gives the
unadjusted use case weight (UUCW). Unadjusted use case point (UUCP) is the sum of
UAW and UUCW.
UUCP = UAW + UUCW
Thirdly, we need to look into 13 technical (Tfactor) and 8 environmental (EFactor)
factors. The technical and environment factors of the project, each assigned value
between 0 and 5, will be used to derive the technical Complexity Factor (TCF) and
Environment Factor (EF) respectively. The unadjusted use case point would be adjusted
based on the values.
TCF = 0.6 + (0.01 X TFactor)
EF = 1.4 + (-0.03 X EFactor)
Finally, the AUCP is derived by
AUCP = UUCP X TCF X EF
Each AUCP would require about 20 man hours. The final estimate is obtained by
Estimated man hours = 20 X AUCP
2.2 Design Phrase
OO Design is a continuity of OO analysis. It extents and updates the analysis model, by
including class design, interactions between subsystems as well as some data storage
attributes that may be needed. Even though some of the design metrics can be collected at
the design phrase, it is difficult and not commonly done. Instead, some form of browsing
the OO Implementation (programming) using the source code that is produced to obtain
measurement for design metrics.
Unlike in the analysis phrase when our measurements aim to obtain estimates for the
software project, measurements in the design phrase aims to indicate the quality of the
design and detect possible design faults and error. We will here discuss 2 design metrics
suite which are deemed more established by the industry as some form of empirical data
are available to ensure their accuracy and usefulness. They are
1. Chidamber and Kemerer, 1994
2.2.1 Chidamber and Kemerer, OO metrics suite—3 Design metrics.
In aim of measuring the key notions of OO software, Chidamber and Kemerer, in 1994,
developed a set of six metrics to identify certain design and code traits in OO software,
like inheritance, coupling and cohesion etc. Out of the six metrics developed, 3 are
classified as design metrics and remaining as code metrics.
The 3 design metrics in the C&K OO metrics suite are Depth of Inheritance Tree (DIT),
Number Of Children (NOC) and Lack of Cohesion in methods (LCOM) and can be
1. Depth of Inheritance Tree (DIT). This metric measures the maximum level of
the inheritance hierarchy of a class. The root of the inheritance tree inherits from
no class and has a DIT count of 0. C&K suggest that DIT can be used to indicate
the complexity of the design, potential for reuse.
2. Number Of Children (NOC). This metric counts the number of immediate
subclasses belonging to a class. NOC was intended to indicate the level of reuse
in a system and a possible indicator of the level of testing required.
3. Lack of Cohesion in Methods (LCOM). This metric is intended to measure the
lack of cohesion in the methods of a class. The LCOM is a count of the number of
method pairs of similarity, in terms of attribute, that is 0 minus the count of
method pairs whose similarity is not zero. It is based on the principle that
different attributes occurring in different methods of a class causes that class to be
less cohesive than one where the same attribute is used in few methods of the
class. C&K view a lack of cohesiveness as undesirable as it is against
encapsulation. Lack of cohesion could imply that the class should probably be
split into two or more subclasses.
2.2.2 Metrics for Object Oriented Design (MOOD) by Abreu
Unlike C&K metrics, MOOD, as the name suggests, is a metrics suite that targeted
specifically to obtain measurements for the design phrase. The emphasis behind the
development of the metrics is on the features of OO design, namely inheritance,
encapsulation and coupling.
In the first proposed of MOOD, 8 metrics were in the suite. It was later refined to 6, the 2
metrics removed are Clustering Factor and Reuse factor. Each of the 6 metrics in MOOD
suite is expressed as a quotient where the numerator is the actual use of a particular
mechanism (i.e. inheritance, information hiding, coupling and polymorphism) in the
system being measured and the nominator is the maximum possible use of the same
mechanism. The value of each metric would then range from 0 (total absence), to 1
(maximum possible presence). The six metrics are summarized as:
1. Attribute Hiding Factor (AHF). This metric is the ratio of hidden (private and
protected) attributes to total attributes and is proposed as a measurement of
encapsulation and information hiding.
2. Method Hiding Factor (MHF). This metric is the ratio of the total inherited
methods and total methods defined. Similar to AHF, it is proposed as a
measurement of encapsulation and information hiding.
3. Coupling Factor (CF). CF is defined as the ratio of the maximum possible number
of couplings in the system to the actual number of couplings not imputable to
inheritance. Abreu views coupling as increasing complexity, reducing potential
reuse and limiting understandability and maintainability.
4. Polymorphism Factor (PF). PF is defined as the ratio of the actual number of
possible different polymorphic situation for a class to the maximum number of
possible distinct polymorphic situations for the class. Polymorphism arises from
inheritance, and Abreu claims that in some cases, overriding methods reduce
complexity, so increasing understandability and maintainability.
5. Attribute Inheritance Factor (AIF). AIF is defined as the ratio of the sum of
inherited attributes in all classes of the system under consideration to the total
number of available attributes for all classes. AIF is suggested to express the level
of reuse in a system. It is claimed, however, that too much reuse causes
deterioration in understandability and testability.
6. Method Inheritance Factor (MIF). MIF is defined as the ratio of the sum of
inherited methods in all classes of the system under consideration to the total
number of available methods for all classes. Just as for AIF, MIF is suggested to
express the level of reuse in a system. It could also claim to be an aid to
assessment of testing needed.
2.3 Implementation Phrase
Code metrics are used as measurements for the implementation phrase and can be
obtained by looking into the program codes. Some of the traditional software code
metrics which can be used in OO program codes. In addition, C&K metric suite defines 3
code metrics specifically for OO program codes. The metrics can be summarized as:
2.3.1 Chidamber and Kemerer, OO metrics suite – 3 Code metrics
1. Weighted Methods per Class (WMC). The sum of the complexities of the
methods in a class.
2. Coupling between objects (CBO). The number of other classes whose methods or
instance attribute(s) are used by methods of this class.
3. Response for a Class (RFC). The sum of the number of methods in the class and
the number of methods called by each of these methods, where each called
method is counted once.
2.3.2 Some code metrics from traditional software metrics
The following are some of the traditional software code metrics which remains valid
when used in an OO software environment.
1. Number of Classes. Total number of classes in a project.
2. Number of Preprocess. Total number of preprocessor lines (import) in a project.
3. Total Line of codes. Total lines of codes found in a project
(Source lines + blank lines + comment lines)
4. Total Blank Lines. Total number of blank lines in a project.
5. Comment Percentage. Ratio of comments and program code.
6. Number of Methods. Total number of methods in a project.
2.4 Testing Phrase
Today’s software applications impose new challenges for software testing. Some of the
commonly known challenges are complex application scenarios, extensive third party
integration and increased security concerns. These factors inherently make testing of
application for more complex and critical than traditional software testing.
Metric for the test phrase can be achieved by Test Effort Estimation proposed by Suresh
Nagestaran in 2001 . Test Effort Estimation provides estimation for test effort based
on the use case model. It is known that a use case to test case mapping is possible. This
means that UCP figure for development can be indirectly used to provide a figure for the
number of test cases as well as the total test effort that is needed for the software project.
This approach towards estimating test efforts is very much similar to UCP [Use Case
Points] to estimate development resource. The approach for estimation using UCP only
needs slight modification in order to be useful to estimate test efforts.
The approach towards estimating test efforts involves 6 basics steps with the first 3 steps
similar to UCP.
1. Determine the number of actors in the system to produce UAW.
2. Determine the number of use cases in the system to produce UUCW.
3. Obtain the Unadjusted Use Case Points (UUCP). UUCP = UAW + UUCW.
4. Compute technical and environmental factors (TEF).
Factor Description Assigned Value
T1 Test Tools 5
T2 Documented inputs 5
T3 Development Environment 2
T4 Test Environment 3
T5 Test-ware reuse 3
T6 Distributed System 4
T7 Performance Objective 2
T8 Security Features 4
T9 Complex interfacing 5
Weights are assigned and multiplied to the assigned values to give the final
values. The products are all added up to give the TEF.
5. Compute adjusted UCP. The formula is
AUCP = UUCP * [0.65 + (0.01 * TEF)]
6. Compute the Effort estimation.
Effort = AUCP * [Conversion Factor]
Where Conversion Factor denotes the man hours in test effort required for a
language/technology combination. The organization will have to determine the
conversion factors for various such combinations.
…….. to be added..
Phrase Metrics Suite Author Associated Metric
Analysis Use Case Points. Gustav Karner Use Case Points
Design 1. OO Metrics Chidamber 1. Number Of Children (NOC)
Suite and Kemerer 2. Depth of Inheritance (DIT)
3. Lack Of Cohesion in Methods
2. Metrics for OO Fernando 1. Method Inheritance
Design Brito e Abreu Factor(MIF)
2. Attribute Inheritance Factor
And 3. Coupling Factor (CF)
Rogério 4. Polymorphism Factor (PF)
Carapuça 5. Method Hiding Factor (MHF)
(INESC/IST) 6. Attribute Hiding Factor (AHF)
Implementation OO Metrics Suite Chidamber 1. Weighted Methods Per Class
(Code) and Kemerer (WMC)
2. Coupling Between Objects
3. Response for a Class (RFC)
• How can OO be measured
o Phrases (OO Methodologies)
• Estimate using use case points
o Existing tools in them.
§ Lorenz and Kidd
o What do we want to achieve through measurements? (Reusability,
complexity, understandability, fault prone, inappropriate design, testing
Purpose of OO metrics.