CSC/ECE 517 Fall 2012/ch1b 1w20 dm: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
No edit summary
No edit summary
Line 210: Line 210:


In this example, all of the operations in the <code>Stack</code> class facilitate the task of supporting a Stack data structure.
In this example, all of the operations in the <code>Stack</code> 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.

Revision as of 01:37, 23 October 2012

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.