CodeSWAT.COM - Metrics

Deprecated: Assigning the return value of new by reference is deprecated in /home/content/s/w/a/swatadmin/html/cswat/templates/ja_bellatrix/ja_cssmenu/ja-cssmenu.php on line 73

You are here:Home

Analyst4j

Metrics

Object Oriented Metrics

Applications developed using object oriented languages like Java are conceived as a collection objects which interact with one another to achieve the desired functionality. Interaction between objects creates a relationship between them. Object oriented metrics proposed by Chidamber & Kemerer and others , provide methods to measure the quality of object design, their relationship, dependency and other OO principles.

Analyst4j measures these metrics automatically, which forms the source for analysis.

Weighted Methods Complexity ( WMC)
Response For Class (RFC)
Lack Of Cohesive Methods (LCOM)
Coupling Between Object (CBO)
Depth of Inheritance Tree (DIT)
Number of Children (NOC)

Weighted methods per class (WMC)

The WMC is a count of the methods implemented within a class or the sum of the complexities of the methods (method complexity is measured by cyclomatic complexity).

WMC1:

Consider a Class C with methods M1, M2...Mn that is defined in the class. Let C1, C2...Cn be the complexity of the methods.

Then WMC1 = C1 + C2 + .... + Cn. However the researcher's didn't define what "Complexity" of a method is deliberately, and left it for the implementers to choose. If all methods complexities are considered to be unity, then

WMC1 = n, the Number of methods.

Therefore, WMC1 = No. Of Methods (Considering complexities of methods to be unity).

WMC2:

WMC2 = C1 + C2 + ... + Cn (Sum of Cyclomatic Complexity of methods).

Interpretation

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

Response for a Class (RFC)

The RFC is the count of the set of all methods that can be invoked in response to a message to an object of the class or by some method in the class. Methods in a class can be used as measures of communication.

Methods can be viewed as definitions of responses to possible messages.Therefore,

RFC = |RS| where RS is the response set for the class. RS (Response set) is the set of all methods that can be invoked in response to a message to an object of the class. Methods include methods outside the class as well, since methods within the class may call methods from other classes.

RS = { M } U { Ri }, where

M = set of all methods in the class.

Ri = set of methods called by method i. The cardinality of this set is a measure of communication.

Interpretation

If a large number of methods can be invoked in response to a message, then testing and debugging of the class becomes more complicated, since it requires a greater level of understanding 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.

Lack of Cohesion (LCOM)

Lack of Cohesion (LCOM) measures the dissimilarity of methods in a class by instance variable or attributes.

Cohesion is the similarity of two things to be the intersection of the sets of properties of the two things. So, the degree of similarity of the methods within the object can be defined to be the intersection of the sets of instance variables that are used by the methods.

If an object class has different methods performing different operations on the same set of instance variables, then the class is said to be cohesive. Cohesion is centered on data that is encapsulated within an object and how methods interact with data. Lack of cohesion, is a measure of how close methods are to the data they access.

The more methods that access each attribute, the lower the value of LCOM and the more cohesive the class

Interpretation

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 subclasses.
Helps identify flaws in the design of classes.
Low cohesion increase complexity, thereby increasing the likelihood of errors during the development process

Coupling Between Object Classes (CBO)

Coupling Between Object Classes (CBO) is a count of the number of other classes to which a class is coupled.

Two objects are coupled if and only if at least one of them acts upon the other. CBO for a class is a count of the Number of other classes to which it is coupled.

CBO relates to the notion that an object is coupled to another object if one of them acts on the other, i.e., methods of one use methods or instance variables of another. Since objects of the same class have the same properties, two classes are coupled when methods declared in one class use methods or instance variables defined by the other class.

Interpretation

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

Depth of Inheritance Tree (DIT)

The depth of a class within the inheritance hierarchy is the maximum number of steps from the class node to the root of the tree and is measured by the number of ancestor classes.

Designers develop an abstraction of the application domain by arranging the classes in a hierarchy. The inheritance hierarchy is a directed acyclic graph that can be described as a tree structure with classes as nodes, leaves and a root. In any application, there can be many possible choices for the class hierarchy.

Design choices on the hierarchy employed to represent the application are essentially choices about restricting or expanding the scope of properties of the classes of objects in the application. Two design decisions which relate to the inheritance hierarchy can be defined.

They are Depth of Inheritance of class of objects and the Number of Children of the class, collectively they represent the genealogy of a class.

Depth of Inheritance(DIT) = depth of the class in the inheritance tree. The depth of a node of a tree refers to the length of the maximal path from the node to the root of the tree.

Depth of inheritance indicates the extent to which the class is influenced by the properties of its ancestors.

Interpretation

The deeper a class is in the hierarchy, the greater the Number of methods it is likely to inherit, making it more complex to predict its behavior.
Deeper trees constitute greater design complexity, since more methods and classes are involved.
The deeper a particular class is in the hierarchy, the greater the potential reuse of inherited methods.

Number of Children (NOC)

The number of children is the number of immediate subclasses subordinate to a class in the hierarchy.

In any application, there can be many possible choices for the class hierarchy. Design choices on the hierarchy employed to represent the application are essentially choices about restricting or expanding the scope of properties of the classes of objects in the application.

Two design decisions which relate to the inheritance hierarchy can be defined. They are Depth of Inheritance of class of objects and the Number of Children of the class, collectively they represent the genealogy of a class.

Number of children = Number of immediate descendants of the class. Number of children indicates the potential impact on descendants.

Interpretation

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 class. If a class has a large Number of children, it may be a case of misuse of sub classing.
If a class has large Number of children, it may require more testing.