Login | Register
My pages Projects Community openCollabNet

Metrics

Table of contents

Simple metrics

Lines of Class Code (LOCC)

LOCC counts number of perfect lines of class code. It processes the internal string representation of AJDT/JDT compiler, so the result is independent from original code styling etc.

Implementation notes:

  • every statement is in a single line,
  • class, aspect, method and advice headers are counted as a one line,
  • imports, comments, javadocs and empty newlines are not counted,
  • newline is not created for a opening curly braces,
  • newline is created for a closing curly braces,
  • string constants are counted as a single line (even when it contains new lines).

CK metrics suite for AOP

Metrics implemented by aopmetrics project can be applied to classes and aspects. Therefore (like in [1]) module will be used as a common term for classes and aspects. Similarly, methods, advices and introductions will be indicated by the operation term.

Weighted Operations in Module (WOM)

WOM counts number of operations in a given module [1]. It's an equivalent of the WMC metric from CK metrics suite.

Similarly to the related OO metric, WOM captures the internal complexity of a module in terms of the number of implemented functions. A more refined version of this metric can be obtained by giving different weights to operations with different internal complexity [1].

View points: [2]

  • The number of operations and the complexity of operations involved is a predictor of how much time and effort is required to develop and maintain the module.
  • The larger the number of operations in a module the greater the potential impact on children, since children will inherit all the operations defined in the module.
  • Modules with large numbers of operations are likely to be more application specific, limiting the possibility of reuse.

Implementation notes:

  • constructors and methods are counted as a member of a class or an aspect,
  • advices and introductions of methods or constructors are counted as a member of an aspect.

Depth of Inheritance Tree (DIT)

DIT is a length of the longest path from a given module to the class/aspect hierarchy root [1].

Similarly to the related OO metric, DIT measures the scope of the properties. The deeper a class/aspect is in the hierarchy, the greater the number of operations it might inherit, thus making it more complex to understand and change. Since aspects can alter the inheritance relationship by means of static crosscutting, such effects of aspectization must be taken into account when computing this metric [1].

View points: [2]

  • The deeper a module is in the hierarchy, the greater the number of operations it is likely to inherit, making it more complex to predict its behavior.
  • Deeper trees constitute greater design complexity, since more operations and modules are involved.
  • The deeper a particular module is in the hierarchy, the greater the potential reuse of inherited operations.

Implementation notes:

  • Object class is not counted.
  • Modification of module's hierarchy using inter-type declarations are being considered.
  • DIT for interfaces is always zero.

Number Of Children (NOC)

NOC is a number of immediate subclasses or sub-aspects of a given module [1].

Similarly to DIT, NOC measures the scope of the properties, but in the reverse direction with respect to DIT. The number of children of a module indicates the proportion of modules potentially dependent on properties inherited from the given one [1].

View points: [2]

  • Greater the number of children, greater the reuse, since inheritance is a form of reuse.
  • Greater the number of children, the greater the likelihood of improper abstraction of the parent module. If a module has a large number of children, it may be a case of misuse of sub-classing.
  • The number of children gives an idea of the potential influence a module has on the design. If a module has a large number of children, it may require more testing of the operations in that module.

Implementation notes:

  • Modification of module's hierarchy using inter-type declarations are being considered.
  • NOC for interfaces is always zero.

Crosscutting Degree of an Aspect (CDA)

CDA is a number of modules affected by the pointcuts and by the introductions in a given aspect [1].

This is a brand new metric, specific to AOP software, that must be introduced as a completion of the CIM metric. While CIM considers only explicitly named modules, CDA measures all modules possibly affected by an aspect. This gives an idea of the overall impact an aspect has on the other modules. Moreover, the difference between CDA and CIM gives the number of modules that are affected by an aspect without being referenced explicitly by the aspect, which might indicate the degree of generality of an aspect, in terms of its independence from specific classes/aspects. High values of CDA and low values of CIM are usually desirable [1].

Coupling on Intercepted Modules (CIM)

CIM is a number of modules or interfaces explicitly named in the pointcuts belonging to a given aspect.

This metric is the dual of CAE, being focused on the aspect that intercepts the operations of another module. However, CIM takes into account only those modules and interfaces an aspect is aware of - those that are explicitly mentioned in the pointcuts. Sub-modules, modules implementing named interfaces or modules referenced through wildcards are not counted in this metric, while they are in the metric CDA (see below), the rationale being that CIM (differently from CDA) captures the direct knowledge an aspect has of the rest of the system. High values of CIM indicate high coupling of the aspect with the given application and low generality/reusability [1].

Implementation notes:

  • NOT IMPLEMENTED YET!

Coupling on Advice Execution (CAE)

CAE is a number of aspects containing advices possibly triggered by the execution of operations in a given module [1].

If the behavior of an operation can be altered by an aspect advice, due to a pointcut intercepting it, there is an (implicit) dependence of the operation from the advice. Thus, the given module is coupled with the aspect containing the advice and a change of the latter might impact the former. Such kind of coupling is absent in OO systems [1].

Coupling on Method Call (CMC)

CMC is a number of modules or interfaces declaring methods that are possibly called by a given module [1].

This metric descends from the OO metric CBO (Coupling Between Objects), which was split into two (CMC and CFA) to distinguish coupling on operations from coupling on attributes. Aspect introductions must be taken into account when the possibly invoked methods are determined. Usage of a high number of methods from many different modules indicates that the function of the given module cannot be easily isolated from the others. High coupling is associated with a high dependence from the functions in other modules [1].

Implementation notes:

  • constructor calls are counted as a method call,
  • calls from introduced methods are counted as a call from aspect,
  • introduced method calls are counted as a aspect's member calls.

Coupling on Field Access (CFA)

CFA is a number of modules or interfaces declaring fields that are accessed by a given module [1].

Similarly to CMC, CFA measures the dependences of a given module on other modules, but in terms of accessed fields, instead of methods. In OO systems this metric is usually close to zero, but in AOP, aspects might access class fields to perform their function, so observing the new value in aspectized software may be important to assess the coupling of an aspect with other classes/aspects [1].

Implementation notes:

  • field access from introduced methods are counted as a access from aspect,
  • (TODO) access to introduced fields are counted as an access to aspect's fields.

Coupling between Modules (CBM)

CBM is a number of modules or interfaces declaring methods or fields that are possibly called or accessed by a given module. It's an equivalent of the CBO metric from CK metrics suite. This is a combination of CFA and CMC metrics.

View points: [2]

  • Excessive coupling between object classes is detrimental to modular design and prevents class is, the easier it is to reuse it in another application.
  • In order to improve modularity and promote encapsulation, inter-object class couples larger the number of couples, the higher the sensitivity to changes in other parts of more difficult.
  • A measure of coupling is useful to determine how complex the testing of various higher the inter-object class coupling, the more rigorous the testing needs to be.

Implementation notes:

  • see notes for CFA and CMC.

Respone For a Module (RFM)

RFM is number of methods and advices potentially executed in response to a message received by a given module [1].

Similarly to the related OO metric, RFM measures the potential communication between the given module and the other ones. The main adaptation necessary to apply it to AOP software is associated with the implicit responses that are triggered whenever a pointcut intercepts an operation of the given module [1].

View points: [2]

  • If a large number of methods can be invoked in response to a message, the testing and debugging of the class becomes more complicated since it requires a greater level of understanding required on the part of the tester.
  • The larger the number of methods that can be invoked from a class, the greater the complexity of the class.
  • A worst case value for possible responses will assist in appropriate allocation of testing time.

Implementation notes:

  • RFM for a module is a sum of: number of methods in the module, number of methods invoked from methods, number of advices implicitly invoked,
  • method introductions are counted as a member of an aspect,
  • calls from method introductions are counted as a call from an aspect,
  • constructors, constructor's invocations, methods invoked from constructors, advises on constructors are not counted,
  • methods invoked in static initialisation and initialisation blocks are not counted.

Lack of Cohesion in Operations (LCO)

LCO is number of pairs of operations working on different class fields minus pairs of operations working on common fields (zero if negative) [1]. When all methods don't access to any field, then LCO = 0 [2].

Similarly to the LCOM (Lack of Cohesion in Methods) OO metric, LCO is associated with the pairwise dissimilarity between different operations belonging to the same module. Operations working on separate subsets of the module fields are considered dissimilar and contribute to the increase of the metric's value. LCO will be low if all operations in a class or an aspect share a common data structure being manipulated or accessed [1].

View points: [2]

  • Cohesiveness of methods within a class is desirable, since it promotes encapsulation.
  • Lack of cohesion implies classes should probably be split into two or more sub-classes.
  • Any measure of disparateness of methods helps identify flaws in the design of classes.
  • Low cohesion increases complexity, thereby increasing the likelihood of errors during the development process.

Implementation notes:

  • only access to instance variables are counted, static fields are omitted,
  • field access from constructors are not considered,
  • introduced methods and fields are treated as normal aspect's members.

Package dependecies

The aopmetrics project provides two versions of package dependencies metrics suite. Both are based on Robert Martin's suite proposed in [3]. First one is unmodified version of the suite. Second one contains modification of Ce metric (and is similar to RefactorIT version). All definition excluding Ce metrics are identical for both versions.

Number of Types (NOT)

NOT is a number of types within given package. This is an indicator of the extensibility of the package

Implementation notes:

  • Every class (normal, inner, anonymous), interface and aspect is counted as a type.

Abstractness (A)

A is the ratio of the number of abstract modules to the total number of modules in the package. Abstractness metric results are within a range of < 0 ; >. A value of zero indicates a completely concrete package and a value of one - a completely abstract.

Implementation notes:

  • Every interface, abstract class and abstract aspect is being considered.

Afferent Couplings (Ca)

Ca is the number of modules outside the package, that depend upon modules within the package [3]. This is an indicator of the package's responsibility.

Implementation notes:

  • Every (normal and qualified) type reference, supertype and implemented interfaces and type of every name reference are analysed.

Efferent Couplings (Ce)

Ce is the number of modules inside the package, that depend upon modules outside the package [3]. This is an indicator of the package's independence.

Implementation notes:

  • See notes for Ca.

Modified Efferent Couplings (Ce)

The aopmetrics project provides also modified version of Ce metric. Original version doesn't indicate how big efferent couplings are. Package depending on single class has the same value of Ce metric like package with two dozens of dependencies.

Ce is the number of modules outside the package, that the modules in the package depend on.

Implementation notes:

  • See notes for Ca.

Instability (I)

I is the ratio of efferent coupling (Ce) to total coupling (Ce + Ca). such that I = Ce / (Ce + Ca). This metric is an indicator of the package's resilience to change. Instability metric results are within a range of < 0 ; 1 >. A value of zero indicates a completely stable package and a value of one indicates a completely instable package.

NOTE: Since the aopmetrics project provides two version of Ce metric, therefore there're two versions of I metric.

Normalized Distance from Main Sequence (Dn)

Dn is the normalized perpendicular distance of the package from the idealized line A + I = 1. This metric is an indicator of the package's balance between abstractness and stability. Dn metric's results are within a range of < 0 ; 1 >. A value of zero indicates perfect package design.

A package that sits on the main sequence (the line A + 1 = 1) is not too abstract for its stability, nor is too instable for its abstractness. It has the right number of concrete and abstract classes in proportion to its efferent and afferent dependencies. Clearly, the most desirable positions for a package to hold are at one of the two endpoints of the main sequence. However, in my experience only about half the packages in a project can have such ideal characteristics. Those other packages have the best characteristics if they are on or close to the main sequence [3].

NOTE: Since the aopmetrics project provides two version of Ce metric, therefore there're two versions of Dn metric.

References

  1. Mariano Ceccato and Paolo Tonella, Measuring the Effects of Software Aspectization PDF
  2. Chidamber and Kemerer, A Metrics Suite for Object Oriented Design PDF
  3. Robert Martin, OO Design Quality Metrics, An Analysis of Dependencies PDF
  4. JDepend documentation HTML
  5. RefactorIT documentation HTML