CSC/ECE 517 Fall 2012/ch1b 1w20 dm

Cohesion

Cohesion is the "glue" that holds a module together.It can be thought of as the type of association among the component elements of a module. Cohesion is related to the Single Responsibility Principle.Generally, one wants the highest level of cohesion possible. An object with high cohesion is defined for one purpose and it performs only that purpose.High cohesion is desired because it increases the likelihood that a module will be comprehendible, reliable, robust, and reusable [1].Alternatively, a module that exemplifies low cohesion is difficult to comprehend, costly to maintain, and less likely to be reused [2].An object with low cohesion tends to try to do a lot of different things.

Types of Cohesion [3]

Following are arranged from lowest (least desirable) to highest (most desirable).

Coincidental Cohesion

A module has coincidental cohesion if its elements have no meaningful relationship to one another and the module itself can be used to achieve several different types of tasks. The following example illustrates coincidental cohesion [4].

 public static class BackendService {
   public static float computeNetPay(int orderId) {
     // implementation
   }
   
   public static float calculateInventoryReorderAmount(int inventoryId) {
     // implementation
   }
 
   public static boolean generateInvoice(int invoiceId) {
     // implementation
   }
   
   // ...
 }

In this example, the BackendService provides a one stop shop for many different types of tasks. This type of cohesion is the least desirable and should be avoided.

Logical Cohesion

A module has Logical cohesion when parts of a module are grouped together as they are logically categorized to do the same thing, even if they are different by nature.Typically, these modules accept a control flag which indicates which operation to execute. The following example illustrates logical cohesion.

 public class DataStore {
   public void SaveData(int destination, byte[] data) {
     switch (destination) {
       default:
       case 0:
         SaveToDb(data)
         break;
       
       case 1:
         SaveToFile(data)
         break;
       
       case 2:
         SaveToWebService(data)
         break;
     }
   }
   
   protected void SaveToDb(byte[] data) {
     // implementation
   }
   
   protected void SaveToFile(byte[] data) {
     // implementation
   }
   
   protected void SaveToWebService(byte[] data) {
     // implementation
   }
 }

In this example, although all of the operations are logically related by the fact that they all save data, the truth is they are in fact quite different. Saving to a database likely requires a completely different implementation than saving to a file or web service.

Temporal Cohesion

A temporally cohesive module is one whose elements are functions that are related in time. That is operations that are performed to reflect a specific behavior or state. The following example illustrates temporal cohesion.

 public class Startup {
   public void Initialize() {
      InitializeLogging();
      
      InitializeUI();
      
      InitializeDb();
   }
   
   public void InitializeLogging() {
     // implementation
   }
   
   public void InitializeUI() {
     // implementation
   }
   
   public void InitializeDb() {
     // implementation
   }
 }

This example highlights a common implementation pattern where tasks are grouped simply by the fact that they need to be executed at around the same time. Aside from needing to be executed at the same time, these operations implement tasks that are indeed quite different.

Procedural Cohesion

Procedural cohesion describes a module whose operations are typically grouped because they are executed within a sequence. Unlike sequential cohesion (discussed below), the operations within a procedural cohesive module can be somewhat unrelated and output from one operation is not necessarily used as input to a subsequently executed operation. The following example illustrates procedural cohesion.

 public class GradeBookSystem {
   public void Login(int teacherId) {
     // implementation
   }
   
   public ArrayList GetStudents(int teacherId) {
     // implementation
   }
   
   public void UpdateGrades(ArrayList grades) {
     // implementation
   }
   
   public void UpdateAttendance(ArrayList dates) {
     // implementation
   }
   
   public void Logout(int teacherId) {
     // implementation
   }
 }

In this example, the GradeBookSystem exposes different tasks that allow the teacher to login, track student grades/attendance and logout. These operations are grouped in a procedurally cohesive manner to facilitate the higher level task of upgrading the teacher's grade book.

Communicational Cohesion

A communicational cohesive module is one whose elements perform different functions, but each function references the same input information or output.The following example illustrates communication cohesion.

public class CustomerInformation {
   public CustomerInformation(int accountNum) {
     // implementation
   }
   
   public String getName() {
     // implementation
   }
   
   public float getBalance() {
     // implementation
   }
   
   // ...
 }

In this example, the getName and getBalance operations facilitate tasks against the common input accountNum.

Sequential Cohesion

A sequentially cohesive module is one whose functions are related such that output data from one function serves as input data to the next function. The intent is to implement a sequence of operations.

For the same Procedural Cohesion example, the GradeBookSystem exposes different tasks that allow the teacher to login, track student grades/attendance and logout. These operations when called sequentially lead to proper functioning of the module as a whole.

Information cohesion

Informational cohesion describes modules that perform several tasks against a shared data structure. The following example illustrates information cohesion.

 class RectangleTransformer {
 
   Rectangle rectangle;
   
   public RectangleTransformer(Rectangle rectangle) { 
     this.recentangle = rectangle; 
   }
 
   public double getArea() {
     // implementation 
   }
 
   public double getPermiter() {
     // implementation 
   }
 
   public void flip() {
     // implementation 
   }
   
   public void stretch(double width, double height) {
     // implementation 
   }
 }

In this example, all of the RectangleTransformer operations are performing actions against the shared rectangle member variable.

Functional Cohesion

Functional cohesion describes a module that is designed to perform one and only one task. A functionally cohesive module may contain multiple methods, but all of these methods are designed to help the user achieve a single task. Object-oriented languages tend to support this level of cohesion better than earlier languages do.Studies indicate that the first two types of cohesion are inferior, communicational and sequential cohesion are very good and functional cohesion is superior.

The following example illustrates functional cohesion.

 public class Stack {
   public Stack() {
     // implementation
   }
   
   public void push(Object obj) {
     // implementation
   }
   
   public Object pop() {
     // implementation
   }
 
   public Object peek() {
     // implementation
   }
   
   public int isEmpty() {
     // implementation
   }
 }

In this example, all of the operations in the Stack class facilitate the task of supporting a Stack data structure.

Measuring Cohesion

The goal of well-designed systems is to have highly cohesive modules. A high degree of cohesion is attained by:

• Including all the relevant elements of the object together in one class instead of chaining through invisible objects
• Include all the necessary elements in the object, so that the elements presence would model the object accurately.
• Ensure that all the necessary elements are present in the class to achieve completeness.

Below are three metrics that can be used to determine the level of cohesion within a system-

Lack of Cohesion 1 (LCOM1)

 LCOM1 = (P > Q) ? (P – Q) : 0
 
 P = Total number of method pairs that do not use a common field of the class.
 Q = Total number of method pairs that access at least one common field of the class.

Lower LCOM1 values indicate higher cohesion and better overall design.

Lack of Cohesion 2 (LCOM2)

 LCOM2 = 1 – sum(mA)/(m*a)
 
 m = Total number of methods in the class.
 a = Total number of attributes in the class.
 mA = Total number of methods that access attribute a.
 sum(mA) = Sum of all mA for all attributes of the class.

Lower LCOM2 values indicate higher cohesion and better overall design. If the total number of methods or attributes is zero than the value of LCOM2 is undefined.

Lack of Cohesion 3 (LCOM3)

 LCOM3 = (m – sum(mA)/a) / (m – 1)
 
 m = Total number of methods in the class.
 a = Total number of attributes in the class.
 mA = Total number of methods that access attribute a.
 sum(mA) = Sum of all mA for all attributes of the class.

LCOM3 values greater than one indicates low cohesion and should be addressed. If the total number of methods is less than two or the number of attributes is zero than the value of LCOM3 is undefined.

Advantages

• Cohesion is the idea that does a single, clearly definable thing. This has the benefit of making your code easier to follow.
• Promotes code reuse, since small atomic blocks are easier to reuse then larger blocks.
• High cohesion makes it easier to replace a module by another one that provides same functionality.
• High cohesion reduces complexity of the system, and hence increase the application's reliability.
• If the module is highly cohesive, the software is more readable and maintainable.
• Communication between developers is easier.

Disadvantages

• Cohesion is the idea that the module does a single task - be it calculating data, checking file etc. The "single task mindedness" drastically reduces code breaking when other modules are changed.
• If a module uses data from multiple other modules - if even one module changes or breaks, this module might need to be changed thus more time wasted.
• It becomes difficult to understand various modules

New Metrics for Object-Oriented Systems

Majority of coupling and cohesion metrics rely on structural information. Most of it is based on relations which leads to methods or attributes being used. These can be used when assessing quality, doing impact analysis and indentifying design patterns. However, structural metrics lack the ability to identify conceptual links.

We look at two of the newly developed conceptual metrics for measuring coupling and cohesion in software systems.

• Conceptual Coupling between Object Classes(CCBO) - Based on CBO coupling metric [5]
• Conceptual Lack of Cohesion on Methods(CLCOM) - Based on LCOM cohesion metric [6]

The above metrics differ from old conceptual metrics because they implement different counting mechanisms used in peer structural cohesion and coupling metrics. These metrics can be evaluated against existing structural and conceptual coupling metrics for predicting faults in a large open-source software.Usage of these metrics therefore, can be done to build operational models for predicting fault-proneness of classes.Also implementation can be done with other structural metrics to improve overall accuracy of bug prediction models. This approach of measuring coupling and cohesion relies on the assumption that the methods and classes of OO systems are orthogonally related. These are known as conceptual dependencies to capture conceptual cohesion and coupling of classes.Conceptual coupling and cohesion metrics extract and analyze the information in the software. Developers utilize this information to represent a problem or solution.New metrics should be able to get this information to support other analysis.

Future work in this field can lead to advanced metrics which use conceptual information for coupling and cohesion measurement.These metrics can be refined further by including Inheritance.Also pre-processing techniques can be applied improve the quality of textual information.

Cohesion and Coupling Examples

As the popular proverb says " A picture is worth a thousand words ", we will try to represent cohesion and coupling in terms of visual programming metaphors. Observe Figures 1 and 2.

Figure1: Loosely Coupled & Highly Cohesive

What can one say about the two diagrams? Which one is easy to understand, remember and modify? Obviously the answer would be Figure 1. This is exactly why it is recommended to have high cohesion and loose coupling in design or implementation of a software application. The two figures gives a clear visualization of the underlying concepts of coupling and cohesion.

Figure2: Highly Coupled & Loosely Cohesive

.

In General

Let us take a look at some simple real life examples to understand the relation between these two terms.

Example 1. Project team - If we assume that a certain project has 20 people working on it, the possible communication channels would be around 400. The team would be very inefficient with high communication overhead. It can be viewed as an example of tight coupling. Therefore, in any team, certain roles and responsibilities are formally assigned to team member, to enhance productivity of the team with smooth coordination. Well defined roles of a team member can be viewed as high cohesion, and establishing communication channels (like defining hierarchy or reporting structure) can be viewed as low coupling. This is a very practical example of low coupling and high cohesion comes.

Example 2. Car - Let us consider another real life example of a car. It has the engine, tire, steering wheel, gear box, brakes etc. Each component of the car performs a given set of functions. Therefore, if the car breaks down, the problem can be analyzed and only certain part needs to be repaired. This can be considered as high cohesion, as each component focuses on the assigned task. At the same time, in order drive the car, all these parts need to interact with each other. This can be viewed as coupling.

Example 3. Child and Parent relationship - Cohesion and coupling can be well expressed using the analogy of a parent child relationship. The child inherits characteristics of its parents. This can be viewed as coupling. At the same time, there is no coupling in the siblings.

In Object Oriented terms

Polymorphism and encapsulation are two major design principles of object oriented programming. In object oriented terms, we can say that, the main vehicle of coupling is polymorphism [7] and the main vehicle of cohesion is encapsulation. More explanation is provided in cohesion and coupling.

In order to achieve modularity, we need to have low coupling and high cohesion.“Modularity is the property of a system that has been decomposed into a set of cohesive and loosely coupled modules.” Booch 1994

Principle: Modularity = Low Coupling +  High Cohesion

It can be simply understood as, breaking something complex into set of manageable pieces. Consider the example of order processing system. If we decide to write entire software in only one program, it will become lengthy, unmanageable, complicated and hard to debug. Instead, we can divide it into modules or subsystems like order entry, order processing, billing and complaints.

Conclusion

By creating modules that are highly cohesive, programmers can prevent costly maintenance, while increasing the readability, reliability, and reusability of their code.The concept of coupling is usually related to the concept of cohesion so low coupling facilitates high cohesion, and vice versa. It is difficult to obtain perfect high cohesion and low coupling throughout the program. Once all the unitary functions that depend only on their inputs are written, a bit of less cohesive and more coupled code is required to glue them together into a working program. But, there are also times where tight coupling is desirable. Tighter the coupling, it improves performance as it reduces the cost of interfaces. So, tight coupling is important when one process is very stable and wants maximum performance and loose coupling comes into play when flexibility is required rather than stability. Experience tells us, however, that it is not always possible to achieve the highest degree of cohesion and the lowest degree of coupling. Consequently, good engineers should use metrics to measure the degree of cohesion and coupling in their programs and be familiar with the different types of cohesion and coupling so that they may be successful in achieving one of the primary goals within object-oriented programming.