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
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
What Is A Module? (2)

The action of a module is what it does, that is, its behavior


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


The action of a module m is to compute the square root of its
argument
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
Cohesion

The degree of interaction WITHIN a module

Meyers defined seven levels of cohesion

Coincidental

Logical

Temporal

Procedural

Communicational

Informational

Functional
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
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
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
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
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
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
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 hard drive
write to hard drive
changed to
write to larger
Coupling

The degree of interaction between two modules

Levels of coupling

Content coupling

Common coupling

Control coupling

Stamp coupling

Data coupling
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
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
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)
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
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
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