COHESION

Definition In computer programming, cohesion is a measure of how strongly-related or focused the elements (or responsibilities) of a single module are. (The term element refers to any piece of code that performs some work or defines some data.) In other words, cohesion examines how the activities within a module are related to one another. Designing Highly Cohesive Modules The objective of designers is to create highly cohesive modules where all the elements of a module are closely related. However, the elements of one module should not be closely related to the elements of another module. Such a relationship leads to tight coupling between modules. Ensuring high cohesion within modules is one way of reducing tight coupling between modules. Together with coupling, cohesion is one of the best measures of the quality of a design. Levels of Cohesion The different levels of cohesion are described below:

FUNCTIONAL COHESION
Description of Functional Cohesion Functional cohesion is when parts of a module are grouped because they all contribute to a single well-defined task of the module. A functionally cohesive module performs one and only one problem related task. Examples of functionally cohesive modules are: Drag Drop an event triggered when a dragged object is dropped on a window, Sum Elements in Array, Convert Kilometers to Miles, Read Customer Record, Calculate Net Pay, Assign Account Number. Functionally cohesive modules may be simple and perform one task, such as Read Customer Record. However, a complex module with numerous sub modules may still be functionally cohesive if all of its subordinate modules are only performed to carry out the task of the parent module. For example, Calculate Net Pay is functionally cohesive although it contains many different functions (e.g., calculate taxable deductions, calculate tax, and calculate CPP deduction). Often, functionally cohesive modules are low-level modules on a Structure Chart. Strengths of Functional Cohesion

Strengths of functional cohesion are:

Functionally cohesive modules are good candidates for re-use, Systems built with functionally cohesive modules are easily understood and, therefore,

easier to maintain. Weakness of Functional Cohesion One weakness of functional cohesion is: Designers should guard against designing over-simplified modules or methods. If functional cohesion is taken too far in structured design, the system design consists of hundreds of modules comprised of two or three lines of code.

INFORMATIONAL COHESION
Description
A module has informational cohesion, if it performs number of actions each with its own entry

point, with independent code for each action, all performed on the same data structure. Ex: C++ class works at this level where well designed objects are modules with informational cohesion Strengths of Informational Cohesion Reduces maintenance cost as it allows changes in a module implementation without changing its usage. It corresponds to the definition of an ADT (abstract data type) or object in anobjectoriented language.

SEQUENTIAL COHESION
Description of Sequential Cohesion Sequential cohesion is when parts of a module are grouped because the output from one part is the input to another part like an assembly line (e.g. a function which reads data from a file and processes the data). A sequentially cohesive module contains activities where output data from one activity serves as input data to the next activity. Examples of activities in a sequentially cohesive module are: retrieve customer, retrieve customer order, and generate invoice, Get and edit input data. Strength of Sequential Cohesion In general, a sequentially cohesive module: has good coupling, Is easy to maintain.

Weakness of Sequential Cohesion Sequentially cohesive modules are not as good candidates for re-use as are functionally cohesive modules. This is because the activities contained within the sequentially cohesive module generally only meet the requirements of that one module.

COMMUNICATIONAL COHESION
Description of Communicational Cohesion Communicational cohesion is when parts of a module are grouped because they operate on the same data (e.g. a module which operates on the same record of information). A communicational cohesive module is one which performs several functions on the same input or output data. For example, obtain author, title, or price of book from bibliographic record, based on a passed flag. (Note: The functions in this example could be performed independently of each other and should be separated for greater flexibility. Maintainability is usually improved when you separate a communicational cohesive module into functionally cohesive modules.) Strengths of Communicational Cohesion Strengths of communicational cohesion are: Communicational cohesion is an acceptable level of cohesion although it is not as good as functional or sequential cohesion. Communicational cohesive modules are easy to maintain. Weaknesses of Communicational Cohesion The drawbacks of communicational cohesive modules are: Other modules may require only part of the input or output data of the communicational cohesive module, making the unnecessary data redundant. The designer must decide whether to discard the redundant data or create a second module passing only the necessary data. But creating a second module causes duplication of code, making maintenance more difficult. It is easier to share code within a communicational cohesive module. This may make it more difficult to make changes in one part of the code without affecting the functionality of another part of the code. Comparison of Communicational and Sequentially Cohesive Modules Communicational cohesive modules and sequentially cohesive modules are similar in many respects. Both types of modules are designed around the data they use. Both are loosely coupled because their elements are not related to elements in other modules. The difference between the two types of modules is the order of execution of the activities within the modules. Activities within a sequentially cohesive module must be carried out in a specific order. One activity cannot be completed until another activity is done. But in a communicational cohesive module, the order of the execution of activities is not important.

PROCEDURAL COHESION
Description of Procedural Cohesion Procedural cohesion is when parts of a module are grouped because they always follow a certain sequence of execution (e.g. a function which checks file permissions and then opens the file). A procedurally cohesive module performs several different and possibly unrelated activities in which control flows from each activity within the module to the next, (i.e., the activities make up part of some function). Activities in a procedurally cohesive module are related by flow of execution rather than by one problem-related function. They often contain a group of functions which make up part of a larger function, but as a group perform no real function. Procedural cohesion may result from an attempt to modularize some part of a flow chart. For example, a procedurally cohesive module may: write record B, read record A, Format A for printing. It is common in a procedurally cohesive module for the input and output data to be unrelated. It is also common for such a module to pass around partially edited data, switches, or flags. For example, a procedurally cohesive module may only initialize alphanumeric fields of an input record before returning the input record. Weaknesses of Procedural Cohesion Weaknesses of procedural cohesion are: Because a procedurally cohesive module performs no real function in itself, it is generally not a black box and not re-usable. Procedurally cohesive modules are not as easily maintained as the modules using the high and middle levels of cohesion.

TEMPORAL COHESION
Description of Temporal Cohesion Temporal cohesion is when parts of a module are grouped by when they are processed - the parts are processed at a particular time in program execution (e.g. a function which is called after catching an exception which closes open files, creates an error log, and notifies the user). A temporally cohesive module is one which performs several activities that are related in time. One of the most common examples of a temporally cohesive module is an initialization routine that initializes data used by many modules throughout a system. Like procedurally cohesive modules, temporally cohesive modules typically consist of partial activities whose only relationship to one another is that they are all carried out at a specific time. Weaknesses of Temporal Cohesion

A temporally cohesive module has several drawbacks: Often the activities in a temporally cohesive module are more closely related to other modules than they are to each other. This type of cohesion also results in tight coupling of data. It makes maintenance of a system more difficult. For example, if a module requires only one piece of data to be initialized, it cannot call the global initialization routine because that would reset data for the entire system. Instead, the developer has to decide whether to remove the initialization code for the data it wants initialized to create a separate initialization routine or to pass a parameter to the initialization routine indicating the piece of data that is to be initialized. In either case, the existing code that invokes the initialization routine must be modified. A better approach would have been to separate the temporally cohesive initialization routine into functionally cohesive modules that initialize related data. Maintenance is made more difficult because often the developer is tempted to share code among activities within the module that are only related in time. As with procedurally cohesive modules, changes made to one activity may affect another activity. It is more difficult to re-use a temporally cohesive module. Comparison of Temporally and Procedurally Cohesive Modules Temporally cohesive modules are similar to procedurally cohesive modules. Both make poor black boxes because their functionality cannot be stated simply without knowing the internals of the modules. Coupling in both types of modules tends to be poor. They differ in the order of execution of activities. The order of execution is important in procedurally cohesive modules. It is not important in temporally cohesive modules. Also, temporally cohesive modules usually contain sequential statements while procedurally cohesive modules often share repetitions and conditions between activities.

LOGICAL COHESION
Description of Logical Cohesion Logical cohesion is when parts of a module are grouped because they logically are categorized to do the same thing, even if they are different by nature (e.g. grouping all mouse and keyboard input handling routines). A logically cohesive module performs several activities of the same general category in which the activity or activities to be executed are selected by the invoking module. The activities within the module are all different. They are only related because they share the same interface to the module. The generalized module is passed a switch to indicate which activity to perform. Parameters may be empty depending on the activity being executed. An example of a logically cohesive module is a general I/O routine which reads, writes, or deletes various combinations of records, depending on the value of a control flag. Control flags are often an indication that a module is logically cohesive. Weaknesses of Logical Cohesion Weaknesses of logical cohesion are:

 Logically cohesive modules are difficult to maintain. Often, programmers end up sharing

related code.
They are also poor candidates for re-use.

COINCIDENTAL COHESION
Description of Coincidental Cohesion Coincidental cohesion is when parts of a module are grouped arbitrarily i.e the only relationship between the parts is that they have been grouped together (e.g. a Utilities class). A coincidentally cohesive module is one whose activities have no meaningful relationship to one another. An example of a module using coincidental cohesion is one which performs various functions such as computing net pay, calculating inventory reorder amount or generating an invoice depending on the value of the parameters passed to the module. Weaknesses Coincidental Cohesion Weaknesses of coincidental cohesion are: Coincidental cohesion is considered the worst level of cohesion. Its activities are not related by flow of data or by flow of control. It is even less cohesive than a logically cohesive module because its activities are not even in the same category. Coincidental cohesion is very difficult to maintain. Both logical and coincidental cohesion require the programmer to know the internal details of the modules.