Cohesion and coupling
- 2. COUPLING
- 3. Coupling (computer programming) In software engineering, coupling is the degree of interdependence between software modules; a measure of how closely connected two routines or modules are; the strength of the relationships between modules. Coupling is usually contrasted with cohesion. Low coupling often correlates with high cohesion, and vice versa. 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.
- 5. Procedural programming A module here refers to a subroutine of any kind, i.e. a set of one or more statements having a name and preferably its own set of variable names.
- 6. Content coupling (high) Content coupling (also known as Pathological coupling) occurs when one module modifies or relies on the internal workings of another module (e.g., accessing local data of another module). In this situation, a change in the way the second module produces data (location, type, timing) might also require a change in the dependent module.
- 7. Common coupling Common coupling (also known as Global coupling) occurs when two modules share the same global data (e.g., a global variable). Changing the shared resource might imply changing all the modules using it.
- 8. External coupling External coupling occurs when two modules share an externally imposed data format, communication protocol, or device interface. This is basically related to the communication to external tools and devices.
- 9. 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).
- 10. Stamp coupling (Data-structured coupling) Stamp coupling occurs when modules share a composite data structure and use only parts of it, possibly different parts (e.g., passing a whole record to a function that only needs one field of it).In this situation, a modification in a field that a module does not need may lead to changing the way the module reads the record.
- 11. Data coupling Data coupling occurs when modules share data through, for example, parameters. Each datum is an elementary piece, and these are the only data shared (e.g., passing an integer to a function that computes a square root).
- 12. Message coupling (low) This is the loosest type of coupling. It can be achieved by state decentralization (as in objects) and component communication is done via parameters or message passing.
- 13. No coupling Modules do not communicate at all with one another.
- 15. Subclass coupling Describes the relationship between a child and its parent. The child is connected to its parent, but the parent is not connected to the child.
- 16. Temporal coupling When two actions are bundled together into one module just because they happen to occur at the same time.
- 17. In recent work various other coupling concepts have been investigated and used as indicators for different modularization principles used in practice.
- 18. Disadvantages Tightly coupled systems tend to exhibit the following developmental characteristics, which are often seen as disadvantages: A change in one module usually forces a ripple effect of changes in other modules. Assembly of modules might require more effort and/or time due to the increased inter-module dependency. A particular module might be harder to reuse and/or test because dependent modules must be included.
- 19. Cohesion In computer programming, cohesion refers to the degree to which the elements of a module belong together. Thus, cohesion measures the strength of relationship between pieces of functionality within a given module. For example, in highlycohesive systems functionality is strongly related. Cohesion is an ordinal type of measurement and is usually described as “high cohesion” or “low cohesion”.
- 21. Cohesion Cohesion is a qualitative measure, meaning that the source code to be measured is examined using a rubric to determine a classification. Cohesion types, from the worst to the best, are as follows:
- 22. Coincidental cohesion (worst) Coincidental cohesion is when parts of a module are grouped arbitrarily; the only relationship between the parts is that they have been grouped together (e.g. a “Utilities” class).
- 23. Logical cohesion Logical cohesion is when parts of a module are grouped because they are logically categorized to do the same thing even though they are different by nature (e.g. grouping all mouse and keyboard input handling routines).
- 24. Temporal cohesion Temporal cohesion is when parts of a module are grouped by when they are processed - the parts are processed at a particular time in program execution (e.g. a function which is called after catching an exception which closes open files, creates an error log, and notifies the user).
- 25. Procedural cohesion Procedural cohesion is when parts of a module are grouped because they always follow a certain sequence of execution (e.g. a function which checks file permissions and then opens the file).
- 26. Communicational/informational cohesion Communicational cohesion is when parts of a module are grouped because they operate on the same data (e.g. a module which operates on the same record of information).
- 27. Sequential cohesion Sequential cohesion is when parts of a module are grouped because the output from one part is the input to another part like an assembly line (e.g. a function which reads data from a file and processes the data).
- 28. Functional cohesion (best) Functional cohesion is when parts of a module are grouped because they all contribute to a single well- defined task of the module (e.g. Lexical analysis of an XML string).
- 29. While functional cohesion is considered the most desirable type of cohesion for a software module, it may not be achievable. There are cases where communicational cohesion is the highest level of cohesion that can be attained under the circumstances.