are here: Freetutes.com
Analysis and Design
Cohesion, as the name suggests, is the adherence of the code statements within
a module. It is a measure of how tightly the statements are related to each other
in a module.Structures that tend to group highly related elements from the point
of view of the problem tend to be more modular. Cohesion is a measure of the amount
of such grouping.
Cohesion is the degree to which module serves a single purpose. Cohesion is
a natural extension of the information-hiding concept. A cohesive module performs
a single task within a software procedure, requiring little interaction with procedures
being performed in other parts of a program. There should be always high cohesion.
Cohesion: modules should interact with and manage the functions of a limited
number of lower-level modules.
There are various types of cohesion
Functional cohesion is the strogest cohesion. In a functionally bound module,
all elements of the module are related to erpforming a single function. Function
like "computer square root" and "sort the away" are clear
examples of functionally cohesive modules.
How does one determine the cohesion level of a module? There is no mathematical
formula that can be used. We have to use our judgement for this. A useful technique
for determining if a module has a functional cohesion is to write a sentence that
describes, fully and accurately, the function or purpose of the module. The following
test can be made.
If the sentence must be compound sentence, if it contains comma, or has more
than one verb, the module is probably performing more than one function, and probably
has sequential or communicational cohesion.
If the sentence contains words relating to time like "first", "next",
"when", "after", etc. Then the module probably has sequential
or temporal cohesion.
If the predicate of the sentence does not contain a single specific object
following the verb (such as "edit all data"). The module probably has
Words like "Initialize and setup" imply temporal cohesion.
When the elements are together in a module because the output of one forms
the input to another, we get sequential cohesion. Here it doesn't provide any
guidelines on how to combine them into modules.
Fig 6.4 - P and Q modules show sequential cohesion
In terms of DFD, this combines a linear chain of successive transformations.
This is acceptable.
- READ-PROCESS; WRITE RECORD
- Update the current inventory record and write it to disk
A module with communicationl cohesion has elements that are related by a reference
to the same input or output data. That is, in a communicationl bound module, the
elements are together because they operate on the same input or output data. An
example of this could be a module to "print and puch record". Communicational
cohesive modules may be performing more than one function. However, communicational
cohesion is sufficiently big so as to be generally acceptable if alternate structures
with higher cohesion cannot be easily identified.
Communicational cohesivemodule consists of all processing elements, which act
upon the same input data set and/or produce the same output data set.
Fig 6.5 - Communicational Cohesion
P and Q form a single module.
Module is defined in terms of the problem structure as captured in the DFD.
It is commonly found in business or commercial applications where one asks what
are the things that can be done with this data set.
A procedurally cohesive module contains elements that belong to a common precedural
limit. For example: a loop or a sequence of decision procedurally cohesive modules
often occur when module structure is determined from some form to flowchart, procedural
cohesion, often cuts accross functional lines. A module with only procedural cohesion
may contain only part of a complete function, or parts of a several functions.
Fig 6.6 - Procedural Cohesion
Often found when modules are defined by cutting up flowcharts or other procedural
artifacts. There is no logical reasoning behind this. Fig 6.6 illustrates this.
In this all the elements that are being used in the procedure 2 are put in the
same module. It is not acceptable. Since elements of processing shall be found
in various modules in a poorly structured way.
Temporal cohesion is the same as logical cohesion, except that the elements
are also related in time, and are executed together. Modules that perform activities
like "initigation", "clean-up", and "termination"
are usually temporarilly bound. Eventhough the elements in a temporally bound
module are logicaly related, temporal cohesion is higher than logical cohesion,
since the elements are all executed together. This will avoid the problem of passing
the flag, and the code is usually simpler.
A module has logical cohesion if there is some logical relationship between
the elements of a module, and the elements perform function that fall in the same
logical class. In general, logically cohesive modules should be avoided, if possible.
Logical Cohesion is module formation by putting together a class of functions
to be performed. It should be avoided. For example, Display_error on file, terminal,
Fig 6.7 Logical Cohesion
Fig 6.7 shows logical cohesion. Here function Display_error is for files, terminals,
and printers. Since the function is to display error, all three functions are
put into same modules.
Coincidental Cohesion is module formation by coincidence. Same code is recognized
as occurring in some other module. Pull that code into a separate module. This
type of cohesion should be avoided since it does not reflect problem structure.
Coincidental cohesion can occur if an exixting program is "modularized"
by chopping into pieces and making different pieces of modules.
Page | Contents
| Next Page >>