NOse Who

wh0 genera
for those who test andsubsequently support the software. generae rate codecode a
.

The design should provide a complete picture of the

software, adduoa
functional and behavioural domain from an implementation ressive.ng the da
Dersnant.

5.2 MODULARITY
There many definitions of the term
are
"module". They range from "a
subroutine" to "a module is an Ada module is a ROPTD
to "C++/ Java
package" "procedures and functions of PASCAL ande
to
Classes", to "Java packages" to "a module is a work assignment for an indivih
programmer" [FAIR2K]. All of these definitions are correct/ A
defined, manageable units with well defined interfaces modular system consist o'
of a modular system include: among the units. Desirable properie
S o f w a r eD e s i g n

207
dsle
Each mnod is a well delined subsystem that is
potentially useful in other
tions applica-
Each module has a single, well defined purpose

M
Jlas can be separately compiled and stored in a
library
use other modules
Modules can
fodules hould be easier to use than to build
Afadules
Mod should be simpler
outside than from the inside from the

single attribute of software that allows a program to be

dularity is the
IMYER78].
able [MYER78]. It enhances design
clarity, which in turn eases intellectually
ansting,
bugging, testir documenting, and maintenance of the software product.implementation, de-
ag A system
om is consi
considered modular if it consists of discreet components so that each
compo-
a n be implemented separately and a change to one
nent ca
component has minimal impact on
ononents. Here, one important question arises is to what extent we shall
other modularize.
the
As the number of modules grows, the effort
associated integrating the module also grows.
with
4 establishes the relationship between cost/effort and number of in a software. modules
Total software
cost
* .......................****
....
...
...
Region of minimum
Cost Cost to
M integrate
*******

Number of modules

Fig. 5.4: Modularity and software cost

It modular by simply chopping
it into a e ODserved that software system cannot be made
a
abstraction and should
a s
needs to support a well defined
Each module
have aa el 0aules. modules. Thus, it
is felt that
clear in which it can interact with other
nder and through
under moddularityace over modularity in a software should be avoided.
5.2.1 Module Coupling modules
Two
Coupling
with high iscoup
ne-measure of the degree of
nterdependence
betweenmodules.
dependent
Twomodules
ach other.Two
o n each
other.
modules

thus, P
are strongly i n t e r c o n n e c t e d and
made
are
with low COupline Loosely coupled"
systems
W
coupling
are arenot.dependent on one another.
 Software Engne
ed" .
208 coupled"

relatively
independent.
"Highly systems share a
modules
which are
For example, if modules
mako
of
shared great
between
modules.
at all; they are completely
1; they
are com.
global var
dependence

independent
i n t e r c o n n e c t i o n s

have no

Unovupled'modules aag
in Fig 5.5

Uncoupled: no dependencies
(a)

Loosely coupled: some dependencies Highly coupled: many dependencies

(b) (c)
Fig: 5.5: Module coupling

A good design will have low coupling. Thus, interfaces should be carefully
order to keep low value of coupling. specifed i
Coupling is measured by the number of interconnections between
modules. For exane-
ple, coupling increases as the number of calls
between modules increases, or the amounte
shared data increases. The
hypothesis that design with high coupling will have
is
Loose coupling, on the other
hand, minimizes the
more en
be achieved in the interdependence amongst modules. Tns
following way8:
Controlling the number of
Avoid passing undesired parameters passed amongst modules
data to calling module
Maintain parent/chilld
.Pass data, not the relationship between calling and called modules
control information
Fig. 5.6 demonstrates two alternative
Information System". design for editing a student cord in a "Stude
The r
first design demonstrates tight
dent name, student 28S

mation address, course is passedcoupling wherein unnecessa1

ssary information

unnecessary increases the to the

calling module. ran Superfluous

overhead, reducing the system pe

m p e r f o r m a n c e /e
e fffi
iciency
S o f n v a r eD e s i g n

209

Edit student
Edit student
record
record

Student name

student ID Student
student address record EOOF Student ID Student
record EOF
course

Retrieve
Retrieve
student student
record
record

Poor design: Tight coupling Good design: Loose coupling

Fig. 5.6: Example of coupling

Types of coupling

Different types fcoupling are content, common, external, control, stamp and data. The strength
ling from
ofcoupling from lowest coupling (best) to highest coupling (worst) is given in Fig. 5.7.

Data coupling Best

Stamp coupling
Control coupling
External coupling
Common coupling

Content coupling (Worst)

Fig. 5.7: The types of module coupling

Given two procedures A and B, we can identify a number of ways in which they can be
coupled.
Data coupling A B
Ihe dependency between module A and B is said to be data coupled if their dependency is
n the fact they communicate by only passing of data. Other tham communicating through
modules are independent. A good strategy is to ensure that no module communi-
WO
cation
ntains "tramp data". In Fig, 5.6 above students name, address, course are examples ot
ran ensuring that modules
m a t are
unnecessarily communicated between modules. By
amunicate only necessary data, module dependency is minimized.
Stamp coupling Afrul
Slam
Samp coupling data structure is passed ro
occurs between module AandB when complete
one
modl OCCurs betwee
module5to anot the structure are usually
necessary 1n
Since not all data making up
er
 pling typically involves
inve
210
the
modules,
stamp
couplin,

calling module should

modules tramp data
pass just ta.
communication
between

ofa
data
structure,

that
that npar
needs a
part
procedure
only s t r u c t u r e .

data
the complete
they communicat by
Control coupling
said to
be
control
coupledif

by
mcans
of that arec
flags that set by passing
one
f
Mod
odule A and
B
This
are

is
usually
accomplished

module.
modul
information.
dependent
the
e a c t e d upon by
modula
to other
rnal ttto the
. . .

External coupling dependency

module has
basically rnal
a
which a his
This is basically
is related
A form of coupling
in

to a particular
type of
hardware.
to th
or
ware being developed tools and
devices.
external
munication
to

Common coupling shared data. Glohal a.

module B have
coupling,
module A and
a change to the
common areas
With languages. Making
common

in programming data to evaluate the effect

ed of De
commonly found a c c e s s that
modules which ha
tracing back
to all the
determine which
module is responsible for
be difficult to
common coupling, it
can
shows how common coupling works [PFLE9RI
value. Fig. 5.8
variable to a particular

Global:
A1
A2 Common data area and
A3
variable names
Variables:
V1
v2

Change V1 to Zero Increment V1 V1 V2+A1

Module X Module Z
Module Y

Fig. 5.8:
Example of common
coupling
Content coupling
pase

Content coupling occurs when

from one module to the middle
module A changes data when control
of module B or
e v e nt h o u

w*to D, eve
Dis supposed to be under the of another. In Fig. 5.9, module B branches
control of C.
Solare DA

Module B

Go To temp

Module DD
E
D

Go To temp

Temp

content coupling
Fig. 5.9: Example of

5.22 M o d u l e C o h e s i o n
module a r e functionally related.
which the elements of a feature ofthe solution
of thedegreeto is related to one
Cobesion is a measure
module implements
functionaity that
This is shown in Fig.
5.10. Cohesion
cohesive modules.
Astrongly interaction with other measure of the mutual off+city
and requires
little or n o
the module together. It is a

be viewed as a glue that keeps

may module.
of a
of the components

Module

strength

modules
within de
relations important
= Strength of Hence,
an
Cohesion module.
5.10:
Fig. within a module
coupling
interaction
the
the minimize

Thus, we want to maximize

cohesion
and
SIgnobjectivo
su
objective is to 0 maximize the module

procedure
that
procedure that
i v e n aa
Given
G Y.
Types of cohesion shown in Fig.
in
5.11.
5 .11.
between
X and
cohesion
ar
a re
and
a nd ofcohesion
here are ofcohesion formsorms
of
ries
seven
opera
types or levels
we can
describe
various

Ou outt erations X and Y,

 212 Sotware Enge
Functional eohenion
Beat higgh)

Sguential wheaion

Commuicational coheaion

Prwvdural cohesion

Temporal cohesion

Logcal cohesion

Coincidental cohesion Worst (low)

of module cohesion
Fig.5.11: Types

ctional cohesion
functional task. This
18
very good reason for th.

X and Y a r e part ofa single often transformed a single inpt be cOnta

in the s a m e procedure.
Such a module datu into
subroutines such as calculate current C n
output datum. The
mathematical
of functional cohesion.
or 'cumulatine sing
typical examples
GPA are

Sequential cohesion
forms the input to Y. This is the reason for them to L.
X outputs s o m e data which to be contained
ed a
the same procedure.
For example, addition of marks of individual subjects into a specific fomat s
the result of the students.
calculate the GPA as input for preparing
A component is made of parts that need to communicate/exchange data for
ones
in a component for communico.Sou
fordifferent functional purposes. They are together
venience. For example calculate current and cumulative GPA uses the "student oro
as input.
Communicational cohesion
X and Y both operate on the same input data or contribute towards the same output data Thi
is okay, but we might consider making them separate procedures.
Procedural cohesion
X and Y are both structured in the same way. This is a poor reason for putting them in tha
same procedure. Thus, procedural cohesion occurs in modules whose instructions althou
accomplish different tasks yet have been combined because there is a specific order in whid
the tasks are to be completed. These types of modules are typically the result offirst lix
charting the solution to a program and then selecting a sequence of instructions tosere
module. Since these modules consist of instructions that acomplish several taskS
virtually unrelated these types of modules tend to be less maintainable. For
report module of an examination system includes the following "calculate student
student record, caleulate cumulative GPA, print cumulative GPA" is a case of procedural chesion
u

Temporal coheslon
X and Y both must perform around the same time. So, module exhibits tempor
i n thesame
when it contains tasks that are related
by the fact that all tasks
must be execut as set a ssetting

time-span. The set of functions responsible for

initialization, start up activiuesion.
aporal cohesion. Ths
Ths
program counters or control 1lags associated with
programs exhibit temporal c
not a good reason to put them in same
procedure.
 S o f h w a r e D e s i g n
213

L o g i c a lc o h e s i o n

cally
perform logica similar operations. Therefore, logical cohesion OCcurs in modules
andininstructions that appear to be related because they fall into the same logical class
ht cons, Considerable duplication can exist in the logical strength level. For example,
of
fund
one
dataiitem in an input transaction may be a date. Separate code would be writ
than
that each such date is a valid date. A better way to construct a DATECHECK
ten tod call this module whenever a date check is necessary.
m o d u l

Coincidental c o h e s i o n

here no conceptual relationship otherthan shared code. Hence, coincidental cohesion

Nand

modules that contain instructions that have little or no relationship to one another.
ists in
e instead of creating two components, each of one part, only one component is made
w unrelated parts. For example, check validity and print is a single component with
two parts. Coincident cohesion is to be avoided as far as possible.

523 Relationship between Cohesion and Coupling

The e5Sence of the design process is that the system is decomposed into parts to facilitate the
hility of understanding and modifying a system. Projects rarely gets into trouble because
capal
ofmassive requirement changes. These changes can be properly recognized and properly
re-

viewed.
If the sofbware is not properly modularized, a host of seemingly trivial enhancement or
of the project. Therefore, a good software design professes clean
changes will result into death
into modules and the arrangement of these modules in a neat
decomposition of a problem
hierarchy. Therefore, a software engineer must the modules with goal of high cohesion
design
and low coupling.
A good example of a system that has high cohesion and low coupling is the plug and
play' feature of the computer system. Various slots in the mother board of the system simply
facilitate to add or remove the various services/functionalities without affecting the entire
cohesive man-
system. This is because the add on components provide the services in highly
ner. Fig. 5.12 provides a graphical review of cohesion and coupling.

High coupling Low coupling

Fig. 5.12: View of cohesion and coupling
Module design with high cohesion and low coupling characterizes a module as black box
whaeentire structure of the system is described. Each module can be dealt separately
en the module functionality is described.
 214
Sotware Engjneent
5.3 STRATEGY OF DESIGN
A good system desigm strategy is to organize the program modules in sino
such a
to and later to, change. Structured design techniques help
develop developerswayto
p develony that.
that a
size and complexity of programs. Analysts ereate instructions for the deudea
the deal with
code should be written and how pieces of code should fit together to devel
together to form opers about h
important for two reasons:
First, even pre-existing code, if any, needs to be understood. re
together.
.Second, it is still common for the project team to have to write Some . iece
original programs that support the application logic of the system. code some and produs
early days, if any design was done, it was just writing down the
In
produws
Many people feel that flowcharts are too detailed, so leading to the detail flowcharm :
oten o
too early, and too far from the
specifications. Hence, there is a sudden jump from being deridad
to flow chat that leads to the cause of
many errors. Flowcharts are at a low specificati
errors in flow-charts could
only found by coding them, seeing that the level. A
be
diagnosing that the error is in the flow chart, then diagnosing where in code ran t wrongy
fixing it, modifying code and recording. Kepeated surgery on the tlow the floweho
chart then
the final flow chart where further errors
can not be fixed and the sometimes lead.
adt
So writers of large and project may fail.
complex software now seldom use flow charts for
result is that we have designed other
notations for expressing desin T
level" than flow charts. designs, and they are at a "highes
This
design and design to code. These
helps us to minimize the length of
jumps from
notations usually permit specifications t
small jumps in place of one or two multiple levels of design, and many
massive jumps.
There are many strategies or
techniques for
bottom up approach, top down approach, and hybrid performing system design. They inclute
approach.
5.3.1 Bottom-Up Design
A common
approach is to identify modules that are
ules collected together in the
are
form of a
required by many programs. These uod
tions, for input-output
functions, for
"library". These modules may be for
maten inc-
es tor result
preparation
graphical functions etc. We may have
"marks entry" etec. system like "maintain student detail", collecu
"maintain subject a
This approach lead to a
to style of design where we
provide larger ones; to combine decide how to hese
modules

one big module

which is the whole
those to
provide even larger and
combine arie
of ones, so
o,
hierarchy the
in Fig. 5.13. This is a desired program. The set alesnodule form a

subordinate toshown
as
of these module
set of forn
those in which it is cross-linked tree structure in these heach module is
Since the
design progressed from
used. wne
design. The main bottom layer
design, chances of
the argument for this
design is that if
upwards, the methoa
validated sooner than arecoding high; but the
is we start le s00n
module soon after
coding a mouesign acan*
esign
module whose sub coded module can be ca
This method has modules have not yet been tested a
actly what functionality one terrible
weakness; we desigmed. cideer
a
module should need to use a lot of intu
provide.
SoftwareDesign

215

Fig. 5.13: Bottom-up tree structure

scn get it wrong, then at a higher level, we will
aave to redesign at a lower level. If a system is tofind that it is not as per requirements
then be built from an
is m o r e suitable as it starts from some existing system, this
approach
existing modules.
3.2 Top-Down Design
Ta ssential idea of top-down
design is that the specification is viewed as
designer should decide how the internals of the blackdescribing
a black
for the program? The
box is constructed
from smaller black boxes; and that those inner black boxes be specified. This
for those inner process is then
repeated boxes,
and so on till the black boxes can be coded directly.
A top down design approach starts by identifying the major modules
of the system,
decomposing them into their lower level modules and iterating until the desired level of detail
is achieved. This is stepwise refinement, starting from an abstract
design, in each step the
design is refined to a more concrete level, until we reach a level where no more refinement is
Deeded and the design can be implemented directly. Most design methodologies are based on
this approach and this is suitable, if the specifications are clear and development is from the
Scrateh. If coding of a part starts soon after it's design, nothing can be tested until all its
subordinate modules are coded.
53.3 Hybrid Design
Pure
p-down or pure bottom-up approaches are often not practical. For a bottom-
p
Ch to be successful, we must have a good notion of the top to which the design should be

ig. Without a good idea about the operations needed at the higher layers, it is difficult to
n e what.operations the current layer should support |JAL098).
op-down to be effective, some bottom-up (mostly in the lowest design
levelo approach
approach is essential for the following reasons:
T0 permit common sub modules need
ear thebottom of the hierarchy, where the intuition is simpler, and the for
of modules at low levels
more numbers
#h pP testing is greater, because there are
than at high levels.
reuse of modules.
s e of pre-written library modules, in particular,