5.5 Cohesion

Partitioning system & how clearly modules are separated from one another is called coupling. Cohesion is how activities within a single module are related to one another. These two are important for measuring partitioning & interdependent.

Designers should create strong, highly cohesive modules that is the elements of one module should not be strongly related to another module. Here are some characteristics of good & bad cohesion:

• Functional cohesion

Functionally cohesive module contains elements that all contribute to the execution of one and only one problem-related task e.g. read transaction record. Another example is calculate net employee salary which is a very complicated module and has may sub-functions but if you can sum up everything it accomplishes as one problem related function, then it’s functionally cohesive.

However there are many jobs that cannot be summed up as a single problem-related function. In this case the level of cohesion depends on how different activities are related to one another. Functional cohesion is the easiest and cheapest type of cohesion.

• Sequential cohesion

Sequentially cohesive modules are those with elements involved in activities that output from one activity serves as input to the next. Advantage of sequential cohesion is good coupling on the other hand not being able to re-use it can be seen as disadvantage. Not to mention that the order of carrying out activities are important in sequentially cohesive modules and more importantly just data flow from one module to another not the control.

• Communicational cohesion

Refers to cohesion between modules which use same input or output. The problem of communicational cohesion is the temptation to share code among activities within that module as result change in part will destroy other parts of module.

• Procedural cohesion

Higher level of cohesion where elements of modules are involved in different and possibly unrelated activities in which control flow from each activity to the next. In this kind of cohesion, control flows from one module to another. These kinds of modules are composed of functions that have little relationship to one another.

• Temporal cohesion

Modules with elements that are involved in activities that are related in time but activities may have no relationship among themselves.

• Logical cohesion

Modules which their elements contribute to activities of same general category in which activities to be executed are selected from outside the module. So in this kind of modules there should be a specific thing which is shared among all of them.

• Coincidental cohesion

Modules those their elements contribute to activities with no meaningful relationship to one another so it’s a bit similar to logically cohesive modules. Activities here are related neither by flow of data nor by flow of control.

There are different ways to determine level of cohesion of a module; one way is to write a short sentence that accurately, honestly, and fully names modules and their functions. These sentences will reveal the level of cohesion among modules. Another way is by drawing decision tree