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

• Initiates periodic measurement of temperature

• Compares measured temperature with optimum values

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

• Updates the report in the database

• Takes necessary action like turning on the cooling system etc

Although the preceding 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.