Object-oriented Metrics

This metric shows how much the code is coupled or in other words how much the classes, methods, method parameters refer to each other. High coupling indicates that the module has a high interdependence with other modules and its variation as well as the reuse in other applications may be difficult. Conversely, if the coupling rate is low, it is a sign of a well-structured code.

For calculation of classes coupling following expression is used:

where r_i - the number of references to the class, where reference is field, local variable, returnable type or parameter of the method;
r_t - the number of references to the class involved in the metric calculation,
n - the number of classes.

The number of types outside of the package, that depend on the type of the current package. High afferent coupling shows that given package is of high importance.

The number of types within the package that depend on the types outside the package. High efferent coupling shows how the given package is dependent on external packages.

I = 1 specifies the maximum unstable package and I = 0 - the most stable package. Low metric value means that changes in this package is likely to lead to changes in the dependent packages.

The formula for instability calculation is as follows :

where C_e \u2013 efferent coupling,
C_a \u2013 afferent coupling.

There are several methods for calculating a lack of cohesion. LCOM values belong to the interval [0; 1], the values LCOM HS (Henderson-Sellers) belong to [0; 2] interval . LCOM HS value greater than 1 indicates a bad cohesion. Formula to calculate metric is as following:

where M - the number of methods in the class (including constructors, getters and setters, methods for adding and deleting events)
F - number of class instance fields,
MF - the number of class methods, which have access to a particular instance field,
- The MF sum for all class instance fields.

The basic idea of this metric is that class absolutely connected if all the methods use all its fields, which means
- and leads to the fact that the LCOM = 0 and LCOM HS = 0.

Metrics LCOM and LCOM HS indicate how much the class is associated, ie, whether all the methods of class of are using all the class fields. In the ideal case, when the class is absolutely associated, then all class methods are using all its fields. In the case of absolute class connectedness LCOM and LCOM HS values are 0, and in case of connectivity deterioration LCOM grows to 1 and LCOM HS grows to 2 besides at LCOM HS values <1 class connectivity is still good.

This metric indicates the average number of internal relations for each type of package, i.e. dependencies between the types of the current package. Computational formula is as follows:

where R - number of relationships types that are internal to given package,
N - total number of types in a package.

It is believed that the best values of the metric lay in the range [1.5; 4].

This is the ratio between the number of internal abstract types (abstract classes and interfaces) and number of internal packet types. The range of values for this metric is [0; 1]. If the metric value is 0, then given package is absolutely specific and does not contain any abstract classes and interfaces. If the metric value is 1, then given package is completely abstract.

where M - number of abstract types in the packet, N - total number of types.

Fully abstract packets are rare, but nevertheless if the value of the metric is zero, this means that there are no abstract classes within the package / namespace, which in its turn means that it does not contain any entity that can be used in a system for implementing various complex objects.

If all packages have low level of abstractness, it indicates that the source code is too concretized and changes may be difficult. Also low abstractness indicates that the code design and development process design patterns were not likely used.

To calculate this metric is necessary to compute the value of abstractness A and instability I using the relevant formulas for these metrics. This will allow to calculate considered metric, which is the normalized perpendicular determining the distance from the given package to the ideal line, called the main sequence. This metric is an indicator of the package balance between abstraction and stability. The ideal package is completely stable and the abstract if I = 0, A = 1 and not absolutely specific and stable if I = 1, A = 0. If the metric value is 0, then it coincides with the main sequence, and if the metric value 1, then package is as far from the main sequence as possible and is found whether in zone of pain (changes in the package leads to changes in dependent packages) or zone of uselessness (abstract package, which is almost not used).

Thus, we find that the best metric value is 0, and 1 is the worst. Formula for metric calculation is as follows:

where A \u2013 abstractness, I \u2013 instability.

Metric "association between classes" for a particular type is the number of other types members that directly use this particular class in their methods. It is essential to strive the case where method mostly uses members of its own class.

This metric shows how many other methods members use given type. With the use of this metric it is possible to identify how much given method depends on other types and as a result to show the need of restructuration of the certain parts in source code. For example, if a class uses only methods of other classes, it means that the class does not describe any new abstraction, and serves as a "mediator" to access methods from another class. The total computational formula of this metric is given below:

where ABCX - metric value for a certain class, i - number of calls to a certain method, structure, interface, or enumeration F that does not belong to given class X, N - total number of classes in the system.