CSC/ECE 517 Fall 2007/wiki2 7 b2: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
 
(24 intermediate revisions by 2 users not shown)
Line 104: Line 104:
</pre>
</pre>


=== Cohesion Metrics ===
=== Cohesion Type Judgement ===
A way to decide the type of cohension.
A way to decide the type of cohension.


Line 123: Line 123:
Two modules are said to be content coupled when one module have direct access or reference to the contents of the other one.
Two modules are said to be content coupled when one module have direct access or reference to the contents of the other one.
Content coupling suffers a great disadvantage. It is simply impossible to reuse content coupled modules because any change to one of the modules would require change to another one.
Content coupling suffers a great disadvantage. It is simply impossible to reuse content coupled modules because any change to one of the modules would require change to another one.
one example would be


==== Common Coupling ====
==== Common Coupling ====
Line 133: Line 132:


example:
example:
There are two modules m1 and m2. When m1 passes a string "mission accomplished" to m2, without commanding m2 to do anything, then m1 simply passes data to m1. However, if m1 pass "mission accomplished" followed by commanding m2 to signal correspondingly, then they are control coupled. Control coupling destroys the independence of modules and therefore suffers the disadvantage of decreased reusability.
*There are two modules m1 and m2. When m1 passes a string "mission accomplished" to m2, without commanding m2 to do anything, then m1 simply passes data to m1. However, if m1 pass "mission accomplished" followed by commanding m2 to signal correspondingly, then they are control coupled. Control coupling destroys the independence of modules and therefore suffers the disadvantage of decreased reusability.


==== Stamp Coupling ====
==== Stamp Coupling ====
Line 139: Line 138:


example:
example:
calculate_witholding( employee_record )
*calculate_witholding( employee_record )


In this example, calculate_witholding will probably need employee salary and id to carry out the computation, however, other data such as address, contact of employee_record are not likely to be needed.  
In this example, calculate_witholding will probably need employee salary and id to carry out the computation, however, other data such as address, contact of employee_record are not likely to be needed.  
Line 156: Line 155:
== Related Concepts ==
== Related Concepts ==
=== Coupling and Cohesion Metrics ===
=== Coupling and Cohesion Metrics ===
Cohesion
Both cohesion and coupling are semantic concepts.
Definition
Cohesion metrics can be scaled from maximum of 1 to minimum of 0, if it is normalized. Here 0 means all elements of the modules are independent while 1 means every element is connnected to each other. For un-normalized cohesion, metrics quantify the degree by counting the connections between elements in a module. Specifically, there are a number of quantities which can be categorized into cohesion metrics.
examples:
* Relational cohesion: This is the average number of internal relationships per class/interface, and is calculated as the ratio of R+1 to the number of classes and interfaces in the package.
* connected components cohesion: The classes and interfaces of a package, and their dependencies, form a graph. This metric counts the number of connected components of that graph.


Cohesion is the degree to which the elements in a design unit (package, class etc.) are logically related, or "belong together". As such, cohesion is a semantic concept.
Coupling metrics are quantified by the amount of interested units between two moduels and are not normalized.
examples:
* associated elements coupling: For a class that is defined in a package p, this counts only associations with model elements in packages that neither contain p nor are contained by p. These are the least desirable associations, because they couple otherwise unrelated packages. Such associations cannot be avoided, but their use should be minimized.
* message sent coupling: Counts the number of messages that instances of this class send to instances of other classes, or unclassified instances.
* connectors coupling: The number of connectors owned by the class.


Cohesion metrics have been proposed which attempt to approximate this semantic concept using syntactical criteria. Such metrics quantify the connectivity (coupling) between elements of the design unit: the higher the connectivity between elements, the higher the cohesion.
Due to the semantic nature of both software metrics, cohesion and coupling can be loosely defined. There is no a single set of benchmarks to map a module or a number of modules to a digit that quantify the degrees of both metrics. However, in certain context, as aforementioned examples, it is possible to associate a paticular type of program units as the metrics of measuring the degree of cohesion and coupling.


Cohesion metrics often are normalized to have a notion of minimum and maximum cohesion, usually expressed on a scale from 0 to 1. Minimum cohesion (0) is assumed when the elements are entirely unconnected, maximum cohesion (1) is assumed when each element is connected to every other element.
=== Other related concepts and metrics ===


Not normalized metrics are based on counts of connections between design elements in a unit (e.g., method calls within a class). As such, not normalized metrics are conceptually similar to complexity metrics.
Complexity — A metric to measure the degree of connectivity between elements of a design unit. It takes into account the relationships and dependencies between the elements in the design unit.  
* High complexity often can lead to high coupling, which decrease the maintainbility of the code.


Impact on quality


A low cohesive design element has been assigned many unrelated responsibilities. Consequently, the design element is more difficult to understand and therefore also harder to maintain and reuse. Design elements with low cohesion should be considered for refactoring, for instance, by extracting parts of the functionality to separate classes with clearly defined responsibilities.
Size — While complexity measures the dependency between the elements in a unit, size metric counts the elemnts contained within the unit. (e.g. number of classes in package, etc.)
* Size metric is a good candidate for meausring developing cost or effort estimates.
* Large size which maybe indicated by profuse amount of methods/classes/packages and most of the time correlated with high coupling and low cohesion.


Empirical results


In practice, cohesion metrics are only of limited usefulness:
Encapsulation — putting in a container, packaging up, or putting a barrier around a group of entities when creating a module. Often, the programming language mechanism that provides encapsulation also provides a means to enforce hiding.
* Encapsulation is not directly related to cohesion and coupling, but it is related to modules.


    * Not normalized cohesion metrics often are strongly related to size metrics. This makes sense since, as discussed, large classes or packages may in fact suffer from low cohesion. Such cohesion metrics then are, of course, good quality indicators, but they are redundant with size metrics - they provide no new information about the element.
    * Normalized cohesion metrics do not consistently have a bearing on system quality. I.e., we cannot conclude from a high or low cohesion value that a class is, e.g., more or less fault-prone. Either, the theoretical negative impact of low cohesion on system quality is not always that critical in practice, or, the cohesion metrics simply fail to identify design elements with unrelated responsibilities.


Information Hiding — implementation decisions, or decisions that are likely to change.
* If information hiding is enforced, then certain kinds of relationships between modules are not possible, and so the amount of coupling possibility is limited.
* Modules with good cohesion do not make visible “nonessential” details.


Coupling
Definition


Coupling is the degree to which the elements in a design are connected.
Abstraction — extracting the essential details about a concept
 
* A good abstraction should have good cohesion.
Impact on quality
 
Coupling connections cause dependencies between design elements, which, in turn, have an impact on system qualities such as maintainability (a modification of a design element may require modifications to its connected elements) or testability (a fault in one design element may cause a failure in a completely different, connected element). Thus, a common design principle is to minimize coupling.
 
Most coupling dependencies are directed - the coupling usually defines a client-supplier relationship between the design elements. Therefore, it is useful to distinguish import coupling ("using") and export coupling ("used"), which we discuss in the following.
 
Import coupling
 
Import coupling measures the degree to which an element has knowledge of, uses, or depends on other design elements. High import coupling can have the following effects:
 
    * Decreased maintainability: changes to the supplier may necessitate follow-up changes (ripple effects) to the client.
      The stability of the supplier is a factor to consider here. High coupling to elements that are not likely to change is less harmful than coupling to variation points.
    * Decreased understandability, increased fault-proneness: elements with high import coupling operate in large context, developers need to know all the services the element relies on, and how to use them.
    * Decreased reusability: To reuse a class or package with high import coupling in a new context, all the required services must also be made available in the new context.
 
Export coupling
 
Export coupling measures the degree to which an element is used by, depended upon, by other design elements. High export coupling is often observed for general utility classes (e.g., for string handling or logging services) that are used pervasively across all layers of the system. Thus, high export coupling is not necessarily indicative of bad design.
 
Again, an important issue to consider here is stability. High export coupling elements that are likely to change in the future can have a large impact on the system if the change affects the interface. Therefore, high export classes should be reviewed for anticipated changes, to ensure that these changes can implemented with minimal impact.
 
Empirical results
 
Coupling metrics have consistently been found to be good indicators of fault-proneness. It seems worthwhile to investigate different dimensions of coupling: import and export coupling, different coupling mechanisms, distinguishing coupling to COTS libraries and application-specific classes/packages. Coupling metrics are suitable to identify design elements with high fault density. Therefore, coupling metrics greatly help to identify small parts of a design that contain a large number of faults.
 
=== Others ===


== Reference ==
== Reference ==
Line 224: Line 205:
* [http://www.cs.unc.edu/~stotts/COMP145/modules.html] - Design for change
* [http://www.cs.unc.edu/~stotts/COMP145/modules.html] - Design for change
* [http://www.kellen.net/Coupling%20and%20Cohesion.htm] - Software Quality and Coupling and Cohesion
* [http://www.kellen.net/Coupling%20and%20Cohesion.htm] - Software Quality and Coupling and Cohesion
* [http://www.sdmetrics.com/LoM.html#LoM] - Metrics list of OOD
* [http://www.cs.auckland.ac.nz/compsci702s1c/lectures/ewan/cs702-notes-lec06-c-and-c.pdf] - A lecture on Coupling and Cohesion
* [https://www.site.uottawa.ca/~tcl/papers/metrics/ExpWithCouplingCohesion.html] - Experiments with Coupling and Cohesion Metrics in a Large System
* [http://www.sce.carleton.ca/faculty/lung/metircs02_conf.pdf] - An Experimental Study of Cohesion and Coupling Metrics

Latest revision as of 04:02, 30 October 2007

Assignment 2 - Topic 7 - Cohesion and Coupling

Cohesion and coupling are concepts that are reasonably easy to understand, but nonetheless, it is challenging to find good examples that are succinct. Browse the hundreds of Web pages that attempt to explain these concepts, picking your favorite examples. Many of these pages mention related concepts; list some of them and explain how they relate to cohesion and coupling. Be sure to mention the metrics that can be used to measure how well a program conforms to the principles of high cohesion and low coupling.

The Concepts

The object-oriented paradigm, the virtuals of readability, maintainability, extensibility, reusability are realized through modularity, which aims at decomposing a complex problem into smaller pieces called modules (e.g. class). A module can be understood as a contiguous program statements, bounded together, having a set of its own variable names and an aggretate identifer.

Well designed object-oriented programs defines proper logic and operational boundaries among different modules, through which many aforementioned desiable properties can be achieved. The degree of interaction within one module was quantified and called module cohesion by Myers in 1978 and the degree of interaction between two different modules was called module coupling. It is considered as good traits when a program has high level cohesion while a low level coupling.

Cohesion

Types of Cohesion From worst to best, the types of cohesion are listed below:

  • Coincidental Cohesion (worst)
  • Logical Cohesion
  • Temporal Cohesion
  • Procedual Cohesion
  • Communicational Cohesion
  • Sequential Cohesion
  • Functional Cohesion
  • Informational Cohension (best)


Coincidental Cohesion (worst)

Coincidental cohesion means the module are grouped randomly, without significant relationshiop. Example,

module miscellaneous
  sin();
  read();
  sendsignal();
  ...
end

Logical Cohesion

A logical cohesion module is one whose elements are somewhat in the same category. Example,

module IOfunction
  printf();
  read_A;
  write_B;
end

Temporal Cohesion

The elements of the module are related in time, a good example is program initialization and termination.

module init
  timer_A=0;
  couter_B=0;
  ...
end

Procedual Cohesion

A procedual cohesion module is one that its elements are involved in different activities but executed in a specific order. Example,

module tableupdate
  read_A();
  wirte_B();
  ...
end

Communicational Cohesion

A communicationally module is one whose elements are not related but use the same input or output data.

module data_A
  task1_read_A();
  task2_read_A();
  task1_write_A();
  ...
end

Sequential Cohesion

A sequentially cohesive module is that one of its elements's output data happens to be input data to another one.

module data_update
  A.update();
  B.update(A);
  ...
end

Functional Cohesion

A sequentially cohesive module is one whose elements contribute to one task, or one problem.

module task
  task.init;
  task.compute;
  task.io;
  ...
end

Informational Cohension (best)

A informationally cohensive module is a "object-oriented" module. It contains complex data structure and all its elements contribute to the object.

module class_A
  A.init;
  A.read;
  A.write;
  ...
end

Cohesion Type Judgement

A way to decide the type of cohension.

Coupling

Coupling is the degree of interaction between two modules. The levels of couplingis listed below.

Types of Coupling

From worst to best:

  • Content Coupling (worst)
  • Common Coupling
  • Control Coupling
  • Stamp Coupling
  • Data Coupling (best)

Content Coupling (worst)

Two modules are said to be content coupled when one module have direct access or reference to the contents of the other one. Content coupling suffers a great disadvantage. It is simply impossible to reuse content coupled modules because any change to one of the modules would require change to another one.

Common Coupling

Two modules are said to be common coupled if both have access to the same global data. Common coupling is undesirable for several reasons. First, if the commonly referred global variale is changed, then every common coupled module has to be changed as well. This greatlly decreases the code maintainability. Second, because more than one module has the potential to modify the value of a global variable, when an error occurs, it is difficult to identify the cause due to very minimal readability. Third, data access control becomes very difficult with common coupled modules. However, common coupling could be a solution when a number of modules have to access a set of attributes defined as global variables.

Control Coupling

Two modules are said to be control coupled when one module passes a control element to the other module.

example:

  • There are two modules m1 and m2. When m1 passes a string "mission accomplished" to m2, without commanding m2 to do anything, then m1 simply passes data to m1. However, if m1 pass "mission accomplished" followed by commanding m2 to signal correspondingly, then they are control coupled. Control coupling destroys the independence of modules and therefore suffers the disadvantage of decreased reusability.

Stamp Coupling

If a data structure (e.g. a struct in C,) is passed as an argument from one module to the other, but instead of using all data contained in the data structure, the receiver of the argument only uses a part of it, then these two modules are said to be stampl coupled.

example:

  • calculate_witholding( employee_record )

In this example, calculate_witholding will probably need employee salary and id to carry out the computation, however, other data such as address, contact of employee_record are not likely to be needed.

Because a module receives more information than it really needs, the difficulty of data access control suffered by common coupled modules also troubles stamp coupled modules. If arguments passed to a module can be reduced to those necessary ones, it not only increases the readability of the code but also improves the likelyhood of it being reused.

Data Coupling

When two modules pass arguments that are either simple arguments or a data structure in which all elements are used by the called module, then they are said to be data coupled.

example:

  • display_time_of arrival( flight_number )
  • compute_product( a, b, result )

Data coupling makes the maintainance easier and do not suffer problems introduced in other types of coupling.

Related Concepts

Coupling and Cohesion Metrics

Both cohesion and coupling are semantic concepts. Cohesion metrics can be scaled from maximum of 1 to minimum of 0, if it is normalized. Here 0 means all elements of the modules are independent while 1 means every element is connnected to each other. For un-normalized cohesion, metrics quantify the degree by counting the connections between elements in a module. Specifically, there are a number of quantities which can be categorized into cohesion metrics. examples:

  • Relational cohesion: This is the average number of internal relationships per class/interface, and is calculated as the ratio of R+1 to the number of classes and interfaces in the package.
  • connected components cohesion: The classes and interfaces of a package, and their dependencies, form a graph. This metric counts the number of connected components of that graph.

Coupling metrics are quantified by the amount of interested units between two moduels and are not normalized. examples:

  • associated elements coupling: For a class that is defined in a package p, this counts only associations with model elements in packages that neither contain p nor are contained by p. These are the least desirable associations, because they couple otherwise unrelated packages. Such associations cannot be avoided, but their use should be minimized.
  • message sent coupling: Counts the number of messages that instances of this class send to instances of other classes, or unclassified instances.
  • connectors coupling: The number of connectors owned by the class.

Due to the semantic nature of both software metrics, cohesion and coupling can be loosely defined. There is no a single set of benchmarks to map a module or a number of modules to a digit that quantify the degrees of both metrics. However, in certain context, as aforementioned examples, it is possible to associate a paticular type of program units as the metrics of measuring the degree of cohesion and coupling.

Other related concepts and metrics

Complexity — A metric to measure the degree of connectivity between elements of a design unit. It takes into account the relationships and dependencies between the elements in the design unit.

  • High complexity often can lead to high coupling, which decrease the maintainbility of the code.


Size — While complexity measures the dependency between the elements in a unit, size metric counts the elemnts contained within the unit. (e.g. number of classes in package, etc.)

  • Size metric is a good candidate for meausring developing cost or effort estimates.
  • Large size which maybe indicated by profuse amount of methods/classes/packages and most of the time correlated with high coupling and low cohesion.


Encapsulation — putting in a container, packaging up, or putting a barrier around a group of entities when creating a module. Often, the programming language mechanism that provides encapsulation also provides a means to enforce hiding.

  • Encapsulation is not directly related to cohesion and coupling, but it is related to modules.


Information Hiding — implementation decisions, or decisions that are likely to change.

  • If information hiding is enforced, then certain kinds of relationships between modules are not possible, and so the amount of coupling possibility is limited.
  • Modules with good cohesion do not make visible “nonessential” details.


Abstraction — extracting the essential details about a concept

  • A good abstraction should have good cohesion.

Reference

  • E. Yourdon, Modern Structured Analysis, Yourdon Press, Englewood Cliffs, NJ, 1989.
  • Stephen R. Schach, Object-oriented & classical Software Engineering, McGraw-Hill, NY, NY, 2005

External Links

  • Cohesion - An wikipedia article about cohesion
  • Coupling - An wikipedia article about coupling
  • [1] - Design Concepts: Cohesion vs. Coupling
  • [2] - Coupling and Cohesion
  • [3] - A Definition of Coupling and Cohesion
  • [4] - What makes a module a good module?
  • [5] - Design for change
  • [6] - Software Quality and Coupling and Cohesion
  • [7] - Metrics list of OOD
  • [8] - A lecture on Coupling and Cohesion
  • [9] - Experiments with Coupling and Cohesion Metrics in a Large System
  • [10] - An Experimental Study of Cohesion and Coupling Metrics