product metrics for object-oriented systemsgarcia/cursos/ger_processos/... · 2.1. object-oriented...

Product Metrics for Object-Oriented Systems

SANDEEP PURAO

The Pennsylvania State University

AND

VIJAY VAISHNAVI

Georgia State University

We survey metrics proposed for object-oriented systems, focusing on product metrics.The survey is intended for the purposes of understanding, classifying, and analyzingongoing research in object-oriented metrics. The survey applies fundamentalmeasurement theory to artifacts created by development activities. We develop amathematical formalism that captures this perspective clearly, giving appropriateattention to the peculiarities of the object-oriented system developmenr process.Consistent representation of the available metrics, following this mathematicalformalism, shows that current research in this area contains varying coverage ofdifferent products and their properties at different development stages. The consistentrepresentation also facilitates several analyses including aggregation across metrics,usage across metrics, equivalent formulation of metrics by multiple researchers, andexploitation of traditional metrics for object-oriented metrics. We also trace thechronological development of research in this area, and uncover gaps that suggestopportunities for future research.

Categories and Subject Descriptors: D.2.8 [Software Engineering]: Metrics—Complexity measures, performance measures, product metrics; K.6.3 [SoftwareManagement]: Software development, software maintenance

General Terms: Measurement, Management, Performance

Additional Key Words and Phrases: Software metrics, object-oriented systems,measurement theory, object-oriented metrics, object-oriented product metrics

1. INTRODUCTIONOver the last decade or so, object-orientation has become firmly establishedas the methodology of choice for devel-

The work of the second author was partially supported by a research course release granted by the RobinsonCollege of Business.Authors’ addresses: S. Purao, School of Information Sciences and Technology, The Pennsylvania StateUniversity, University Park, State College, PA 16802; email: [email protected]; V. Vaishnavi, J. MackRobinson College of Business, Georgia State University, Atlanta, GA 30302; email: [email protected] to make digital/hard copy of part or all of this work for personal or classroom use is grantedwithout fee provided that the copies are not made or distributed for profit or commercial advantage, thecopyright notice, the title of the publication, and its date appear, and notice is given that copying is bypermission of ACM, Inc. To copy otherwise, to republish, to post on servers, or to redistribute to lists requiresprior specific permission and/or a fee.c©2003 ACM 0360-0300/03/0600-0191 $5.00

oping new systems. Consequently, a sig-nificant share of efforts in research andindustrial practice has focused on infor-mation systems development with the

ACM Computing Surveys, Vol. 35, No. 2, June 2003, pp. 191–221.

192 Purao and Vaishnavi

object-oriented paradigm. A key researcharea in this field has been measurementof and metrics for object-oriented sys-tems [Lorenz and Kidd 1994; Henderson-Sellers 1996]. As differences betweentraditional and object-oriented system de-velopment have been identified, the needfor metrics, distinct and relevant to object-oriented systems, has been recognized[Berard 1993]. Research in proposing, ap-plying, validating, and extending metricsfor object-oriented systems has reacheda critical mass, as evidenced by severalpublications, presentations, and products(e.g., Lorenz and Kidd 1994; Henderson-Sellers 1996; Zuse 2001).

Much of the research, however, hasbeen opportunistic and fragmented[Henderson-Sellers 1996; Bandi 1998;Briand et al. 1999], without regard forconcerns such as completeness of cov-erage, and has resulted in unnecessaryrepetition of efforts. Without the benefitof a birds-eye perspective, researchersin different groups have continued to“discover” and “propose” similar metrics.For instance, Chidamber and Kemerer[1991], Chen and Lu [1993], Lorenz andKidd [1994], Karlsson [1995], Tegardenet al. [1995] and De Champeaux [1997]all propose metrics that deal with relatedaspects of inheritance in object-orientedsystems. On the other hand, Abreu andCarapuca [1994] and Karlsson [1995]propose metrics that have names thatappear to be related (“polymorphismfactor” and “polymorphism”), though theyentail different computations and havedifferent semantics.

The objective of this paper, therefore, isto present a survey and an analysis of prod-uct metrics proposed for object-orientedsystems so that research on the topic canbe understood, classified, and analyzed.The survey is organized around a frame-work and a mathematical formalism.1The framework is made up of two per-

1 These organizing principles are developed for allobject-oriented metrics. The listing (in the Appendix,available online in the ACM Digital Library) andanalysis of the existing literature focuses on productmetrics, which includes approximately 375 metrics.

spectives, internal and external, appliedto the underlying phenomena—products,processes, and resources—arising fromthe object-oriented development activi-ties. The internal perspective drives thestructure of the mathematical formalismensuring proper application of measure-ment principles. The external perspec-tive allows interpretation and use of themetrics.

The focus of this paper is the internalperspective, following fundamental mea-surement theory, captured by our math-ematical formalism. Using this mathe-matical formalism, we formulate uniformrepresentations of existing metrics. Weanalyze these representations to discoverdisparate or related interpretations ofsimilar concepts and to identify gaps inexisting metrics, and we speculate on howour mathematical formalism can supportthe external (utilitarian) perspective.

The rest of the paper is organized as fol-lows. Section 2 outlines the object-orientedmetrics framework2 elaborating on theobject-oriented development process andthe internal, measurement-theory-basedperspective on metrics. Section 3 identi-fies entities arising out of object-orientedsystem development, lists attributes thatwere generated in a bottom-up manner,and explicates our representation formal-ism by demonstrating its application fora representative sample of metrics. Thecomplete set of metrics identified from areview of the literature—represented withthe formalism—is shown in the Appendix(available in the ACM Digital Library).Section 4 demonstrates usefulness of therepresentation formalism by performingseveral analyses and suggesting a num-ber of others that may be useful. Fi-nally, Section 5 draws conclusions andspeculates on use of the formalism for amapping against the external, utilitarianperspective.

2 The paper is not a survey of metrics frameworks(e.g., Abreu and Carapuca [1994]; Tegarden et al.[1995]; Henderson-Sellers [1996]), though these wereconsulted during the development of our formalismfor representing metrics.

ACM Computing Surveys, Vol. 35, No. 2, June 2003.

Product Metrics for Object-Oriented Systems 193

Fig. 1 . An object-oriented measurement framework.

2. FRAMEWORK

We use the framework shown in Figure 1to organize, understand, and classify theextensive research on object-oriented met-rics. The framework is based on two dis-tinct perspectives about object-orienteddevelopment activities, which give rise toproducts, execute processes, and expendor reuse resources. The first perspective,based on measurement theory [Roberts1979], is the internal perspective. It op-erationalizes the representational or theentity-attribute-metric view [Fenton andPfleeger 1997] to ensure a sound scien-tific basis for each metric. The other per-spective, external perspective, is based onthe purposive or the goal-question-metricparadigm [Basili 1992] and allows the useof metrics in response to prediction or as-sessment needs of system developmentprofessionals.

Following the internal perspective, ametric, then, is a function that assignsa number or symbol to an entity in or-der to characterize an attribute or a groupof attributes. The value of the metric iscalled a measure. Measurement is the pro-cess by which a metric is computed fromattributes of entities in the real worldusing clearly defined rules [Fenton andPfleeger 1997; Finkelstein 1984; Roberts1979].

Rigor in software measurement re-quires separating the scientific basis formeasurement from the eventual use of the

resulting metric. The commonly held view-point that no metric is “valid” unless itis a good predictor can undermine thisrigor. An analogy would be to reject theusefulness of measuring a person’s heighton the grounds that it does not tell usanything about that person’s intelligence[Fenton and Pfleeger 1997]. The result isthat potentially valid metrics of importantinternal attributes become distorted. Overthe last few years, researchers have ques-tioned the scientific basis of many soft-ware metrics [Baker et al. 1990; Fenton1991, 1994; Zuse and Bollman 1989; Zuse1991; Henderson-Sellers 1996]. A largebody of literature on metrics has been crit-icized for not considering their basis inmeasurement theory [Fenton 1994]. Ourfocus in this paper, accordingly, is pre-dominantly on this internal perspective.Such a perspective is necessary to ensurethat the metrics are constructed with aproper scientific basis; however, it is notsufficient.

A corresponding, external view can adda utilitarian perspective—that is, inter-preting measurements in light of thegoals, following the goal-question-metricapproach [Basili 1992]. Given the almostlimitless variety of interpretations of goalsand few validation efforts [Bandi 1998; Liand Henry 1993; Basili et al. 1996], weonly demonstrate (in Section 5) a possi-ble approach to GQM mapping based oneducated speculations about a specific in-stance of the external perspective. Our



primary focus, thus, is on the internal per-spective of the framework.

2.1. Object-Oriented System Development

A meaningful approach to classifyingobject-oriented metrics can start withexamining the underlying phenomenaof object-oriented system development.There is general consensus in academeand practice that developing systemsusing the object-oriented paradigm re-quires new development approaches. Thisstream of thought can be traced toBrooks [1987], who argued for elimi-nating accidental (software) complexityand controlling essential complexity bymatching the method and process tothe application. With object-orientation,the accidental complexity can be mini-mized and the essential complexity canbe better controlled if a process that isappropriate for this paradigm can be fol-lowed. Over the last few years, a num-ber of researchers and practitioners havediscussed and prescribed object-orientedsoftware development approaches (e.g.Rational [2001]; Baudoin and Hollowell[1996]; De Champeaux [1997]; Booch[1994]; Jacobson et al. [1992]). One candiscern two recurring themes in theseapproaches (also see Mili et al. [1995]):(a) an iterative-incremental process, and(b) reuse-based development.3

More broadly, a software developmentprocess is a model for “the progressionfrom identification of a need in some ap-plication domain to the creation of a soft-ware product that responds to that need”[Blum 1994, p. 83]. It identifies develop-ment tasks, establishes expectations forintermediate deliverables, and suggestsreview and evaluation criteria. The two re-curring themes identified above change, inseveral ways, the form and shape of de-velopment process for object-oriented sys-tems, compared to the traditional develop-ment processes.

First, the distinction between analysis,design, and implementation often blurs

3 We do not include in the survey those product met-rics whose purpose is to measure reuse because ofthe paucity of such metrics at the present time.

in object-oriented system development.For example, a developer may deal withthe concept of “class” during the designand construction as well as the deploy-ment phases, refining the understandingthrough these successive phases. This isin contrast to earlier paradigms of devel-opment, which may have used, say, dataflow diagrams during design, hierarchicalcharts during construction, and modulesduring deployment, that is, transformingthe representations through the succes-sive phases. Since the artifacts created ateach stage go through refinement (insteadof transformation) as the development ofan object-oriented system progresses, thisblurring is not only natural but inevitable.The iterations are, therefore, a key as-pect of the development process. Insteadof the traditional, linear, phase-orientedapproaches, other forms such as micro-macro [Booch 1994], recursive-parallel[Berard, 1993], and iterative-incremental[McGregor and Korson 1995]—which sug-gest iteratively building a system in incre-ments that represent increasing levels offunctionality—become more appropriatefor object-oriented system development.

2.2. An Internal Measurement Perspective

An internal measurement perspective pro-vides the appropriate scientific basis formeasurement of the underlying phenom-ena. It suggests that we consider ar-tifacts produced via the object-orientedsystem development process as “things,”similar to the ontological stance pro-posed by Wand and Weber [1995]. Metrics,then, represent measurements of proper-ties of these things. A formal manifesta-tion of this theory is the relational model[Marciniak 1994] (see Figure 2). It seeksto formalize our intuition about the waythe world works. Since one tends to per-ceive the real world by comparing thingsin them, not by assigning numbers tothem [Fenton and Pfleeger 1997, pp. 24–25], relationships, that is, empirical obser-vations, form the basis of measurement.One, then, attempts to develop metricsthat represent attributes of the entitieswe observe, such that manipulation of the



Fig. 2 . The relational model.

metrics preserve relationships we observeamong entities.

The set of entities, E, together with theset of empirical relations, R, is called anempirical relation system (E, R), definedwith respect to a specific attribute. Mea-suring the attribute characterized by (E,R) requires a mapping M into a numeri-cal relation system (N , P ). The represen-tation condition asserts that M maps en-tities in E to numbers in N , and empiricalrelations in R to numerical relations in P ,such that the empirical relations preserveand are preserved by the numerical rela-tions [Fenton and Pfleeger 1997, p. 31]. Forexample, consider the binary relation #,which is mapped by M to the numericalrelation !=. Then, formally, we can assert:x # y ⇔ M (x) !=M ( y). The real worldis called the domain of the mapping, andthe mathematical world is called the range[Fenton and Pfleeger 1997, p. 29].

A metric, then, is a function that assignsa number or symbol to an entity in orderto characterize an attribute or a group ofattributes; the value of the metric is calleda measure. Measurement is the processby which a metric is computed from at-tributes of entities in the real world usingclearly defined rules [Fenton and Pfleeger1997; Finkelstein 1984; Roberts 1979].Following measurement theory, metricscan be classified along two dimensions.The first represents the distinction be-tween direct and indirect measurement.A direct metric is one that can be com-puted without any interpretation. An in-direct metric is one that requires/involves

interpretation [Rombach 1990]. The inter-pretation is applied to the computation ofthe “metric” instead of to the “attribute,”since it is the metric that is “named” by theresearchers. The second dimension distin-guishes between elementary and compos-ite metrics. An elementary metric is onethat maps a single attribute of an entityto a number or symbol; a composite met-ric is one that requires a (mathematical)combination of several elementary metricsfor one or multiple entities [Abreu et al.1995]. Figure 3 summarizes these two di-mensions.

Following the discussion of object-oriented system development (Sec-tion 2.1), another distinction—betweensyntax-based (i.e., static analysis, e.g.,average number of methods per class) andexecution-based (i.e., dynamic analysis,e.g., average frequency of method execu-tion) metrics is also possible [Barnes andSwim 1993]. Metrics in the first categoryare functions that can be computed forartifacts without reference to the execu-tion environment, whereas those in thesecond category can only be computedwith the knowledge of runtime behavior.Separate consideration of this dimensionis not necessary in our framework since amapping to the underlying phenomenon—system development process—capturesthis aspect.4

3. METRICS

3.1. Entities and Attributes forObject-Oriented Systems

Bush and Fenton [1990]; Rombach [1990];Ince [1990], and Fenton [1991, 1994] haveproposed a classification of entities insoftware engineering that are amenableto measurement in three distinct cate-gories: Processes, Products, and Resources.Processes are software-related temporal

4 Yet another dimension, objective versus subjectivemetrics, deals with the measurement technique. Ob-jectivity means precisely defined and repeatedly ob-tainable results, regardless of collector or time; sub-jectivity means depending either on the collector’sjudgment or use of arbitrary procedures. Subjectiv-ity is a larger concern with the external, utilitarian,perspective.



Fig. 3 . Dimensions for classifying metrics.

activities; Products are artifacts, deliv-erables or documents that arise out ofthese processes; and Resources are ele-ments consumed by the processes. Specificinstantiations in each of the above threecategories can differ across different sit-uations. For example, for a large system,the entity Subsystem would be a mean-ingful entity, though it may not be so fora smaller system. Further, the terms usedfor different entities may also differ. Forexample, the term Link may be used insome cases to denote all associations suchas relationships, inheritance, or aggrega-tion links. On the other hand, each of thesemay be considered separate entities in an-other case. Such varying usage is also ob-served in the different metrics proposed byresearchers. To ensure a consistent repre-sentation of the metrics, our first task wasto arrive at a comprehensive superset ofentities.

To achieve this, we iterated using acombination of top-down and bottom-upapproaches. The top-down approach wascharacterized by an examination of theiterative-incremental development lifecy-cle as the basis for identifying the en-tities of interest (see Section 2.1). Theproducts and processes of the lifecyclealong with an identification of resourcesconsumed in these processes provided uswith the first set of entities. These re-sults were supported by the bottom-up ap-proach, which was characterized by a thor-ough survey of metrics proposed for object-oriented systems—adjusting the results toreflect any additional entities considered

by the researchers, which were not iden-tified by the top-down process. Iteratingthrough this combination of approachesresulted in a set of entities, that forms thebasis for our analysis. Following the scopeof the paper, the discussion in this and thefollowing sections focuses on metrics forentities in the Product category.

Another aspect that emerged duringthis combination of approaches was theimportance of the different lifecycle stagesfor characterizing the entities in the Prod-uct category. Due to the incremental na-ture of the object-oriented developmentprocess, and the progressive refinementparadigm (see Section 2.1), products inobject-oriented systems go through fewtransformations. Instead, they are sub-jected to refinements and progress from re-quirements to specifications to implemen-tation and then into an operational state.Consider, for instance, the entity Class,which may be captured as a requirement,defined as part of a design specification,coded as part of an implementation, andrun as part of an operational system. Ateach of these stages, it provides differentopportunities for measurement.

We observed that most researchers haverelegated this aspect to a discussion of“applicability” of a proposed metric atdifferent stages. We argue that this isan important aspect of the definition ofan entity, as it clarifies the measure-ment possibilities for an entity as itproceeds through the different phases.The appropriate mechanism to repre-sent this is to characterize the different



Fig. 4 . States of products.

Table I. Entities for Object-Oriented SystemsEntities States

Abbreviation Name Requirements Design Implementation OperationalAssociation Association

A AttributeC Class

Event EventHierarchy Hierarchy

Link LinkE MessageM Method

Package PackageP Parameter

Scenario ScenarioB SubsystemS SystemU Use Case

Note: Grey cells denote the possible states for which the entity may have metrics.

lifecycle stages as “states” that the en-tity may exist in. Continuing with theexample, the entity Class may exist inall states—requirement, design, imple-mented, or operational—whereas the en-tity Use Case may exist in the statesrequirement and design. We have iden-tified four generic states to which theentities may be mapped. These are: Re-quirements, Design, Implementation, andOperational. Figure 4 shows the states5

identified (for entities in products) definedas follows:

—Requirements: The expression of userneeds about an artifact (e.g., a system)that is yet to be designed or constructed.

5 After a system is deployed, it can be in a mainte-nance (evolution) state. Clearly, metrics are impor-tant for this state as well. However, to keep the pa-per within manageable limits, we do not consider themetrics for this state.

—Design (i.e., specifications): The set ofspecifications that captures, in the formof a blueprint, the user requirements,based on which, the construction of theartifact will proceed.

—Implementation (i.e., code): The artifactafter it has been constructed and built,ready for deployment in its intended en-vironment.

—Operational: The artifact after it isdeployed so that it is functioning inthe intended environment, such as anorganization.

Mapping the entities against the statesidentified above provides us with a pos-sibility matrix, suggesting that possiblydifferent measurements about these enti-ties may be performed in different states.Table I shows the entities and the abbre-viation for entities in the category Product



and the possibility matrix, mapping theentities against the states, with the appro-priate cells marked to indicate the mea-surement possibilities.

Attributes for these entities were iden-tified next. We identified these primarilythrough a bottom-up analysis of the met-rics available in the literature. We firstidentified the set of all the attributes usedin the metrics. We then augmented this setby identifying missing attributes througha comparison of the attributes of differententities. For example, if an attribute of theentity System was structure, a similar at-tribute may have been meaningful for theentity Class. If such an attribute was notrevealed by the bottom-up analysis for theentity Class, it was added. A number ofattributes also fell into clusters followingthese steps. For example, there were sev-eral subattributes related to the attributeposition in hierarchy for the entity Class.These included impact on subclasses, andimpact of superclasses. The process iter-ated across differet entities with the ad-dition, deletion, refinement, or renamingof attributes for each in light of decisionsmade for the other entities. The attributesshown in Table II are the result of this it-erative process.

The entities and attributes provided thefirst two elements of the mathematicalformalism for representing the metrics.Section 3.2 describes this formalism.

3.2. A Mathematical Formalism

The mathematical formalism we havedeveloped provides a logical and coher-ent language for representing the diversemeasures proposed by researchers. Theformalism follows many of the sugges-tions put forward by Henderson-Sellers[1996], such as consistency of naming. Ingeneral, if a symbol, say A, is used torepresent one concept of a variable (say,Attribute), then (i) it should always rep-resent that variable and no other and(ii) only this symbol and no other symbolshould be used for this particular concept.Such consistency supports both rigor andcommunication [Henderson-Sellers 1996].Stylistically, communication and under-

standing are also improved if symbols re-ferring to a consistent set of concepts orinterpretations are similar [Henderson-Sellers 1996].

The following decisions support the ex-pressiveness of our formalism. We assigneach generic metric a name that includesthe mathematical operator(s) used in thedefintion of that metric. The generic met-ric is also expressed as a computable for-mulation. The formulation is based onthe following decisions. To denote a setof entities, we use a symbol derived fromthe first letter, where possible, for exam-ple, C for class or S for system. To in-dicate a restricted population of the set,we use the set followed by a qualifica-tion, for example, A inherited representsthe attributes inherited. An element ofthe set is indicated by a lowercase rep-resentation (a for an attribute or c for aclass). If multiple elements must be rep-resented, we use a count indicator, forexample, a i in A indicates consideringeach attribute in the set of attributes. Theprefix notation is used for the formula-tion, for example, C descendents(c) indi-cates classes that are descendents of aclass, c. In addition, we apply primitive op-erators, for example, |X| to indicate cardi-nality, and other operations such as sum,avg, and fraction. These expect the usualarguments and return the usual results,for example, ‘sum’ expects multiple argu-ments and returns one value. Other thansuch summative operators, a function re-turns a single value if the argument is anelement, and a set of values if the argu-ment is a set.

The computation of each metric is,therefore, expressed as a combinationof mathematical operators on values as-signed to attributes of entities. These arespecified as arguments, as elements orsets, to functions. If the metric requiresa nonprimitive operation, it is specified asa function(), for example, fan-out(), and,where possible, is mapped to the primitiveoperators.

Finally, the mapping of entities to statesis indicated by the notation <as> follow-ing the entity. If an entity can be in mul-tiple states for a measure, all states are



Table II. Attributes for Product Entities in Object-Oriented SystemsEntity Attribute

Abbreviation Name Name SubattributeAssociation Association size

A Attribute interactionposition impact of superclassesposition impact on subclassesposition impact of super plus impact on sub

C Class abstractnessBehaviorcomments

effortinteraction object levelinteraction internalinteraction class levelinterface

performanceposition relative in structureposition changing the impact of superposition changing the impact in subposition impact of superclassesposition impact on subclasses

reuse with respect to other classesreuse internalsize

structure with respect to other classesstructure Aggregatestructure Arrangement

Event Event sizeHierarchy Hierarchy structure Arrangement

Link Link arityE Message sizeM Method abstractness

effortinteraction instance level (similar to object level)interaction definition level (similar to class level)Interface

PerformancePosition impact of superclasses plus impact on subclassesPosition changing the impact from superclassesPosition impact on subclasses/methods of subclassesPosition impact of superclasses/methods of superclassesPosition changing the impact in subclasses

reuse with respect to other methods or classessizesize relative to class

structure Arrangementstructure Aggregatestructure

Package Package abstractnessinteraction

sizestructure

P Parameter sizeScenario Scenario size

B Subsystem interactioninterface

sizestructure Aggregatestructure Arrangement

S System behaviorchange

comments AggregateContinue



Table II. ContinuedEntity Attribute

Abbreviation Name Name Subattributedoc Aggregate

dynamicseffort

interfaceperformancerequirements

reuse from external repositoryreuse Internalreuse Resultsize Aggregatesize

structure Aggregatestructure Arrangement

U Use Case interfacesize

structure

Table III. The Representation FormalismGeneric Form Computable FormulationEntity/Attrib/Name() [Primitive Operation] [Defined Operation] (argument[s]) [Constraints]ExamplesSystem/Structure/max inherit breadth() max (|C at (level i) |), level i in Level(s)

Notation Sets and Elements ExamplesA set of all elements A set of all attributesA qualification a subset of elements A inherited set of inherited

attributesa an element of the set a an attributea i a countable element a i a specific attribute

Prefix Notation MeaningP(m) parameters of a methodC usedBy (c) classes used by a classsum (|T sendMessage(M(c))|) sum of send statements in methods of a classNotes:function (x) = result obtained by applying function to element x.function (X) = set resulting from applying that function to each element of X.the function is read “of” unless specified otherwise, e.g., C usedBy(m).

Notation Primitives Examples|x| Non-Unique |P(M(c))| Number of parameters of methods

Cardinality of the classavg Average avg (|A(c i) |) s.t. c i in C(s) Average number of attributes per

class for the systemsum Summation sum (|M(c)|, |M calledBy(c)|) Sum of methods of the class and

methods called by the methodsof a class

fraction Fraction fraction (|C super(s)|, |C(s)|) Fraction of classes that aresuperclasses in the system

indicated. For example, C <as> Imple-mentation would indicate that the en-tity is being considered in the stateImplementation. Similarly, C <as> De-sign or Implementation would indicatethat the entity is being considered inthe state Design or Implementation. Fi-nally, C <as> Design and Implementa-

tion would indicate that entity being con-sidered is Class, in the states Designand Implementation, since computation ofthe metric requires information from bothstates. The four states outlined earlier andshown in Figure 4 form the basis of thismapping. Table III shows the representa-tion formalism.



Table IV. Representation of Sample Metrics

Generic Metric Name expressed as Metric Formulation expressedEntity<as> State(s)/Attribute/Metric using the Standard Formalism Proposed by E

lem

enta

ry

Dir

ect

Method<as>design or implementation/ |M connectedTo (m)| Nakanishi et al. 1995 y nabstractness/methods connected()Method<as>design or implementation/ |DirectUsersOf (m)| Jacobson et al. 1992 n yinteraction/method users()Association<as>design or Arity (association) De Champeaux 1997 y yimplementation/size/arity()Class<as>design or implementation/ |C ancestors (c)| Abreu and 1994 n yposition/ancestors() CarapucaClass<as>design or implementation/ |C ancestors (c)| De Champeaux 1997 n yposition/ancestors() Li 1998 n y

Tegarden et al. 1995 n y

Class<as>design or implementation/ |C children (c)| Abreu and 1994 y yposition/children() Carapuca

Chidamber and 1994 y yKemererMarchesi 1998 y y

Class<as>design or implementation/ sum(ChenLuValue (A (c))) Chen and Lu 1993 y ystructure/sum attrib chenlu value()Use Case<as>design/interface/ |C offerring (useCase)| Jacobson et al. 1992 y yclasses offering()System<as>design or implementation/ |C parents in r(C(s))| Bieman and 1995 y yreuse/classes reused by inheritance() KarunanithiSystem<as>design or implementation/ |C relatedTo(C parents in Bieman 1995 n nreuse/classes related to classes r(C(s)))| and Karunanithireused by inheritance()

Note: n=no, y= yes.

3.3. Representing O-O Metrics

There exists a rich body of literature onobject-oriented metrics that includes re-search on object-oriented product met-rics, the focus of this paper. Using theformalism outlined in Section 3.2, eachmetric available from the literature isre-represented as an ordered tuple withthree elements <E, A, M>. The first isthe entity (and its mapping to one ormore states), which is explicitly identi-fied following the set of notations shownin Table I. The second is the attribute,following the set of attributes presentedin Table II. Finally, the metric itself isspecified along with the manner of com-putation, following the representation for-malism presented in Table III. The re-representation results in a reformulationof the metrics proposed by different re-searchers to a common language. For ex-ample, the metric proposed by Abreu andCarapuca [1994] is re-represented in the

table as Class<as>design or implementa-tion/position/ancestors( ) and its compu-tation is shown as |C ancestors(c)|. Thepredetermined set of symbols for denot-ing different entities has provided a com-mon language for the representation, andthe format for elements, sets, and differ-ent operations outlined earlier has pro-vided a grammar for this representation.Then, the application of the two has re-sulted in a uniform representation of thegeneric measures addressing a need iden-tified by Henderson-Sellers [1996].

To present the results, we have adopteda tabular format. The metrics have beengrouped following a hierarchy of entitiesand attributes. A specific generic metricmay map to one or more metrics proposedby different researchers. Information onthe origin of the metric is preserved in thepresentation as secondary informationabout the metric. Table IV shows a repre-sentative sample of measures representedusing the above scheme. Observe that the



Table V. Number of Metrics by Entity-AttributeEntity Number of Metrics Attribute Number of Metrics

Association 1 size 1Attribute 4 interaction 2

position 2Class 164 behavior 8

comments 3interaction 46interface 7

performance 5position 23

reuse 8size 10

structure 54Event 1 size 1

Hierarchy 2 arrangement 2Link 0 arity 0

Message 0 size 0Method 36 abstractness 1

interaction 14interface 1

performance 2position 5

size 9structure 4

Package 5 abstractness 1interaction 3structure 1

Parameter 0 size 0Scenario 3 size 3

Subsystem 2 structure 2System 134 change 1

dynamics 12effort 10

interface 1performance 1requirements 5

reuse 27size 19

structure 57unable to determine 1

Use Case 3 interface 1size 2

information in the Elementary and Directcolumns classify the metrics accordingto the classification scheme shown inFigure 3.

The complete tables along with addi-tional information are presented in an ap-pendix, available in the ACM Digital Li-brary. All the information compiled for theavailable metrics is stored in a repository,which facilitates and automates its pro-cessing for further analysis. For example,all the analysis tables shown in Section 4are generated from this repository usingSQL queries.

4. COVERAGE, ANALYSIS, AND TRENDS

4.1. Coverage

The metrics compiled can be viewed fromseveral perspectives to assess coverageachieved by prior research. We developand discuss three such perspectives.

4.1.1. Coverage of Entities and Attributes.The first analysis summarizes the pro-posed metrics using the entity-attributedimension. Table V shows this sum-mary. The table consists of entities and



attributes for these entities arranged ver-tically, against which is shown a count ofmetrics proposed for each entity-attributepair.

The most striking feature of the tableis the number of cells for which very fewmetrics have been proposed. Though infor-mation on Process and Resource metricsis beyond the scope of this paper, we notethat the paucity of metrics is even moresevere for those categories.

4.1.2. Availability of Metrics at DevelopmentStages. One approach to addressing thepaucity of Process-based metrics is to re-consider the Product-based metrics fortheir applicability to different states. Thisprovides the second perspective for our as-sessment of coverage. For example, a met-ric such as Number of Classes can be usedat different states: Requirements, Design,Implementation, and Operational. Mea-suring the same attribute at differentstates can, then, be used as a surrogatefor applicability to different stages ofthe development process. Following thearguments about the development pro-cesses for object-oriented systems (seeSection 2.1), the refinement in products(instead of transformation) can, therefore,be the basis for measuring the process.These metrics can be the basis for measur-ing the progress through phases as wellas iterations of the development process.Further, some metrics are applicable onlyin certain states. These can be useful forchanges observed across increments (ver-sions). For example, measuring Numberof Classes from one version of the im-plemented system to another can providean indication of the functionality realizedduring the increment. Table VI shows theavailability of metrics for entities in thecategory Product across different states.

The table shows the count of metricsfor each entity in the Product categorymapped against the states. For example,the entity Association may be measuredduring the Design and Implementationstates. Metrics that are applicable to mul-tiple states are also indicated against each

entity, indicating the combination of statesfor which these metrics are applicable.Note that the total across columns, fora row, may not match the correspondingnumber in Table V due to the possible ap-pearance of a metric in multiple cells alongthe row.

Table VI indicates that the numberof metrics proposed for the Design, andImplementation states far outweigh thoseproposed for either the Requirements orOperational states. One possible explana-tion for this bias may be the relative easewith which metrics at the former statescan be computed compared to those at thelatter two states. Clearly, additional met-rics are needed at the Requirements andOperational states. A significant numberof metrics apply to multiple states, forexample, Design as well as Implemen-tation. This is supported by the natureof the development process for object-oriented systems, which is one of iterativerefinement rather than transformation.Metrics that utilize information avail-able in multiple states provide anotheropportunity. However, few such metricshave been proposed. With the paradigm ofrefinement for the development process, itwould be reasonable to expect that moremetrics would be suggested that comparesimilar properties measured across multi-ple states. This represents another majorshortcoming of existing research.

4.1.3. Classification Based on Elementarityand Directness. Finally, a third perspectiveis afforded by the nature of the metric fol-lowing the classification scheme proposedin Figure 3. This scheme classifies the met-rics along two dimensions: direct versusindirect, and elementary versus compos-ite. In Table VII, we provide a summary ofthe metrics proposed along these two di-mensions. The table shows a count of met-rics for each entity—attribute, mappedagainst the values of the two classificationdimensions.

The table shows that the proposedmetrics are concentrated in the Direct-Elementary column (leftmost column)



Table VI. Availability of Metrics at Different StatesEntity Attribute 1 2 3 4 1 or 2 1 or 3 2 or 3 3 or 4 1 or 2 or 3 1 or 3 or 4

Association size 1Attribute position 2

interaction 2Class performance 1 3 1

structure 13 39size 1 9

position 6 16interface 1 5

interaction 1 17 22 1comments 3behavior 7 1

reuse 1 1 1Event size 1

Hierarchy arrangement 2Link arity

Message sizeMethod performance 1 1

Interface 1abstractness 1

position 5size 6 3

structure 1 2 1interaction 1 1 12

Package abstractness 1interaction 1 2structure 1

Parameter sizeScenario size 2 1

Subsystem structure 2System dynamics 1 9

structure 6 7 42 1size 1 3 4 3 8

reuse 2 22requirements 5

effort 3 1change 1

performance 1Use Case size 2

interface 1Legend: 1 =Requirements, 2 =Design, 3 = Implementation, 4 =Operational.

or Indirect-Composite column (rightmostcolumn). The concentration in the left-most column is heartening since it in-dicates that researchers have implicitlyfollowed good measurement principles,which clearly map to a single entity and asingle attribute. The focus also representsan opportunity. The elementary metricscan be combined in several ways to deriveadditional, interesting metrics that couldbecome the basis of mappings against ex-ternal concerns. The concentration in therightmost column appears problematic asit indicates that several metrics are beingproposed that may lack a sound measure-ment basis, particularly as their measure-

ment inherently requires interpretationfrom the developers.

4.2. Analysis

The representation formalism allows sev-eral paths for analyzing the metrics. Inthis section, we demonstrate a few of thesepossibilities. These do not constitute anexhaustive list. Several additional com-parisons and analyses are possible withthe consistent representation scheme wehave suggested.

4.2.1. Aggregations Across Metrics. Ag-gregation reflects how object-oriented



Table VII. Number of Metrics by Metric-TypeEntity Attribute Direct Indirect

Elementary Composite Elementary CompositeAssociation size 1Attribute interaction 2

position 2Class behavior 5 1 2

comments 3interaction 4 4 10 28interface 2 1 1 3

performance 5position 6 4 1 12

reuse 4 1 3size 5 1 1 3

structure 14 2 8 30Event size 1

Hierarchy arrangement 2Link arity

Message sizeMethod abstractness 1

interaction 5 4 3 2interface 1

performance 2position 2 2 1

size 5 1 1 2structure 4


Parameter sizeScenario size 1 2

Subsystem structure 2System change 1

dynamics 12effort 9 1

interface 1performance 1requirements 2 3

reuse 10 2 2 13size 9 3 2 5

structure 21 13 7 16unknown 1

Use Case interface 1size 2

artifacts are structured, for example, howmethods and attributes “aggregate” to be-come classes. Aggregation across metricsreflects the use of a summative opera-tor (sum, average, etc.) to define a metricfor an entity from the corresponding met-rics for its constituent entities. For exam-ple, the metrics avg inherit depth() andmax inherit depth() for the entity Sys-tem represent different aggregations ofthe metric depth from root() for the en-tity Class. As individual Classes are ag-gregated into a System, properties of (i.e.,metrics about) Classes can be aggregatedinto properties of (i.e., metrics about) Sys-

tems. A number of existing metrics canbe mapped against one another in thismanner. In fact, a number of metrics forthe entity System do represent aggre-gations of metrics proposed for the en-tity Class. Table VIII shows a mappingof existing metrics that are related toeach other via such aggregation. It showsthe two metrics related to each otherin this manner, and shows the compu-tation of one that involves aggregatingthe other. As can be seen from the re-sults, a number of metrics do, in fact,represent aggregations of other metrics.Such aggregation, however, assumes that


206 Purao and VaishnaviTa

ble

VIII

.A

ggre

gatio

nA

cros

sM

etric

sM

etri

c1

Met

ric

2M

etri

c1

asA

ggre

gati

onof

<Met

ric

2>S

yste

m/s

tru

ctu

re/s

um

asso

ciat

ion

arit

y()

Ass

ocia

tion

/siz

e/ar

ity(

)su

m(<

arit

y(as

soci

atio

ni)

>)s.

t.as

soci

atio

nii

nA

ssoc

iati

ons(

s)S

yste

m/s

tru

ctu

re/s

um

asso

ciat

ion

arit

yan

dcl

asse

s()

Ass

ocia

tion

/siz

e/ar

ity(

)su

m(<

clas

ses(

s)>,

sum

<ari

ty(a

ssoc

iati

oni)

>s.

t.as

soci

atio

nii

nA

ssoc

iati

on(s

))S

yste

m/s

tru

ctu

re/a

vgin

stan

cem

eth

ods(

)C

lass

/siz

e/in

stan

cem

eth

ods(

)av

g(<

inst

ance

met

hod

s(c

i)>)

s.t

cii

nC

(s)

Sys

tem

/str

uct

ure

/avg

inst

ance

attr

ibu

tes(

)C

lass

/siz

e/at

trib

ute

s()

avg

(<at

trib

ute

s(c

j)>)

s.t.

cii

nC

(s)

Cla

ss/s

ize/

sum

attr

ibu

tes

and

met

hod

sde

fin

ed()

Cla

ss/s

ize/

attr

ibu

tes(

)su

m(<

attr

ibu

tes(

c)>,

<met

hod

s(c)

>)

Cla

ss/r

euse

/avg

glob

alu

sage

per

met

hod

()C

lass

/siz

e/m

eth

ods(

)(s

um|R

efer

ence

sToG

loba

l(s(

c))|,

<cla

ssat

trib

s(c)

>)/(

<met

hod

s(c)

>)C

lass

/siz

e/su

mat

trib

ute

san

dm

eth

ods

defi

ned

()C

lass

/siz

e/m

eth

ods(

)su

m(<

attr

ibu

tes(

c)>,

<met

hod

s(c)

>)

Cla

ss/in

terf

ace/

sum

met

hod

sin

and

met

hod

sca

lled

()C

lass

/siz

e/m

eth

ods(

)su

m(<

met

hod

s(c)

>,|M

call

edB

y(c)|)

Cla

ss/in

tera

ctio

n/a

vgn

onlo

cal

refs

()C

lass

/siz

e/m

eth

ods(

)(<

sum

met

hod

non

loca

lref

s(c)

/(<m

eth

ods(

c)>)

Sys

tem

/str

uct

ure

/avg

inh

erit

edm

eth

ods(

)C

lass

/siz

e/m

eth

ods(

)av

g(<

met

hod

sin

her

ited

(ci(

s))>

)s.

t.c

iin

C(s

)C

lass

/inte

ract

ion

/su

mm

eth

ods

sen

din

gm

essa

ges

to()

Cla

ss/s

ize/

met

hod

s()

sum

(<m

eth

ods

sen

din

gm

essa

ges

to(m

i)>)

s.t.

mii

nM

(c)

Sys

tem

/str

uct

ure

/avg

clas

sm

eth

ods(

)C

lass

/siz

e/cl

ass

met

hod

s()

avg

(<cl

ass

met

hod

s(c

i)>)

s.t

cii

nC

(s)

Cla

ss/in

tera

ctio

n/s

um

mes

sage

exch

ange

s()

Cla

ss/s

ize/

mes

sage

sre

ceiv

edby

clas

s()

sum

(<m

essa

ges

sen

t(O

(c))

>,<m

essa

ges

rece

ived

bycl

ass

(O(c

))>)

Sys

tem

/str

uct

ure

/su

msy

nta

xh

alst

ead

com

plex

ity(

)C

lass

/str

uct

ure

/su

mm

eth

odco

mpl

exit

y()

sum

((H

alst

ead

com

plex

ity(

mi)

*<s

um

met

hod

com

plex

ity(

mi)

>)/s

um

(usa

bili

ty(s

)))

s.t.

mii

nM

(C(s

)),n

oco

mpu

tabl

efo

rmu

lati

onof

usa

bili

ty()

prov

ided

Sys

tem

/str

uct

ure

/avg

clas

sre

spon

sibi

liti

es()

Cla

ss/s

tru

ctu

re/s

um

clas

sre

spon

sibi

liti

es()

avg

(<su

mcl

ass

resp

onsi

bili

ties

(ci)

>)s.

t.c

iin

C(s

)

Cla

ss/in

tera

ctio

n/s

um

exte

rnal

inte

ract

ion

()C

lass

/str

uct

ure

/pu

blic

met

hod

s()

sum

(su

m(<

publ

icm

eth

ods(

c)>,

<pu

blic

attr

ibu

te(c

)>),

sum

(|Cal

lsT

o(M

(ci)

)|,|U

sage

Of(

A(c

i)|))

)s.

t.c

iin

C(s

(c))

,cin

oteq

ual

toc

Sys

tem

/str

uct

ure

/avg

inh

erit

dept

h()

Cla

ss/p

osit

ion

/dep

thfr

omro

ot()

avg

(<de

pth

from

root

(ci)

>)s.

t.c

iin

C(s

)C

lass

/pos

itio

n/m

axin

her

itde

pth

()C

lass

/pos

itio

n/d

epth

from

root

()m

ax(<

dept

hfr

omro

ot(c

)>)

Sys

tem

/str

uct

ure

/su

min

her

itan

ceco

mpl

exit

y()

Cla

ss/p

osit

ion

/dep

thfr

omro

ot()

sum

(in

tern

alC

ompl

exit

y(M

(cj)

*(1-

rela

tive

Ord

er(c

j)))

*<d

epth

from

root

(ci)

>,<c

hil

dren

(ci)

>s.

t.c

jin

Can

cest

or(c

i),c

iin

C(s

)w

her

eco

mpu

tabl

efo

rmu

lati

ons

ofin

tern

alC

ompl

exit

y()

and

rela

tive

Ord

er()

are

not

prov

ided

.S

yste

m/d

ynam

ics/

sum

inte

ract

ion

com

plex

ity(

)C

lass

/pos

itio

n/a

nce

stor

s()

sum

(com

plex

ity(

ci)

*<an

cest

ors(

ci)

>,R

FC

met

ricN

um

ber(

ci)

,|P

(M(c

i))|,|T

sen

dMes

sage

(ci)|)

s.t

cii

nC

(s)

wh

ere

no

com

puta

ble

form

ula

tion

for

com

plex

ity(

ci)

ispr

ovid

edan

dco

nfl

icti

ng

form

ula

tion

ispr

ovid

edfo

r|P

(M(c

))|

Sys

tem

/str

uct

ure

/avg

inh

erit

edm

eth

ods(

)C

lass

/pos

itio

n/m

eth

ods

inh

erit

ed()

avg

(<m

eth

ods

inh

erit

ed(c

i(s)

)>)

s.t.

cii

nC

(s)

Sys

tem

/str

uct

ure

/su

mex

pon

enti

alin

non

root

pare

nts

()C

lass

/pos

itio

n/p

aren

ts()

sum

(k∧

(<pa

ren

ts(c

non

Roo

ti)

>-1)

)s.

t.c

non

Roo

tii

n(C

(s)-

Cro

ot(s

)),

k>

1


Product Metrics for Object-Oriented Systems 207S

yste

m/s

tru

ctu

re/s

um

inh

erit

ance

com

plex

ity(

)C

lass

/pos

itio

n/c

hil

dren

()su

m(i

nte

rnal

Com

plex

ity(

M(c

j)*(

1-re

lati

veO

rder

(cj)

))*

<dep

thfr

omro

ot(c

i)>,

<ch

ildr

en(c

i)>

s.t.

cji

nC

ance

stor

(ci)

,cii

nC

(s)

wh

ere

com

puta

ble

form

ula

tion

sof

inte

rnal

Com

plex

ity(

)an

dre

lati

veO

rder

()ar

en

otpr

ovid

ed.

Cla

ss/in

tera

ctio

n/s

um

met

hod

sse

ndi

ng

mes

sage

sto

()C

lass

/inte

ract

ion

/met

hod

sse

ndi

ng

mes

sage

sto

()su

m(<

met

hod

sse

ndi

ng

mes

sage

sto

(mi)

>)s.

t.m

iin

M(c

)

Cla

ss/in

tera

ctio

n/s

um

mes

sage

exch

ange

s()

Cla

ss/in

tera

ctio

n/m

essa

ges

sen

t()

sum

(<m

essa

ges

sen

t(O

(c))

>,<m

essa

ges

rece

ived

bycl

ass

(O(c

))>)

Sys

tem

/dyn

amic

s/su

mat

trib

para

min

tera

ctio

nfo

rsy

stem

()C

lass

/inte

ract

ion

/su

mat

trib

para

min

tera

ctio

n()

sum

(<su

mat

trib

para

min

tera

ctio

n(c

i)>)

s.t.

cii

nC

(s)

Rep

osit

ory/

reu

se/a

vgre

use

freq

uen

cype

rcl

ass

Cla

ss/r

euse

/reu

sefr

equ

ency

()av

g(<

reu

sefr

equ

ency

(ci)

>)s.

t.c

iin

C(r

epos

itor

y)

Sys

tem

/inte

rfac

e/av

gw

eigh

ted

sum

met

hod

para

ms(

)C

lass

/inte

rfac

e/w

eigh

ted

sum

met

hod

para

ms(

)av

g(<

wei

ghte

dsu

mm

eth

odpa

ram

s(c

i)>)

s.t.

cii

nC

(s)

Cla

ss/s

tru

ctu

re/a

vgm

eth

odm

ccab

eco

mpl

exit

y()

Met

hod

/str

uct

ure

/met

hod

mcc

abe

com

plex

ity(

)av

g(<

met

hod

mcc

abe

com

plex

ity

(M(c

))>)

Cla

ss/s

tru

ctu

re/s

um

clas

sle

ngt

hpa

ram

sin

tera

ctio

n()

Met

hod

/str

uct

ure

/met

hod

len

gth

para

ms

inte

ract

ion

()su

m<m

eth

odle

ngt

hpa

ram

sin

tera

ctio

n(m

i)>

s.t.

mii

nM

(c)

Met

hod

/inte

ract

ion

/su

min

put

outp

ut

para

ms(

)M

eth

od/in

tera

ctio

n/a

rgu

men

tsse

nt(

)su

m(<

argu

men

tsre

ceiv

ed(m

)>,<

argu

men

tsse

nt(

m)>

)

Sys

tem

/dyn

amic

s/su

mat

trib

para

min

tera

ctio

nfo

rsy

stem

()M

eth

od/in

tera

ctio

n/s

um

attr

ibpa

ram

inte

ract

ion

()su

m(<

sum

attr

ibpa

ram

inte

ract

ion

(ci)

>)s.

t.c

iin

C(s

)

Met

hod

/inte

ract

ion

/su

min

put

outp

ut

para

ms(

)M

eth

od/in

tera

ctio

n/a

rgu

men

tsre

ceiv

ed()

sum

(<ar

gum

ents

rece

ived

(m)>

,<ar

gum

ents

sen

t(m

)>)

Cla

ss/in

tera

ctio

n/s

um

met

hod

sse

ndi

ng

mes

sage

sto

()M

eth

od/in

tera

ctio

n/m

eth

ods

sen

din

gm

essa

ges

to()

sum

(<m

eth

ods

sen

din

gm

essa

ges

to(m

i)>)

s.t.

mii

nM

(c)

Cla

ss/in

tera

ctio

n/s

um

mes

sage

exch

ange

s()

Met

hod

/inte

ract

ion

/mes

sage

sse

nt(

)su

m(<

mes

sage

sse

nt

(O(c

))>,

<mes

sage

sre

ceiv

edby

clas

s(O

(c))

>)

Cla

ss/in

tera

ctio

n/a

vgn

onlo

cal

refs

()M

eth

od/in

tera

ctio

n/s

um

met

hod

non

loca

lref

s()

(<su

mm

eth

odn

onlo

calr

efs(

c)/(

<met

hod

s(c)

>)

Sys

tem

/str

uct

ure

/avg

met

hod

size

()M

eth

od/s

ize/

lin

esof

code

()av

g(<

lin

esof

code

(mi)

>)s.

tm

iin

M(C

(s))

Sys

tem

/str

uct

ure

/avg

inte

rpa

ckag

ecl

ass

usa

ge()

Pac

kage

/inte

ract

ion

/su

mu

sage

ofcl

asse

sin

oth

erpa

ckag

es()

avg

(<su

mu

sage

ofcl

asse

sin

oth

erpa

ckag

es(p

acka

gei)

>)s.

t.pa

ckag

eii

nP

acka

ges(

s)S

yste

m/s

tru

ctu

re/s

um

asso

ciat

ion

arit

yan

dcl

asse

s()

Sys

tem

/siz

e/cl

asse

s()

sum

(<cl

asse

s(s)

>,su

m<a

rity

(ass

ocia

tion

i)>

s.t.

asso

ciat

ion

iin

Ass

ocia

tion

(s))

Cla

ss/in

tera

ctio

n/s

um

mes

sage

exch

ange

s()

Sys

tem

/siz

e/m

essa

ges(

)su

m(<

mes

sage

sse

nt

(O(c

))>,

<mes

sage

sre

ceiv

edby

clas

s(O

(c))

>)

Sys

tem

/siz

e/su

msc

enar

iosi

zes(

)S

cen

ario

/siz

e/w

eigh

ted

obje

cts

and

inte

ract

ion

s()

sum

(<w

eigh

ted

obje

cts

and

inte

ract

ion

s(sc

enar

ioi)

>)s.

t.sc

enar

ioii

nS

cen

ario

(s)

Not

e:s.

t.=

such

that

.



the property being measured can, in fact,be aggregated. Some aggregate metrics,however, violate this assumption, for ex-ample, when sum halstead complexity()is computed for the entity System usingsum method complexity() for each class asthe input.

The notion of aggregation also presentsan opportunity. Several metrics may beidentified for whom such aggregationshave not been proposed by other re-searchers. The inverse is also true. Basedon aggregate measures suggested, the cor-responding elemental measures can bederived. The natural aggregation relation-ships between entities, such as Method-Class and Class-System, therefore, clearlysuggest opportunities for aggregating ordecomposing metrics across these entitiesalong the dimensions of artifact granular-ity and mathematical aggregation akin tothose suggested by Talbi et al. [2001].

4.2.2. Usage Across Metrics. Usage ac-ross metrics represents the use of one ormore existing metric definitions for defin-ing a new metric. It represents a notionsimilar to the idea of composite metricsdiscussed earlier (see Figure 3). Often,such usage can occur when one metric def-inition (e.g., “number of methods”) is usedby another metric definition (e.g., “fractionof public methods”). The usage therefore,typically, occurs within the properties fora single entity as opposed to across enti-ties. Several metrics use other metrics in anumber of ways. Table IX shows this usageacross metrics. It shows the computationthat exploits another metric, indicatedby <angular brackets>. For instance, themetric average method attribute usage()utilizes the metrics <attributes(c)> and<methods(c)> in its computation. FromTable IX, it is apparent that some met-rics that represent basic counting suchas number of attributes <attributes(c)> ornumber of methods <methods(c)> are usedrepeatedly in the computation of othermetrics. This points to the need for accu-rate counting practices. For example, it isnecessary to clearly specify the manner ofcounting number of methods by address-

ing nuances such as inherited methods,overridden methods, virtual methods, getand set methods, etc. Without clear ap-plication of such practices, these metricsare likely to lead to widely different re-sults. A second observation from Table IXis the existence of several composite met-rics that use more than one elementarymetrics. For example, consider the met-ric relative position(). It uses as many asfour other metrics including <parents(c)>,<depth from root(c)>, <local methods(c)>,and <methods inherited(c)>. We contendthat such usage of multiple elementarymetrics is likely to be against the basictenets of measurement principles. The ex-ample cited here, for instance, attempts toadd the values from the above componentmetrics. The resulting metric, therefore,may not be able to measure a meaningfulproperty of interest.

Analysis of metrics in this manner—usage in computation in other metrics—therefore, underscores the importance ofsome elementary metrics that are repeat-edly used and suggests opportunities forinvestigating the appropriateness of othermetrics that utilize multiple componentmetrics.

4.2.3. Equivalent Formulations of RelatedMetrics. A few metrics represent similarproposals by different researchers. The ev-ident popularity of these metrics (similarproposals from multiple researchers) sug-gests that the metrics are either (a) im-portant and recognized as such by mul-tiple researchers, or (b) easy to computeand represent straightforward opportuni-ties for counting. In general, we find thatthe latter has dictated the identificationof similar metrics by multiple researchers.Table X shows these metrics. For eachmetric that is suggested by multiple re-searchers, we show the generic metricname, and the number of researchers whohave proposed the metric. A qualificationfor inclusion in this table is that the re-lated metrics follow identical or at leastsubstantially similar formulations. Theanalysis highlights the importance of acommon language for expressing the met-ric and a common repository for metrics.


Product Metrics for Object-Oriented Systems 209Ta

ble

IX.

Usa

geA

cros

sM

etric

sM

etri

c1

Met

ric

2C

ompu

tati

onof

Met

ric

1u

sin

g<M

etri

c2>

Cla

ss/b

ehav

ior/

attr

iban

dm

eth

odpo

lym

orph

ism

()A

ttri

bute

/pos

itio

n/c

lass

esde

fin

edin

()n

orm

aliz

edsu

m(<

clas

ses

defi

ned

in(a

)>,<

clas

ses

defi

ned

in(m

)>)

--

“nor

mal

ized

sum

()”

not

defi

ned

Sys

tem

/str

uct

ure

/fra

ctio

nat

trib

hid

ing(

)C

lass

/siz

e/at

trib

ute

s()

frac

tion

(su

m(|A

hid

den

(ci)|),

sum

(<at

trib

ute

s(c

j)>)

)s.

t.c

i,c

jin

C(s

)S

yste

m/s

tru

ctu

re/f

ract

ion

attr

ibu

tein

her

it()

Cla

ss/s

ize/

attr

ibu

tes(

)fr

acti

on(s

um

(|Ain

her

ited

(ci)|),

sum

(<at

trib

ute

s(c

j)>)

)s.

t.c

i,c

jin

C(s

)S

yste

m/s

ize/

wei

ghte

dsu

mat

trib

ute

sm

eth

ods(

)C

lass

/siz

e/at

trib

ute

s()

wei

ghte

dsu

m(<

attr

ibu

tes(

ci)

>,<m

eth

ods(

ci)

>)s.

t.c

iin

C(s

)

Sys

tem

/reu

se/f

ract

ion

reu

sesa

vin

gsge

ner

aliz

atio

nco

sts(

)C

lass

/siz

e/at

trib

ute

s()

frac

tion

((w

eigh

ted

sum

(A(c

i),M

(ci)

,neg

ativ

e(re

use

Cos

t(c

i)))

)+w

eigh

ted

sum

(reu

seF

ract

ion

(cj)

*<at

trib

ute

s(c

j)>,

reu

seF

ract

ion

(cj)

*<m

eth

ods(

cj)

>,n

egat

ive(

reu

seC

ost(

cj)

))),

wei

ghte

dsu

m(<

attr

ibu

tes(

ck)

>,<m

eth

ods(

ck)

>)*

gen

eral

izat

ion

Cos

t(c

k)))

s.t.

cii

nC

reu

sedF

rom

Rep

osit

ory(

s),c

jin

Cin

her

ited

An

dUse

d(s)

,ck

inC

reu

sabl

ePro

duce

dFro

m(s

)C

lass

/str

uct

ure

/wei

ghte

dsu

mat

trib

ute

asso

ciat

ion

met

hod

sru

lefo

rcl

ass(

)C

lass

/siz

e/at

trib

ute

s()

sum

(wei

ght1

*(<a

ttri

bute

s(c)

>+|A

ssoc

iati

ons(

c)|),

wei

ght2

*av

g(<l

ines

ofco

de(M

(c))

>)/S

TD

LO

C*

<met

hod

s(c)

>,w

eigh

t3*

|Ru

lesP

erR

ule

Set

(c)|

*av

g(|A

nte

cede

ntC

lau

sesP

erR

ule

(c)|)

*|R

ule

Set

s(c)|)

wh

ere

ST

DL

OC

mea

ns

agre

edla

ngu

age-

depe

nde

nt

stan

dard

LO

Cpe

rm

eth

od,o

ther

term

sn

otfu

lly

defi

ned

,wei

ghts

deci

ded

byde

sign

erC

lass

/str

uct

ure

/met

hod

attr

ibu

teu

sage

fun

ctio

n()

Cla

ss/s

ize/

attr

ibu

tes(

)fr

acti

on(s

um

(|Mco

nta

inin

gm

i(c)|),

(<at

trib

ute

s(c)

>*|X|))

s.t.

X=

Mad

ded(

c)u

nio

nM

inh

erit

edR

odefi

ned

(c),

mii

nX

.C

lass

/str

uct

ure

/ave

rage

met

hod

attr

ibu

teu

sage

()C

lass

/siz

e/at

trib

ute

s()

frac

tion

(su

m(|M

usi

ng(

ai)|/<

met

hod

s(c)

>),<

attr

ibu

tes(

c)>)

s.t.

aii

nA

(c)

Met

hod

/str

uct

ure

/met

hod

len

gth

para

ms

inte

ract

ion

()C

lass

/siz

e/at

trib

ute

s()

len

gth

(m)

*sq

uar

e(c

oupl

ing(

m))

s.t.

len

gth

(m)=|T

if(m

)|+

|Tca

se(m

)|+<a

ttri

bute

s(m

)>;c

oupl

ing(

m)=

sum

(ip(

m),

op(m

))s.

t.ip

(m)=

(1+

<arg

um

ents

rece

ived

(m)>+

void

(m))

s.t.

void

(m)=

1if

mre

turn

sva

lue

and

0,ot

her

wis

e;op

(m)=

(su

m(|R

efer

ence

sTo

mi(

m)|

*(1+|P

refe

ren

cedB

ym

(mi)|+

void

(mi)

)+su

m(|R

efer

ence

sTo

aj(

m)|)

)s.

t.m

iin

Mre

fere

nce

dBy

(m),

aji

nA

refe

ren

cedB

y(m

)C

lass

/str

uct

ure

/cla

ssle

ngt

hin

tera

ctio

n()

Cla

ss/s

ize/

attr

ibu

tes(

)le

ngt

h(c

)*

squ

are

(cou

plin

g(c)

)s.

t.le

ngt

h(c

)=su

m(l

engt

h(m

i))

s.t.

mii

nM

(c);

cou

plin

g(c)=

sum

(ip(

mj)+

(su

m(r

jk)+

sum

(rj

l)))

s.t.

mji

nM

(c),

k=

1..N

MR

(c),

l=N

MR

(c)+

1..N

MR

(c)+

NV

R(c

),N

MR

(c)=|u

niq

ue

(Mre

fere

nce

dBy(

M(c

)))|,

NV

R(c

)=|u

niq

ue

(Are

fere

nce

dBy

(M(c

)))|,

rj

k=|R

efer

ence

sTo

mk

(mj)|*

(1+

|Rre

fere

nce

dBy

mj(

mk)+

void

(mk)

,rj

l+|R

efer

ence

sTo

al(

mj)|

s.t.

len

gth

(m)=|T

ys(m

)|+|T

case

(m)|+

<att

ribu

tes(

m)>

;co

upl

ing(

m)=

sum

(ip(

m),

op(m

))s.

t.ip

(m)=

(1+

<arg

um

ents

rece

ived

(m)>+

void

(m))

s.t.

void

(m)=

1if

mre

turn

sva

lue

and

0,ot

her

wis

e;op

(m)=

(su

m(|R

efer

ence

sTo

mi(

m)|

*(1+

Con

tin

ue



ble

IX.

Con

tinue

dM

etri

c1

Met

ric

2C

ompu

tati

onof

Met

ric

1u

sin

g<M

etri

c2>

|Pre

fere

nce

dBy

m(m

i)|+

void

(mi)

)+su

m(|R

efer

ence

sTo

aj(

m)|)

)s.

t.m

iin

Mre

fere

nce

dBy

(m),

aji

nA

refe

ren

cedB

y(m

)C

lass

/reu

se/in

terf

ace

attr

ibu

tem

eth

odm

ean

ing

and

acce

ss()

Cla

ss/s

ize/

attr

ibu

tes(

)re

usa

bili

ty(c

)*

((su

m(r

eusa

bili

ty(m

i)s.

t.m

iin

M(c

)))/

<met

hod

s(c)

>)+

((su

m(r

eusa

bili

ty(a

j)s.

t.a

jin

A(c

)))/

<att

ribu

tes(

c)>)

,s.t

.reu

sabi

lity

(c)=

(des

crip

tion

mea

nin

gfu

lnes

s(c

)+n

ame

-m

ean

ingf

uln

ess

(c))

/(|C

cou

pled

To

(c)|+

<dep

thfr

omro

ot(c

)>+

1),r

eusa

bili

ty(m

i)=

(nam

em

ean

ingf

uln

ess

(mi)+

Pu

sedB

y(m

i)+

((su

m(r

eusa

bili

ty(p

k))

s.t.

pk

inP

(mi)

)/|p(

mi)|))

/(|fu

nct

ion

spe

rfor

med

By

(mi)+

call

sTo

-fo

reig

nC

lass

es(m

i)|),

reu

sabi

lity

(pk)=

(nam

em

ean

ingf

uln

ess

(pk)

)/(|s

ubT

ypes

Of

(typ

esO

f(p

k)|+

1)or=

5if|p(

mi)|=

0,re

usa

bili

ty(a

j)=

(nam

em

ean

ingf

uln

ess

(aj)

)/(|s

ubT

ypes

Of

(aJ)|+

1)s.

t.n

ame

mea

nin

gfu

lnes

s()

and

desc

ript

ion

mea

nin

gfu

lnes

s()

are

deci

ded

ona

scal

e1.

.5by

the

deve

lope

r.C

lass

/str

uct

ure

/fra

ctio

nm

eth

odat

trib

ute

usa

ge()

Cla

ss/s

ize/

attr

ibu

tes(

)fr

acti

on((

sum

(|Mac

cess

ing

ai(

c)|/<

attr

ibu

tes(

c)>)

-|M|),

(1-|M|))

s.t.

aii

nA

(c)

frac

tion

((<m

eth

ods(

c)>

-su

m(|M

acce

ssin

ga

i(c)|))

,|M

(c)|)

s.t.

aii

nA

(c)

Cla

ss/s

tru

ctu

re/f

ract

ion

priv

ate

attr

ibu

tes(

)C

lass

/siz

e/at

trib

ute

s()

frac

tion

(|Apr

ivat

e(c)|,<

attr

ibu

tes(

c)>)

Cla

ss/s

tru

ctu

re/f

ract

ion

obje

ctva

lued

atrr

ibu

tes(

)C

lass

/siz

e/at

trib

ute

s()

frac

tion

(|Aob

ject

Val

ued

(c)|,

<att

ribu

tes(

c)>)

Cla

ss/s

tru

ctu

re/f

ract

ion

sim

ple

valu

eat

trib

ute

s()

Cla

ss/s

ize/

attr

ibu

tes(

)fr

acti

on(|A

valu

e(c)|,<

attr

ibu

tes(

c)>)

Sys

tem

/str

uct

ure

/fra

ctio

nm

eth

odh

idin

g()

Cla

ss/s

ize/

met

hod

s()

frac

tion

(su

m(|M

hid

den

(ci)|),

sum

(<m

eth

ods(

cj)

>))

s.t.

ci,

cji

nC

(s)

Sys

tem

/str

uct

ure

/fra

ctio

nm

eth

odin

her

it()

Cla

ss/s

ize/

met

hod

s()

frac

tion

(su

m(<

met

hod

sin

her

ited

(ci)

>),s

um

(<m

eth

ods(

cj)

>)),

s.t.

ci,

cji

nC

(s)

Sys

tem

/str

uct

ure

/fra

ctio

nov

erri

dden

met

hod

sn

ewm

eth

ods(

)C

lass

/siz

e/m

eth

ods(

)fr

acti

on(s

um

(<m

eth

ods

over

ridd

en(c

i)>)

,su

m(|M

new

(cj)|)

*su

m(<

desc

enda

nts

(cj)

>))

s.t.

ci,

cji

nC

(s)

Cla

ss/c

omm

ents

/fra

ctio

nco

mm

ente

dm

eth

ods(

)C

lass

/siz

e/m

eth

ods(

)fr

acti

on(|M

com

men

ted

(c)|,

<met

hod

s(c)

>)

Cla

ss/p

osit

ion

/rel

ativ

epo

siti

on()

Cla

ss/s

ize/

met

hod

s()

sum

(<de

pth

from

root

(c)>

,<pa

ren

ts(c

)>,<

met

hod

sin

her

ited

(c)>

,|C

sub

(c)|,

<loc

alm

eth

ods(

c)>)

Cla

ss/p

osit

ion

/fra

ctio

nm

eth

ods

over

ridd

en()

Cla

ss/s

ize/

met

hod

s()

frac

tion

((<m

eth

ods

over

ridd

en(c

)>*

<dep

thfr

omro

ot(c

)>),

(<m

eth

ods(

c)>)

)C

lass

/pos

itio

n/f

ract

ion

over

load

edm

eth

ods(

)C

lass

/siz

e/m

eth

ods(

)fr

acti

on(<

met

hod

sO

verl

oade

dfr

omre

posi

tory

(c)>

,<m

eth

ods

inh

erit

ed(c

)>)

Sys

tem

/siz

e/w

eigh

ted

sum

attr

ibu

tes

met

hod

s()

Cla

ss/s

ize/

met

hod

s()

wei

ghte

dsu

m(<

attr

ibu

tes(

ci)

>,<m

eth

ods(

ci)

>)s.

t.c

iin

C(s

)

Sys

tem

/reu

se/f

ract

ion

reu

sesa

vin

gsge

ner

aliz

atio

nco

sts(

)C

lass

/siz

e/m

eth

ods(

)fr

acti

on((

wei

ghte

dsu

m(A

(ci)

,M(c

i),n

egat

ive(

reu

seC

ost(

ci)

))+

(wei

ghte

dsu

m(r

euse

Fra

ctio

n(c

j)*<

attr

ibu

tes(

cj)

>,re

use

Fra

ctio

n(c

j)*<

met

hod

s(c

j)>,

neg

ativ

e(re

use

Cos

t(c

j)))

,(w

eigh

ted

sum

(<at

trib

ute

s(c

k)>,

<met

hod

s(c

k)>)

*


Product Metrics for Object-Oriented Systems 211ge

ner

aliz

atio

nC

ost(

ck)

))s.

t.c

iin

Cre

use

dFro

mR

epos

itor

y(s)

,cji

nC

inh

erit

edA

ndU

sed(

s),c

kin

Cre

usa

bleP

rodu

cedF

rom

(s)

Cla

ss/s

tru

ctu

re/w

eigh

ted

sum

attr

ibu

teas

soci

atio

nm

eth

ods

rule

for

clas

s()

Cla

ss/s

ize/

met

hod

s()

sum

(wei

ght1

*(<a

ttri

bute

s(c)

>+|A

ssoc

iati

ons(

c)|),

wei

ght2

*av

g(<l

ines

ofco

de(M

(c))

>)/S

TD

LO

C*

<met

hod

s(c)

>,w

eigh

t3*

|Ru

lesP

erR

ule

Set

(c)|

*av

g(|A

nte

cede

ntC

lau

sesP

erR

ule

(c)|)

*|R

ule

Set

s(c)|)

wh

ere

ST

DL

OC

mea

ns

agre

edla

ngu

age-

depe

nde

nt

stan

dard

LO

Cpe

rm

eth

od,o

ther

term

sn

otfu

lly

defi

ned

,wei

ghts

deci

ded

byde

sign

er.

Cla

ss/s

tru

ctu

re/r

elat

ive

para

mu

sage

bym

eth

ods(

)C

lass

/siz

e/m

eth

ods(

)(s

um

(|xfr

acti

on(m

i)|))

/(|x|

*<m

eth

ods(

c)>)

s.t.

mii

nM

(c),

x=

un

iqu

e(u

nio

n(t

ypes

Of

(Pu

sedB

y(m

i)))

)s.

t.m

iin

M(c

),x

frac

tion

(mi)=

inte

rsec

t(x

,un

iqu

e(t

ypes

Of

(Pu

sedB

y(m

i)))

Cla

ss/p

osit

ion

/fra

ctio

nm

eth

ods

inh

erit

edfu

nct

ion

()C

lass

/siz

e/m

eth

ods(

)fr

acti

on((|M

virt

ual

Add

ed(c

)|+|M

virt

ual

Inh

erit

ed(c

)|+2

*(<

met

hod

sad

ded(

c)>+|<

met

hod

sin

her

ited

(c)>

),2

*<m

eth

ods(

c)>)

Cla

ss/p

osit

ion

/met

hod

ssp

ecia

lize

dfu

nct

ion

()C

lass

/siz

e/m

eth

ods(

)av

g(P+

O+

N)

s.t.

P=

frac

tion

(|Min

her

ited

Red

efin

edW

ith

New

Beh

avio

r(c)|,

|Min

her

ited

Red

efin

ed(c

)|)O=

frac

tion

(|Min

her

ited

Red

efin

ed(c

)|,<m

eth

ods

inh

erit

ed(c

)>)

N=

frac

tion

(lev

el(c

)*

<met

hod

sad

ded(

c)>,

(<m

eth

ods

adde

d(c)

>+

1)*

(lev

el(c

)+1)

)C

lass

/str

uct

ure

/ave

rage

met

hod

attr

ibu

teu

sage

()C

lass

/siz

e/m

eth

ods(

)fr

acti

on(s

um

(|Mu

sin

g(a

i)|/<

met

hod

s(c)

>),<

attr

ibu

tes(

c)>)

s.t.

ai

inA

(c)

Cla

ss/r

euse

/inte

rfac

eat

trib

ute

met

hod

mea

nin

gan

dac

cess

()C

lass

/siz

e/m

eth

ods(

)re

usa

bili

ty(c

)*

((su

m(r

eusa

bili

ty(m

i)s.

t.m

iin

M(c

)))/

<met

hod

s(c)

>)+

((su

m(r

eusa

bili

ty(a

j)s.

t.a

jin

A(c

)))/

<att

ribu

tes(

c)>)

,s.t

.reu

sabi

lity

(c)=

(des

crip

tion

mea

nin

gfu

lnes

s(c

)+n

ame

-m

ean

ingf

uln

ess

(c))

/(|C

cou

pled

To

(c)|+

<dep

thfr

omro

ot(c

)>+

1),r

eusa

bili

ty(m

i)=

(nam

em

ean

ingf

uln

ess

(mi)+

Pu

sedB

y(m

i)+

((su

m(r

eusa

bili

ty(p

k))

s.t.

pk

inP

(mi)

)/|p(

mi)|))

/(|fu

nct

ion

spe

rfor

med

By

(mi)+

call

sTo

-fo

reig

nC

lass

es(m

i)|),

reu

sabi

lity

(pk)=

(nam

em

ean

ingf

uln

ess

(pk)

)/(|s

ubT

ypes

Of

(typ

esO

f(p

k)|+

1)or=

5if|p(

mi)|=

0,re

usa

bili

ty(a

j)=

(nam

em

ean

ingf

uln

ess

(aj)

)/(|s

ubT

ypes

Of

(aJ)|+

1)s.

t.n

ame

mea

nin

gfu

lnes

s()

and

desc

ript

ion

mea

nin

gfu

lnes

s()

are

deci

ded

ona

scal

e1.

.5by

the

deve

lope

r.C

lass

/str

uct

ure

/fra

ctio

nm

eth

odat

trib

ute

usa

ge()

Cla

ss/s

ize/

met

hod

s()

frac

tion

((su

m(|M

acce

ssin

ga

i(c)|/<

attr

ibu

tes(

c)>)

-|M|),

(1-|M|))

s.t.

aii

nA

(c)

frac

tion

((<m

eth

ods(

c)>

-su

m(|M

acce

ssin

ga

i(c)|))

,|M

(c)|)

s.t.

aii

nA

(c)

Sys

tem

/str

uct

ure

/fra

ctio

nfu

nct

ion

alit

ydi

stri

buti

onin

inh

erit

ance

chai

n()

Cla

ss/s

ize/

met

hod

s()

frac

tion

(<m

eth

ods(

ci)

>,av

g(<m

eth

ods(

ci)

>)s.

t.c

iin

C(s

)

Cla

ss/s

tru

ctu

re/c

lass

vers

us

inst

ance

attr

ibu

tes(

)C

lass

/siz

e/cl

ass

attr

ibu

tes(

)(<

clas

sat

trib

ute

s(c)

>/|A

inst

ance

(c)|)

Sys

tem

/str

uct

ure

/std

dev

clas

sre

spon

sibi

liti

es()

Cla

ss/s

tru

ctu

re/s

um

clas

sre

spon

sibi

liti

es()

stdd

ev(<

sum

clas

sre

spon

sibi

liti

es(c

i)>)

s.t.

cii

nC

(s)

Con

tin

ue



ble

IX.

Con

tinue

dM

etri

c1

Met

ric

2C

ompu

tati

onof

Met

ric

1u

sin

g<M

etri

c2>

Cla

ss/p

osit

ion

/rel

ativ

epo

siti

on()

Cla

ss/s

tru

ctu

re/lo

cal

met

hod

s()

sum

(<de

pth

from

root

(c)>

,<pa

ren

ts(c

)>,<

met

hod

sin

her

ited

(c)>

,|C

sub

(c)|,

<loc

alm

eth

ods(

c)>)

Cla

ss/p

osit

ion

/rel

ativ

epo

siti

on()

Cla

ss/p

osit

ion

/dep

thfr

omro

ot()

sum

(<de

pth

from

root

(c)>

,<pa

ren

ts(c

)>,<

met

hod

sin

her

ited

(c)>

,|C

sub

(c)|,

<loc

alm

eth

ods(

c)>)

Cla

ss/p

osit

ion

/fra

ctio

nm

eth

ods

over

ridd

en()

Cla

ss/p

osit

ion

/dep

thfr

omro

ot()

frac

tion

((<m

eth

ods

over

ridd

en(c

)>*

<dep

thfr

omro

ot(c

)>),

(<m

eth

ods(

c)>)

)C

lass

/reu

se/in

terf

ace

attr

ibu

tem

eth

odm

ean

ing

and

acce

ss()

Cla

ss/p

osit

ion

/dep

thfr

omro

ot()

reu

sabi

lity

(c)

*((

sum

(reu

sabi

lity

(mi)

s.t.

mii

nM

(c))

)/<m

eth

ods(

c)>)+

((su

m(r

eusa

bili

ty(a

j)s.

t.a

jin

A(c

)))/

<att

ribu

tes(

c)>)

,s.t

.reu

sabi

lity

(c)=

(des

crip

tion

mea

nin

gfu

lnes

s(c

)+n

ame

-m

ean

ingf

uln

ess

(c))

/(|C

cou

pled

To

(c)|+

<dep

thfr

omro

ot(c

)>+

1),r

eusa

bili

ty(m

i)=

(nam

em

ean

ingf

uln

ess

(mi)+

Pu

sedB

y(m

i)+

((su

m(r

eusa

bili

ty(p

k))

s.t.

pk

inP

(mi)

)/|p(

mi)|))

/(|fu

nct

ion

spe

rfor

med

By

(mi)+

call

sTo

-fo

reig

nC

lass

es(m

i)|),

reu

sabi

lity

(pk)=

(nam

em

ean

ingf

uln

ess

(pk)

)/(|s

ubT

ypes

Of

(typ

esO

f(p

k)|+

1)or=

5if|p(

mi)|=

0,re

usa

bili

ty(a

j)=

(nam

em

ean

ingf

uln

ess

(aj)

)/(|s

ubT

ypes

Of

(aJ)|+

1)s.

t.n

ame

mea

nin

gfu

lnes

s()

and

desc

ript

ion

mea

nin

gfu

lnes

s()

are

deci

ded

ona

scal

e1.

.5by

the

deve

lope

r.S

yste

m/s

tru

ctu

re/f

ract

ion

met

hod

inh

erit

()C

lass

/pos

itio

n/m

eth

ods

inh

erit

ed()

frac

tion

(su

m(<

met

hod

sin

her

ited

(ci)

>),s

um

(<m

eth

ods(

cj)

>)),

s.t.

ci,

cji

nC

(s)

Cla

ss/p

osit

ion

/rel

ativ

epo

siti

on()

Cla

ss/p

osit

ion

/met

hod

sin

her

ited

()su

m(<

dept

hfr

omro

ot(c

)>,<

pare

nts

(c)>

,<m

eth

ods

inh

erit

ed(c

)>,

|Csu

b(c

)|,<l

ocal

met

hod

s(c)

>)C

lass

/pos

itio

n/f

ract

ion

over

load

edm

eth

ods(

)C

lass

/pos

itio

n/m

eth

ods

inh

erit

ed()

frac

tion

(<m

eth

ods

Ove

rlod

edfr

om,<

met

hod

sin

her

ited

(c)>

)

Cla

ss/p

osit

ion

/fra

ctio

nm

eth

ods

inh

erit

edfu

nct

ion

()C

lass

/pos

itio

n/m

eth

ods

inh

erit

ed()

frac

tion

((|M

virt

ual

Add

ed(c

)|+|M

virt

ual

Inh

erit

ed(c

)|+2

*(<

met

hod

sad

ded(

c)>+|<

met

hod

sin

her

ited

(c)>

),2

*<m

eth

ods(

c)>)

Cla

ss/p

osit

ion

/met

hod

ssp

ecia

lize

dfu

nct

ion

()C

lass

/pos

itio

n/m

eth

ods

inh

erit

ed()

avg

(P+

O+

N)

s.t.

P=

frac

tion

(|Min

her

ited

Red

efin

edW

ith

New

Beh

avio

r(c)|,

|Min

her

ited

Red

efin

ed(c

)|)O=

frac

tion

(|Min

her

ited

Red

efin

ed(c

)|,<m

eth

ods

inh

erit

ed(c

)>)

N=

frac

tion

(lev

el(c

)*

<met

hod

sad

ded(

c)>,

(<m

eth

ods

adde

d(c)

>+

1)*

(lev

el(c

)+1)

)C

lass

/pos

itio

n/r

elat

ive

posi

tion

()C

lass

/pos

itio

n/p

aren

ts()

sum

(<de

pth

from

root

(c)>

,<pa

ren

ts(c

)>,<

met

hod

sin

her

ited

(c)>

,|C

sub

(c)|,

<loc

alm

eth

ods(

c)>)

Sys

tem

/str

uct

ure

/fra

ctio

nov

erri

dden

met

hod

sn

ewm

eth

ods(

)C

lass

/pos

itio

n/d

esce

nda

nts

()fr

acti

on(s

um

(<m

eth

ods

over

ridd

en(c

i)>)

,su

m(|M

new

(cj)|)

*su

m(<

desc

enda

nts

(cj)

>))

s.t.

ci,

cji

nC

(s)

Su

bsys

tem

/str

uct

ure

/wei

ghte

dsu

mte

rnal

clas

sco

mpl

exit

y()

Cla

ss/in

tera

ctio

n/s

um

exte

rnal

inte

ract

ion

()su

m(w

eigh

ti*

<su

mex

tern

alin

tera

ctio

n(c

i)>)

s.t.

cii

nC

(su

bsys

tem

),w

eigh

ti=

LO

Ces

tim

ated

(ci)

/su

m(L

OC

esti

mat

e(c

j)),

cji

nC

(su

bsys

tem

)S

yste

m/s

tru

ctu

re/f

ract

ion

over

ridd

enm

eth

ods

new

met

hod

s()

Cla

ss/p

osit

ion

/met

hod

sov

erri

dden

()fr

acti

on(s

um

(<m

eth

ods

over

ridd

en(c

i)>)

,su

m(|M

new

(cj)|)

*su

m(<

desc

enda

nts

(cj)

>))

s.t.

ci,

cji

nC

(s)


Product Metrics for Object-Oriented Systems 213C

lass

/pos

itio

n/f

ract

ion

met

hod

sov

erri

dden

()C

lass

/pos

itio

n/m

eth

ods

over

ridd

en()

frac

tion

((<m

eth

ods

over

ridd

en(c

)>*

<dep

thfr

omro

ot(c

)>),

(<m

eth

ods(

c)>)

)C

lass

/pos

itio

n/f

ract

ion

met

hod

sin

her

ited

fun

ctio

n()

Cla

ss/p

osit

ion

/met

hod

sad

ded(

)fr

acti

on((|M

virt

ual

Add

ed(c

)|+|M

virt

ual

Inh

erit

ed(c

)|+2

*(<

met

hod

sad

ded(

c)>+

<met

hod

sin

her

ited

(c)>

),2

*<m

eth

ods(

c)>)

Cla

ss/p

osit

ion

/met

hod

ssp

ecia

lize

dfu

nct

ion

()C

lass

/pos

itio

n/m

eth

ods

adde

d()

avg

(P+

O+

N)

s.t.

P=

frac

tion

(|Min

her

ited

Red

efin

edW

ith

New

Beh

avio

r(c)|,|

Min

her

ited

Red

efin

ed(c

)|)O=

frac

tion

(|Min

her

ited

Red

efin

ed(c

)|,<m

eth

ods

inh

erit

ed(c

)>)

N=

frac

tion

(lev

el(c

)*

<met

hod

sad

ded(

c)>,

(<m

eth

ods

adde

d(c)

>+

1)*

(lev

el(c

)+1)

)H

iera

rch

y/ar

ran

gem

ent/

aggr

egat

ecl

ass

abst

ract

ion

fun

ctio

n()

Cla

ss/p

osit

ion

/fra

ctio

nm

eth

ods

inh

erit

edfu

nct

ion

()ar

eaU

nde

r(c

urv

eDefi

ned

By

(<fr

acti

onm

eth

ods

inh

erit

edfu

nct

ion

(ci)

>,le

vel(

ci)

)s.

t.c

iin

C(h

iera

rch

y)S

yste

m/s

tru

ctu

re/r

elat

ion

ship

abst

ract

ion

fun

ctio

n()

Cla

ss/p

osit

ion

/fra

ctio

nm

eth

ods

inh

erit

edfu

nct

ion

()fr

acti

on(s

um

(<fr

acti

onm

eth

ods

inh

erit

edfu

nct

ion

(ci)

>),

|Ass

ocia

tion

sag

greg

atio

ns(

c)|)

s.t

Ass

ocia

tion

sag

greg

atio

ns(

c)=

un

iqu

e(A

ssoc

iati

ons

invo

lvin

g(c)

un

ion

Agg

rega

tion

sin

volv

ing(

c)),

(ci,

c)in

Ass

ocia

tion

sag

greg

atio

ns

c ©C

lass

/com

men

ts/c

omm

ents

per

met

hod

()C

lass

/com

men

ts/c

omm

ent

lin

es()

avg

(<co

mm

ent

lin

es(M

(c))

>)s.

t.m

iin

M(c

)

Met

hod

/pos

itio

n/f

ract

ion

met

hod

inh

erit

edn

otov

erlo

aded

()M

eth

od/p

osit

ion

/inh

erit

ance

occu

rren

ces(

)fr

acti

on(d

iffe

ren

ce(<

inh

erit

ance

occu

rren

ces(

)>,<

over

load

occu

rren

ces(

)>),

<in

her

itan

ceoc

curr

ence

s()>

)M

eth

od/p

osit

ion

/fra

ctio

nm

eth

odin

her

ited

not

over

load

ed()

Met

hod

/pos

itio

n/o

verl

oad

occu

rren

ces(

)fr

acti

on(d

iffe

ren

ce(<

inh

erit

ance

occu

rren

ces(

)>,<

over

load

occu

rren

ces(

)>),

<in

her

itan

ceoc

curr

ence

s()>

)M

eth

od/s

tru

ctu

re/w

eigh

ted

sum

mcc

abe

hal

stea

d()

Met

hod

/str

uct

ure

/met

hod

mcc

abe

com

plex

ity(

)(3

.42

*lo

ge

(Eff

ort

hal

stea

d(m

))+

0.23

*<m

eth

odm

ccab

eco

mpl

exit

y(m

)>+

16.2

*lo

ge

(<li

nes

ofco

de(m

)>))

[See

Hal

stea

d[]

for

Eff

ort

hal

stea

d,se

ecy

clom

atic

com

plex

ity]

Hie

rarc

hy/

arra

nge

men

t/h

iera

rch

yle

ngt

hpa

ram

sin

tera

ctio

n()

Met

hod

/str

uct

ure

/met

hod

len

gth

para

ms

inte

ract

ion

()su

m<m

eth

odle

ngt

hpa

ram

sin

tera

ctio

n(m

i)>

s.t.

mii

nM

(C(h

iera

rch

y))

Sys

tem

/str

uct

ure

/sys

tem

len

gth

para

ms

inte

ract

ion

()M

eth

od/s

tru

ctu

re/m

eth

odle

ngt

hpa

ram

sin

tera

ctio

n()

met

hod

com

plex

ity

(mai

nfu

nct

ion

(s))+

sum

<met

hod

len

gth

para

ms

inte

ract

ion

(mi)

>s.

t.m

iin

M(C

(s))

Met

hod

/str

uct

ure

/met

hod

len

gth

para

ms

inte

ract

ion

()M

eth

od/in

tera

ctio

n/a

rgu

men

tsre

ceiv

ed()

len

gth

(m)

*sq

uar

e(c

oupl

ing(

m))

s.t.

len

gth

(m)=|T

if(m

)|+

|Tca

se(m

)|+<a

ttri

bute

s(m

)>;c

oupl

ing(

m)=

sum

(ip(

m),

op(m

))s.

t.ip

(m)=

(1+

<arg

um

ents

rece

ived

(m)>+

void

(m))

s.t.

void

(m)=

1if

mre

turn

sva

lue

and

0,ot

her

wis

e;op

(m)=

(su

m(|R

efer

ence

sTo

mi

(m)|

*(1+|P

refe

ren

cedB

ym

(mi)|+

void

(mi)

)+su

m(|R

efer

ence

sTo

aj(

m)|)

)s.

t.m

iin

Mre

fere

nce

dBy

(m),

aji

nA

refe

ren

cedB

y(m

)C

lass

/str

uct

ure

/cla

ssle

ngt

hin

tera

ctio

n()

Met

hod

/inte

ract

ion

/arg

um

ents

rece

ived

()le

ngt

h(c

)*

squ

are

(cou

plin

g(c)

)s.

t.le

ngt

h(c

)=su

m(l

engt

h(m

i))

s.t.

mii

nM

(c);

cou

plin

g(c)=

sum

(ip(

mj)+

(su

m(r

jk)+

sum

(rj

l)))

s.t.

mji

nM

(c),

K=

1..N

MR

(c),

l=N

MR

(c)+

1..N

MR

(c)+

NV

R(c

),N

MR

(c)=|u

niq

ue

(Mre

fere

nce

dBy(

M(c

)))|,

NV

R(c

)=|u

niq

ue

(Are

fere

nce

dBy

(M(c

))|,r

jk=|R

efer

ence

sTo

mk

(mj)|*

(1+|R

refe

ren

cedB

ym

j(m

k)+

void

(mk)

,rj

l+|R

efer

ence

sTo

al(

mj)

|s.t.

len

gth

(m)=|T

ys(m

)|+|T

case

(m)|+

<att

ribu

tes(

m)>|;

cou

plin

g(m

)=su

m(i

p(m

),op

(m))

s.t.

ip(m

)=(1+

<arg

um

ents

rece

ived

(m)>+

void

(m))

s.t.

void

(m)=

1if

mre

turn

sva

lue

and

0, Con

tin

ue



ble

IX.

Con

tinue

dM

etri

c1

Met

ric

2C

ompu

tati

onof

Met

ric

1u

sin

g<M

etri

c2>

oth

erw

ise;

op(m

)=(s

um

(|Ref

eren

cesT

om

i(m

)|*

(1+

|Pre

fere

nce

dBy

m(m

i)|+

void

(mi)

)+su

m(|R

efer

ence

sTo

aj(

m)|)

)s.

t.m

iin

Mre

fere

nce

dBy

(m),

aji

nA

refe

ren

cedB

y(m

)R

epos

itor

y/re

use

/par

ams

ofm

eth

odof

pare

nts

clas

ses

inre

posi

tory

()M

eth

od/in

tera

ctio

n/a

rgu

men

tsre

ceiv

ed()

<arg

um

ents

rece

ived

(m)>

s.t.

min

M(C

pare

nt

inr

(C(s

)))

Cla

ss/in

tera

ctio

n/c

lass

inh

erit

non

inh

erit

inte

ract

ion

()M

eth

od/in

tera

ctio

n/s

um

met

hod

non

loca

lref

s()

sum

(<su

mm

eth

odn

onlo

calr

efs

(mi)

>)s.

t.m

iin

M(c

)

Met

hod

/str

uct

ure

/wei

ghte

dsu

mm

ccab

eh

alst

ead(

)M

eth

od/s

ize/

lin

esof

code

()(3

.42

*lo

ge

(Eff

ort

hal

stea

d(m

))+

0.23

*<m

eth

odm

ccab

eco

mpl

exit

y(m

)>+

16.2

*lo

ge

(<li

nes

ofco

de(m

)>))

[See

Hal

stea

d[]

for

Eff

ort

hal

stea

d,se

ecy

clom

atic

com

plex

ity]

Cla

ss/s

tru

ctu

re/w

eigh

ted

sum

attr

ibu

teas

so-

ciat

ion

met

hod

sru

lefo

rcl

ass(

)M

eth

od/s

ize/

lin

esof

code

()su

m(w

eigh

t1*(

<att

ribu

tes(

c)>+|A

ssoc

iati

ons(

c)|),

wei

ght2

*av

g(<l

ines

ofco

de(M

(c))

>)/S

TD

LO

C*

<met

hod

s(c)

>,w

eigh

t3*

|Ru

lesP

erR

ule

Set

(c)|

*av

g(|A

nte

cede

ntC

lau

sesP

erR

ule

(c)|)

*|R

ule

Set

s(c)|)

wh

ere

ST

DL

OC

mea

ns

agre

edla

ngu

age-

depe

nde

nt

stan

dard

LO

Cpe

rm

eth

od,o

ther

term

sn

otfu

lly

defi

ned

,wei

ghts

deci

ded

byde

sign

er.

Cla

ss/r

euse

/fra

ctio

nfu

nct

ion

al()

Met

hod

/siz

e/st

atem

ents

()fr

acti

on(|T

fun

ctio

nO

rien

ted(

c)|,<

stat

emen

ts(c

)>)

Sys

tem

/reu

se/f

ract

ion

sou

rce

reu

se()

Met

hod

/siz

e/st

atem

ents

()fr

acti

on(|T

impo

rted

(s,r

)|,<s

tate

men

ts(s

)>)

Met

hod

/siz

e/fr

acti

onin

stan

ceat

trib

ute

su

sed

bym

eth

od()

Met

hod

/siz

e/in

stan

ceat

trib

ute

su

sed

frac

tion

(<in

stan

ceat

trib

ute

su

sed(

m)>

,|A(c

(m)|)

Cla

ss/b

ehav

ior/

attr

iban

dm

eth

odpo

lym

orph

ism

()M

eth

od/p

osit

ion

/cla

sses

defi

ned

inn

orm

aliz

edsu

m(<

clas

ses

defi

ned

in(a

)>,<

clas

ses

defi

ned

in(m

)>)

--

“nor

mal

ized

sum

()”

not

defi

ned

Sys

tem

/str

uct

ure

/syn

tax

inh

inte

ract

com

plex

ity(

)S

yste

m/s

tru

ctu

re/s

um

inh

erit

ance

com

plex

ity(

)su

m(<

sum

syn

tax

hal

stea

dco

mpl

exit

y(s)

>,<s

um

inh

erit

ance

com

plex

ity(

s)>,

<su

min

tera

ctio

nco

mpl

exit

y(s)

>)S

yste

m/s

tru

ctu

re/s

ynta

xin

hin

tera

ctco

mpl

exit

y()

Sys

tem

/str

uct

ure

/su

msy

nta

xh

alst

ead

com

plex

ity(

)su

m(<

sum

syn

tax

hal

stea

dco

mpl

exit

y(s)

>,<s

um

inh

erit

ance

com

plex

ity(

s)>,

<su

min

tera

ctio

nco

mpl

exit

y(s)

>)P

acka

ge/a

bstr

actn

ess/

frac

tion

abst

ract

clas

ses(

)S

yste

m/s

tru

ctu

re/a

bstr

act

clas

ses(

)fr

acti

on(<

abst

ract

clas

ses(

pack

age)

>,|C

(pac

kage

)|)w

her

en

oco

mpu

tabl

efo

rmu

lati

onof

Cab

stra

ct()

ispr

ovid

edS

yste

m/r

euse

/inve

rse

reu

seve

rsu

sn

ewco

st()

Sys

tem

/reu

se/r

euse

vers

us

new

cost

()1/

rela

tive

cost

<reu

seve

rsu

sn

ewco

st(c

)>

Sys

tem

/siz

e/fr

acti

onn

onro

otcl

asse

s()

Sys

tem

/reu

se/r

oot

clas

ses(

)1

-fr

acti

on(<

root

clas

ses(

s)>,

<cla

sses

(s)>

)C

lass

/pos

itio

n/f

ract

ion

over

load

edm

eth

ods(

)S

yste

m/r

euse

/met

hod

sov

erlo

aded

from

repo

sito

ry()

frac

tion

(<m

eth

ods

Ove

rloa

ded

from

repo

sito

ry(c

)>,

<met

hod

sin

her

ited

(c)>

)S

yste

m/r

equ

irem

ents

/use

case

sac

tors

inte

ract

ion

sot

her

s()

Sys

tem

/siz

e/u

seca

ses(

)k1

(|squ

are(

<use

case

s(s)

>)+

<use

case

acto

rin

tera

ctio

ns

wit

hou

tex

ten

dsu

ses(

)>+

k2(<

use

case

acto

rin

tera

ctio

ns(

)>-<

use

case

acto

rin

tera

ctio

ns

wit

hou

tex

ten

dsu

ses(

)>),

k1an

dk2

are

empi

rica

lly

dete

rmin

edS

yste

m/s

tru

ctu

re/s

ubs

yste

ns

and

lin

ks()

Sys

tem

/siz

e/su

bsys

tem

s()

(k1

*<s

ubs

yste

ms(

s)>,

k2*|A

rcac

ross

Su

bsys

tem

s(s)|)

s.t.

k1,k

2co

nst

ants

Sys

tem

/reu

se/f

ract

ion

clas

ses

leve

rage

d()

Sys

tem

/siz

e/cl

asse

s()

frac

tion

(|Cle

vera

ged

(s)|,

<cla

sses

(s)>

)S

yste

m/r

euse

/fra

ctio

nsu

perc

lass

es()

Sys

tem

/siz

e/cl

asse

s()

frac

tion

(|Csu

per

(s)|,

<cla

sses

(s)>

)


Product Metrics for Object-Oriented Systems 215S

yste

m/r

euse

/fra

ctio

ncl

asse

sim

port

edve

rbat

im()

Sys

tem

/siz

e/cl

asse

s()

frac

tion

(|Cim

port

edV

erba

rtim

(s)|,

<cla

sses

(s)>

)

Cla

ss/b

ehav

ior/

attr

iban

dm

eth

odpo

lym

orph

ism

()S

yste

m/s

ize/

clas

ses(

)n

orm

aliz

edsu

m(<

clas

ses

defi

ned

in(a

)>,<

clas

ses

defi

ned

in(m

)>)

--

“nor

mal

ized

sum

()”

not

defi

ned

Sys

tem

/eff

ort/

clas

ses

per

deve

lope

r()

Sys

tem

/siz

e/cl

asse

s()

<cla

sses

(s)>

/|Dev

elop

ers

invo

lved

In(s

)|S

yste

m/r

euse

/fra

ctio

ncl

asse

sre

use

das

is()

Sys

tem

/siz

e/cl

asse

s()

frac

tion

(|Cre

use

dAsI

s(s)|,<

clas

ses(

s)>)

Sys

tem

/reu

se/f

ract

ion

clas

ses

reu

sed

mod

ified

()S

yste

m/s

ize/

clas

ses(

)(s

um

(|Cre

use

dAsI

s(s)|,|

Cm

odifi

edD

uri

ngR

euse

(s)|)

)/(<

clas

ses(

s)>)

Sys

tem

/siz

e/fr

acti

onn

onro

otcl

asse

s()

Sys

tem

/siz

e/cl

asse

s()

1-

frac

tion

(<ro

otcl

asse

s(s)

>,<c

lass

es(s

)>)

Sys

tem

/str

uct

ure

/syn

tax

inh

inte

ract

com

plex

ity(

)S

yste

m/d

ynam

ics/

sum

inte

ract

ion

com

plex

ity(

)su

m(<

sum

syn

tax

hal

stea

dco

mpl

exit

y(s)

>,<s

um

inh

erit

ance

com

plex

ity(

s)>,

<su

min

tera

ctio

nco

mpl

exit

y(s)

>)S

yste

m/r

equ

irem

ents

/use

case

acto

rin

tera

ctio

ns

wit

hou

tex

ten

dsu

ses(

)S

yste

m/r

equ

irem

ents

/use

case

acto

rin

tera

ctio

ns(

)<u

seca

seac

tor

inte

ract

ion

s()>

-|In

tera

ctio

ns

(Act

ors(

s),

Use

Cas

esR

elat

edT

o(U

seC

ases

Dir

ectl

yIn

tera

ctin

gWit

h(A

ctor

s(s)

)))|

Sys

tem

/req

uir

emen

ts/u

seca

ses

acto

rsin

tera

ctio

ns

oth

ers(

)S

yste

m/r

equ

irem

ents

/use

case

acto

rin

tera

ctio

ns(

)k1

(|squ

are(

<use

case

s(s)

>)+

<use

case

acto

rin

tera

ctio

ns

wit

hou

tex

ten

dsu

ses(

)>+

k2(<

use

case

acto

rin

tera

ctio

ns(

)>-<

use

case

acto

rin

tera

ctio

ns

wit

hou

tex

ten

dsu

ses(

)>),

k1an

dk2

are

empi

rica

lly

dete

rmin

edS

yste

m/r

equ

irem

ents

/use

case

sac

tors

inte

ract

ion

sot

her

s()

Sys

tem

/req

uir

emen

ts/u

seca

seac

tor

inte

ract

ion

sw

ith

out

exte

nds

use

s()

k1(|s

quar

e(<u

seca

ses(

s)>)+

<use

case

acto

rin

tera

ctio

ns

wit

hou

tex

ten

dsu

ses(

)>+

k2(<

use

case

acto

rin

tera

ctio

ns(

)>-<

use

case

acto

rin

tera

ctio

ns

wit

hou

tex

ten

dsu

ses(

)>),

k1an

dk2

are

empi

rica

lly

dete

rmin

edN

ote:

s.t.=

such

that

.



Table X. Equivalent Formulations of Metrics from Different ResearchersEntity Attribute Metric Proposed by*Class interaction sum method import interactions with friends() 2

interface public local methods() 2position ancestors() 4position children() 3position depth from root() 4position descendants() 5position max inherit depth() 2position sum method import interactions with ancestors() 2

reuse fraction functional() 2size attributes() 4

structure method attribute usage in class() 3structure public attributes() 2structure sum method complexity() 2

Method interaction methods sending messages to() 2position classes inheriting() 2

size executable statements() 2size instance attributes used 2size statements() 2

System reuse fraction classes importedverbatim() 2reuse fraction classes leveraged() 2size atttributesin system() 2size classes() 5size messages() 2size methods in system() 3size subsystems() 4size use cases() 2

structure abstract classes() 2structure avg instance attributes() 2structure avg messages sent() 2structure avg method size() 2structure avg methods() 2structure inheritance associations() 2structure multiple inheritance() 2structure sum association arity() 2

*Number of researchers.

4.2.4. Metrics That Use Functions Proposedfor Traditional Metrics. A few metrics makeuse of functions that were suggested fortraditional metrics. The most telling ex-ample in this category is the metrics thatuse the McCabe [1976] cyclomatic com-plexity function. Table XI shows thesemetrics. For example, the cyclomatic com-plexity function is used by several re-searchers to compute complexity. Thisdemonstrates the researchers’ biases inapplying traditional functions to object-oriented systems. Prima facie, such appli-cations suggest a possible misuse of thetraditional functions, following the argu-ments presented in Section 2.1. We seeonly a few such uses, with cyclomaticcomplexity being the most glaring. Oth-ers include Boehm’s complexity number,which is used for some metrics by differ-ent researchers. Such analysis can force

researchers to rigourously evaluate theappropriateness of traditional metrics forobject-oriented systems.

Additional analyses of metrics are cer-tainly possible beyond the three pos-sibilities discussed above. Consider, forexample, using the dimensions of arti-fact granularity (method ⊂ class, class ⊂subsystem, and so on), and mathemati-cal aggregation (set theoretic operationson elements of a set, e.g., class ∈ set ofclasses). Talbi et al. [2001] suggest a tax-onomy that can be useful in this regard.Other analyses may include investigat-ing the use of statistical summary op-erators (such as average) or dispersionoprators (such as min, max, or variance)across metrics that apply to elements ver-sus sets. We leave these, along with sev-eral others, as further extensions to thisresearch.



Table XI. Metrics Built on Traditional MetricsEntity Attribute Metric Researcher YearClass size sum attribute boehm size() Sharble and Cohen 1993Class structure avg method mccabe complexity() Etzkorn et al. 1999Class structure class mccabe complexity() Karlsson 1995Class structure sum distance times method and

attributes halstead complexity()Etzkorn et al. 1999

Method size halstead length() De Champeaux 1997Method size halstead volume() Abreu and Carapuca 1994Method structure method mccabe complexity() Abreu and Carapuca 1994Method structure weighted sum mccabe halstead() De Champeaux 1997

Subsystem structure class group mccabe complexity() Karlsson 1995System structure assoc mccabe complexity() Kolewe 1993System structure sum syntax halstead complexity() Kim et al. 1994

Table XII. Number of Metrics Proposed over Time for EntitiesEntity 1989 1991 1992 1993 1994 1995 1996 1997 1998 1999

Association 1Attribute 4

Class 2 7 17 49 28 9 45 19 4Event 1

Hierarchy 1 1Link

MessageMethod 4 3 16 10 7Package 3 2

ParameterScenario 3

Subsystem 2System 3 5 22 4 43 34 1 24 14

Use Case 2 1Note: Only entities for which metrics have been proposed are shown.

4.3. Trends

Based on the compilation of metrics, wefurther present a historical perspectiveon available object-oriented metrics thatcan provide a sense of the direction inwhich the field appears to be moving.Tables XII and XIII show the numberof metrics proposed over time, mappedagainst the entities and attributes. Thetables suggest that intense level of activ-ity witnessed during the mid-1990s (1994to 1997) appears to be tapering off asmore researchers are shifting their agen-das away from measurement concerns.

This is a disturbing finding because anumber of concerns still remain, as seenfrom our analysis in Sections 4.1 and 4.2,where we have identified a number of gapsin the present state of the research. Ourdiscipline has been criticized for changingfocus too quickly to meet the vagaries ofthe market. As key issues dealing withmeasurement of object-oriented develop-ment processes remain unresolved, we see

a similar trend. We hope that the presentanalysis will provide researchers specificavenues that they may consider for ad-vancing the field.

5. CONCLUDING REMARKS

We have presented a survey of existingmetrics proposed for object-oriented sys-tems focusing on product metrics. In par-ticular, we have analyzed the metrics forthe coverage of entities, attributes, anddevelopment stages (indicated as states).The classification of metrics is also basedon the dimensions of elementarity anddirectness. Our analysis has includedthe investigation of computation acrossmetrics such as aggregation (Table VIII)or usage across metrics (Table IX),equivalent formulations of metrics bymultiple researchers (Table X), and ex-ploitation of traditional metrics for object-oriented metrics (Table XI). We have alsoanalyzed activity in this area over time,



Table XIII. Number of Metrics Proposed over Time for Entity-AttributesEntity Attribute 1989 1991 1992 1993 1994 1995 1996 1997 1998 1999

Association size 1Attribute interaction 2

position 2Class behavior 1 1 1 5

comments 2 1interaction 1 5 6 3 10 17 3interface 3 1 2

performance 5position 1 13 8 8 6

reuse 6 1size 3 7 3

structure 2 7 9 8 9 11 7 4Event size 1

Hierarchy arrangement 1 1Link arity

Message sizeMethod abstractness 1

interaction 2 1 3 6 2interface 1

performance 2position 1 3 2

size 1 6 1 4structure 1 2 1


Parameter sizeScenario size 3

Subsystem structure 2System change 1

dynamics 2 1 8effort 9

performance 1requirements 2 3

reuse 2 5 3 1 2 12 3size 1 9 9 4 5 3

structure 8 3 18 17 1 8 8indeterminate 1

Use Case interface 1size 1 1

and commented on the trends (Tables XIIand XIII). The survey provides a historicalview of existing research, uncovers gaps inexisting research, and suggests opportuni-ties for future research.

The presented analysis is based on auniform representation of existing met-rics and is aided by storing this informa-tion in a structured repository for easeof processing; all the analysis tables inSection 4 are generated from this repos-itory. The complete data with the uniformrepresentation is available online in theACM Digital Library, in a format that iseasily amenable to conversion to a stan-dardized representation using the eXten-sible Markup Language. This uniformity

in representation (Table IV) is achievedby applying a mathematical formalism(Table III), which in turn is driven bya framework for object-oriented metrics(Figure 1), the relational model for mea-surement (Figure 2), and the dimensionsfor classifying metrics (Figure 3). Fur-ther support for the framework is pro-vided by use of the object-oriented systemdevelopment process as the underlyingphenomenon, which suggests the distinc-tion between the entities products, pro-cesses, and resources, and, specifically, thestates of products (Figure 4). Based onthese concepts, a bottom-up analysis ofthe metrics proposed for object-orientedsystems has resulted in the entities



Table XIV. Application of MetricsPossible Steps for Identifying Apprppriate Metrics

Step Selection Example Source1 Entity Class Table I2 Goal/Question Maintainability Decision-Maker3 State(s) Specifications Decision-Maker, Choice from Figure 44 Attribute(s) Position, Structure Decision-Maker, Choice from Table II5 Metric Type Elementary and Direct Decision-Maker, Choice from Figure 3, Table VII6 Metrics Results below Metrics Repository

Application of MetricsEntity Attribute Metric State Elementary DirectClass position methods added() 2 or 3 y yClass position children() 2 or 3 y yClass position methods inherited() 2 or 3 y yClass position parents() 2 or 3 y yClass position methods overridden() 2 or 3 y yClass position max inherit depth() 2 or 3 y yClass structure avg method params() 2 or 3 y yClass structure sum attrib chenlu value() 2 or 3 y yClass structure attrib combinations

constraints()2 or 3 y y

Class structure local methods() 2 or 3 y yClass structure classes thisclass depends on() 2 or 3 y yClass structure methods longer than N loc() 2 or 3 y yClass structure public attributes() 2 or 3 y yClass structure public methods() 2 or 3 y yClass structure method params() 2 or 3 y yClass structure bidirectional class usage() 2 or 3 y yClass structure classes used() 2 or 3 y yClass structure abstract classes used() 2 or 3 y yClass structure classes dependent on() 2 or 3 y y∗Legend: 1=Requirements, 2 =Design, 3 = Implementation, 4 =Operational; y= yes.

and attributes presented in Tables Iand II.

Finally, we suggest one plausible use ofa metrics repository compiled using thisformalism: use of the metrics for specificgoals or for answering questions. Deter-mining specific instantiaition of “goals”or “questions” is a rather daunting task.A goal/question relates to either quantifi-ably assessing some attribute of an ex-isting product, process, or resource, orquantifiably predicting some attribute ofa future product, process, or resource.Mylopoulos et al. [1992] also suggest alter-natives for understanding and interpret-ing nonfunctional requirements, whichcan be adapted for this purpose. Alongwith these works, the GQM paradigm sug-gests that available entity-attribute pairsor entity-attribute-metric tuples may beused to answer questions arising from pre-determined goals.

In this regard, researchers have sug-gested approaches to relate metrics to

quality characteristics (see, for example,Mylopoulos et al. [1992]; Shepperd [1992];Gillibrand and Liu [1998]). It is diffi-cult, however, to reach a genuine consen-sus about the definitions of exernal at-tributes that are sometimes referred toas ilities [Fenton 1994]. ISO 9126 [ISO9126; ISO/IEC FCD 9126-2nd], for exam-ple, defines Quality as consisting of: Func-tionality, Reliability, Usability, Efficiency,Maintainability, and Portability. McCallet al.’s [1977] hierarchy of ilities indicateshierarchies of Maintainability, which con-sists of Simplicity, Modularity, and ofConciseness; and of Dependability, whichconsists of Reliability, Safety, Security,Availability, Maintainability, Usability,and Extendability. These terms are noto-riously difficult to operationalize with uni-versal applicability.

We acknowledge these problems, whichhave been reported elsewhere. However,in spite of these problems, it may be pos-sible to derive broad guidelines for using



the metrics. Table XIV shows one possi-ble approach to using our representationto select appropriate metrics in the contextprovided by the development lifecycles. Itshows a possible question (“assessmentof maintainability”) for the goal (“improv-ing maintainability”), and the progressionfrom a goal/question to an attribute, selec-tion of state(s), metric type(s), and the re-sulting metrics extracted from the metricsrepository.

Clearly, the above analysis does not ex-tend to expressing judgments about indi-vidual metrics, such as their trustworthi-ness or relevance. These concerns are thetopic of research on specific metrics andtheir mapping against specific concerns.Analysis like that presented in Table XIVmerely serves as the first step in identi-fying possibilities, which may be informedby other research that takes into accountissues such as trustworthiness. Our con-tribution has been mainly in providing aninsightful survey of object-oriented prod-uct metrics using the internal perspective(Figure 1) and a mathematical formalism.

ACKNOWLEDGMENTS

We acknowledge the help of the reviewers and theassociate editor, whose comments helped shape thepaper through the revisions.

REFERENCES

ABREU, B. F. AND CARAPUCA, R. 1994. Candidatemetrics for object-oriented software within ataxonomy framework. J. Syst. Softw. 26, 87–96.

ABREU, B. F., GOULAO, M., AND ESTEVES, R. 1995. To-ward the design quality evaluation of object-oriented software systems. In Proceedings ofthe Fifth International Conference on SoftwareQuality. 44–57.

BAKER, A. L., BIEMAN, J. M., FENTON, N. E., GUSTAFSON,D., MELTON, A., AND WHITTY, R. W. 1990. Aphilosophy for software measurement. J. Syst.Softw. 12, 277–281.

BANDI, R. K. 1998. Using object-oriented designcomplexity metrics to predict maintenance per-formance. Ph.D. dissertation, Georgia State Uni-versity, Atlanta, GA.

BARNES, G. AND SWIM, B. 1993. Inheriting softwaremetrics. J. Obj.-Orient. Program. 6 (November–December), 27–34.

BASILI, V. R. 1992. Software modeling and mea-

surement: The Goal/Question/Metric paradigm.Tech. Rep. CS-TR-2956. Department of Com-puter Science, University of Maryland, CollegePark, MD.

BASILI, V. R., BRIAND, L. C., AND MELO, W. L. 1996.A validation of object-oriented design metrics asquality indicators. IEEE Trans. Softw. Eng. 22,751–761.

BAUDOIN, C. AND HOLLOWELL, G. 1996. Realizingthe Object-Oriented Lifecycle. Prentice Hall,Englewood Cliffs, NJ.

BERARD, E. V. 1993. Essays on Object-OrientedSoftware Engineering. Prentice Hall, EnglewoodCliffs, NJ.

BIEMAN, J. M. AND KARINATHINI, S. 1995. Measure-ment of language-supported reuse in object-oriented and object-based software. J. Syst.Softw. 30, 271–293.

BLUM, B. A. 1994. Taxonomy of software develop-ment methods. Commun. ACM 37, 82–94.

BOOCH, G. 1994. Object-Oriented Analysis and De-sign with Applications. Benjamin/CummingsPub. Co., Redwood City, CA.

BRIAND, L. C., DALY, J. W., AND WUST, J. K. 1999.A unified framework for coupling measurementin object-oriented systems. IEEE Trans. Softw.Eng. 25, 91–121.

BROOKS, F. 1987. No silver bullet: Essence and ac-cidents of software engineering. IEEE Comput.20, 4, 10–19.

BUSH, M. E. AND FENTON, N. E. 1990. Softwaremeasurement: A conceptual framework. J. Syst.Softw. 20, 223–231.

CHEN, J. Y. AND LU, J. F. 1993. A new metric forobject-oriented design. Inform. Softw. Tech. 35(April), 232–240.

CHIDAMBER, S. R. AND KEMERER, C. F. 1991. To-wards a metric suite for object oriented design.SIGPLAN Not. 26, 197–211.

CHIDAMBER, S. R. AND KEMERER, D. F. 1994. A met-rics suite for object-oriented design. IEEE Trans.Softw. Eng. 20, 476–493.

DE CHAMPEAUX, D. 1997. Object-Oriented Devel-opment Process and Metrics. Prentice Hall,Englewood Cliffs, NJ.

ETZKORN, L., BANIYA, J., AND DAVIS, C. 1999. Designand complexity metrics for OO classes. J. OOP12, 1, 35–40.

FENTON, N. E. 1991. Software Metrics, A RigorousApproach. Chapman & Hall, New York, NY.

FENTON, N. E. 1994. Software measurement: Anecessary scientific basis. IEEE Trans. Softw.Eng. 20, 199–206.

FENTON, N. E. AND PFLEEGER, S. L. 1997. SoftwareMetrics, A Rigorous and Practical Approach,2nd ed. International Thomson Computer Press,Boston, MA.

FINKELSTEIN, L. 1984. A Review of the Fundamen-tal Concepts of Measurement. Measurement. 2,1, 25–34.



GILLIBRAND, D. AND LIU, K. 1998. Quality metricsfor OO design. J. Obj.-Orient. Program. 17, 175–184.

HENDERSON-SELLERS, B. 1996. The mathematicalvalidity of software metrics. Softw. Eng. Notes21, 89–94.

INCE, D. 1990. Software metrics: Introduction. In-form. Softw. Tech. 32, 297–303.

ISO 9126. 1991. Information technology—Software product evaluation—quality char-acteristics and guidelines for their use, ISO,Geneva, Switzerland.

ISO/IEC FCD 9126-2ND. 1998. Software qualitycharacteristics and metrics—part 1: Qualitycharacteristics and sub-characteristics. ISO,Geneva, Switzerland.

JACOBSON, I., CHRISTERSON, M., JONSSON, P., AND

OVERGAARD, G. 1992. Object-Oriented Soft-ware Engineering. A Use Case Driven Approach.Addison-Wesley, Reading, MA.

KARLSSON, E. 1995. Software Reuse: A Holistic Ap-proach. John Wiley & Sons, New York, NY.

KIM, E. M., CHANG, O. B., KUSUMOTOS, S., AND KIKUNO, T.1994. Analysis of metrics for object-orientedprogram complexity. In Proceedings of the Eigh-teenth Annual International Computer Softwareand Applications Conference (COMPSAC ’94).IEEE Computer Society, Press, Los Alamitos,CA, 201–207.

LI, W. 1998. Another metric suite for object-oriented programming. J. Syst. Softw. 44, 155–162.

LI, W. AND HENRY, S. 1993. Object oriented metricsthat predict maintainability. J. Syst. Softw. 23(Nov.), 111–122.

LORENZ, M. AND KIDD, J. 1994. Object-OrientedSoftware Metrics. Prentice Hall, EnglewoodCliffs, NJ.

MARCHESI, M. 1998. OOA metrics for the UnifiedModeling Language. In Proceedings of the Sec-ond Euromicro Conference on Software Mainte-nance and Reengineering. IEEE Computer Soci-ety Press, Los Alamitos, CA.

MARCINIAK, J. (ED.) 1994. Encyclopedia of SoftwareEngineering. John Wiley & Sons, New York, NY.

MC CABE, T. J. 1976. A complexity measure. IEEETrans. Softw. Eng. SE-2, 4, 308–320.

MCCALL, J. A., RICHARDS, P. K., AND WALTERS, G. F.1977. Factors in software quality, RADC TR-77-369, I, II, III. U.S. Rome Air DevelopmentCenter Reports NTIS AD/A-049 014, 015, 055.Rome, NY.

MCGREGOR, J. AND KORSON, T. 1994. Integrated

object-oriented testing and development process.Commun. ACM 37, 59–77.

MILI, H., MILI, F., AND MILI, A. 1995. Reusingsoftware: Issues and research directions. IEEETrans. Softw. Eng. 21, 528–562.

MYLOPOULOS, J., CHUNG, L., AND NIXON, B. 1992.Representing and using nonfunctional require-ments: A process-oriented approach. IEEETrans. Softw. Eng. 18, 6 (June), 483–497.

NAKANISHI, K. T. ARANO, K. T., AND IMASE, M. 1995.A matric for evaluating class library interfacesand its application to library upgrades. In Pro-ceedings of the International Conference on Soft-ware Maintenance (ICSM ’95, Nice, France).IEEE Computer Society Press, Los Alamitos,CA.

RATIONAL 2001. The Rational Unified Process.Available online at http://www.rational.com/products/rup/index.jsp.

ROBERTS, F. S. 1979. Measurement Theory with Ap-plications to Decision Making, Utility and the So-cial Sciences. Addison-Wesley, Reading, MA.

ROMBACH, H. D. 1990. Design measurement: Somelessons learned. IEEE Softw. 7 (March), 17–25.

SHARBLE, R. C. AND COHEN, S. S. 1993. The object-oriented brewery: A comparison of two object-oriented development methods. ACM SIGSOFTSoftw. Eng. Notes 18, 2, 60–73.

SHEPPERD, M. 1992. Products, processes and met-rics. Inform. Softw. Tech. 34, 674–680.

TALBI, T., MEYER, B., AND STAPF, E. 2001. A metricframework for object-oriented development. InProceedings of the 39th IEEE International Con-ference and Exhibition on Technology of Object-Oriented Languages and Systems (TOOLS).164–172.

TEGARDEN, D. P., SHEETZ, S. D., AND MONARCHI, D. E.1995. A software complexity model of object-oriented systems. Decis. Supp. Syst. 13, 241–262.

WAND, Y. AND WEBER, R. 1995. On the deep struc-ture of information systems. Inform. Syst. J. 5,203–223.

ZUSE, H. 1991. Software Complexity—Measuresand Methods. De Gruyter, Berlin, Germany.

ZUSE, H. 2001. Zuse/Drabe Measurement Infor-mation System. Available online at http://home.t-online.de/home/horst.zuse/zd-www.html.

ZUSE, H. AND BOLLMAN, P. 1989. Software Metrics:Using Measurement Theory to Describe the Prop-erties and Scales of Static Software ComplexityMetrics. Technische Universitat Berlin, Berlin,Germany.

Received July 2001; revised October 2002, March 2003; accepted April 2003


product metrics for object-oriented systemsgarcia/cursos/ger_processos/... · 2.1. object-oriented...

Documents