Page 139 - DCAP405_SOFTWARE_ENGINEERING
P. 139
Software Engineering
Notes Measuring Cohesion
Module cohesion was defined by Yourdan and Constantine as how tightly bound or related its
internal elements are to one another and an attribute that can be used to predict properties of
implementations such as ease of debugging, ease of maintenance, and ease of modification.
Since cohesion refers to the degree to which module components belong together, cohesion
measurement should prove to be a very useful restructuring tool.
Following the original guidelines, skilled engineers conduct the assessment of module cohesion.
These engineers would apply a set of subjective criteria to analyze associations between
\processing elements and classify the nature of these associations. Because of the subjective
nature of the assessment, the measurement of module cohesion has been difficult to automate,
and cohesion has not been effectively used as a software quality indicator. Several approaches
have been used to develop objective, automatable methods for measuring module cohesion.
The first approach, an association-based approach, is to formalize the notion of the associations
between processing elements as a set of rules concerning data dependencies in module code.
This method requires the analysis of code-level information and thus cannot be applied before
code is written. The second approach, a slice-based approach. They measure functional cohesion
in terms of the connections between code data tokens on module output slices. This method also
requires code level information. Cohesion measures for object-oriented software have also
been defined using a slice-based approach, and by analyzing the connectivity between methods
through common references to instance variables. Method bodies are needed to apply these
code-level class cohesion measures.
Coupling of a subsystem characterizes its interdependence with other subsystems. A subsystem’s
cohesion, on the other hand, characterizes its internal interdependencies. When used in
conjunction with other attributes, measurements of a subsystem’s coupling and cohesion can
contribute to software quality models.
Did u know? How can be the abstraction of a software system can be represented?
An abstraction of a software system can be represented by a graph and a module (subsystem)
by a subgraph. Software-design graphs depict components and their relationships.
Measuring Coupling
Coupling is an internal software attribute that can be used to indicate the degree of
interdependence among the components of a software system. It has been recognized that good
software design should obey the principle of low coupling. A system that has strong coupling
may make it more complex because it is difficult to understand, change, and correct highly
interrelated components in the system. Coupling is therefore considered to be a desirable goal
in software construction, leading to better values for external attributes such as maintainability,
reusability, and reliability.
A first-order principle of software architecture is to increase cohesion and reduce coupling.
Cohesion (interdependency within module) strength/level names: (from worse to better, high
cohesion is good).
Refinement: Modern software development is a complicated process especially when a
software system becomes large and complicated. Software developers must apply software
refinement in order to proceed from a high-level abstract model to a final executable
132 LOVELY PROFESSIONAL UNIVERSITY