CodeMR is a powerful software quality tool which is integrated with IDEs and supports multiple programming languages. Java, Kotlin, Scala and C++.
Measurement plays a key role in quality improvement activities and metrics are the quantitative measurement of software design quality.
CodeMR automatically extracts quality metrics and class relations from source code and visualizes them on a graph-based interactive visual environment. This visual environment effectively simplifies comprehension and refactoring of complex software systems.
Software external quality displays the visible symptoms when there are issues, but the roots are invisible internal quality attributes: program structure, complexity, coupling, testability, reusability, readability, maintainability. Coupling, Complexity, Cohesion and Size are the fundamental internal quality attributes of a software.
Visual properties of a node in a graph are its color, size, and shape pattern. Each quality attribute is mapped to different physical properties of a node. The user can change mapping scheme by defining different metric query statements.
Color: Indicates the complexity of entity. Complexity changes the color scale to a blue-to-red spectrum. Colors get warmer while complexity of an entity increases. Because red color is associated with danger in most cultures, red color indicates high complexity.
Shape: While the coupling attribute value of a class increases, the node shape becomes more cornered. A class with high coupling has more corners that indicate more interaction points with other classes. Circle means low coupling, where six-edges star means very high coupling.
Size: The area of the bounding square around the shape and it naturally represents the size of class, as size of class increases the node becomes bigger as it is shown in diagram.
Size is one of the oldest and most common forms of software measurement. Measured by the number of lines or methods in the code. A very high count might indicate that a class or method is trying to do too much work and should be split up. It might also indicate that the class might be hard to maintain.
- CLOC (Class Lines of Code): The number of all nonempty, non-commented lines of the body of the class. CLOC is a measure of size and also indirectly related to the class complexity.
- NOF (Number of Fields): The number of fields (attributes) in a class
- NOM (Number of Methods): The number of methods in a class.
- NOSF (Number of Static Fields): The number of static fields in a class.
- NOSM (Number of Static Methods): The number of static methods in a class.
- CM-LOC (Class-Methods Lines of Code): Total number of all nonempty, non-commented lines of methods inside a class.
- NoI (Number of Interfaces): Total number of Interfaces.
- NoCls (Number of Classes):Total number of classes.
- NoE (Number of Entities): Total number of Interfaces and classes.
- NORM (Number of Overridden Methods): The number of Overridden Methods.
- nofP (Number of Packages): Number of Packages in the project
- nofPa (Number of External Packages): Number of External Packages referenced by the project
- nofEE (Number of External Entities): Number of External classes and interfaces referenced by the project
Implies being difficult to understand and describes the interactions between a number of entities. Higher levels of complexity in software increase the risk of unintentionally interfering with interactions and so increases the chance of introducing defects when making changes.
- WMC (Weighted Method Count): The weighted sum of all class’ methods and` represents the McCabe complexity of a class. It is equal to number of methods, if the complexity is taken as 1 for each method. The number of methods and complexity can be used to predict development, maintaining and testing effort estimation. In inheritance if base class has high number of method, it affects its’ child classes and all methods are represented in subclasses. If number of methods is high, that class possibly domain specific. Therefore they are less reusable. Also these classes tend to more change and defect prone.
- DIT (Depth of Inheritance Tree): The position of the class in the inheritance tree. Has 0 (zero) value for root and non-inherited the multiple inheritance, the metric shows the maximum length. Deeper class in the inheritance tree, probably inherit. Therefore, it is harder to predict its behavior. Also this class relatively complex to develop, test and maintain.
- RFC (Response For a Class) : The number of the methods that can be potentially invoked in response to a public message received by an object of a particular class. If the number of methods that can be invoked at a class is high, then the class is considered more complex and can be highly coupled to other classes. Therefore more test and maintain effort is required.
- SI (Specialization Index) : Defined as NORM * DIT / NOM. The Specialization Index metric measures the extent to which subclasses override their ancestors classes. This index is the ratio between the number of overrid- den methods and total number of methods in a Class, weighted by the depth of inheritance for this class. Lorenz and Kidd precise : Methods that invoke the superclass’ method or override template are not included.
Coupling between two classes A and B if:
- A has an attribute that refers to (is of type) B.
- A calls on services of an object B.
- A has a method that references B (via return type or parameter).
- A has a local variable which type is class B.
- A is a subclass of (or implements) class B.
Tightly coupled systems tend to exhibit the following characteristics:
- A change in a class usually forces a ripple effect of changes in other classes.
- Require more effort and/or time due to the increased dependency.
- Might be harder to reuse a class because dependent classes must be included.
- NOC (Number of Children): The number of direct subclasses of a class. The size of NOC approximately indicates how an application reuses itself. It is assumed that the more children a class has, the more responsibility there is on the maintainer of the class not to break the children’s behaviour. As a result, it is harder to modify the class and requires more testing.
- CBO (Coupling Between Object Classes): The number of classes that a class is coupled to. It is calculated by counting other classes whose attributes or methods are used by a class, plus those that use the attributes or methods of the given class. Inheritance relations are excluded. As a measure of coupling CBO metric is related with reusability and testability of the class. More coupling means that the code becomes more difficult to maintain because changes in other classes can also cause changes in that class. Therefore these classes are less reusable and need more testing effort.
- CBO Lib: The number of dependent library classes.
- CBO App: The number of dependent classes in the application.
- EC (Efferent Coupling): Outgoing Coupling. The number of classes in other packages that the classes in the package depend upon is an indicator of the package’s dependence on externalities.
- AC(Afferent Coupling): Incoming Coupling. The number of classes in other packages that depend upon classes within the package is an indicator of the package’s responsibility.
- ATFD (Access to Foreign Data): is the number of classes whose attributes are directly or indirectly reachable from the investigated class. Classes with a high ATFD value rely strongly on data of other classes and that can be the sign of the God Class.
- Degree: Degree of corresponding graph vertex of the class
- InDegree: In-degree of corresponding graph vertex of the class
- OutDegree: Out-degree of corresponding graph vertex of the class
Measure how well the methods of a class are related to each other. High cohesion (low lack of cohesion) tend to be preferable, because high cohesion is associated with several desirable traits of software including robustness, reliability, reusability, and understandability. In contrast, low cohesion is associated with undesirable traits such as being difficult to maintain, test, reuse, or even understand.
- LCOM (Lack of Cohesion of Methods): Measure how methods of a class are related to each other. Low cohesion means that the class implements more than one responsibility. A change request by either a bug or a new feature, on one of these responsibilities will result change of that class. Lack of cohesion also influences understandability and implies classes should probably be split into two or more subclasses. LCOM3 defined as follows LCOM3 = (m – sum(mA)/a) / (m-1) where :
- m number of procedures (methods) in class
- a number of variables (attributes) in class. a contains all variables whether shared (static) or not.
- mA number of methods that access a variable (attribute)
- sum(mA) sum of mA over attributes of a class
- LCAM (Lack of Cohesion Among Methods(1-CAM)): CAM metric is the measure of cohesion based on parameter types of methods. LCAM = 1-CAM
- LTCC (Lack Of Tight Class Cohesion (1-TCC)): The Lack of Tight Class Cohesion metric measures the lack cohesion between the public methods of a class. That is the relative number of directly connected public methods in the class. Classes having a high lack of cohesion indicate errors in the design.