See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/2253619

Object-Oriented Software Engineering: Measuring and Controlling the

Development Process

Article · January 1997

Source: CiteSeer

CITATIONS READS

31 4,512

1 author:

Fernando Brito e Abreu

ISCTE-Instituto Universitário de Lisboa
203 PUBLICATIONS   2,199 CITATIONS   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Automated quality model for websites View project

GESTO: UM PROCESSO EXPERIMENTAL PARA DETERMINAR O SENTIDO DE UMA OBRA DE ARQUITECTURA View project

All content following this page was uploaded by Fernando Brito e Abreu on 28 December 2012.

The user has requested enhancement of the downloaded file.

 Revised version: Originally published in Proceedings of
"4th Int. Conf. on Software Quality", McLean, VA, USA, 3-5 October 1994

Object-Oriented Software Engineering:

Measuring and Controlling the Development Process

Fernando Brito e Abreu (INESC/ISEG)

Rogério Carapuça (INESC/IST)

INESC, Rua Alves Redol, 9, Apartado 13069, 1000 Lisboa, PORTUGAL

(phone: +351-1-3100226 / fax: +351-1-525843 / email: [email protected])

technical and managerial issues, the former having

ABSTRACT
received much more attention in the past few years.
Although the benefits of Object-Orientation are mani- Several problem areas in OOSE are, among others, the
fold and it is, for certain, one of the mainstays for software adoption of the OO technology itself (i.e. paradigm shift),
production in the future, it will only achieve widespread the lack of adequate life-cycle models that support
practical acceptance when the management aspects of the reusability, the ability to assess the quality of the
software development process using this technology are development process and resulting products, and the
carefully addressed. Here, software metrics play an capability of evaluating the productivity of development
important role allowing, among other things, better teams. These last two issues are fundamental in order for
planning, the assessment of improvements, the reduction managers to control, steer and follow up software
of unpredictability, early identification of potential development efforts.
problems and productivity evaluation. This paper proposes Quality and productivity are indeed the two most im-
a set of metrics suitable for evaluating the use of the main portant input parameters for controlling any industrial
abstractions of the Object-Oriented paradigm such as process. Successful control requires some means of
inheritance, encapsulation, information hiding or measurement. The need for software metrics is now fully
polymorphism and the consequent emphasis on reuse that, recognized by the software engineering community and
together, are believed to be responsible for the increase in included in standards like the [ISO9000-3]. The reasons
software quality and development productivity. Those for using metrics in software development are mainly
metrics are aimed at helping to establish comparisons independent of the adopted paradigm, although the latter
throughout the practitioners’ community and setting deeply influences the set of metrics to choose, as its
design recommendations that may eventually become concepts and corresponding abstractions are either disjoint
organization standards. Some desirable properties for such or implemented differently [Abreu93].
a metrics set are also presented. Future lines of research This paper aims at achieving some advances towards a
are envisaged. solution to the problem of assessing quality and
productivity on OO systems and is organized as follows:
the next section introduces the specific goals of the current
1. INTRODUCTION
research work in quantitative methods applied to Object-
The continuing increase in both the amount and Orientation from which this paper originated. Section 3
complexity of the information to be handled by organi- presents a set of criteria for choosing a suitable metrics
zations, and the need to develop cheaper, more reliable, set. Section 4, the core of this paper, includes the detailed
easily alterable and reusable application systems, required proposal of a metrics set named MOOD, for guiding and
to deal with that information in an efficient and user- assessing OO design quality and potential productivity
friendly way, was the ground where Object-Oriented (OO) gains. The possible shapes of expected design
technology has bloomed in recent years. However, object- recommendations based on the MOOD set are introduced
orientation is not a panacea for successful system in section 5. Some complementary research topics that
development as noted in [Jacobson92]. The shift from deserve further effort are identified in section 6. Some
craftsmanship to industrialism must come on a more concluding remarks are presented in section 7.
fundamental level that also includes the organization of
the complete development process. Object-Oriented Soft-
2. QUALITY AND OBJECT-ORIENTATION
ware Engineering (OOSE) has, accordingly, received an
inflated attention. Its main objective is to make the OO Quality of software systems can be characterized by
software development process an engineering activity, the presence of a certain number of external1 attributes
either by adapting "traditional" software engineering tech-
niques, or by proposing its own. OOSE deals with
1 - Perceptible to purchasers, subcontractors and end users.
like functionality, reliability, usability, efficiency, main- objective. After surpassing this problem by deciding to
tainability and portability [ISO9126] which can be further adopt just a few (but not too few) metrics, we need to set
detailed. However, due to the evident difficulty and cost2 some evaluation criteria based on the goals we want to
of evaluating those attributes, most efforts on the software achieve. Without them it is relatively easy to fall in the
quality field have focused on defining and evaluating "YAM"3 trap or become swamped by the myriad of those
suitable development processes. It is believed that a proposed in the available literature. A better perspective
defined and controlled process will lead to the production on this problem can be obtained in [Zuse91]. Next we will
of quality software products and with fewer costs. Let us derive a set of criteria to help define the MOOD set.
call this approach "outside-in". Object-Orientation came Different people at different times or places should
to strengthen the complementary "inside-out" approach yield the same values when measuring the same systems.
where the quality of internal structure is supposed to be Subjectivity makes metrics comparisons throughout soft-
the key for ensuring that (external) quality and increased ware industry an impossible mission. Subjective ratings
productivity are achieved. (e.g. "Very Low", "Low", "Average", "High", "Very
Object-Orientation is well suited for what is called High") are copious in the metrics literature. That is un-
"seamless development", which basically stands for using doubtedly one of the reasons that leads to metrics
the same formalism and corresponding notation through- suspicion among software practitioners and the computer
out the life-cycle, by means of stepwise refinement. The science community in general. One road to achieve this
traditional barriers between analysis and design and objectivity is:
particularly between design and coding, characterized by
formalism shifts with corresponding translation rules, are Criterion 1: metrics determination should be formally
bound to diminish. Therefore, analysis and design play an defined
even more important role than ever. Coding, for instance,
can be considered just as a "fill-in-the-design-blanks" acti- For being useful, metrics must be collected and ana-
vity. Better internal quality is due to new abstractions lyzed throughout time in as many different projects as
brought by this paradigm such as classes, methods, possible in order to establish comparisons and derive
inheritance, polymorphism, encapsulation or messages and conclusions. However, those projects will surely vary in
a corresponding increased emphasis on reuse. However, size. If metrics other than the ones specifically designed to
the use of those abstractions can be varied, depending measure size also depend on it, no cumulative knowledge
mainly on the designer ability, so we can expect rather will be achieved. So:
different quality products to emerge, as well as different
productivity gains.
Criterion 2: non-size metrics should be system size
The aim of the research going on in our team is two-
independent
fold. First, we want to be able to identify quality OO
designs by means of quantitative evaluation (i.e. using
Metrics are supposed to represent some product or
metrics) of the use of the paradigm abstractions that are
process attribute. Thus we are faced with the issue of units
supposed to be responsible for internal quality. Second,
of measurement. Subjective or "artificial" units inevitably
we want to express some of the external quality attributes
yield to misunderstandings. Remember, for instance, the
and productivity advances as a function of those metrics.
discussions around different interpretations of LOC (lines
Our first step was to develop some metrics for OO
of code) [Albrecht83] and Function Points
designs, from a set of criteria presented in next section,
[Symons91][Dreger89]. Then:
that among other things, is expected to allow doing
comparative evaluation throughout the OO community,
and eventually help training new OO software Criterion 3: metrics should be dimensionless or ex-
practitioners by setting design standards that traduce best pressed in some consistent unit system
practice.
The cost of recovering from effects caused by an error
increases exponentially with elapsed project progress,
3. CRITERIA FOR DESIRED METRICS since its commitment. Metrics, particularly design ones,
The choice of a set of metrics exposes the pitfalls of are aimed at exposing the defects provoked by those errors
measuring too much and becoming overwhelmed by a and buried in the design. We must be able to collect
large amount of unmanageable numeric data, or measuring metrics as soon as a first design is available, if we want to
too little and not gaining sufficient insight into the desired identify the possible flaws, before too much effort is built
on top of them. Therefore:
2 - In industries other than software, quality assessment is often done by
evaluating samples of massively produced products, thus allowing to
dilute the corresponding effort (i.e. scale economy benefit). 3 - Yet Another Metric...

2
Criterion 4: metrics should be obtainable early in the • Clustering Factor
life-cycle • Polymorphism Factor
• Method Hiding Factor
Real software systems are usually built by a team of • Attribute Hiding Factor
people. Often is possible to break down the specification • Reuse Factor
in almost independent modules or subsystems. Each team Considering that metrics are intended to quantify the
member or small group of members can be responsible for presence or absence of a certain property or attribute, we
each of those subsystems. Then, we need metrics can view them as probabilities. They would then range
applicable not only to the whole system under considera- from 0 (total absence), to 1 (maximum possible presence).
tion, but also to each one of its modules or subsystems, This perspective was also used in the ESPRIT REBOOT
thus allowing to pin-point "ill-designed" ones. So: project [Stalhane92]. This kind of interpretation allows the
application of statistical theory to software metrics. For
instance, statistically independent metrics can be
Criterion 5: metrics should be down-scaleable
combined (e.g. multiplied) so that the result can still be
interpreted as a probability.
Metrics collection is a repetitive task, therefore tedious
The MOOD metrics definitions are based on a group
and boring for human beings. The worst is that it takes a
of formally defined functions and on set theory and simple
lot of time and money! Provided that criterion 1 is met,
mathematics. This fulfills criteria 1 and 6. All MOOD
and that designs are also formally defined, it is possible to
metrics are expressed as quotients where the numerator is
build some kind of syntactic analyzer that extracts from
the actual use (in the design under consideration) of a
them the needed information for computing the metrics.
given OO abstraction and the denominator is the
The effort to build such a tool is considerable but it is
maximum achievable possible value for the same
worth while. Then:
abstraction use. As a result, all metrics are size
independent and dimensionless and criteria 2 and 3 are
Criterion 6: metrics should be easily computable met. The MOOD metrics meet criterion 4 because they are
applicable as soon as a preliminary system design is
Many specification and programming languages (either available. The proposed metric set can be applied to any
graphical or textual) that support the OO paradigm existent Class Cluster (as defined in section 4.4), or any
abstractions are available in the marketplace. Each of them combination of them, and so we can say that criterion 5 is
has its own constructs that allow for implementation of also fulfilled. No reference is made to specific language
those abstractions in more or less detail. Again, the constructs, that is, MOOD metrics refer to OO abstrac-
requirement of a common base of understanding for the tions, and not to its implementations. Criterion 7 is there-
metrics analysis process, leads us to the need of avoiding fore also accomplished.
the syntactic level. Tools such as those mentioned in the
previous paragraph can guarantee this independence.
Therefore: 4.2 Encapsulation and Information Hiding
Plenty of OO analysis and design methods, as well as
Criterion 7: metrics should be language independent programming languages exist, but often different termi-
nologies are used to refer to the same abstraction with the
Several authors have suggested sets of metrics for the inevitable entanglement of non-experts. The basic OO
OO paradigm; see for instance [Bieman92, Campanai94, concepts are introduced along with metrics definitions in
Chidamber91, Karunanithi93, Yousfi92]. However, most order to help this paper to be as self-explanatory as pos-
of the proposed metrics do not fulfill all the above criteria, sible.
mainly 1, 2, 3 and 7. Objects are an encapsulation of information and be-
havior relative to some entity of the application domain
under consideration (sometimes referred as the UoD -
4. THE MOOD METRICS SET Universe of Discourse). In real systems many objects with
4.1 Introduction similar information (data) and behavior (functionality) can
be found. The class abstraction captures this reality and
The MOOD (Metrics for Object Oriented Design) set can be viewed as an abstract data type. The class
is a collection of metrics that were designed with the definition includes at least two types of features:
above defined criteria in mind. The set includes the fol- attributes (also called variables, fields or data members),
lowing metrics: which stand for the stored information and methods (also
• Method Inheritance Factor called operations, function members, tasks or routines),
• Attribute Inheritance Factor which represent the behavior. All objects created belong to
• Coupling Factor a certain class, so they are often referred as class

3
instances. Within each class all objects share the same 4.3 Inheritance
methods. The object instance variables (i.e. local data) are
Inheritance is a mechanism for expressing similarity
defined in the corresponding class.
among classes. Semantically, it allows the portrayal of
Many features defined in a class are designed for im-
generalization and specialization. As far as design is con-
plementing certain functionalities that are only relative to
cerned, it allows for the simplification of the definition of
the class itself. Those features should be hidden from
inheriting classes. When a class inherits from another, that
client programmers4, not for protection sake but for
means it can use its methods and attributes, unless they are
helping them to cope with complexity, as internal imple-
redefined locally. A class Cd that inherits directly or
mentation details do not (or should not) bring a better
perspective on how to use the services of the class. indirectly from a class Ca is said to be a descendent5 of
Another very important advantage of this information class Ca which, conversely, is called an ancestor6 of class
hiding mechanism is that the use of a class is independent Cd . Now, being more restrictive, a class Cc that inherits
of its implementation, thus allowing to alter it without
directly from a class C p is said to be a child of class C p
"side-effects". As a conclusion, all information about a
class should be private to the class, unless it is specifically which, conversely, is called a parent of class Cc .
declared public. The public part of a class is called its Inheritance can be single or multiple, depending on the
interface and should only be the "tip of the iceberg". The number of parents. The inheritance relation will be
public methods represent the services that the supplier represented here by an arrow, for instance as in
class is able to render to client classes. The hidden part is Cc → C p or Cd → Ca .
called the implementation. The number of methods
The composition of several inheritance relations
defined in class Ci is given by: defines a directed acyclic graph, often called an inheri-
Md (Ci ) = Mv ( Ci ) + Mh ( Ci ) tance hierarchy tree. A base class is the root of such an
where: inheritance hierarchy (i.e. the one that does not inherit;
• Mv ( Ci ) - number of visible methods (interface) in who has no ancestors). Formally we can define the
class Ci function:
• Mh ( Ci ) - number of hidden methods 1 iff ∀j ∈ 1, TC , ¬∃C j : Cb → C j
(implementation) in class Ci is _ base( Cb ) =
0 otherwise
Then we define the Method Hiding Factor: where TC is the total number of classes in the system
under consideration.

∑
TC
Mh (Ci ) A leaf class is a class that has no descendants. For-
MHF = i =1

∑
TC mally, we can define the function:
i =1
Md ( Ci )
1 iff ∀j ∈ 1, TC , ¬∃C j : C j → Cl
Conversely, the number of attributes defined in class is _ leaf ( Cl ) =
0 otherwise
Ci is given by:
In a class hierarchy, each class can have features either
Ad (Ci ) = Av ( Ci ) + Ah ( Ci ) inherited from its ancestors or the locally defined. These
where: latter features can be either new or a redefined version of
Av (Ci ) - number of visible attributes in class Ci inherited ones (overriding situation), or even only declared
Ah (Ci ) - number of hidden attributes in class Ci but not implemented there7. Some approaches even allow
to drop inherited features.
Then we define the Attribute Hiding Factor: For defining the MOOD set of metrics we will need
some basic class metrics. They will be introduced next, by
means of functions where the argument is the class under
∑
TC
Ah (Ci ) consideration and the returned value is the value for the
AHF = i =1

∑
TC corresponding metric. Let Ci be any class of the system
i =1
Ad (Ci )
under consideration. We define:

5 - Sometimes also called subclass.

6 - Also referred as superclass.
7 - The implementation is left to its descendants. These kind of features
4- Programmers in a team using the class, other than its creator. are usually called "deferred".

4
• Children Count, CC ( Ci ) - number of children of
Ci (note: if CC ( Ci ) = 0 then Ci is a leaf class) • Total number of Methods Inherited,
TMi = ∑k=1 Mi (Ck ) = ∑k=1 Mn (Ck )* DCC
TC TC
• Descendants Count, DC (Ci ) - number of ( k ) − Mo (Ck )
descendants of Ci
= ∑k=1 Md (Ck ) − Mo (Ck ) * DCC
TC
( k ) − Mo (Ck )
• Parents Count, PC( Ci ) - number of parents of Ci
(notes: if PC( Ci ) =0 then Ci is a base class; if
• Total number of Methods Available,
PC( Ci ) >1 we have multiple inheritance).
TMa = TMd + TMi = ∑k =1 Ma (Ck )
TC

• Ancestors Count, AC (Ci ) - number of ancestors of

= ∑k =1 Md (Ck ) − Mo (Ck ) * 1 + DC( Ck )
TC
Ci .
• Md (Ci ) - number of Methods defined in Ci
= ∑k =1 Mn (Ck )* 1 + DC(Ck )
TC
• Mn ( Ci ) - number of New8 Methods defined in Ci
• Mi ( Ci ) - number of Methods Inherited in Ci (not
Note: iff there are no overriding situations, that is,
overridden)
• Mo (Ci ) - number of Overridden Methods in Ci ∀i ∈ 1, TC Md (Ci ) = Mn (Ci )
(inherited methods that are redefined) the two expressions above become:
• Ma ( Ci ) - number of Available9 Methods in Ci
TMi = ∑k =1 Mi ( Ck ) = ∑k =1 Md (Ck ) * DC(Ck )
TC TC
The following relations hold, and can be easily trans-
posed to attributes instead of methods:
= ∑k =1 Mn (Ck ) * DC(Ck )
TC

Md (Ci ) = Mn ( Ci ) + Mo (Ci )
TMa = TMd + TMi = ∑ k =1 Ma ( Ck )
TC

Ma ( Ci ) = Md (Ci ) + Mi ( Ci )
= ∑k =1 Mn ( Ck ) * 1 + DC( Ck )
TC
= Mn (Ci ) + ∑ j =1
PC (Ci )
Ma ( C j )
where Ci → C j = ∑k =1 Md (Ck ) * 1 + DC( Ck )
TC

This last expression is recursive up the inheritance

chain, till a base class is found. The only situation in • Total Length of Inheritance Chain, (total number of
which it is not valid is when methods inherited from inheritance relations),
different parents (when PC ( Ci ) > 1 ) have the same
TLIC = ∑i =1 PC (Ci ) = ∑i =1 CC( Ci )
TC TC

designation10.
Some system metrics are now defined, based on the
above ones. The demonstration of some expressions is not • Total Number of Inheritance Paths, (total number of
included here because they are either trivial or beyond the inheritance paths from a base class to a leaf class),
scope of this paper.
TNIP =
• Total number of Methods Defined, TLIC − TC − ∑i =1 is _ base(Ci ) + is _ leaf (Ci )
TC

TMd = TMn + TMo = ∑k =1 Md (Ck )

TC
We then define the Method Inheritance Factor as:

• Total number of New Methods defined, TMi

MIF =
TMn = ∑k =1 Mn (Ck )
TC
TMa

• Total number of Methods Overridden, Note: MIF=0 means that there is no effective inheri-
TMo = ∑k =1 Mo (Ck )
TC
tance (i.e. there are no inheritance hierarchies or all
inherited methods are overridden).

8 - "New" denotes those methods that are not overriding inherited ones. Similarly, we can also define the Attribute Inheritance
9 - "Available" stands for those methods that can be invoked in Factor given by:
association with the class under consideration (i.e. those defined in that
class as well as the inherited ones).
10 - This situation is generally referred as "name clashing".

5
 TAi reuse because they do not need to drag along anything
AIF = else. We shall name them Class Clusters and the shape of
TAa each one will be of a single or several intercommunicating
inheritance hierarchy trees. For a total number of Class
where TAi and TAa have definitions similar to TMi and Clusters, TCC, we define the Clustering Factor:
TMa .
TCC
CLF =
4.4 Coupling and Clustering TC
A class Cc is called a client of class Cs , and Cs a
4.5 Polymorphism
supplier11 of class Cc , whenever Cc contains at least one
reference to a feature (method or attribute) of class Cs . Polymorphism is a greek originated word that means
"many forms". When applied to Object-Orientation, it
We will represent this client-supplier relation by
stands for the possibility of sending a message without
Cc ⇒ Cs . knowing which will be the form (class) of the object that
Some of these client-supplier relations can be viewed will bind that message to one of its interface methods. All
as communications between class instances. These the potential receiving classes belong to the same inheri-
communications should be made explicit for the sake of tance hierarchy tree. Binding can be static (at compilation
understandability. Some approaches use the designations time) or dynamic13 (at run time).
message, event or stimulus, to refer to the call that an Messages can be bound to instances of a certain class
instance of the client class does to a supplier class method. or to instances of one of its descendants and not the other
It is desirable that classes communicate with as few others way around. Consider for instance that the class ball is
as possible and even then, that they exchange as little specialized by classes tennis_ball, golf_ball, soccer_ball
information as possible [Meyer88]. and rugby_ball. If by sending the message ball.new (call
Supplier class references are not only made by means of constructor method), we get a tennis_ball or a
of messages. A supplier class type reference can be made golf_ball, everything is fine. However, if the message
inside client classes in situations such as: soccer_ball.new is sent, getting some instance of class ball
• a public or private global attribute (some languages is not acceptable as it might consist, for example, of a
only allow global attributes to be private) rugby_ball.
• a public or private method argument or local attribute If there is no overriding, a message to a class or to one
A bigger number of client-supplier relations increase of its descendants will be bound to the same method (i.e.
complexity, reduces encapsulation and potential reuse, and no polymorphism). Conversely, we will obtain the
limits understandability and maintainability. possible maximum polymorphism potential if all methods
Every class in a certain system is a potential supplier of are overridden in all classes (except the base ones, of
all other classes and vice-versa. Thus, the maximum value course). In fact, if a method M in class Ci , is overridden
of client-supplier relations12 is given by TC − TC . If
2
in all descendants of class Ci , then a message bound to M
we consider the following function:
can have DC (Ci ) possible addressees other than the
1 iff Cc ⇒ Cs ∧ Cc ≠ Cs implementation of M in class Ci . Those correspond to the
is _ client ( Cc , Cs ) = same amount of different implementations of M in Ci
0 otherwise
then, the Coupling Factor is given by: descendants (polymorphic situations). Extending this
reasoning to whole methods in the whole system, the
maximum number of possible different polymorphic
∑ ∑
TC TC
i =1 j =1
is _ client (Ci , C j ) situations is given by:
COF =
TC 2 − TC
∑
TC
i =1
Md (Ci ) * DC( Ci )
The "web" defined by client-supplier and inheritance
relations is, in real systems, a set of disjoined graphs For a given system, however, the total number of
where nodes represent classes and edges represent the possible different polymorphic situations is:
relations. Each of these graphs is a potential cluster for
∑ ∑
TC DC ( Ci )
i =1 j =1
Mo ( C j )
11 - Note that a class can be client (and therefore supplier) of itself.
12 - Here we have not considered the "harmless" reflexive client-supplier
situations, that is, a class being supplier of itself. 13 - Also called late or delayed binding.

6
Note: the inner sum refers to the descendants of Ci 1 iif Ci ∈ L
in _ library( Ci ) =
0 otherwise
Finally we define the Polymorphism Factor:
L = {classes in the reusable class library}

∑ ∑ M (C )
TC DC(Ci )
i =1 j =1 o j 5. DESIGN HEURISTICS
PF =
∑ M (C ) * DC(C )
TC
d i i By thorough interpretation of data taken from real
i =1
projects, we believe that we will be able to compute
design heuristics. Those can exhibit three shapes:
4.6 Reuse recommended lower limit (LL), recommended interval
(INT) and recommended upper limit (UL). Table 1 shows
Reuse, enforced by the OO paradigm abstractions, is
which shape applies for each of the MOOD metrics. The
expected to produce big impacts on development produc-
appropriateness of each limit (including the interval ones)
tivity and quality. It apparently14 saves a lot of develop- is expected to increase as our metrics collection and
ment time, thus reducing system costs or allowing savings analysis process proceed.
to be spent on building more functionality, quality
assurance or other activities. Reusable components are
MOOD METRIC LL INT UL
usually more carefully designed than ordinary program
code. Besides, its repeated use brings out quickly any Method Inheritance Factor x
flaws in its design or implementation. That is why those Attribute Inheritance Factor x
components tend to be of better quality, therefore Coupling Factor x
embedding that quality in systems who incorporate them. Clustering Factor x
Reuse in OO software development can mainly take Polymorphism Factor x
two shapes: reuse of library components and reuse by Method Hiding Factor x
means of inheritance. Then, we can consider three types Attribute Hiding Factor x
of classes in a given system: (i) those base classes built Reuse Factor x
totally new, (ii) those extracted from a library and finally
(iii) those that reuse existing classes by means of inheri- Table 1: Shape of design heuristics based on MOOD
tance. As stated in the inheritance section above, inherited
class definitions are usually specialized either by According to this framework, expected recommenda-
extending its features or by redefining ("overriding") tions will be of the kind:
them. This specialization effort, together with that of
building classes "from scratch" corresponds to the effec- • "Keep the Method Inheritance Factor between 0.25
tive "new" part of the system under consideration. We and 0.37"
want to quantify exactly the other part, that is, the one • "Coupling Factor should be below 0.52"
corresponding to used library classes and the fraction of • "Good Reuse Factors are those above 0.43"
all others that may be imputed to inheritance. For this Values mentioned above are irrelevant. We expect to
fraction calculation, we will only consider methods, as disclose some realistic ones in a following paper.
those are much more expensive to build and maintain than
attributes. Now we can define the Reuse Factor as:
6. FUTURE WORK

∑
TC
in _ library(Ci ) We are presently developing a tool for supporting the
RF = i =1
+ collection, storage and analysis of the MOOD metrics set.
TC The core of this tool (metrics definition dictionary, metrics
MIF * ∑i =1 1 − in _ library(Ci )
TC storage, human-machine interface) is language
+ independent. Specific implementation language stubs will
TC parse the specification code and determine the base
measure function values. The C++ stub is under
where construction and we plan to develop an Eiffel [Meyer92]
one in the near future. When the tool becomes fully
operational, we will proceed to an extensive evaluation of
available systems and try to derive and refine the values
for the limits mentioned in the design recommendations.
14 - We can not downplay the effort of searching, and eventually The study of correlation between MOOD metrics and
adapting, reusable components from the class library, as well as the quality attributes as those mentioned in [ISO9126] will be
effort of building, validating and maintaining it.

7
one of next steps. We will also investigate the statistical [Bieman92] Bieman J., "Deriving Measures of
independence of each MOOD metric towards each of the Software Reuse in Object Oriented Systems", Proceedings
other ones. of The BCS-FACS Workshop on Formal Aspects of
We think that the MOOD metrics (except the Reuse Measurement, Springer-Verlag, 1992.
Factor) can be combined to obtain a generic OO software
[Campanai94] Campanai M. and Nesi P., "Supporting
system complexity metric. That is one of our future chal-
O-O Design with Metrics", Proceedings of TOOLS
lenges. We will start by evaluating the MOOD metrics
Europe'94, France, 1994.
against a set of desiderata for software complexity metrics
defined in [Weyuker88]. [Chidamber91] Chidamber S. and Kemerer C.,
A concurrent effort for developing a resource estima- "Towards a Metrics Suite for Object Oriented Design",
tion model named MOORED (Model for Object Oriented Proceedings of OOPSLA'91, pp.197-211, 1991.
Resource Estimation Determination) is under way, and
[Dreger89] Dreger J.B., Function Point Analysis,
some cross-fertilization is expected in the field of com-
Prentice-Hall, Englewood Cliffs, NJ,1989
plexity and productivity evaluation.
[ISO9000-3] ISO/IEC 9000 Part 3, Guidelines for the
Application of ISO 9001 to the Development, Supply and
7. CONCLUSIONS
Maintenance of Software, 1991.
The adoption of the Object-Oriented paradigm is ex-
[ISO9126] ISO/IEC 9126, Information Technology
pected to help produce better and cheaper software. The
- Software Product Evaluation - Quality Characteristics
main concepts of this paradigm, namely, inheritance,
and Guidelines for their use, 1991.
encapsulation, information hiding or polymorphism, are
the keys to foster reuse and achieve easier maintainability. [Jacobson92] Jacobson I., Christerson M., Jonsson P.
However, the use of constructs that support those concepts and Övergaard G., Object-Oriented Software Engineering
can be more or less intensive, mainly depending on the - A Use Case Driven Approach, ACM Press / Addison-
designer ability. Advances in quality and productivity Wesley, 1992.
need to be correlated with the use of those constructs.
[Karunanithi93] Karunanithi S. and Bieman J.,
Therefore, we need to evaluate them quantitatively to
"Candidate Reuse Metrics For Object Oriented and Ada
guide OO design. The availability of these metrics should
Software," Proceedings of IEEE International Software
allow comparison of different systems or different
Metrics Symposium, pp.120-128, May 1993.
implementations of the same system, thus helping to
derive some design heuristics that could/should be [Meyer88] Meyer B., Object-oriented Software
included in design tools. Those heuristics would at least be Construction, Prentice Hall International, 1988.
a valuable help to new staff members.
[Meyer92] Meyer B., Eiffel: The Language,
"Blind" choice (or creation) is dangerous, so a set of
Prentice Hall International, 1992.
common requirements for metrics and corresponding
rationale was introduced, which includes the need for [Stalhane92] Stalhane T. and Coscolluela A., "Final
formal definition, language independence, dimension- Report on Metrics", Deliverable D1.4.B1, ESPRIT Project
lessness, ease of calculation and early obtainability. A 5327 (REBOOT), February 1992.
suitable metrics set named MOOD was then proposed. We
[Symons91] Symons C.R., Software Sizing and
believe that these metrics can help in setting OO design
Estimating - Mk II Function Point Analysis, John Wiley &
standards at the organization level, helping OO
Sons, 1991.
practitioners to guide their development process and,
hopefully, leaving them in a cheerful MOOD... [Weyuker88] Weyuker E., "Evaluating Software Com-
plexity Metrics", IEEE TSE, vol.14, n.9, pp.1357-1365,
September 1988.
REFERENCES
[Yousfi92] Yousfi N., "Measuring Internal
[Abreu93] Abreu F.B., "Metrics for Object Ori- Attributes of Object-Oriented Software Products", Pro-
ented Software Development", Proceedings of 3rd Inter- ceedings of the 5th Int. Conference on Software Engi-
national Conference on Software Quality, ASQC, Lake neering & its Applications, Toulouse, 1992.
Tahoe, USA, October 1993.
[Zuse91] Zuse H., Software Complexity: Mea-
[Albrecht83] Albrecht A.J. and Gaffney J.E., sures and Methods, Walter de Gruyer, 1991.
"Software Function, Source Lines of Code and Develop-
ment Effort Prediction", IEEE TSE, vol.9, n.6, pp.639-
648, November 1983.

View publication stats