The Full Wiki

Dependency (software): Wikis

Advertisements

Note: Many of our articles have direct quotes from sources you can cite, within the Wikipedia article! This article doesn't yet, but we're working on it! See more info or our list of citable articles.

Encyclopedia

(Redirected to Coupling (computer science) article)

From Wikipedia, the free encyclopedia

In computer science, coupling or dependency is the degree to which each program module relies on each one of the other modules.

Coupling is usually contrasted with cohesion. Low coupling often correlates with high cohesion, and vice versa. The software quality metrics of coupling and cohesion were invented by Larry Constantine, an original developer of Structured Design[1] who was also an early proponent of these concepts (see also SSADM). Low coupling is often a sign of a well-structured computer system and a good design, and when combined with high cohesion, supports the general goals of high readability and maintainability.

Contents

Types of coupling

Coupling can be "low" (also "loose" and "weak") or "high" (also "tight" and "strong"). Some types of coupling, in order of highest to lowest coupling, are as follows:

Content coupling (high)
Content coupling is when one module modifies or relies on the internal workings of another module (e.g. accessing local data of another module).
Therefore changing the way the second module produces data (location, type, timing) will lead to changing the dependent module.
Common coupling
Common coupling is when two modules share the same global data (e.g. a global variable).
Changing the shared resource implies changing all the modules using it.
External coupling
External coupling occurs when two modules share an externally imposed data format, communication protocol, or device interface.
Control coupling
Control coupling is one module controlling the flow of another, by passing it information on what to do (e.g. passing a what-to-do flag).
Stamp coupling (Data-structured coupling)
Stamp coupling is when modules share a composite data structure and use only a part of it, possibly a different part (e.g. passing a whole record to a function which only needs one field of it).
This may lead to changing the way a module reads a record because a field, which the module doesn't need, has been modified.
Data coupling
Data coupling is when modules share data through, for example, parameters. Each datum is an elementary piece, and these are the only data which are shared (e.g. passing an integer to a function which computes a square root).
Message coupling (low)
This is the loosest type of coupling. Modules are not dependent on each other, instead they use a public interface to exchange parameter-less messages (or events, see Message passing).
No coupling
Modules do not communicate at all with one another.
Advertisements

Object-oriented programming

Subclass Coupling
Describes the relationship between a child and its parent. The child is connected to its parent, but the parent isn't connected to the child.
Temporal coupling
When two actions are bundled together into one module just because they happen to occur at the same time.

Advantages and disadvantages

Tightly coupled systems tend to exhibit the following developmental characteristics, which are often seen as disadvantages:

  1. A change in one module usually forces a ripple-effect of changes in other modules.
  2. Assembly of modules might require more effort and/or time due to the increased inter-module dependency.
  3. A particular module might be harder to reuse and/or test because dependent modules must be included.

Loosely coupled systems tend to exhibit the following developmental characteristics, which are often seen as advantages:

  1. A change in one module usually does not force a ripple-effect of changes in other modules.
  2. Assembly of modules might require less effort and/or time due to the decreased inter-module dependency.
  3. A particular module might be easier to reuse and/or test because dependent modules do not need to be included.

Performance issues

Whether loosely or tightly coupled, a system's performance is often reduced by message and parameter creation, transmission, translation and interpretation overhead. See event-driven programming

Message Creation Overhead and Performance
Since all messages and parameters need to possess particular meanings in order to be consumed (i.e., result in the intended logical flow within the receiver), they must be created with a particular meaning. Creating any sort of message requires overhead whether CPU or memory overhead. Creating a single integer value message (which might be a reference to a string, array or data structure) requires less overhead than creating a complicated message such as a SOAP message. Longer messages require more CPU and memory to produce. In order to optimize runtime performance, message length must be minimized and message meaning must be maximized.
Message Transmission Overhead and Performance
Since a message must be transmitted in full in order to have its full meaning, message transmission must be optimized. Longer messages require more CPU and memory to transmit and receive. Also, when necessary, receivers must reassemble a message into its original state in order to receive it in its entirety. Hence, in order to optimize runtime performance, message length must be minimized and message meaning must be maximized.
Message Translation Overhead and Performance
Message protocols and messages themselves often contain extra information (i.e., packet, structure, definition and language information). Hence, the receiver often needs to translate a message into a more refined form by removing extra characters and structure information and/or by converting values from one type to another. Any sort of translation increases CPU and/or memory overhead. In order to optimize runtime performance, message form and content must be reduced and refined to maximize its meaning and reduce translation.
Message Interpretation Overhead and Performance
All messages must be interpreted by the receiver. Simple messages such as integers might not need any additional processing in order to be interpreted. However, complex messages such as SOAP messages require a parser and a string transformer in order for them to exhibit their intended meanings. In order to optimize runtime performance, messages must be refined and reduced to minimize interpretation overhead.

Solutions

One approach to decreasing coupling is functional design, which seeks to limit the responsibilities of modules along functionality, coupling increases between two classes A and B if:

  • A has an attribute that refers to (is of type) B.
  • A calls on services of an object B.
  • A has a method which references B (via return type or parameter).
  • A is a subclass of (or implements) class B.

Low coupling refers to a relationship in which one module interacts with another module through a simple and stable interface and does not need to be concerned with the other module's internal implementation (see Information Hiding).

Systems such as CORBA or COM allow objects to communicate with each other without having to know anything about the other object's implementation. Both of these systems even allow for objects to communicate with objects written in other languages.

Module coupling

Coupling in Software Engineering[2] describes a version of metrics associated with this concept.

For data and control flow coupling:

  • di: number of input data parameters
  • ci: number of input control parameters
  • do: number of output data parameters
  • co: number of output control parameters

For global coupling:

  • gd: number of global variables used as data
  • gc: number of global variables used as control

For environmental coupling:

  • w: number of modules called (fan-out)
  • r: number of modules calling the module under consideration (fan-in)

Coupling(C) = 1 - \frac{1}{d_{i} + 2\times c_{i} + d_{o} + 2\times c_{o} + g_{d} + 2\times g_{c} + w + r}

Coupling(C) makes the value larger the more coupled the module is. This number ranges from approximately 0.66 (low coupling) to 1.0 (highly coupled)

For example, if a module has only a single input and output data parameter

C = 1 - \frac{1}{1+0+1+0+0+0+1+0} = 1 - \frac{1}{3} = 0.67

If a module has 5 input and output data parameters, an equal number of control parameters, and accesses 10 items of global data, with a fan-in of 3 and a fan-out of 4,

C = 1 - \frac{1}{5 + 2\times 5 + 5 + 2\times 5 + 10 + 0 + 3 + 4} = 0.98

See also

References

  1. ^ W. Stevens, G. Myers, L. Constantine, "Structured Design", IBM Systems Journal, 13 (2), 115-139, 1974.
  2. ^ Pressman, Roger S. Ph.D (1982). Software Engineering - A Practitioner's Approach - Fourth Edition. ISBN 0-07-052182-4

Advertisements






Got something to say? Make a comment.
Your name
Your email address
Message