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 Conceptual 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 Conceptual Lack of Cohesion on Methods(CLCOM) - Based on LCOM cohesion metric

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.