A metric suite for object oriented design by s r chidamber and c f kemerer 1994
Download
1 / 14

A Metric Suite for Object Oriented Design by S. R. Chidamber and C. F. Kemerer (1994) - PowerPoint PPT Presentation


  • 88 Views
  • Uploaded on

A Metric Suite for Object Oriented Design by S. R. Chidamber and C. F. Kemerer (1994). 2 criticisms of metrics during the early phase of OO. Complexity metrics lacked solid theoretical bases ( e.g. E. Weyuker) Traditional metrics do not include OO concepts The goal of the paper :

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' A Metric Suite for Object Oriented Design by S. R. Chidamber and C. F. Kemerer (1994)' - august-schmidt


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
A metric suite for object oriented design by s r chidamber and c f kemerer 1994
A Metric Suite for Object Oriented Designby S. R. Chidamber and C. F. Kemerer (1994)

  • 2 criticisms of metrics during the early phase of OO.

    • Complexity metrics lacked solid theoretical bases ( e.g. E. Weyuker)

    • Traditional metrics do not include OO concepts

  • The goal of the paper:

    • Propose metrics that have a firm basis in theory

    • Evaluate the metrics against established criteria (e.g. Weyuker)

    • Present empirical data to illustrate the characteristics of metrics


Booch s oo design
Booch’s OO Design

  • Theory behind OO Design centers around “CLASS”

    • Identification of classes

    • Defining the meaning of classes

    • Defining the relationships between/among classes

    • Defining the implementation of a class with methods and data

  • Thus, metrics for OO design measure the complexity indesigning CLASSES

  • The metrics outlined here mainly captures static behavior, not dynamic behavior.

?


Measurement theory
Measurement Theory

  • OO design may be viewed more formally as a system, D, with 3 components:

    • Design, D = ( C, R, B) where

      • C = set of classes

      • R is a set of empirical relations on the classes, C.

      • B is a set of binary operation on the elements of C.

    • An example of empirical relationship is >, where a class is > another class if it contains more methods.

      • Note that a binary relationship may have properties such as transitivity or completeness (every element participates)

  • In order for the OO empirical system to be measured, it must be transformed into a formal system that has relations and operations. An example of such a formal system is the “real number” system, which is ordered. (Example with height of children)

    Children’s height → real number

    Relation : taller → relation: >

    Binary op: standing “on top” → binary op: +

    • This is a transformation metric, M, where for d in Design, D= (C,R,B), is mapped to a formal real system, Real = (n, R, Op);

      or M(d)→ Real


Some important concepts definitions
Some Important Concepts & Definitions

  • Each object, or element, in OO is an individual that has properties.

    • Object is a representation of an application domain, as seen by the designer, that includes

      • Methods

      • Instance variables

    • More formally, Object = (i, P(i) ) where

      • i = individual object

      • P(i) = collection of properties of i

      • For an individual object, x, the properties of x, P(x), are described with methods, (Mx) and instance variables, (IVx) .

        • P(x) = { M x } U { IV x } where U is the logical union, OR, of sets


Design properties for oo
Design Properties for OO

  • Couplingin OO between two objects X and Y is defined as:

    • (1) action by {Mx} on { P(y) = [{My} U {IVy}] }or

    • (2) action by {My} on { P(x) = [{Mx} U {IVx}] }

      2. Cohesionis defined in terms of a similarity function, S, where

    • S(A, B) = P(A) ^ P(B) , ^ is the logical intersection, AND, of sets

      • Consider M1 and M2, methods 1 and 2 of the same Object.

      • S(M1, M2) = { IV1 } ^ { IV2 } where {IV1} is the set of instance variables accessed by method M1.

    • Cohesion is defined by this similarity function based on the belief that different methods of the same object performing different operations on the same set of instance variables implies that the object is cohesive. (The “degree of similarity” isbased on the similarity of methods which in turn is measured bythe number of the “common” instance variables.)


Design properties for oo cont
Design Properties for OO (cont.)

3. Complexityof an object may be viewed as the cardinality of the object’s set of properties based on the concept that the larger the set of anything, the more complex it is. (properties may be anything of interest such as “input variables”)

4. Scopeof properties of an object speaks to how far an object’s properties influences other objects. (“span of influence”)

  • In OO, the depth of inheritance may be viewed as the scope.

    • Depth of Inheritance = depth of class in the inheritance tree

  • In OO, the number of children of a class may also be viewed as an influencing factor.

    • Number of children of a class = number of immediate descendants of a class

      5. Communications among the methods is another measure of OO design – this is like coupling

  • Response set of a class of objects = { all methods that can be invoked in response to a message to an object of the class}

    6. Combination of objects, X and Y, is defined as the logical union of P(X) and P(Y).(not clear on the applicability of this in OO)


E weyuker s 9 metric evaluation criteria
E. Weyuker’s 9 Metric Evaluation Criteria

  • Let mbe a metric for a program entity; then it should have the following properties :

    • Non-Coarseness: given any program X there is another program Y where m(X) != m (Y)

    • Non-Uniqueness: there exist program entities X and Y such that m (X) = m(Y)

    • **Permutation is significant : there exists program entities X and Y such that X is a rearrangement of Y and m (x) != m (Y)

    • Implementation (design detail) is important: there exists programs X and Y such that they produce the same output given the same input and m (X) != m (Y)

    • Monotonicity: given program entities X, Y, m (X) <= m (X +Y) and m (Y) <= m (X +Y) where + is the concatenation of X and Y.

    • Non-equivalence of interaction: there are program entities of X,Y, and Z such that m (X) = m (Y) but m (X + Z) != m ( Y+Z)

    • Interaction increases complexity : there are program entities X, and Y such that m(X) + m(Y) <= m (X + Y) where the first + is addition and second is some other operation such as concatenation.

    • **Finiteness: given a nonnegative number, c, there is only a finite number of program entities that satisfies m(X) = c.

    • ** Renaming Principle: if Y is a renaming of X, the m(X) = m(Y)

      ** Are not considered by C-K in this article


6 c k metrics for oo design
6 C-K Metrics for OO design

  • Weighted Methods per Class (WMC)

    • WMC = SUM( Cj ), where C1, ----, Cn are the complexity weights assigned to each of the methods M1, ----, Mn in the class.

    • If the weights are all equal to 1, then WMC = number of methods in the class.

    • (based on the complexityproperty of larger the cardinality of a set of methods the more time and effort is needed.)

  • Depth of Inheritance Tree (DIT)

    • DIT = length of a node to the root of an inheritance tree.

    • In case of multiple inheritance, pick the maximum length.

    • (based on the scopingproperty, where the deeper scope indicates more influence indepth that is harder to understand.)


6 c k metrics for oo design1
6 C-K Metrics for OO design

  • Number of Children (NOC)

    • NOC = number of immediate sub-classes subordinate to the class.

    • (based on the scoping property where the broader the scope implies more influence in breadth and possibly more complexity.)

  • Coupling Between Objects (CBO)

    • CBO = number of classes a class is coupled to, where coupled is defined as a method in a class calling another class or uses its variables.

    • The notion of coupling allows for both fan-in and fan-out.

    • (based on the coupling property where less coupling is better; more coupling prevents re-use and is hard to maintain)


6 c k metrics for oo design2
6 C-K Metrics for OO design

  • Response for a class (RFC)

    • RFC = (number of methods in class) + (number of remote methods calledby the methods in class), the ‘+’ operator is the arithmetic sum.

    • A called on method is counted once even if it may be called several times.

    • (based on the complexityand communication properties where higher cardinality implies more difficulty – more testing also)

  • Lack of Cohesion in Methods (LCOM)

    • LCOM = [(Cardinality of P) – (Cardinality of Q)] if cardinality of P is > cardinality of Q; otherwise LCOM = 0, where

      • For each method Mj, IVj = set of instance variables used by Mj

      • P = { (IVj, IVk) where logical intersection of IVj and IVk is empty }

      • Q = { (IVj, IVk) where logical intersection of IVj and IVk is non-empty }

      • (based on the idea that similarity of methods gives us cohesion and less similarity shows lack of cohesion --- where similarity of methods in a class is defined as operating on the same instance variable )

Note that “degree of “ 0 is not included in LCOM; that is, no matter by how much

the cardinality of Q is bigger than cardinality of P, it is the same zero!


Meeting oo booch s design theory steps
Meeting OO Booch’s Design Theory(Steps)

  • Earlier it is said that the theory behind OO design centers around “class”

    • Identification of classes

    • Defining the meaning of classes

    • Defining the relationships between/among classes

    • Defining the implementation of a class with methods and data

  • Do the C-K metrics cover all these design points of “CLASS” ?


C k metrics coverage of oo design steps
C-K Metrics coverage of OO Design Steps

Do you agree with the author’s assessment?


Meeting weyuker s metric evaluation
Meeting Weyuker’s Metric Evaluation ?

metric

W1

W2

W4

W5

W6

W7

WMC

Yes

Yes

Yes

Yes

Yes

No

DIT

Yes

Yes

Yes

No

Yes

No

NOC

Yes

Yes

Yes

Yes

Yes

No

CBO

Yes

Yes

Yes

Yes

Yes

No

RFC

Yes

Yes

Yes

Yes

Yes

No

LCOM

Yes

Yes

Yes

NO

Yes

No

  • W7 is “interaction increases complexity” – none of the metrics satisfy

  • this condition

  • W8-”finiteness” and W9-”renaming”applies to all metrics; W3-”permutation” is not applicable


Some managerial usage of these metrics
Some Managerial “Usage” of these metrics

  • Data from 2 commercial projects indicated that designers kept inheritance hierarchies “shallow”; this indicates that for simplicity, the designers gave up some re-use. (Can managers encourage people to increase DIT or NOC ?)

  • Another observation indicated that a class had a large number (42) of sub-classing. In this case, looking at NOC helped find some potential excess in sub-classing.

  • Clearly, combinations of metrics may also help manage the over-all design.

    • WMC along with NOC and DIT to look at structuring of class

    • CBO and RFC to look at excessive interaction and communications


ad