Cohesion, Coupling and SOA
Bragging Rights on Coupling
AOP: The Worst Form of Coupling
Binding and Coupling
Subroutine Call Coupling
Seven Levels of Coupling or Seven Deadly Sins?
Coupling with Contracts
In the first posting of this series I went back to the origins of the coupling term that was coined by Edward Yourdan to explain good programming practice in terms of subroutines. I then tried to come up with a list of coupling types which would help explain what were good and bad form of coupling.
This served to clarify the concept in my mind but the list of coupling types is not exhaustive and term 'coupling' is still not clearly defined. Coupling is a measure, usually described as 'loose' and 'tight' which correspond to the value judgement of 'bad' and 'good' respectively.
A good measure has numbers that describe it, but this is not yet the case with coupling. I and other authors have attempted to rank coupling types in order of merit with the ranking an implicit measure of coupling.
There have been attempts to measure coupling by looking at program artefacts like variable names and measuring how many times they are referenced. These attempts seem to miss the point by measuring what can be measured rather measuring coupling properly. Some of these approaches are described in footnote 1.
In this posting I try to suggest some definitions relating to coupling. This will not come up with useful numbers but it will try to explore the concept of coupling and may be a basis on which more theory can be developed.
Coupling is about how easy it is to change applications. If one part of an application (module) has to be changed because another part of a program changes then these program parts a tightly coupled. If one module does not have to be changed for changes made to another module then these application modules are loosely coupled. There are a number of programming practices that can be put in place to loosen the coupling between modules. This is good because it reduces the effort required to maintain your code.
The above would seem to be a fairly elementary description. Definitions however can still be made more precise, so that the concept can be analysed in more detail.
Lets say we have two modules A and B in a system S. The number of changes that can be made to A can be defined as C(A).
We can make changes to A because we want system S to do something different, or we can make changes to A for other reasons. We might want S to be produce results more quickly or we just might want A or S to be reorganised to be more easily comprehended. A change to A might not mean any change the output of S.
In order for A to be changed and the result of S to be changed to a desirable result (which may be an unchanged outcome for S) then in some cases some module B would have to change as well.
The coupling between A and B is defined as the effort required to make changes to B as a result of these changes A. For change j then there is work (and cost) associated with this change for systems S say Wj(S). The work in module Wj(A) and module be Wj(B).
Coupling then can be defined in terms of an individual change
Coupling(j) =the work required in B to make change j as a result of the change in Aj.
Coupling(A,B) is the sum of all work require in B for such changes j.
This leaves the concept of 'Coupling Type' to be explained. A system can be organised to reduce coupling between A and B. A coupling type is a way of organising the system. Some ways of organising will mean that a change to A require changes to B. Some ways of organising will mean that B can remain independent of changes in A. Some ways may increase or decrease the work involved in making changes to B when A is changed.
In general a way of organising a system S is O(S) which is another system which produces the same results. This is a change to the structure of the system rather than a change to the outcomes of the system. If we wanted to measure the coupling of a way of organising O then 'all' we have to do is sum all the Coupling(A,B) over all such S, A and B. A coupling type describes a number of ways of organising a system. The coupling associated with a coupling type is therefore the sum of all the Coupling (A,B) over all these ways of organising S.
To express this succinctly:
Coupling between two modules (A and B) of a system (S) is the work required to make changes to a module (B) as result of changes to another module (A) and still produce the desired outcome of a system (S).
A coupling type is scheme for organising the system (S). A measure of the coupling of a coupling type is the sum over all A and B for systems S which conform to this coupling type.
These technical definitions of coupling describe big, practically incomputable numbers. The conclusions we can draw though are
- There is nothing really special about a coupling type. There could be a very large number of these and they are not confined to simple statements about how to pass parameters between modules. My earlier posting attempting to count these is inherently futile expect to provide common examples.
- Coupling is about work relating to a change. I have not defined what I mean by 'work' intentionally. We could count lines of code changed or look at whether logic or data is changing. We count the costs of making these changes (eg. Hours of labour). It is meant to be used in its common sense. If it is necessary to trawl through technical documentation to make a change to one line of code this is still consider then the trawling effort should be consider as part of the work expended for this change.
- Coupling is about systems in general. It is not just code instructions that are relevant. You might have to change constants, configurations, contracts or XML. These need to be considered in the concept of coupling.
- The concept of coupling is relevant to systems theory examples outside of the field of computer science. Systems can also refer to biological or sociological systems (See footnote 2).
- A change may not actually change the behaviour of the system at all but it is still relevant for coupling.
- Coupling at its most elementary level looks at two particular modules, a particular system and a particular change. Thus it sensible to say A is tightly coupled to B in a system S in relation to change j.
- Coupling can aggregated up to the module or level or to the Coupling Type level. Thus we can have A loosely coupled to B. We can talk about a Way of Organisation or a Coupling Type as facilitating loose coupling.
- Restriction have not been placed on A and B. Therefore if B=S we can have A tightly coupled with the rest of the system S. A and B could intersect or A could be a sub-module of B.
To determine whether one coupling type is better than another the above suggests we need to enumerate all possible changes and work out which type leaves you with less work involved in one module as result of changes in another. This is obviously impractical but the analyst can do a couple of things to determine a good coupling type. A range of typical changes can be investigation or the coupling type can be looked at in relation to a specific type of change. For instance the benefits of message queuing can be looked at in relation to changing the location or speed of hardware.
This posting has added some precision to the concept of coupling. Counting all the possible ways to change a system is futile, however good and bad coupling will be become evident by looking at coding examples and foreseeing the changes that will be required to any system.
Footnote 1:
The following web pages describe metrics for coupling. These can be based on a static analysis of code or a dynamic tracing of the execution paths. In both cases the emphasis is counting the reference to a variable or type. This has some value in the task of maintaining code but is not a measure of the work required to change one module based on the need to change another. In some cases there may be some correspondence between the amount of work in changing the use of the variable with the number of times it is reference but not generally.
Lethbridge, Timothy C. and Anquetil, Nicolas, Experiments with Coupling and Cohesion Metrics in a Large System, April 2000, https://www.site.uottawa.ca/~tcl/papers/metrics/ExpWithCouplingCohesion.html
Poshyvanyk, Denys and Marcus, Andrian, The Conceptual Coupling Metrics for Object-Oriented Systems, http://www.cs.wayne.edu/~vip/publications/poshyvanyk-ConceptualCoupling.pdf
Glover, Andrew, In pursuit of code quality: Code quality for software architects: Use coupling metrics to support your system architecture, April 2006, http://www.ibm.com/developerworks/java/library/j-cq04256/
FrontEndArt describes one of its products for montoring source code quality include various metrics for coupling, http://www.frontendart.com/monitor/help/node22.html
Diederik Krols provides a blog-site archive which includes the postion "OO-Metrics for Coupling". This provides a coupling metric based on types shared across a module boundary. http://dotbay.blogspot.com/2006_01_01_archive.html
Footnote 2:
The concept of "structural coupling" in systems theory is used to describe co-evolution in biological and social systems. This is where, if entity A evolves then entity B might need to evolve to compensate. There would seem to be more complicated processes at play here than in a computer application.
Kay, Robert and Goldspink, Chris, Towards a Complex Non-linear Systems Theory of Organisation, http://ftp.informatik.rwth-aachen.de/Publications/CEUR-WS/Vol-72/044%20Kay%20Complex.pdf
