Cohesion and coupling:
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 highly cohesive systems functionality is strongly related.
Cohesion is an ordinal type of measurement and is usually described as “high cohesion” or “low cohesion”. Modules with high cohesion tend to be preferable because high cohesion is associated with several desirable traits of software including robustness, reliability, reusability, and understandability whereas low cohesion is associated with undesirable traits such as being difficult to maintain, test, reuse, or even understand.
Cohesion is increased if:
- The functionalities embedded in a class, accessed through its methods, have much in common.
- Methods carry out a small number of related activities, by avoiding coarsely grained or unrelated sets of data.
Advantages of high cohesion (or “strong cohesion”) are:
- Reduced module complexity (they are simpler, having fewer operations).
- Increased system maintainability, because logical changes in the domain affect fewer modules, and because changes in one module require fewer changes in other modules.
- Increased module reusability, because application developers will find the component they need more easily among the cohesive set of operations provided by the module.
Coupling is the manner and 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
Coupling can be "low" (also "loose" and "weak") or "high" (also "tight" and "strong").
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.
Content coupling (high)
Content coupling occurs when one module modifies or relies on the internal workings 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 occurs 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. This is basically related to the communication to external tools and devices.
Control coupling
Control coupling is one module controlling the flow of another, by passing it information on what to do.
Data coupling
Data coupling occurs when modules share data through, for example, parameters.
No coupling
Modules do not communicate at all with one another.
Decision Tree and Decision Table:
A decision tree is a decision support tool that uses a tree-like graph or model of decisions and their possible consequences, including chance event outcomes, resource costs, and utility. It is one way to display an algorithm. Decision trees are commonly used in operations research, specifically in decision analysis, to help identify a strategy most likely to reach a goal. A decision tree is a flowchart-like structure in which each internal node represents a "test" on an attribute, each branch represents the outcome of the test and each leaf node represents a class label.The paths from root to leaf represents classification rules.
atOptions = {
'key': 'a900f2dbf175e78754c26c6231a4b673',
'format': 'iframe',
'height': 90,
'width': 728,
'params': {}
};