COHESION AND COUPLING material

 

5.3 COHESION AND COUPLING

 

●      We have so far discussed that effective problem decomposition is an important characteristic of a good design.

●      Good module decomposition is indicated through high cohesion of the individual modules and low coupling of the modules with each other.

●      Cohesion is a measure of the functional strength of a module, whereas the coupling between two modules is a measure of the degree of interaction (or interdependence) between the two modules.

●      Coupling: Intuitively, we can think of coupling as follows.

 

●      Two modules are said to be highly coupled, if either of the following two situations arise:

●      If the function calls between two modules involve passing large chunks of shared data, the modules are tightly coupled

●      If the interactions occur through some shared data, then also we say that they are highly coupled.

●      If two modules either do not interact with each other at all or at best interact by passing no data or only a few primitive data items, they are said to have low coupling.

 

Cohesion:

●      To understand cohesion, let us first understand an analogy. Suppose you listened to a talk by some speaker. You would call the speech to be cohesive, if all the sentences of the speech played some role in giving the talk a single and focused theme.

●      we can extend this to a module in a design solution. When the functions of the module co-operate with each other for performing a single objective, then the module has good cohesion

●      If the functions of the module do very different things and do not co-operate with

each other to perform a single piece of work, then the module has very poor cohesion.

 

Functional independence

●      By the term functional independence, we mean that a module performs a

single task and needs very little interaction with other modules.

●      A module that is highly cohesive and also has low coupling with other modules is said to be functionally independent of the other modules.

●      Functional independence is a key to any good design primarily due to the

following advantages it offers:

 

Error isolation: Whenever an error exists in a module, functional independence reduces the chances of the error propagating to the other Modules.

Scope of reuse: Reuse of a module for the development of other applications becomes easier. The reasons for this is as follows. A functionally independent module performs some well-defined and precise task and the interfaces of the module with other modules are very few and simple

Understandability: When modules are functionally independent, complexity

of the design is greatly reduced. This is because of the fact that different

modules can be understood in isolation, since the modules are independent

of each other.

5.3.1 Classification of Cohesiveness

●      Cohesiveness of a module is the degree to which the different functions of the

module co-operate to work towards a single objective.

●      The different modules of a design can possess different degrees of freedom

●      The cohesiveness increases from coincidental to functional cohesion.

Coincidental cohesion: A module is said to have coincidental cohesion,

if it performs a set of tasks that relate to each other very loosely, if at

all. In this case, we can say that the module contains a random

collection of functions.

 

Logical cohesion: A module is said to be logically cohesive, if all

elements of the module perform similar operations, such as error

handling, data input, data output, etc

 

Temporal cohesion: When a module contains functions that are related by

the fact that these functions are executed in the same time span, then the

module is said to possess temporal cohesion

 

Procedural cohesion: A module is said to possess procedural cohesion, if

the set of functions of the module are executed one after the other, though

these functions may work towards entirely different purposes and operate on

very different data.

 

Communicational cohesion: A module is said to have communicational

cohesion, if all functions of the module refer to or update the same data

Structure.

 

Sequential cohesion: A module is said to possess sequential cohesion, if

the different functions of the module execute in a sequence, and the output

from one function is input to the next in the sequence.

 

Functional cohesion: A module is said to possess functional cohesion, if

different functions of the module co-operate to complete a single task. For

example, a module containing all the functions required to manage

employees’ pay-roll displays functional cohesion.

 

5.3.2 Classification of Coupling

●      The coupling between two modules indicates the degree of interdependence between them.

●      Intuitively, if two modules interchange large amounts of data, then they are highly interdependent or coupled. We can alternately state this concept as follows.

●      The degree of coupling between two modules depends on their interface complexity

●      The interface complexity is determined based on the number of parameters and the complexity of the parameters that are interchanged while one module invokes the functions of the other module

●      These different types of coupling, in increasing order of their severities have also been

 

Data coupling: Two modules are data coupled, if they communicate using an elementary data item that is passed as a parameter between the two, e.g. an integer, a float, a character, etc. This data item should be problem related and not used for control purposes.

Stamp coupling: Two modules are stamp coupled, if they communicate using a composite data item such as a record in PASCAL or a structure in C.

Control coupling: Control coupling exists between two modules, if data from one module is used to direct the order of instruction execution in another. An example of control coupling is a flag set in one module and tested in another module.

Common coupling: Two modules are common coupled, if they share some global data items.

Content coupling: Content coupling exists between two modules, if they share code. That is, a jump from one module into the code of another module can occur. Modern high-level programming languages such as C do not support such jumps across modules

 

●      The degree of coupling increases from data coupling to content coupling.

●      High coupling among modules not only makes a design solution difficult to understand and maintain, but it also increases development effort and also makes it very difficult to get these modules developed independently by different team members.

 

5.5 APPROACHES TO SOFTWARE DESIGN:

●      There are two fundamentally different approaches to software design that are in use today— function-oriented design, and object-oriented design.

●      Though these two design approaches are radically different, they are complementary rather than competing techniques

5.5.1 Function-oriented Design

 

The following are the salient features of the function-oriented design approach:

Top-down decomposition: A system, to start with, is viewed as a black box that provides certain services (also known as high-level functions) to the users of the system. In top-down decomposition, starting at a high-level view of the system, each high-level function is successively refined into more detailed functions.

Centralised system state: The system state can be defined as the values of certain data items that determine the response of the system to a user  action or external event.

 

 

 

 

5.5.2 Object-oriented Design

●      In the object-oriented design (OOD) approach, a system is viewed as being made up of a collection of objects (i.e. entities).

●      Each object is associated with a set of functions that are called its methods.

●      Each object contains its own data and is responsible for managing it.

●      The object-oriented design paradigm makes extensive use of the principles of abstraction and decomposition as explained below.

●      Objects decompose a system into functionally independent modules.

●       Objects can also be  considered as instances of abstract data types (ADTs)

Data abstraction: The principle of data abstraction implies that how data is exactly stored is abstracted away.

●      This means that any entity external to the object (that is, an instance of an ADT) would have no knowledge about how data is exactly stored, organized, and manipulated inside the object.

Data structure: A data structure is constructed from a collection of primitive data items.

Data type: A type is a programming language terminology that refers to anything that can be instantiated.

Let us examine the three main advantages of using ADTs in programs:

●      The data of objects are encapsulated within the methods.

●      The encapsulation principle is also known as data hiding.

●      The encapsulation principle requires that data can be accessed and manipulated only

through the methods supported by the object and not directly.

●      This localises the errors. The reason for this is as follows. No program element is allowed to change a data, except through invocation of one of the methods. So, any error can easily be traced to the code segment changing the value. That is, the method that changes a data item, making it erroneous can be easily identified.

●      An ADT-based design displays high cohesion and low coupling. Therefore, object- oriented designs are highly modular.

●      Since the principle of abstraction is used, it makes the design solution easily understandable and helps to manage complexity