Architectural Quality Assessment with CodeMR

As Tom de Marco says, “you cannot control what you cannot measure”. Measurement plays a key role in quality improvement activities and metrics are the quantitative measurement of software design quality.

For software quality, there are basically four internal attributes. Which are coupling, cohesion, complexity and size. Many design patterns are closely related with these attributes

Coupling is the degree of interdependency between software modules. For example if class A calls a method of class B, extends class B, or has a field or parameter from type B, then A depends on B. High coupling reduces maintainability, understandability and reusability.

Complexity is the degree of difficulty in understanding the internal and external structure of classes and their relationships. When we try to understand the design we should not feel like we are solving a puzzle. Code with high complexity is harder to test, reuse and maintain. Even if we desire low complexity, sometimes if the problem domain is complex, it also affects the code complexity, but the design should not include additional complexity. So, it is important how the software designer manages the domain complexity.

Cohesion is the degree to which the elements of a module belong together. How they are related to each other. A class should have one, and only one, reason to change. if software modules are cohesive then it is easy to locate where to change for a given feature.

And finally, size is the quantity of some attributes like line of code, number of classes, methods etc.

These quality attributes are correlated with each other. a class with high lines of code is most probably doing more than one job, less cohesive, highly coupled.

How can we measure coupling, complexity, cohesion and size of software entities. simply by using metrics for quantifying different attributes. Software metrics are quantitative measures of the degree to which a software component possesses a given attribute. There are many metrics defined in the literature and supported by CodeMR. Some of them are:

• Lines of Code (LOC)
• Number of Classes/Entities
• Number of Fields (NOF)
• Number of Methods(NOM)
• Lack of Cohesion in Methods (LCOM)
• Cohesion Amongst Methods (CAM)
• Weighted Methods per Class (WMC)
• Response For a Class (RFC)
• Depth of Inheritance Tree (DIT)
• Number of Children (NOC)
• Coupling Between Object Classes (CBO)
• Afferent/Efferent Coupling

They all give quantitative information about internal quality attributes (like coupling cohesion, complexity or size) For example, if the weighted method count metric is so high you can say the class is very complex. Then you should think if it is possible to make it less complex if not possible in the meantime at least you should test well, if you did not test well then you should get ready for the consequences.

There is a clear relation between software metrics and code smells. Applying Design patterns generally results in better metric values. On the other hand, code smells results in worse metric values. For example, applying adaptor and factory patterns increase cohesion while decreasing the coupling. Dead code, duplicate code increase line of code, long methods and large classes will most probably also have low cohesion and high coupling.

On the other hand applying metrics in practice is not so easy, there are some problems in practice as well. For example, A single metric value may not give a meaningful result about quality. There are so many metrics, and most of the time they must be evaluated together. Definitions of some metrics are ambiguous or give a numerical value that is hard to interpret by developers. Hard to guess thresholds values of each metrics.

Challenges with metrics

• Too many metrics to use
• Ambiguous Definition
• Different Scale and Direction
• Determining Thresholds

How CodeMR helps you on architectural quality assessment with Architectural Quality Visualisation?

Limited Time, Limited Resources

Many developers are not quality and metric experts, they don’t have much time to analyse all metric. In a limited time with limited resources, we should find which are the critical parts and where to start improvement.

An integrated representation of complex and multi-dimensional data

There is a need for an integrated representation of complex and multi-dimensional data, which should be intuitive, catchy and memorable. Visualisation helps users to see the big picture. Brings quality attributes and relationships together

Easy to perceive and comprehend

It lets users see the big picture. Brings metrics and relationships together.

For more info please visit:

• Website: https://www.codemr.co.uk/
• Twitter: @CodeMR_
• LinkedIn: https://www.linkedin.com/company/codemr