Introduction to Modules: Cohesion and Coupling

1. July 17th, 2000 Chapter 6: Introduction To Objects • 6.1 What Is A Module? • 6.2 Cohesion • 6.3 Coupling • 6.4 Data Encapsulation • 6.5 Abstract Data Types • 6.6 Information hiding • 6.7 Objects • 6.8 Inheritance, Ploymorphism, and Dynamic Binding • 6.9 Cohesion and Coupling of Objects

2. What Is A Module? • A set of one or more contiguous program statements having a name by which other parts of the system can invoke it, and preferably having its own distinct set of variable names [Stevens, Myers, and Constantine, 1974] • COBOL paragraph and section () • C/C++ header file (x) • Ada package and generic (x) • Assembler macro (x) • A module is a lexically contiguous sequence of program statements, bounded by boundary elements, having an aggregate identifier [Yourdon and Constantine, 1979] • begin … end - Pascal, Ada • { … } - C/C++, Java • An object is a module and so is a method within an object

3. What Is A Module? (2) • The action of a module is what it does, that is, its behavior • The action of a module m is to compute the square root of its argument • The logic of a module is how the module performs its action • Newton’s method • The context of a module is the specific usage of that module • m is asked to compute the square root of a double precision integer • The name assigned to a module is its action, not its logic or its context • m should be named as compute square root

4. Cohesion • The degree of interaction WITHIN a module • Meyers defined seven levels of cohesion • Coincidental • Logical • Temporal • Procedural • Communicational • Informational • Functional

5. Cohesion (2) • Coincidental cohesion • A module performs multiple completely unrelated actions • Example • Print next line, reverse the string of characters comprising the second argument, add 7 to the fifth argument, convert the fourth argument to floating number • How can such modules possibly arise in practice? • Drawbacks • Degrade the maintainability of the product • These modules are not reusable

6. Cohesion (3) • Logical cohesion • A module performs a series of related actions, one of which is selected by the calling module • Example function code = 7 new operation (function code, dummy 1, dummy 2, dummy3) • Problems • The interface is difficult to understand; the comprehensibility of the module as a whole degrades • The code for more than one action may be intertwined, leading to severe maintenance problems • Difficult to reuse such a module in other products • Example - Figure 6.5

7. Cohesion (4) • Temporal cohesion • A module performs a series of actions related in time • The actions of this module are weakly related to one another, but are more strongly related to actions in other modules • Example • open master file, new master file, transaction file, and initialize sales region table, read first transaction record ... • initialize sales region table • update sales region table • print sales region table • Problems • Change impact (a few other modules will be affected; regression fault) • Unlikely to be reusable in a different product

8. Cohesion (5) • Procedural cohesion • A module performs a series of actions related by the sequence of steps to be followed by the product • Example • “read part number from database” and “update repair record on maintenance file” • Problems • The actions of this module are still weakly connected • Unlikely to be reusable in a different product • Break up the module with procedural cohesion into separate modules each performing one action

9. Cohesion (6) • Communicational cohesion • A module performs a series of actions related by the sequence of steps to be followed by the product and all the actions are performed on the same data • Example • “update record in database” and “write it to the audit trail” • “calculate new trajectory” and “send it to the printer” • Problems • Cannot be reused

10. Cohesion (7) • Informational cohesion • A module performs a number of actions, each with its own entry point, with independent code for each action, all performed on the same data structure • Example - Figure 6.6 • What is the difference between “logical cohesion” and “informational cohesion”? • A module with informational cohesion is essentially an implementation of an abstract data type (will be explained in Section 6.5) • Informational cohesion is optimal for the object-oriented paradigm

11. Cohesion (8) • Functional cohesion • A module performs exactly one action or achieves a single goal • Example • get temperature of furnace; compute orbital of electron; write to diskette; calculate sales commission • Advantages • A “properly designed, thoroughly tested, and well-documented” module with functional cohesion can often be reused • Maintenance is easier • Easy to locate faults • Easy to correct (because the module is easier to understand) • Change impact is slight • Easy to extend - write to hard drive changed to write to larger hard drive

12. Coupling • The degree of interaction between two modules • Levels of coupling • Content coupling • Common coupling • Control coupling • Stamp coupling • Data coupling

13. Coupling (2) • Content coupling • Two modules are content-coupled if one directly references the contents of the other • Examples • Module P modifies a statement of module Q • Module P refers to local data of module Q in terms of some numerical displacement within Q • Module P branches to a local label of module Q • Problems • Any changes to Q requires a change to P • Impossible to reuse P without reusing Q

14. Coupling (3) • Common coupling • Two modules are common-coupled if they both have access (write) to the same global data • Example - Figure 6.9 • FORTRAN common statement (COBOL); COBOL-80’s global statement; C++/Java’s modifier public • Why common coupling is undesirable? • Unreadable code (contradicts the spirit of structured programming) • Figure 6.10 (Determining under what conditions the while loop terminates is a nontrivial question) • Side effects (might change other global variables) - need to examine the entire module to find out precisely what it does • edit this transaction(record 7) • Change impact (any changes to the declaration of the global variable will affect other modules that access the global variable) • Difficult to reuse • Unauthorized access to the data

15. Coupling (4) • Under what situations where “common coupling” is a preferable alternative? • When the use of a central database is not available • Employ a module to initialize the global data and do not allow all other modules to update the global data • A better solution to obviate common coupling is to use information hiding (will be discussed in Section 6.6)

16. Coupling (5) • Control coupling • Two modules are control-coupled if one pass an element of control to the other module, that is, one module explicitly controls the logic of the other • Example • If module p class module q, and q passes back a flag to p that says, “ I am unable to complete my task,” then q is passing data. But if the flag means, “I am unable to complete my task; accordingly, write error message ABC123,” then p and q are control coupled. • Problems • The called module has to be aware of the internal structure and logic of the calling module • Even worse if associated with modules with logical cohesion

17. Coupling (6) • Stamp coupling • Two modules are stamp-coupled if a data structure is passed as an argument, but the called module operates on only some of the individual components of that data structure • Difficult to understand and to be reusable • When a pointer to a data structure is passed, stamp coupling could also happen if only some of the components of that data structure are operated on by the called module

18. Coupling (7) • Data coupling • Two modules are data-coupled if all arguments are homogeneous data items. • Every argument is either a simple argument or a data structure in which all elements are used by the called module • The problems of content, common, control, and stamp coupling are not present • Coupling example • Figure 6.11, 6.12, and 6.13 • Importance of coupling • Maintenance (fault detection and correction) • Reuse