CSC/ECE 517 Fall 2007/wiki2 7 an

Cohesion and coupling. Cohesion and coupling are concepts that are reasonably easy to understand, but nonetheless, it is challenging to find good examples that are succinct. Browse the hundreds of Web pages that attempt to explain these concepts, picking your favorite examples. Many of these pages mention related concepts; list some of them and explain how they relate to cohesion and coupling. Be sure to mention the metrics that can be used to measure how well a program conforms to the principles of high cohesion and low coupling.

What is coupling?

Coupling is the degree to which each program module relies on each one of the other modules. Unnecessary object coupling needlessly decreases the reusability of the coupled objects and also increases the chances of system corruption when changes are made to one or more of the coupled objects.

Thus the design goal is to minimize coupling and improve reusability. Coupling is broadly divided into two types-low coupling and high coupling. Low coupling refers to a relationship in which one module interacts with another module through a stable interface and does not need to be concerned with the other module's internal implementation With low coupling, a change in one module will not require a change in the implementation of another module. Low coupling is often a sign of a well-structured computer system, and when combined with high cohesion, supports the general goals of high readability and maintainability.

On the other hand, systems with high coupling face the following problems

• Change in one module forces a ripple of changes in other modules.

• Modules are difficult to understand in isolation.

• Modules are difficult to reuse or test because dependent modules must be included.

Thus it is evident that low coupling tends to produce reusable methods. But it is also not possible to write completely decoupled methods since the program will not work.

Examples of coupling

High coupling

A perfect example of high coupling is the human body. Every organ can be considered as an independent module which is intricately dependent on many other organs for its functioning. An irregularity in the working or performance of any organ affects almost the entire body. Thus the modules can be considered to be tightly coupled in this case. A direct consequence of this high coupling is that reuse of modules is extremely difficult. Imagine doing a liver transplant without having to worry about organ rejection!!! This is unfortunately not possible due to the highly coupled nature of the human body.

Low coupling

An example of a low coupled system is the modern plumbing system. Almost every part of the system can be replaced with ease since the modules hardly depend on each other.

Types of coupling

Content coupling

In this type of coupling, one module modifies or relies on the working of another module. Therefore any change in the second module leads to a change in the working of the dependent module. An example of this type of coupling would be case in which one module refers to some data in another module by a fixed offset. Thus as the data in the module changes the value accessed by the dependent module also changes.

Content coupling is bad and should be avoided. The reasons are

• Changes in the called module may require corresponding changes in the calling module too.

• Since the two modules are inextricably linked, it is not possible too reuse the calling module without including the called module.

Common coupling

In this type of coupling, two modules share the same global data. Here again, changing one module requires changing the other. Reusability is also reduced. There are also security concerns in the sense that a malicious module may adversely manipulate global data which can affect the entire design. Coupling between modules c, g and k represents this type of coupling.

Control coupling

As the name suggests, one module can control the decisions made by another module. This is usually done by passing the controlling information from one module to another. An example would be a module that prints a name in either upper or lower case, the decision of which is taken by another module which passes a control flag (0 or 1) to the first module. For this type of coupling to work efficiently, one module must know the internal logic and structure of another module. Coupling between modules d and e represents this type of coupling.

Stamp coupling

This type of coupling is also known as data structured coupling since modules share a composite data structure but use only a part of it. Thus it becomes harder to understand what the individual modules do and makes it easier for the modules to accidentally mess up with the data. This can also lead to malicious data modification. An example would be passing a partially used data structure between modules by means of a pointer in C. Coupling between modules b and a represents this type of coupling.

Data coupling

This is the best type of coupling in which modules share data through parameters. As a result, modules only communicate data which is used between them. Thus changes in one module are less likely to affect the other module, leading to better maintenance. Coupling between modules a and c represents this type of coupling.

What is cohesion?

Cohesion is the measure of the strength of functional relatedness of elements within a module. Cohesion can also be defined as the degree of interaction within a module since it describes how well the contents of a module cohere. A cohesive module performs a single task within a software procedure, requiring little interaction with procedures being performed in other parts of a program. Stated simply, a cohesive module should (ideally) do just one thing. Cohesion is also broadly divided into two types- high cohesion and low cohesion. Modules with high cohesion are desirable because they support code reuse, maintenance and design change. Modules with low cohesion on the other hand, are difficult to test, maintain, reuse and even difficult to understand.

Examples of cohesion

Low cohesion

Consider a temperature measurement system for a piece of machinery. The concerned module has the following tasks

• Initiate periodic measurement of temperature

• Compare measured temperature with optimum values

• Produce an error report in case of discrepancy and subsequently notifies the user

• Update the report in the database

• Take necessary action like turning on the cooling system etc

Although the above tasks are loosely related, each is an independent functional entity that might best be performed as a separate module. Combining the functions into a single module can serve only to increase the likelihood of error propagation when a modification is made to one of its processing tasks.

High cohesion

An example of high cohesion is a module which is dedicated to perform just one task. In the above example, if each of the functional entities are served by an independent module, the system would be described as a highly cohesive system.

Types of cohesion

Coincidental cohesion

This is the worst type of cohesion and should be avoided. Coincidental cohesion is when the activities of a module are related neither by data nor by flow of control. It may seem like the parts of a module have no significant relationship and are randomly grouped. An example would be a module which multiplies two numbers and prints out the string hello! It has low reusability, low maintainability and in order to fix a module it is necessary to break it up into smaller, independent modules.

Logical cohesion

A logically cohesive module contains a number of activities of the same general kind. Thus parts of a module are grouped because they logically are categorized to do the same thing, even if they are different by nature. The activities, although different, are forced to share the one and only interface to the module. The resulting module is neither easy to understand nor to maintain.

Temporal cohesion

A temporally cohesive module is one whose elements are involved in activities that are related in time. Temporally cohesive modules, like procedurally cohesive ones, tend to be composed of partial functions whose only relationship to one another is that they all happen to be carried out at a certain time. The activities are usually more closely related to activities in other modules than they are to one another, a situation that leads to tight coupling.

Procedural cohesion

Procedural cohesion is when parts of a module are grouped because they always follow a certain sequence of execution. They are composed of pieces of functions that have little relationship to one another except that they’re carried out in a specific order at a certain time. An example would be a module which accepts start and destination addresses and then calculates the shortest route between them.

Communicational cohesion

Communicational cohesion is when parts of a module are grouped because they operate on the same data. For example to find out some facts about a book we may wish to fond the title of the book, its author, price and publisher. These four activities operate on the same input data which makes the module communicationally cohesive.

Sequential cohesion

A sequentially cohesive module is one whose elements are involved in activities such that output data from one activity serves as input data to the next. Its structure is thus similar to an assembly line. An example would be of a module which reads data form a file, processes the data and displays the appropriate output.

Functional cohesion

This is the best type of cohesion with respect to maintainability. A functionally cohesive module contains elements that all contribute to the execution of one and only one problem-related task. An example would be a module which is dedicated to computing the cosine of a given angle