To provide context for the literature described in this dissertation, this

plumponionchipsΛογισμικό & κατασκευή λογ/κού

18 Νοε 2013 (πριν από 3 χρόνια και 11 μήνες)

94 εμφανίσεις

8

CHAPTER 2

Relevant Prior Research


2.1 Basic Object
-
Oriented Concepts


To provide context for the literature described in this dissertation, this
section outlines some basic concepts and terminology of object
-
oriented
technology, and a b
rief overview of the object
-
oriented software development
life cycle and how it differs from the traditional life cycles.


The difference between object
-
oriented and traditional, functionally
oriented approaches to software development is predominantly one

of mind
-
set,
which subsequently influences the software's organization and the development
process [Andersen and Sheffler, 1992]. Functionally oriented software is
organized into functions that are applied to data, and is considered too expensive
to main
tain. Object
-
oriented approaches, which organize software into
interacting objects, were established to address the difficulties of software
development and software maintenance. Object
-
oriented concepts evolved from
academic research and analysis of bas
ic characteristics of good software practice.


Cox defines the object
-
oriented paradigm as “a system building tool
which puts the reusability of software at the center of the software development
process


[Cox, 1986]. Wegner defines object
-
orientation in
terms of objects,
classes, and inheritance [Wegner, 1987]. He views an object
-
oriented system as
being composed of a set of objects which are grouped into classes. Classes are
defined by the inheritance hierarchy. Korson and McGregor define five basic
c
oncepts in the object
-
oriented paradigm [Korson and McGregor, 1990]. The five
concepts are objects, classes, inheritance, polymorphism, and dynamic binding.

9


A
class

defines the template for objects, which are the basic system
components in the object
-
ori
ented paradigm. Objects sharing the same
definitions are grouped into classes. An object is an instance of a class. An
object

is anything that can be perceived and is relatively stable in form; it must be
denotable by name, have a well
-
defined context a
nd interface, and exhibit a
persistent internal state; finally, an object and its operations cannot be considered
independent of one another. It is this intimate association of an object with its
operations that is the hallmark of object
-
oriented software
. Polymorphism and
inheritance are two aspects unique to OO systems.


Polymorphism

means having the ability to take several forms. Booch
defines Polymorphism as a concept, according to which a name (such as a
variable declaration) may denote objects of m
any different classes that are related
by some common super class;

thus, any object denoted by this name is able to
respond to some common set of operations in different ways [Booch, 1986, 1994,
1996].

Jacobson et al., define Polymorphism as a con
cept wh
ich means that the
sender of a stimulu
s (message) does not need to know the receivi
ng
object

s class

[Jacobson et al., 1993]
. The receiving
object

can belong t
o an arbitrary class. The
stimulus (message) can be interpreted in different ways, depend
ing on

the
receiver

s class. It is the receiver of a stimulus th
at determines how a stimulus
will be interpre
ted, not the transmitter.

One of the major benefits of
p
olymorphism is

that the programmer does not have to comprehend, or even be
aware of, existing o
perations to add a new operation to a class. Without
polymorphism, the developer writes code consisting of large case or switch
statements, which implies that the developer should be aware of existing
operations in order to add a new operation.


Complexit
y of OO software gets
reduced through the use of polymorphism.

10


Inheritance

is a reuse mechanism that allows programmers to define
classes incrementally by reusing previously defined
classes

as the basis for new
classes. Inheritance decreases the software

complexity of OO systems. This is
primarily due to inheritance enabling the programmer to reuse previously
defined classes, including their variables and operations, as part of the definition
of a new class. This reduces the number of operations and ope
rands required.
Structured systems do not have an inheritance mechanism as part of their formal
specification.

2.1.1 Object
-
Oriented Development Life Cycle


Object
-
orientation has had a profound effect on the software development
life cycle, largely throu
gh successful exploration of the capabilities inherent in
the paradigm. Two of the principal effects are:



The concept of an object forces a different conceptualization of the
problem and solution domains, and requires different analysis techniques.



The pro
perty of encapsulation allows projects to proceed in an
incremental fashion, where increments are far more insulated from each
other than was previously possible.


It is beyond the scope of this dissertation to detail the variety of object
-
oriented develop
ment methodologies that have been proposed in the recent
years. Fortunately the state of the practice has evolved to the point where a high
degree of commonality has emerged between techniques, making it possible to
present the salient points of most in an

overview fashion. The remainder of this
section is devoted to this overview since it provides an understanding of how
this life cycle differs from the traditional life cycle. The following text and
11

diagram
(Figure 2.1)
are adapted from the Software Architects’ Synthe
sis (SASY)
(c) development life cycle description [Korson and McGregor].

There are five main phases in the application development process:



Domain Analysis
: the process of coming to an understanding of the
domain of the application. The domain is modeled,
clarified, documented,
and fundamental classes and their interrelationships are sorted out.



Application Analysis
: the process of determining exactly what will be
built for the requested application. The requirements specifications are
clearly spelled out i
n this phase.



Application Design
: the process where the mechanisms for implementing
the actual application are determined. System architecture, data
structures, efficiency considerations, etc., are all dealt with here.



Class Development
: classes are develo
ped and tested in the language of
implementation.



Incremental Integration and System Testing
: classes are integrated into
cluster and subsystem modules and finally into a complete application.
Integration testing verifies that these modules work correctly,

effectively,
and meet requirements.


Many of these phases or steps are familiar from a traditional structured
design process. The major difference is that all steps are performed repeatedly, as
necessary, in multiple
iterations
. A number of iterations res
ult in a complete,
testable module or sub
-
module termed an
increment
. This iterative process of
developing system increments continues until the system is complete. As later
increments are implemented, it is inevitable that misconceptions and outright
erro
rs will be detected in increments developed earlier. Due to the insulating
12

effect of encapsulation, all types of incorrect system behavior are corrected, when
discovered, with much less violence to the overall design than would normally
occur in a traditio
nal development environment.

One complete
increment

of several
iterations

is diagrammed below.



An increment is
a defined subset of the total system functionality.



An iteration is

one pass over some set of activities
.


The complete system is assembled fro
m multiple increments.



Activity

Domain
Analysis

Application
Analysis

Class
Development

Application
Design

Application
Assembly

Iterations

Increment

Start

Increment

Finish

Single
Increment

of

multiple
Iterations

1

2

4

3

Shading
indicates
activity level

Light

Heavy

Not all activities require
equal effort for different
iterations.

Figure
2.
1: OO Development Life Cycle

13


Application Design takes a very prominent role over coding in the OO life
cycle, so much so that some of the OO methodologies do not even mention
coding as a separate phase. One can, therefore, expect to find a similar bias in
O
O metrics, where design metrics become more prominent than the code
metrics. This is very different from metrics for traditional systems whe
re most of
the metrics are code
-
based metrics. The increased prominence of the design task
also means that the lev
el of detail available at the design level in an OO life cycle
is much greater than what is available in a traditional system design. The
iterative nature of the object
-
oriented product life cycle also presents metric
opportunities and techniques not avai
lable with traditional production methods.
Since analysis and design are tasks in the life cycle, that are repeated throughout
the life of the product, the opportunity exists for a class of
early metrics.

Object
-
oriented designs have been determined to be

conceptually more stable than other
techniques because the major system concepts usually do not change from early
stages of the design. Thus estimates made at an early point in development can
be refined rather than discarded.


For more discussion on obj
ect
-
oriented software development, please refer
to the books by Booch, Coad and Yourdon, or Jacobson et al [Booch, 1994, 1996;
Coad and Yourdon, 1991a, 1991b ; Coad 1997; Jacobson et al., 1993]. All of these
books provide an excellent discussion on object
-
oriented software development,
and describe specific methodologies.

2.2 Software Complexity Metrics


A
software metric

defines a standard way of measuring some attribute of
the software development process. For example, size, cost, defects,
communication
s, difficulty, and environment are all attributes. Examples of
attributes in the physical world are mass, length, time and the like. "Kilo
-
lines of
14

executable source" illustrates one metric for the size attribute. Metrics can be
primitive (directly measu
rable or countable, such as counting lines of code) or
computed (such as non
-
comment source statements/ engineer/ month) [Grady
and Caswell, 1987].


To many project managers, software metrics are a means for more
accurate estimations of project milestones,

as well as a useful mechanism for
monitoring progress. As DeMarco says, "You cannot control what you cannot
measure" [DeMarco, 1982].


There are four major reasons why one should be interested in metrics in
general:



O湥n
o映瑨攠f慪or⁲敡eo湳⁴o敡e畲u⁴桥⁳o晴f慲攠摥e敬e灭敮e⁰ oc敳s⁩s
t桡琠楴⁩ tro摵c敳or攠e楧oro畳⁰ 楮c楰i敳⁩ to⁴桥⁤敶敬o灭敮e⁰ oc敳s
楴s敬映慮搠d敳畬ts⁩ ⁡ b整t敲⁵ 摥dst慮a楮g o映瑨攠摥f敬e灭敮e⁰ ocess.



䄠獥Ao湤

r敡eo渠瑯⁳tart⁡整r楣s⁰ ogr慭⁩ ⁴桡琠h桥敡e畲um敮e
慣t楶楴楥i⁡湤⁴oo汳⁴og整桥h敡搠 o⁡⁧r敡e敲敶敬映fo灨楳t楣慴楯渠n渠
so晴f慲攠敮e楮敥e楮g⁴散桮楱i敳.



周楲搬⁴桥⁵s攠e映fommo渠瑥rm楮o汯gy敡 s⁴oor攠eo湳
楳t敮e⁵ 攠e映瑨攠
most⁥晦散t楶攠摥e敬epm敮e⁥湶楲o湭敮es⁡湤⁴oo汳.



F楮慬汹Ⱐ睥⁨慶攠愠e慹⁴o⁤整erm楮攠e畲⁰uogr敳s⸠⁁猠.攠業灬敭ent
c桡hg攬⁷攠數灥pt⁴o⁳敥敡e畲慢汥⁲敳畬ts.


S敶敲慬⁣om灬數楴yetr楣s⁥ 楳t⁦潲⁴桥

tr慤楴楯湡n⁳yst敭eⰠ慮,⁳敶敲慬a
mor攠慲攠扥楮g⁰ro灯s敤⁦or⁴桥扪散t
-
or楥湴敤⁳yst敭e⸠⁃.m灬數楴y整r楣s⁡ 攠
摥d楧湥搠瑯敡e畲uⰠ楮⁲敬慴楶攠t敲msⰠ,桥⁤h晦楣u汴y⁨ m慮a⁨慶 ⁩渠nork楮g
w楴栠hrogr慭s⸠⁔.攠e桥潲整楣慬⁢慳敳⁦潲⁴桥h攠浥瑲楣s⁩ c汵摥

gr慰a⁴桥潲yⰠ
楮景fm慴楯渠瑨敯ryⰠ桵m慮⁩湦orm慴楯渠nroc敳s楮g⁴桥潲yⰠ慮,⁧敮er慬⁳yst敭e
15

complexity theory. The following two subsections discuss the complexity
metrics in the procedural and object
-
oriented paradigms respectively.

2.2.1 Complexity Metr
ics in the Procedural Paradigm


Several complexity metrics have been proposed to measure the
complexity of a procedure, a function, or a program in the procedural paradigm.
These metrics range from simple size metrics such as Lines of Code (LOC) to
very c
omplicated program structure metrics such as Robillard and Boloix’s
statement inter
-
connectivity metrics [Robillard and Boloix, 1989]. This section
presents some sample complexity metrics in the procedural paradigm.


Some of these complexity metrics are l
exical measures. The lexical metrics
count certain lexical tokens in a program. These metrics include Halstead’s
software science complexity metrics and Bail’s size metric. Halstead defines
software science metrics based on the lexical token counts in a

program
[Halstead, 1977]. Software science metrics are a set of metrics based on four basic
counts of lexical tokens in a program. The four basic counts are number of
unique operators, number of unique operands, total occurrence of operators, and
total
occurrence of operands. Bail defines the program complexity on the size of
a program needed to describe an algorithm [Bail, 1988]. The size of the program
is defined by the number of bits needed to describe the algorithm.


Other measures are based on the

analysis of patterns in a graph when the
graph is constructed from the control flows of a program. McCabe defines the
cyclomatic complexity measure based on the control flows in a
procedure/function [McCabe, 1976]. A directed graph is derived based on t
he
control flows of a procedure/function. The cyclomatic complexity is based on
the complexity of the directed graph. McCabe and Butler later extend the
16

cyclomatic complexity to measure structure chart design [McCabe and Butler,
1989].


Another group of
metrics measures the inter
-
connection of system
components. The inter
-
connection may be based on the statements or the
components of a program such as procedures or functions. Some examples of
such metrics are McClure’s invocation complexity, Henry
-
Kafur
a’s information
flow complexity, Woodfield’s review complexity, and Robillard and Boloix’s
statement inter
-
connection complexity.


McClure defines the invocation complexity based on the possible
execution paths in a program and the difficulty of determinin
g the path for an
arbitrary set of input data [McClure, 1978]. Henry and Kafura define the
information flow complexity based on the interconnectivity among
procedures/functions [Henry and Kafura, 1981]. The inter
-
connectivity between
the two procedures/f
unctions may be caused by a data structure or a procedure
call. Woodfield defines review complexity, on the basis of the difficulty of
understanding a system. The more complex a system is, the more time it takes to
understand it. “To understand the syst
em, the software must be reviewed. The
more times a system is reviewed, the less additional time it will take to
understand the system” [Woodfield, 1980]. Robillard defines the complexity of a
program in terms of the inter
-
connections among statements.
The complexity is
based on the information
-
theory concepts of entropy and excess entropy
[Robillard and Boloix, 1989].


Cant, Jeffery and Henderson Sellers present their approach to complexity
metrics which is based on an understanding of the cognitive pro
cesses of the
analyst or programmer as they undertake the challenges of program
development or maintenance [Cant, Jeffery, and Henderson
-
Sellers, 1995]. In
17

their complexity model they attempt to quantify a number of cognitive process
involving the softwar
e developer or maintainer. The authors claim that initial
studies show that this cognitive complexity model is applicable to object
-
orient
systems too [Cant, Henderson
-
Sellers, and Jeffery, 1994].


Almost all of the above work has been done in the context

of the
procedural paradigm. Since the object
-
oriented paradigm exhibits different
characteristics from the procedural paradigm, software metrics in the object
-
oriented paradigm need to be studied. This is because, object
-
oriented concepts
like inheritan
ce, classes, and message passing cannot be characterized by any of
the metrics mentioned above.

2.2.2 Complexity Metrics in the Object
-
Oriented Paradigm


The current state of software metrics for object technology is best
described by Taylor as "
In Search
of Metrics
" [Taylor, 1993]. We have very few
metrics available that are validated for use in OO systems. Capers Jones in his
book
Programming Productivity,
[Jones, 1986] describes the state of software
metrics as "
The search for a Science of Measurement.
" He summarizes the software
measurement trends as


"... software engineering is slowly emerging from the dark fog of lines
-
of
-
code measurements to explore new methods and new concepts of
measurement. The inability of lines
-
of
-
cod
e measures to be used for fourth
-

and fifth
-
generation languages is triggering one of the more significant
waves of discovery of the century. This may eventually trigger a new
science provisionally termed conceptual symbology, or the study of all
symbols
used to communicate abstract and complex ideas. At the
pragmatic, day
-
to
-
day level, new software measures are starting to appear
that come to grips with functions, with structural complexity, and with data
18

complexity. Although these methods were develope
d independently by
different researchers, new synergistic hybrid measurements are starting to
be explored, with significant potential values...."

[Jones, 1986].


This discussion, dated 1986, was with respect to traditional software
development. Many chang
es have happened since then (in the context of
traditional methodologies) and today lots of validated metrics for traditional
software are available. However, the above discussion seems very appropriate
for OO software development today. We have very few

validated OO metrics
available. Researchers have recognized this fact, which becomes evident from
literature survey. The bulk of the literature on OO metrics has been published
after 1990.


Most of the literature published on OO metrics can be classifie
d as
conceptual
,
idea
-
generating
, or
raising
-
issues

[Keyes, 1992; Moreau and Dominick,
1989, 1990a, 1990b; Taylor, 1993; Thomas, 1989]. All of these papers, without
exception, emphasize the need for usable OO metrics, if the current level of
interest of o
rganizations in OO technology is to be sustained and supported.
These papers also emphasize that the metrics should be available as an
integrated part of the OO development methodologies. The reason for this
emphasis is that, if the metrics are not an in
tegral part of the development
process, then programmers and project managers perceive the metrics as an
overhead and the metrics will not be used. A brief discussion of these papers is
provided in the following paragraphs.


Keyes, in her paper, argues th
at metrics like lines of code and function
points won't do at the dawn of the graphical, object era [Keyes, 1992]. Taylor
also argues that metrics generated for previous generations of software
technology may not be suitable for object
-
oriented technology

[Taylor, 1993]. The
19

author says that the key to make object
-
oriented methodology work is a set of
metrics that accurately predict resources required to implement the design. The
author also proposes that we can start with basic things like number of meth
ods,
number of component objects, total number of messages (across all methods),
number of objects receiving messages (collaborators), total number of parameters
(across all messages), ratio of public to private methods, etc., as object
-
oriented
metrics.
Lake and Cook prescribe metrics for measurement of inheritance in C++
environments [Lake and Cook, 1992]. Henderson
-
Sellers opines that metrics for
software designed and built using a functional decomposition approach are
largely inappropriate for OO softw
are development [Henderson
-
Sellers, 1992].
The author argues that new concerns such a
s

code reuse, effort spent in creating
generalized classes, as well as the cost of locating stored library modules need to
be considered [Henderson
-
Sellers, 1992, 1993].


Thomas takes a slightly different approach [Thomas, 1989]. He suggests
that lines of code can be used as a metric of reuse in object
-
oriented systems, in
the form of lines of code reused. He also suggests that metrics of coupling and
cohesion (both tradi
tional metrics) can be used in object
-
oriented systems, but
they should be applied to classes instead of modules. The author describes the
OO metrics as
Food for the Software Accountants
. According to the author the high
cost and poor track record of sof
tware make it essential that OO users provide
accurate data on the development process, because it is this data that will
provide the hard proof of the promised benefits of OO technology in large scale
projects.


Moreau and Dominick describe their long ter
m goals of research as
including formulation of complexity models for object
-
oriented development of
software and the formulation and validation of software
-
development metrics
20

appropriate to object
-
oriented systems [Moreau and Dominick, 1989]. In two
oth
er papers the authors present "A Programming Environment Evaluation
Methodology for Object
-
Oriented Systems" [Moreau and Dominick, 1990a and
1990b]. In these papers, the authors discuss the methodology and a specific test
case application of the methodolo
gy. Identifying and defining primary and
additional metrics is specifically mentioned as one of the eleven phases of the
methodology and is thus considered an integral part of the methodology by the
authors. In their test case illustration, the authors
have used some existing
traditional software metrics, and have also proposed some new metrics.


One observation that can be made about the papers discussed above, is
that almost all of them propose new OO metrics. But unfortunately none of the
papers prov
ide any theoretical basis for these metrics, nor do they define or
describe the metric in any detail. This gap is very wide and very obvious from
the diversity of metrics being proposed; and there is a tremendous potential for
future research in trying to

bridge this gap and reach the level of sophistication
and maturity that we have achieved with traditional software metrics like
Cyclomatic Complexity [McCabe, 1976], Software Science [Halstead, 1977].


More recently, we have begun to see researchers attem
pting to define,
describe and validate OO metrics.
But, it can said that these attempts are real
ly in
the
early stages.
Current work in the area of object
-
oriented metrics can be
broadly classified into two approaches:




v敳t楧慴楮g t桥⁥ht敮e⁴o⁷桩c栠數楳t楮g⁴r慤楴楯湡n整r楣s⁣慮⁢攠es敤e
⡥(t桥h⁤楲散t汹 or⁡晴 r⁦ 湥
-
t畮楮g⤠)or扪散t
-
or楥湴敤⁳祳瑥浳⁛ 敧慲摥渠
慮a⁓桥整稬‱㤹㈻⁂慮步zⰠ,慵a晭慮Ⱐ慮搠dum慲Ⱐㄹ㤱㬠䉡湫敲⁥ ⁡ ⸬‱㤹㐻.
Gr慨aⰠㄹ㤶,⸠.

21

The logic for th
is line of research is that these metrics are well understood
by practitioners and researchers, and these metrics are empirically tested
and validated. However, there is no clear agreement about the
effectiveness of these metrics for object
-
oriented syste
ms.



D敶敬e灩pg⁡敷⁳畩t攠e映f整r楣s⁳灥p楦ic慬ay⁦潲扪散t
-
or楥it敤⁳yst敭e
孁[扯btⰠㄹ㤳㬠䅢,敵⁡湤⁃慲慰ac愬‱㤹㐻⁂a湳楹愬‱㤹㜻⁃桥渠慮搠䱵Ⱐ
ㄹ㤳㬠䍨楤慭扥b⁡湤 K敭敲敲Ⱐㄹ㤱ⰱ㤹㐻⁈敮摥eson
-
S敬汥esⰠㄹ㤶愻a
䱯r敮稬e
ㄹ㤳㬠䱯r敮稠慮搠d楤iⰠㄹ㤴㬠剡橡牡浡渠慮搠䱹甬‱㤹㈻⁔ay汯rⰠ
ㄹ㤳1⸠.

周攠汯g楣⁦潲⁴桩s楮攠e映牥s敡ec栠hs⁴桡琠h桥扪散t
-
or楥湴敤⁳祳瑥浳
楮摩d慴攠愠灡e慤楧浡瑩挠a桩晴⁩渠瑨攠f慹⁳o晴w慲攠楳⁤敶敬e灥搬⁡p搠d敮e攠
m整r楣s⁧敮敲慴敤⁦or 灲敶楯畳⁧敮敲ati
o湳映fo晴f慲攠e散桮o汯gy 慲攠湯e
s畩t慢汥⁦潲扪散t
-
or楥湴敤⁴散桮o汯gy⸠.䅮At桥h楮攠e映牥慳o湩湧⁩n⁴桡琠
t桥⁥h楳t楮g整r楣s⁤ 潴⁨慶 ⁡⁳tro湧⁴桥or整楣慬⁦o畮摡d楯渮†坥祵n敲
灲o灯s敳⁴桡琠hr慤楴楯n慬⁳o晴f慲攠eom灬數楴y整r楣s⁤ 潴⁰ ss敳s
a
灰po灲楡i攠浡t桥h慴楣慬⁰ao灥pt楥iⰠ慮,⁣o湳敱略et汹⁦慩氠lo⁤楳灬慹
w桡琠浩杨h⁢攠瑥rm敤潲m慬⁰a敤楣t慢汥⁢敨慶楯r⁛坥祵步rⰠㄹ㠸崮

Utilizing Existing Traditional Software Metrics

:


In one of the few studies on object
-
oriented metrics, traditional sof
tware
metrics such as lines of code, Software Science [Halstead, 1977], Cyclomatic
Complexity [McCabe, 1976] are investigated as possible indicators of complexity
for object
-
oriented systems [Tegarden and Sheetz, 1992]. The motivations for the
authors to t
ake this line of research are :



周攠er慤楴楯湡n整r楣s⁥ 楳t



周敲攠楳⁥浰楲楣慬⁥a楤敮c攠eo⁳異灯rt⁴桥楲⁵s攠景e⁳tr畣t畲u搠dystems

22



They are well under
stood by practitioners and researchers

This research reports the effects of polymorphism and inheritance on the
complexity of object
-
oriented systems as measured by the traditional metrics.
The authors report that results of this research indicate the appr
opriateness of the
use of
traditional metrics for the measurement of complexity of object
-
oriented
systems. The authors also discuss the use of traditional metrics for object
-
oriented systems, and how the metrics should be computed to capture the
unique a
spects of OO systems. This study highlights the need to investigate the
applicability of other traditional metrics for object
-
oriented systems.


In another study Banker, Kauffman, and Kumar propose new output
metrics called
Object
-
Points
, and
Object
-
Count
s

which are specialized metrics for
output measurement in object
-
oriented CASE (Computer Aided Software
Engineering) environments [Banker, Kauffman, and Kumar, 1991; Banker et al.,
1994]. The motivation for both Object
-
Point and Object
-
Count metrics is de
rived
from Function
-
Point and Function Count, which are traditional software metrics.
The metrics are proposed as more intuitive and low cost approaches to
measuring the CASE outputs. In a CASE environment, the information about the
different kinds of ob
jects used in applications is stored in a central repository.
The paper identifies four types of objects that are stored in the repository


Rule
Sets, 3GL Modules, Screen Definitions, and User Reports. The metrics are
defined as follows :





4


Obje
ct
-
Counts =

O扪散t
-
䥮It慮a敳





††
t=1





4


Object
-
Points =

O扪散t
-
䕦景ft
-
坥楧桴

⨠*扪散t
-
䥮It慮a敳






t=1

23

where,


t

= object type (Rule Sets, 3GL module, Sc
reen Definition,
and User Report).

Object
-
Effort
-
Weight
t

= average development effort associated with object type
t, based on project manager heuristics,


Object
-
Instances

= total number of instances of object type t in a CASE
application,

This pap
er is a classical example of utilizing the knowledge of existing metrics,
and redefining new metrics to fit in the context of OO technology, instead of
using traditional metrics directly. The authors have also evaluated these two
metrics using regression
models and the results show that it has a potential to
yield as accurate, if not better, estimates than function points based measures.
This study demonstrates that existing metrics can also be indirectly used in
deriving new metrics. Grahm also takes a
similar approach and defines a new
metric, Task Points, which has been patterned after the Function Points, and
according to the author offers a potential replacement for Function Points
[Grahm, 1996]. Task Point is defined as:


Task Points = Number of at
omic tasks (i.e. those with no component tasks;
the leaf nodes of the task tree)


Moreau and Dominick classify metrics into intra
-
object and inter
-
object
metrics [Moreau and Dominick, 1990a, 1990b]. They argue that traditional
metrics will be useful as in
tra
-
object metrics but not as inter
-
object metrics. The
authors further use traditional metrics to compare two implementations of a
graphical editor, a traditional implementation in C and an object
-
oriented
24

implementation in C++. The metrics used are Sof
tware Science [Halstead, 1977]
and Cyclomatic Complexity [McCabe, 1976].


Jacobson et al., in their book
Object
-
Oriented Software Engineering
, also
argue that common traditional source code metrics can be used with various
degrees of usefulness in object
-
o
riented software [Jacobson et al., 1993]. Thus,
we see a significant number of researchers putting in their research effort in
trying to effectively make use of the traditional metrics. However, as mentioned
earlier, there is no clear understanding on th
is issue. A good many researchers
[K
eyes, 1992; Taylor, 1993; etc.]

argue that traditional metrics have no role to play
in the object
-
oriented context.

Developing New Metrics Specifically for Object
-
Oriented Systems :


In this line of research, researche
rs are working to propose new,
theoretically sound metrics designed specifically to capture the unique aspects of
the OO systems.


The work done by Chidamber and Kemerer is considered pioneering in
object
-
oriented metrics [Chidamber and Kemerer, 1991, 1994
]. They present
theoretical work that builds a suite of metrics for object
-
oriented design. The
proposed metrics are formally evaluated against a widely accepted list
[Weyuker, 1988] of software metric evaluation criteria and the evaluation
suggests that

these metrics perform relatively well [Chidamber and Kemerer,
1991]. For each proposed metric, the authors give the definition, the theoretical
basis, and different
viewpoints
. In another recent paper the authors present
empirical data
to demonstrate th
at
these metrics
could be used
in both C++ and
Smalltalk environments [Chidamber and Kemerer, 1994]. Li and Henry study
these metrics with reference to the maintenance effort in two commercial systems
and conclude that these metrics in general can be used

as predictors of
25

maintenance effort, though two of the metrics are found to be not as good as
expected [Li 1992; Li and Henry, 1993; Li et al., 1995].
The major criticism about
the work done by Li and Henry, is that “Maintenance Effort” was
operationaliz
ed as the number of lines of code changed. This is perhaps as
controversial as using the lines of code (LOC) as a size metric. More recently
another study was conducted in which an experimental study was conducted to
validate these metrics as predictors
of reliability (fault
-
proneness) [Basili, and
Briand, 1996]. This study has similar conclusions and found that five of the six
metrics seem to be useful to predict class reliability during the early phases of the
life cycle. Kolewe confirms (based on a f
ield study) that two of the metrics (Class
Coupling, and Response For Class) correlate with the defect densities [Kolewe,
1993].

But the work of Chidamber and Kemerer, is n
ot without criticisms. Li and
Henry
point out the ambiguities

in the
definition of

one of the metric,
LCOM
-

lack of Cohesion in Methods
, and have attempted
to
rephrase the definition

[Li
and Henry,
1993]
.
Hitz and Montazeri have also critiqued the me
trics
(especially
the metrics
-

Coupling Between
Object, and Lack of Cohesion in Methods)

for
their
ambiguities [Hitz and Montazeri, 1996].


In a similar vein Abreu and other researchers have proposed a suite of six
metrics called the MOOD metrics (Metrics for Object
-
Oriented Design). These
metrics include Method Hiding Factor, Attribute Hidi
ng Factor, Method
Inheritance Factor, Attribute Inheritance Factor, Polymorphism Factor, and
Coupling Factor [Abreu and Carapuca, 1994; Abreu, Goulao, and Esteves, 1995].
Abreu and Melo also report that in an experimental study they found these
metrics to

correlate with the system reliability and maintainability [Abreu and
Melo, 1996]. In a very recent study Harrison, Counsell, and Nithi report that the
MOOD metrics can be said to be theoretically valid,
but
only if appropriate
26

changes are made to rectify

existing problematic discontinuities [Harrison,
Counsell, and Nithi, 1998].


Th
us far th
ese are
the only two metrics sets
(Chidamber and Keme
rer

s
metrics suite, and the MOOD metrics)

which
have
been used in some validation
studies. But we

also
see
that
researchers have also criticized these two metrics
sets

for their

weaknesses.


Harrison, Counsell, and Nithi further say th
at the
Chidamber and Kemerer

s metrics suite seems useful to designers and

developers of systems, giving them
an evaluation of the sy
stem at the class leve
l,
while the MOOD metrics could be of use to pro
ject managers as the metrics
operate at a sys
tem level

[Harison, Counsell, and Nithi, 199
8].
T
hey
further say
that
their utility will continue to be
questioned until a sufficient number

of
empirical
valid
ations have
been performed
. Without further empirical
validation, we c
annot be sure that it is worth paying attenti
on to these metrics.


Moreau and Dominick [Moreau and Dominick, 1990a] argue that there are
three major factors that affe
ct the complexity of programming in an OO
environment :

1.

the number of unique messages that will be sent by the current object
(message vocabulary size),

2.

the complexity of the inheritance mechanism that must be interpreted to
determine the characteris
tics of the objects that will be used, and

3.

the number of messages to which the current object must respond
(message domain size).

The authors then propose the following three new metrics : Message Vocabulary
Size, Inheritance Complexity, and Message Do
main Size.

27


Lorenz, takes a similar approach and proposes a set of Object
-
Oriented
Design Metrics and Project Completion Metrics [Lorenz, 1993]. Lorenz is one of
the few researchers who has proposed some process metrics for object
-
oriented
software develo
pment. Additionally, the author also provides rules of thumb for
using these metrics. An exclusive book on Object
-
Oriented Software Metrics by
Lorenz and Kidd [Lorenz and Kidd, 1994] contains about thirty OO metrics and
rules of thumb for using them. How
ever, the major weakness of this book is that
the metrics have not been validated in any form
-

theoretically, subjectively, or
empirically.


As mentioned in the earlier section, the object
-
oriented paradigm
encourages putting relatively more effort into d
esign than the procedural
paradigm. More effort on design means more information with which design
-
based metrics can be computed.
Churcher and Shepperd

say that the data
models for OO systems are relatively richer than the data models for
conventional sys
tems, and that the former have a greater number of components
and relationships between them. Therefore metrics for OO systems should
attempt to capture this richness

[Churcher and Shepperd, 1995]
.

The argument
for this is that, the more infor
mation a me
tric captures, the better its abil
ity to
predict external attributes of systems
, such as reliability, maintainability,
testa
bility
,

etc.
This is the classical argument in code
-
based
metrics versus
design
-
based metrics.
Obviously

code
-
based metrics
measured
after t
he system
has been developed are more
accurate
than
the design metrics measured before
the system

has been
developed. This is because
cod
e
-
based metrics have more
information availab
le.


But the utility of

code
-
based metrics is
limited, because
the
effort

to take any corrective actions, at tha
t stage is
prohibitively

expensive.
Th
is
is the reason why design
-
based metrics
are preferred even though they may
28

not be as ac
curate as code
-
based metrics



they
(design
-
based metrics)
provide
an opportunity

for cor
recting and recovering from any flaws
that have been
identified.
Therein
lies one of the advantages of the
OO
paradigm


OO design
s
are relatively richer

in information
, and therefore metrics
,

if properly defined
,

c
an take advantage of that information avai
lab
le at an

early
stage in the life cycle
.

Unfortunately most of the research described above does not exploit this
additional information. We have come across two studies which seem to take
advantage of the additional information available in an OO des
ign. Recently,
Chen, and Lu propose
Operation Argument Complexity

and
Attribute Complexity

metrics which utilize the complexity of the arguments (parameters) of the class
methods and the complexity of the class attributes [Chen and Lu, 1993]. Abbott
goes

one step further and defines the
Interaction Level

metric which is derived
from the number and strength of interactions between the class attributes and the
parameters of the class methods [Abbott, 1993]. The weakness of both of the
above studies is

that neither of the studies have validated the metrics either
analytically or empirically. The only validation done in both the cases is
subjective validation, where the metrics values are compared to
expert

judgments. (Validation of the metrics propose
d by Abbott and by Chen and Lu
is the focus of the
research

reported in this dissertation
).


Churcher and Shepperd acknowledge that metrics of OO languages is
receiving increasing attention. But they argue that, it is premature to develop
and apply OO metrics while there rema
ins uncertainty in not only the precise
definitions of many fundamental quantities, but also a lack of qualitative
understanding of the structure and behavior of OO systems [Churcher and
Shepperd, 1995].

29

Tegarden, Sheetz, and Monarchi present a software
complexity model for
OO systems. This model defines the software complexity at the variable,
method, object and system levels [Tegarden and Sheetz, 1993; Tegarden, Sheetz,
and Monarchi, 1995]. The authors also propose several metrics at each of the
level
s. This work is consistent with the work done by other researchers who
have also defined metrics at multiple levels [Abbott, 1993; Abreu, 1994; De
Champeaux, 1997; Lorenz and Kidd, 1994].


A metric
which

can be interpreted
and used at multiple level
s, is
useful to different people in the softw
are
development team. For example if a metri
c

gives information at the system level,
then
that information is useful for the a project
manager, whi
le

a metric

which
provides information at the class
level

would be useful to a designer.

The
metrics suite proposed by

Chidamber and Kemerer

seems useful to designers
and

developers of systems,
while the MOOD metrics
seem appropriate
to pro
ject
managers

[Harison, Counsell, and Nithi, 199
8].


It is
preferable

if

the same metric
definiti
on is used at all levels, because it
would
provide

con
sistent information
.

Several other authors have proposed various OO metrics with little or no
validation. Bansiya presents a suite of over thirty metrics called QMOOD++
(Qualit
y Metrics for Object Oriented Development) [Bansiya, 1997]. Rajaraman
and Lyu present metrics to measure the coupling at both the class and method
level. The authors further present data to support their argument that these
metrics are better predictors
of perceived difficulty, than metrics such as lines of
code, Halstead’s Software Science, and McCabe’s Cyclomatic Complexity
[Rajaraman and Lyu, 1992]. However, the authors do not clearly define what
they mean by perceived difficulty and how it was measur
ed, leading to the
conclusion that it can at best be a subjective validation. Kim et al.

define
complexity as the summation of syntax complexity, inheritance complexity
,

and
30

interaction complexity, and argue that the metrics presented by Chidamber and
Kem
erer do not account for all the three complexities [Kim et al., 1994]. They
also present a new metric, Complexity of Program, but provide no supporting
validation for the metric. Kolewe proposes three new metrics, Number of Class
Hierarchies, Number of C
lass Clusters, and Association Complexity, again with
no theoretical or empirical support [Kolewe, 1993]. Frakes and Terry [Frakes and
Terry, 1996] in their survey paper list several more metrics which have been
defined to measure the extent of reuse in O
O systems [Bieman, 1992; Bieman and
Karunanithi, 1993]. Many other metrics have been proposed without providing
either
a

theoretical basis or empirical support [Fajeau, 1994; Martin, 1994; Welker,
1994].

As can be seen from the above discusion, many res
earchers have proposed
new OO metrics. The increasing attention that this topic (object
-
oriented metrics)
is receiving can be further underscored by the publication of the two most recent
textbooks on this topic, in which the authors present several metri
cs [de
Champeaux, 1997; Henderson
-
Sellers, 1996a]. The advantage of these metrics is
that they are developed specifically to capture the unique features of the object
-
oriented systems. But it must be noted that in almost all the cases the metrics are
at
the proposal stage and need to be validated; and in most cases the metrics do
not take full advantage of the detailed information available at the design level in
OO systems.

2.3 Maintenance in the Software Life Cycle


The world of software maintenance is
a world in which programmers
spend half of their lifetime. The major professional challenge is to understand
and conquer the complexity of the system [Parikh, 1983].

31


Yau and Collofello define software maintenance as a very broad activity
that includes er
ror corrections, enhancements of capabilities, deletion of obsolete
capabilities, and optimization [Yau and Collofello, 1985]. According to Yau and
Collofello, the first phase of the maintenance process consists of analyzing a
program in order to understa
nd the program logic and design. This phase is
affected by the complexity, documentation, and self
-
descriptiveness of the
program. The second phase consists of generating a particular modification
proposal to accomplish the implementation of the maintena
nce objective. This
phase is affected by the extensibility of the program. The third phase consists of
accounting for the ripple effect that is a consequence of program modifications.
The primary attribute affecting ripple effect is the stability of the

program, where
stability is defined as the resistance to the amplification of changes in the
program. The fourth phase consists of testing the modified program to ensure
that the modified program has at least the same reliability as before. This phase
i
s affected by the testability of the program.


Most researchers categorize maintenance activities as adaptive, corrective,
and perfective [Leintz and Swanson, 1980].
Adaptive maintenance

is environment
-
driven. The need for adaptive maintenance arises whe
n there are changes in
hardware, operating systems, files, or compilers which impact the system.
Corrective maintenance

is error
-
driven. This activity is equivalent to debugging,
but it occurs after the system is placed in operation. Since programs are
never
truly error free, corrective maintenance is required throughout the life of a
system.
Perfective maintenance

is user driven. Most perfective maintenance
occurs in the form of report modifications to meet changing user requirements
[Leintz and Swans
on, 1980]. The bulk of maintenance activities are of this latter
type.

32


Three steps occur in maintenance:

1.

Understanding the existing system

2.

Implementing the changes

3.

Validating the modified system [Boehm, 1981]


Boehm says that from a life
-
cycle planning a
spect, the main lesson for us
in the maintenance production function is that software maintenance is not
optional [Boehm, 1981]. For each dollar spent on software development, another
dollar needs to be budgeted just to keep the software viable over its l
ife
-
cycle;
after that another optional dollar can be spent on desirable enhancements over
the life
-
cycle. He presents the results of a survey conducted in 487 business data
processing locations, to find out the distribution of software maintenance effort
by activity. The results show that corrective maintenance, generally the major
portion of the hardware maintenance budget, tends to consume only a relative
small (21.7%) portion of the software maintenance activity. Thus achieving error
free software dev
elopment does not eliminate the need for a significant level of
software maintenance. Software enhancements account for a major portion
(41.8%) of the software maintenance effort. Additionally, he also discusses the
comparison between the estimated annua
l maintenance effort (using COCOMO)
and the actual effort for 24 maintenance projects. The basic assumption
underlying the COCOMO maintenance model is that software maintenance costs
are determined by substantially the same cost driver attributes that det
ermine
software development costs.

2.3.1 Maintenance in the Object
-
Oriented Systems


The concepts of inheritance and of polymorphism provide the great
strengths of object
-
oriented systems, but they also introduce difficulties in
33

program analysis and unders
tanding. Wilde and Huitt [Wilde and Huitt, 1992]
in their paper titled "Maintenance Support for Object
-
Oriented Programs,"
describe some of the maintenance issues that are unique to object
-
oriented
systems. The paper presents examples from a PC Smalltalk

environment and
from two real life systems, and analyzes problems of dynamic binding, object
dependencies, dispersed program structure, control of polymorphism, high
-
level
understanding and detailed code understanding. For example, some of the work
on go
od object
-
oriented programming style would seem to encourage the use of
many small methods [Johnson and Foote, 1988]. Wilde and Huitt also have
found (in the systems that they studied) the use of a large number of small
methods. If this pattern is typica
l of object
-
oriented systems, there are significant
implications for maintenance performance. The code for any given task would
be very widely dispersed. Understanding of a single line of code may require
tracing a chain of method invocations through sev
eral different object classes and
up and down the object hierarchy to find where the work is really getting done.
Such searching is both time
-
consuming and error
-
prone. Finding such chains
gets even more complicated by the dynamic binding problems.


Thus

we can see that object
-
oriented systems have unique maintenance
problems. It therefore becomes important that we have valid and effective
metrics to estimate the maintainability of object
-
oriented systems.

2.4 Complexity Metrics and Maintenance Performan
ce


Complexity is an antonym of testability, readability, maintainability, and
comprehensibility [Curtis et al., 1979]. Complexity causes two major problems in
maintenance. A more complex system is more difficult to understand and
therefore difficult to
maintain. The second problem is that, complex programs
require more corrective maintenance throughout their lives [Gibson and Senn,
34

1989]. Complex programs contain more errors, and those errors are more
difficult to uncover during testing. Consequently
they remain undetected until
late in the life cycle.


Several studies have been conducted to examine the relationships between
design complexity, code and structure complexities and maintenance
performance [Curtis et al., 1979; Gibson and Senn, 1989; Henry

and Selig, 1990;
Mancl and Havanas, 1990; Rombach, 1987, 1990; Li and Henry, 1993]. Most of
these studies, however, were done in the context of traditional software systems.
Nevertheless, these studies are useful in understanding the effectiveness of
me
trics in estimating maintainability.


Most software measurements are solely derived from the source code
[Rombach, 1987, 1990]. Although the source code metrics can be utilized to
provide important maintainability information, the costs of restructuring a

program to improve maintainability can be quite high during the coding phase
of the life cycle. A more cost
-
effective approach would be the application of
metrics during the program design phase. Any restructuring necessary to
improve maintainability co
uld then be accomplished much easier than
restructuring code. Therefore, it is much more important to establish
relationships between design metrics and maintainability.

Studies involving Traditional Systems


Gibson and Senn have examined the effect of sy
stem structure on the
complexity and consequent maintainability of a COBOL system [Gibson and
Senn, 1989]. They found that system improvements lead to decreased
total
maintenance time

and
decreased frequency of ripple effect errors
. However, the study
al
so found that system differences are not discernible to programmers;
programmers were unable to separate the complexity of the systems from the
35

complexity of the maintenance tasks. They thus establish (a) correlation between
system complexity and maintena
nce performance and (b) the need for objective
metrics.


Henry and Selig have conducted experiments to test whether metrics
available during detailed design (before coding begins) can be applied to predict
code quality earlier in the cycle, since this woul
d offer the benefit of a shortened
life cycle [Henry and Selig, 1990]. The design specifications were written in Ada
-
like program
-
design language, and the final code was written in Pascal. The
results indicate that code metrics depend strongly on the des
ign specification's
refinement level while the structure metrics are independent of the refinement
level. The study also demonstrates that automatic generation of metrics for
design specifications is possible.


Curtis et al. have conducted experiments us
ing FORTRAN programs to
measure the psychological complexity of software maintenance tasks using
Halstead and McCabe metrics [Curtis et al., 1979]. Psychological complexity
refers to characteristics of software which make it difficult to understand and
he
nce difficult to make changes or maintain. They found that the psychological
complexity metrics correlated with both the
accuracy of the modification

and the
time to completion
. However these metrics were most predictive of performance
for less experienc
ed programmers, thus indicating that these appear to assess
psychological complexity primarily where programming practices do not
provide assistance in understanding code. This study thus demonstrates the
limitations of the complexity metrics.

Studies inv
olving Object
-
Oriented Systems


Rombach reports the results of a
controlled experiment to study the
maintainability of the distributed software
partly
in the object
-
oriented language
36

Lady [Rombach, 1990]. He
summarizes his findings by saying that
the
soft
wa
re
written in object
-
oriented language was
found
to be more maintainable than
software written

in
a
conventional
language (in this case a
n extended version of
P
ascal).

The author also concludes
that design complexity metrics could predict
maintenance,
a
nd understandability almost as well as the corresponding code
measures. Some of the measures were applicable as early as the end of
architectural design.

The complexity metrics
used
were based on
an information
flow model similar to the one
presented by
Henry and Kafura

[Henry and
Kafura, 1981].
T
hese metrics
however
were not
object
-
oriented metrics
.


Mancl and Havanas present a case study of the impact of the C++
programming language and object oriented design on the maintenance phase of
a software deve
lopment project [Mancl and Havanas, 1990]. The results show
increased software reuse and reduced complexity of software changes in the
parts of the project that use object
-
oriented design. The study attempts to
evaluate the differences between object
-
ori
ented programming and conventional
structured programming. The measurements in this paper identify some of the
places where object
-
oriented programming had a significant impact on
increasing productivity. The authors used "the number of lines of code mod
ified
per maintenance task" as a measure of the maintenance effort.


Li and Henry have studied the applicability of OO complexity metrics
(proposed by Chidamber and Kemerer) with reference to the maintenance in two
commercial systems and conclude that thes
e metrics in general can be used as
predictors of maintenance effort, though two of the metrics were not as good as
expected [Li 1992; Li and Henry, 1993; Li, Henry, Kafura and Schulman, 1995].
But,
the weakness of this study is that,
t
he authors used “th
e number of lines
changed per class” as a measure of the maintenance effort. Li and Henry also
37

define some additional metrics. Abreu and Melo also report that in an
experimental study they have found their MOOD metrics to correlate with the
system reliabi
lity and maintainability [Abreu and Melo, 1996]. Harrison and
Samaraweera report the usefulness of a design metric (the number of test cases)
to predict the testing time [Harrison and Samaraweera, 1996].

2.5 Metrics Validation and Measurement Theory


One
of the major criticisms of using metrics defined for conventional
systems in OO systems, is that these metrics are not based on theoretical
foundations [Chidamber and Kemerer, 1991, 1994]. Over the last few years, there
have been many publications critici
zing most metrics for their lack of
consideration for measurement theory [Henderson
-
Sellers, 1996a, 1996b; Bush
and Fenton, 1990; Fenton, 1997; Hitz and Montazeri, 1996; Kitchenham, Pfleeger
and Fenton, 1995; Morasca, et al., 1997; Schneidewind, 1992; Shep
perd, 1995;
Weyuker, 1988].

Weyuker proposes that traditional software complexity metrics do not
possess appropriate mathematical properties, and consequently fail to display
what might be termed normal predictable behavior [Weyuker, 1988]. Weyuker
has d
eveloped a formal list of properties for software metrics [Weyuker, 1988].
These properties are, however, not without criticism. Fenton suggests that these
properties are not predicated on a single consistent view of complexity [Fenton,
1991]. Cherniavs
ky and Smith suggest that Weyuker’s properties should be used
carefully since the properties may only give necessary, but not sufficient

conditions for good complexity metrics [Cherniavsky and Smith, 1991]. Her list,
while currently still subject to debat
e and refinement, is still a widely known
formal analytical approach and is widely used [Chidamber and Kemerer, 1991,
1994].

38

Even the work done by Chidamber and Kemerer on their metrics suite,
which has been independently validated by several researchers
, has been
criticized for its weaknesses based on measurement theory [Hitz and Montazeri,
1996]. Briand and Morasca acknowledge the theoretical problems in the field of
software measurement [Briand and Morasca, 1996]. They say that concepts such
as compl
exity, coupling, cohesion or even size have inconsistent definitions and
are subject to interpretation. They argue for the need to define unambiguously
the most important measurement concepts, and present a mathematical
framework. The authors use this fr
amework to propose definitions of several
measurement concepts. However, the authors acknowledge that this framework
is not fully objective. Even this framework is not without criticisms. Poels and
Dedene criticize the above framework saying that it has

a number of
inconsistencies which might hinder its acceptance [Poels and Dedene, 1997;
Briand and Morasca, 1997]. They argue that to reach a consensus on a universal
software measurement theory, a number of inconsistencies that may result in
ambiguity an
d confusion must be removed.

Kitchenham, Pfleeger, and Fenton present another Framework for
Software Measurement Validation [Kitchenham, Pfleeger, and Fenton, 1995].
However, this framework is criticized by Morasca et al., arguing that this
framework puts

inappropriate restrictions and is a misrepresentation of
Weyuker’s properti
e
s [Morasca et al., 1997].


Other frameworks have been presented by researchers [Basili

and Weiss
,
1984; Schneidewind, 1992], but after analyzing all these frameworks, one can
only come to th
e conclusion that, a) the need for theoretically sound metrics is
universally recognized, and b) there is as of now no agreement on a consistent
measurement
-
theoretic

basis for the metrics. Harrison, Counsell, and Nithi
39

concur with this summarization.
In a recent paper they opine, “Proposals
concerning the validation of software metrics have been published frequently
and continue to be debated. The community is also beginning to accept that
software metrics must be not only validated theoretically, but

also empirically,
through observation of their use during software development projects both in
the laboratory and in the real world” [Harrison, Counsell, and Nithi, 1998].

2.6 Summary


To summarize the findings from the literature, complexity metrics hav
e
been found to be effective in estimating the maintainability of
software systems.
In fact, this property of the complexity metrics is quite often considered a
necessity to establish the validity of the metrics. Literature survey
however,
also
shows tha
t
the
bulk of the work in the area of complexity metrics is done in the
context of the traditional systems, and also that most of the complexity metrics
are defined at the code level and not at the design level. The IS research
community is showing a stro
ng interest in the area of object
-
oriented metrics, as
evidenced by the number of opinion papers arguing about the need for OO
metrics. We have begun to see a few object
-
oriented metrics emerging on the
scene
, notable among them are the MOOD metrics and

t
he metrics suite
proposed by Ch
i
damber and K
emerer
, which have been used in some validation
stu
dies
.
But,
the

utility of these metrics continues to be que
stioned
.


Overall
,
very little work has been done in validating the

metrics by correlating them to
sof
tware maintainability or any other software quality
, and there is a very strong
need to validate

the metrics
.