CPSC 333: Levels of Coupling

Location: [CPSC 333] [Listing by Topic] [Listing by Date] [Previous Topic] [Next Topic] Levels of Coupling


This material was covered during lectures on February 28, 1997.


Page-Jones cites a set of ``principles'' that he adapts from Yourdon and Constantine's work on structured design. These principles refer to the kind of connections between modules that are desirable:

  1. Create narrow (as opposed to broad) connections.
  2. Create direct (as opposed to indirect) connections.
  3. Create local (as opposed to remote) connections.
  4. Create obvious (as opposed to obscure) connections.
  5. Create flexible (as opposed to rigid) connections.

Sets (usually, pairs) of modules have connections that follow these principles if their level of coupling is low, and violate these principles if their level of coupling is high.

As for levels of cohesion, you can estimate the level of coupling for a set of modules by considering each of the ``kinds'' of coupling listed below, one at a time. It's not important that you determine the precise level of coupling for a given set of modules - but it is important to decide whether this is ``unnacceptably high,'' ``high but unavoidable,'' ``acceptable,'' or ``ideal.''

Highest Coupling

The following extremely high level of coupling should not be allowed (at least, not at this stage in software development) under any circumstances.

Content Coupling

Two (or more) modules exhibit content coupling if one refers to the ``inside'' - the ``internal'' or ``private'' part - of the other in some way. Pages-Jones gives the following examples:

Page-Jones also calls this ``Pathological Coupling'' - and it could said with some justification that the above examples do involve ``sick programming practices.''

Fortunately, high level programming languages make these difficult - though you can certainly do these things using assembly languages (or C).

``Optimization'' is sometimes cited as an excuse for these. This is the only plausible excuse for these I can think of - you might consider resorting to some of these only after every other sensible strategy has failed to produce a program that meets the system's performance requirements (long after you've reimplemented critical sections, used hardware components instead of software where possible, etc.)

However, optimization is often unnecessary, and there are less troublesome things you can to do to improve program efficiency. Since the above practices make proper testing difficult, and program maintenance almost impossible, programming practices that introduce ``content coupling'' should be regarded as a last resort (and ideally, never be used).

High Coupling

These levels of coupling are undesirable, but may also be unavoidable. You should try to minimize the use of these, and use ``information hiding'' - developing and using well-defined interfaces - to limit the effects of these.

Common Coupling

Two or more modules exhibit common coupling if they refer to the same global data area - that is, to something that corresponds to a data store on a DFD or a ``register'' that must be shared by several processes.

External Coupling

Two or more modules exhibit external coupling if they share direct access to the same I/O device or are ``tied to the same part of the environment external to software'' in some other way.

Moderate Coupling

This level of coupling is perfectly acceptable.

Control Coupling

Two modules exhibit control coupling if one (``module A'') passes to the other (``module B'') a piece of information that is intended to control the internal logic of the other. This will often be a value used in a test for a case statement, if-then statement, or while loop, in module B's source code.

This is perfectly acceptable. However, the program architecture (as shown by the structure chart) should make it clear that module A does control module B in this way - preferably by having module A call module B directly, or vice-versa. Then, when the system is combined together (``integrated'') and tested, the two modules will be combined together, and tested as one unit, relatively early in the process - so that any problems arising from this ``control coupling'' will be detected early on.

Low Coupling

Page-Jones calls this ``Normal Coupling,'' and it's the most desirable kind of ``coupling'' of modules, if they're to be connected at all.

Stamp Coupling

This is a special case (or extension) of data coupling, so you may want to skip down and read about that first.

Two modules (``A'' and ``B'') exhibit stamp coupling if one passes directly to the other a ``composite'' piece of data - that is, a piece of data with meaningful internal structure - such as a record (or structure), array, or (pointer to) a list or tree.

Data Coupling

Two modules exhibit data coupling if one calls the other directly and they communicate using ``parameters'' - a simple list of inputs and outputs (and inputs that are modified) --- with each parameter being an ``elementary'' piece of data, such as an integer, floating point number, boolean value, member of an enumerated set, character, or (maybe) character string. The modules exhibit stamp coupling if ``composite'' data types are used for parameters as well.

Ideally, this (``data coupling'') is the usual type of interaction between modules that need to communicate at all: Modules with higher levels of coupling this are only used ``when necessary.''

Lowest Level of Coupling

Modules A and B have the lowest possible level of coupling - no coupling at all - if they have no direct communication and are also not ``tied together'' by shared access to the same global data area or external device.

This is the ideal situation, because it implies that A and B be implemented, tested, and maintained (almost) completely independently; neither will affect the behaviour of the other

Of course, it is necessary to have some communication among modules in any nontrivial system.

Reference

Once again, Page-Jones' book, The Practical Guide to Structured Systems Design, is highly recommended as a reference for more information about levels of coupling.

Location: [CPSC 333] [Listing by Topic] [Listing by Date] [Previous Topic] [Next Topic] Levels of Coupling


Department of Computer Science
University of Calgary

Office: (403) 220-5073
Fax: (403) 284-4707

eberly@cpsc.ucalgary.ca