Modular cohesion in software engineering

When facing complex projects we usually divide it into smaller simpler chunks on which we can work in a focused fashion because this way we are able maximize the quality and the coherence of our work. In this sense, the software industry is no exception; a recurring technique used when developing of software products modular programming. Modular programming is a software design method that divides the functionalities of a program in modules so that every module contains only what is necessary to provide one aspect of the functionality.

Because complex computer products are frequently developed in a modular way, It is essential to make sure that the modules will be reliable, reusable, solid and understandable. These characteristics are achieved with high modular cohesion. In this context, cohesion is a measure that determines the degree to which the elements of a module achieve the same goal.

This definition might be a somewhat vague, since just determining “how well the parts of a program work together” can be a little subjective. What does cohesion mean in software engineering? The answer to this question depends, many times, on the context. For example, if the product that we develop is an application to process and edit text, everything we do will be cohesive if whatever we build in the end does nothing but processing text. However, this definition is too general as to evaluate the quality of our software. It is  For this reason that several cohesion levels have been defined so we can determine if the parts of our project can work optimally together.

Casual cohesion

Casual cohesion is the lowest level of cohesion and it is present when the parts of a module are strongly related but only because they are in the same file. Placing all the code in one file makes it cohesive but at the end of the day it is not what we are looking for since proximity between lines of code is not the only relationship that exist.

Temporary cohesion

Writing code that is temporarily cohesive implies that its elements are activated at the same time but that is all; that is the only connection between all the elements. Imagine two functions located in the same module only because they are called at once. This solution is not precisely cohesive since execution time alone is not the only factor (nor is it the most important), to take into account when making module elements work efficiently.

Procedural cohesion

Procedural cohesion refers to modules with functions that are called to complete a given procedure but which do not necessarily work to achieve the same functionality. Like temporary cohesion, procedural cohesion is based on the time at which the code runs instead of on its goal to be achieved by the code.

Logical cohesion

This level of cohesion is a bit more interesting and projects implementing it are of higher quality than those implementing the aforementioned cohesion levels. Logical cohesion is based upon the idea that those components of the code that perform similar functions should be grouped into the same module. In other words, the criterion for grouping software components is the degree of similarity of what those do. Nevertheless, this level of cohesion is still quite weak because performing similar activities does not imply that these are the same. Therefore, components achieving similar but yet not the same goals should be separated into different modules. 

Communicational cohesion

This is a more robust level of cohesion. Communicational cohesion implies that all components of the module use the same input or produce the same output. Therefore, software elements that are compliant with communicational cohesion are no just performing similar functions but rather use or produce the same data. This level of cohesion is not bad if the tasks to be carried out are not very complex.

Sequential cohesion

Sequential cohesion is stronger than the procedural one. Modules which are sequentially cohesive do not contain components that are simply run one after the other. Rather, a component runs using other component’s output data as its input data. Taking into account that the output of a component is strictly necessary for the execution of another component it makes perfect sense to place those in the same module.

Functional cohesion

This is the ideal level of cohesion when designing a software product. Functional cohesion implies that a given module contains only the necessary elements to implement a single functionality. This type of cohesion goes one step beyond sequential cohesion. In this regard it is not just that the output of a component is the input of another, but rather that all components are absolutely necessary and essential for the module to perform well-defined specific behaviour.

Conclusion

High modular cohesion is a common mantra in the software design because it is associated with robustness with which software functionalities are implemented. Functional cohesion, therefore is the metric against which, ideally, we would want to evaluate the quality of the modular design of software products.