Question

Define what is coupling and cohesion. From the design perspective, what should be the goals with regard to coupling and cohesion? Explain with your own examples highlighting the difference between them

Answer 1

Coupling: Coupling is the measure of the degree of interdependence between the modules. A good software will have low coupling.

Types of Coupling:

• Data Coupling: If the dependency between the modules is based on the fact that they communicate by passing only data, then the modules are said to be data coupled. In data coupling, the components are independent to each other and communicating through data. Module communications don’t contain tramp data. Example-customer billing system.
• Stamp Coupling In stamp coupling, the complete data structure is passed from one module to another module. Therefore, it involves tramp data. It may be necessary due to efficiency factors- this choice made by the insightful designer, not a lazy programmer.
• Control Coupling: If the modules communicate by passing control information, then they are said to be control coupled. It can be bad if parameters indicate completely different behavior and good if parameters allow factoring and reuse of functionality. Example- sort function that takes comparison function as an argument.
• External Coupling: In external coupling, the modules depend on other modules, external to the software being developed or to a particular type of hardware. Ex- protocol, external file, device format, etc.
• Common Coupling: The modules have shared data such as global data structures.The changes in global data mean tracing back to all modules which access that data to evaluate the effect of the change. So it has got disadvantages like difficulty in reusing modules, reduced ability to control data accesses and reduced maintainability.
• Content Coupling: In a content coupling, one module can modify the data of another module or control flow is passed from one module to the other module. This is the worst form of coupling and should be avoided.

Cohesion: Cohesion is a measure of the degree to which the elements of the module are functionally related. It is the degree to which all elements directed towards performing a single task are contained in the component. Basically, cohesion is the internal glue that keeps the module together. A good software design will have high cohesion.

• Functional Cohesion: Every essential element for a single computation is contained in the component. A functional cohesion performs the task and functions. It is an ideal situation.
• Sequential Cohesion: An element outputs some data that becomes the input for other element, i.e., data flow between the parts. It occurs naturally in functional programming languages.
• Communicational Cohesion: Two elements operate on the same input data or contribute towards the same output data. Example- update record int the database and send it to the printer.
• Procedural Cohesion: Elements of procedural cohesion ensure the order of execution. Actions are still weakly connected and unlikely to be reusable. Ex- calculate student GPA, print student record, calculate cumulative GPA, print cumulative GPA.
• Temporal Cohesion: The elements are related by their timing involved. A module connected with temporal cohesion all the tasks must be executed in the same time-span. This cohesion contains the code for initializing all the parts of the system. Lots of different activities occur, all at init time.
• Logical Cohesion: The elements are logically related and not functionally. Ex- A component reads inputs from tape, disk, and network. All the code for these functions is in the same component. Operations are related, but the functions are significantly different.
• Coincidental Cohesion: The elements are not related(unrelated). The elements have no conceptual relationship other than location in source code. It is accidental and the worst form of cohesion. Ex- print next line and reverse the characters of a string in a single component.

Coupling and Cohesion: A View from the Software Designer Perspective:

Software development is time-consuming and expensive.   Under the best circumstances, one goes from an idea to requirements, design, coding, testing, deployment, and then a maintenance phase.   This is, more or less, the classic software development model. Of course, changing requirements can throw off this entire process. EHR vendors are experiencing this first-hand due to changing MU requirements. The threat of obsolescence due to changes in computing technology may also result in new requirements that alter software development cycles.

Consider how much computing has changed since 2000.   In 2000, the Internet was just beginning to come into its own, and LAN-based client/server was still the next big thing.   Creating a complex web application such as a content management system was expensive, and the tools to do so were not that great. Java was five years old, Rails was four years in the future, and .Net was still two years away.     Look at how much things have changed in just 12 years. Mobile computing is a fact of life; anybody with a web hosting account can launch a content management system-based website; and the cloud and multi-processing are coming to the forefront of software development.

Coupling
Coupling is defined as the degree of interdependence between two or more classes, modules, or components. Tight coupling is bad, and loose coupling is good.   This will make more sense with an example.

Let’s say we have a clinical research application that contains a patient information collection form. On this form is a field for the SSN. Whenever a patient enrolls in a study, the form checks the SNN to see whether: 1) it is a valid SSN (i.e., fits the pattern 000-00-0000), and 2) the patient has been a subject in prior studies. In the current version of the application, when the cursor leaves the SSN field, the following procedure runs.

Procedure SSN Check
Begin
If is_Number(Left_Three_Chars)
Then
Result=0
Else
Result =1

If is_Number(Middle_Two_Chars)
Then
Result=0
Else
Result =1

If is_Number(Right_Three_Chars)
Then
Result=0
Else
Result =1

If Result=0
Then
Count = “SELECT SSN
FROM patients
WHERE SocNum=SSN”
Else
Print “This is not a valid SSN”

End

This procedure checks whether each part of the SSN is a number, and if everything is okay, it searches for the SNN in the patients table and returns 1 if the patient has been in a prior study.   This type of code is easy (and tempting) to write in form-based development environments. Why is it bad? The Count query makes a direct call to the database. As a result, the SSN text field is tied directly to the database, exhibiting tight coupling. With one form, this is not a huge problem. However, if the application has multiple forms and more than one requires SSN verification, it might become a headache if the form changes, the database changes, or the query is altered. Any of these situations could prove to be costly and messy because developers would have to find every place in the application where a SSN check occurred, change the programming code, and test the final application.

Cohesion
Cohesion is defined as the degree to which all elements of a module, class, or component work together as a functional unit. High cohesion is good, and low cohesion is bad. The ideal situation is one where a module, class, or component provides only one function or, at most, a very closely related set of functions.    Looking at the above procedure, we see that it performs two functions. It validates SSNs, and it performs a database query. These are completely unrelated actions and, thus, the procedure exhibits low cohesion.

Improving the Design
Moving unrelated functions into their own units (i.e., module, class, or component) would be a good first-step in improving the design.   One solution would be creating a data access module then placing all database queries for the entire application in one location. Consequently, forms would no longer have to know anything about the database–or even that it exists.   Next, we could do the same with validation. Since any real-world application is likely to require validation for a range of form fields (e.g., birthdates, duplicate names, vital signs, etc.) it makes sense to have one component that handles validation as well.

Here is the SSN Check procedure after Validation and Data Access modules have been created.

Procedure SSN Check
Begin
Result =Validate (SSN)
If Result=0
Then
Count=Database_look_up(SSN)
Else
Print “This is not a valid SSN”

End

The new version of the SSN Check procedure merely passes information to functions in the Validation and Data Access modules. This procedure is now oblivious as to how validation is performed as well as how SSN numbers are stored.   Further, new functions can be added to either module without affecting the SSN Check procedure.   The form is now loosely coupled to the database, and the two new components are highly cohesive, each providing a single or closely-related set of functions.