SOFTWARE ENGINEERING TECHNIQUES
LESSON 13:
Topics Covered
Software Design- Features of a good software design, Cohesion
and Coupling, Classifications of cohesion and coupling
Objectives
Upon completion of this Lesson, you should be able to:
• Know what is meant by software design
• Know what are the good features of a software design
Know what is meant by cohesion and coupling in software
design and the various classifications of cohesion and coupling
In today’s lecture we’ll see what do you exactly mean by a
software design and the features of a good software design as
well as cohesion and coupling.
What is a software design?
Software Design
Design phase of software development deals with
transforming the customer requirements as in the SRS
document into a form implementable using a programming
language. In order to be easily implementable in a conventional
programming language, the following items must be designed
during the design phase:
• Different modules required to implement the design
solution.
• Control relationship among the identified modules, i.e. the
call relationship among modules.
• Interface among different modules ie, details off data items
exchanged among different modules.
• Data structures of individual modules
• Algorithms required to implement individual modules.
Thus the goal of the design phase is to take the SRS in
document as the input and to produce the above-mentioned
items at the completion stage of design phase. A good software
design is seldom arrived through a single step procedure that
goes through a series of steps. We can broadly classify various
design activities into two important parts:
i. Preliminary design
ii. Detailed design
What is a Good Software Design?
Judging the goodness of design involves many subjective
factors, which depend on a particular application. EG: - A
embedded software may have to be implemented in a limited
series of memory and therefore one may have to sacrifice design
comprehensibility in order to achieve compactness while of
code. Therefore for embedded applications, factors like design
comprehensibility may take a back seat while judging a
goodness of a design. In other words a design solution, which
can be judged good for one application, may not be good for
© Copy Right: Rai University
48
another application. A good software design should have the
following desirable characteristics:
• A good design should capture all the functionalities of the
system correctly.
• It should be easily understandable.
• It should be efficient.
• It should be easily maintainable.
Understandability of design is a major factor, which is used to
evaluate for the goodness of a design, since a design is easily
understandable it is also easy to maintain and change, unless a
design is easily understandable it would require a tremendous
effort to maintain it. In order to enhance the understand ability
of a design, it should have the following features.
• Use of consistent and meaningful names for various design
components
• Use of a cleanly decomposed set of modules
• Neat management of modules in a hierarchy, tree like
diagram
Modular design is one of the fundamental principles of a good
design. Decomposition of a problem into modules facilitates
taking advantage of divide and conquer principle. If different
modules are almost independent of each other then each
module can be understood separately eventually reducing
complexity greatly.
Clean decomposition of a good design in to modules means
that the modules in a soft ware design should display high
cohesion and low coupling. We will shortly introduced the
concept of cohesion and coupling and discuss what these terms
mean.
Neat arrangement of modules in a hierarchy means
• Low fan out
• Abstraction
Cohesion and Coupling
A good software design implies clean decomposition of a
problem into modules and arrangement of these modules in a
neat hierarchy. The primary characteristics of a clean
decomposition are high cohesion and low coupling.
Cohesion is the measure of the functional strength of a
module where as coupling of module with another module is
the measure of degree of functional independence or
interaction between two modules.
A module having high cohesion and low coupling is said to be
functionally independent of other modules. By the term
functional independence we mean that a cohesive module
performs a single task or function. A functionally independent
module has minimal interactions with other modules.
3E.253
Functional independence is the key to good design primarily Functional Cohesion : A functional cohesion is said to exist if

SOFTWARE ENGINEERING TECHNIQUES

due to following reasons: different elements of the cohesion cooperate to achieve a single
• Functional independence reduces error propagation. function. Eg:- Managing an employees pay roll.
Therefore, an error existing in one module is not directly When a module displays functional cohesion and if we are
affects other modules and also error existing in other asked to describe what the module does we can describe it using
modules does not directly affect this module. a single sentence.
• Re-use of a module is possible, because each module
performs some well Coincidental Logical Temporal Procedural Communicational Sequential Functional
defined and precise
function and the interface Low High
of the module with other
modules is simple and minimal. Therefore any such module
Classification of Coupling
can be easily taken out and reused in a different program
Coupling indicates how closely two modules interact or how
• Complexity of a design is reduced because different modules independent they are. The degree of coupling between two
can be understood in isolation as modules are more or less modules depends on their interface complexity. Five types of
independent of each other. coupling can occur between two modules:
Even though no quantitative measures are available to Data Coupling: Two modules are data coupled if they
determine the degree of cohesion and coupling, a communicate via an elementary data item that is passed as a
understanding of different kinds of cohesion and coupling will parameter between the two. E.g.: Integer, float, character
give us some idea regarding the degree of cohesiveness of a
This data item should be a problem related and not used for
module. Therefore by examining the type of cohesiveness
the control purpose.
exhibited by a module, we can roughly tell whether it displays
high or low cohesion. Stamp Coupling: Two modules are stamp coupled if they
communicate via a composite data item such as a record in
Classifications of Cohesiveness PASCAL or a structure in ‘C’.
The different classes of cohesiveness that can exist in a design
Control Coupling: Control coupling exists between two
are depicted.
modules, if data from one module is used to direct the order
A module is said to have coincidental cohesion if it performs a of execution of instructions in another. An example of control
set of tasks that are related to each other very loosely. In case the coupling is a flag set in one module and tested in other module.
module contains random collection of functions. In this case it
Common Coupling : Two modules are common couples if
is likely that the functions have been put in the module out of
they share some global data areas.
pure coincidence without pure thought or design.
Content Coupling: Content coupling exists between two
Logical cohesion : A module is said to be logically cohesive, if
modules if their code is shared. Eg:- Branch from one module
all the elements of the similar operations e.g. error handling,
to another module.
data input data out put etc. An example of logical cohesion is
cases where a set of print functions generating an output report The degree of coupling is in ascending order from data
has been arranged in a single module. coupling to content coupling.
Temporal Cohesion : When a module contains tasks that are The different types of coupling are as given below.
related by the fact that all tasks must be executed in the same
Data Stamp Control Common Content
time span, the module is said to exhibit temporal cohesion.
The set of functions responsible for initialization start up, shut Low High
down of the same process etc exhibit temporal cohesion.
Procedural cohesion : A module is said to possess procedural
cohesion if the set of functions of the modules are all part of Effect on
procedure in which certain sequence of steps has to be carried Clean- overall
out in certain order for achieving an objective. Eg: the algorithm liness system
of Imple- Modifi- Understand- maintain-
for decoding a message. Cohesion level Coupling mentationability ability ability
Communication cohesion: A module is said to have Functional Good Good Good Good Good
communicational cohesion if all the functions of the module Fairly
Sequential Good Good Good Good
Good
refer to or update the same data structures. Eg : the set of Communicational Medium Medium Medium Medium Medium
functions defined on an array or a stack. Procedural Variable Poor Variable Variable Bad
Sequential Cohesion : A module is said to possess sequential Temporal Poor Medium Medium Medium Bad
Logical Bad Bad Bad Poor Bad
cohesion, if the elements of the module from different parts Coincidental Bad Poor Bad Bad Bad
of a sequence, where output of one element of a sequence is
the input to the next element of the sequence.

© Copy Right: Rai University

3E.253 49
 Summary
SOFTWARE ENGINEERING TECHNIQUES
In this lecture, we provided a broad overview of the activities
involved in software design phase. We then characterized the
features of a good software design by introducing the concepts
of cohesion and coupling. Cohesion is the measure of the
functional relatedness of elements (instructions, data
definitions, etc.) within a single module. In a good design, the
cohesion of every module is high. Together with coupling,
cohesion is one of the best measures of the quality of a design.
A module may exhibit any of seven levels of cohesion
depending on how the activities within the module are related.
In sequence from best to worst, these seven levels are:
functional (elements contribute to a single, problem related
activity); sequential (activities within the module are connected
in that the output from one serves as the input to another);
communicational (activities share the same input or output);
procedural (activities share the same procedural
implementation); temporal (activities can be carried out at the
same time); logical (activities appear to belong to the same
general category); coincidental (activities have no relationship to
one another).
The maintainability of modules with functional, sequential, and
communicational cohesion tends to be significantly higher than
that of modules of the four lowest levels of cohesion.
Exercises
1. What do you mean by the terms cohesion and coupling in
the context of software design? How are the concepts of
cohesion and coupling useful in arriving at good software
designs?
2. Enumerate the different types of cohesion that a module
might exhibit?
3. Enumerate the different types of coupling that might exist
between two modules?
4. Is it true that whenever you increase cohesion of different
modules in your design, coupling among these modules
automatically decreases? Justify your answer through a
suitable example.
5. What according to you is a good software design?
6. What do you understand by the term functional
independence in the context of a software design? How can
you achieve functional independence in a software design?
Assignment
1. Design a questionnaire to gather information about the user
interface of some tool (such as Spread sheet ) with which
you are familiar. Try to distribute the questionnaire to a
number of user and evaluate the results.
2. Draw possible data flow diagrams of system design for the
following.You may make reasonable assumptions.
A salary system. The input is a list of employee number who
are to be paid that month The system maintains tables holding
tax rates and the annual salary for each employee. The output is
a salary slip for each employee.
© Copy Right: Rai University
50
Further Readings and Information Sources
1. W. P. Stephens, G. J. Meyers, and L. L. Constantine,
“Structured Design,” IBM Systems Journal, 1974, vol. 13,
no. 2, pp. 115-139
2. D. L. Parnas, On the criteria to be used in decomposing
systems into modules, Communications of the ACM, v.15
n.12, p.1053-1058, Dec. 1972
3. Brian W. Kernighan , P. J. Plauger, The Elements of
Programming Style, McGraw-Hill, Inc., New York, NY, 1982
4. John B. Bowen, Module size: a standard or heuristic?,
Journal of Systems and Software, v.4 n.4, p.327-332, Nov.
1984
5. D. N. Card, F. E. McGarry, G. T. Pager et al., The Software
Engineerino Laboratory, NASA/GSFC, February 1982
6. Glenford J. Myers, Composite Structure Design, John Wiley
& Sons, Inc., New York, NY, 1978
7. R. D. Cruickshank and J. E. Gaffney, “Measuring the
Development Process: Software Design Coupling and
Strength Matrices,” Proceedings of the Fifth Annual
Software Engineering Workshop, NASA/GSFC, November
1980
8. Thomas J. Emerson, A discriminant metric for module
cohesion, Proceedings of the 7th international conference on
Software engineering, p.294-303, March 26-29, 1984,
Orlando, Florida, United States
9. L. A. Marascuilo and M. McSweeney, Nonparametric and
Distribution Free Methods for the Social Sciences. California:
Brooks/Cole, 1977, pp. 466-471, pp. 431-435
10. F. E. McGarry, “Measuring Software Development
Technology,” Proceedings of the Seventh Annual Software
Engineering Workshop, NASA/GSFC, December 1982
11. Peter C. Belford , Richard A. Berg , Thomas L. Hannan,
Central flow control software development: A case study of
the effectiveness of software engineering techniques,
Proceedings of the 4th international conference on Software
engineering, p.85-93, September 17-19, 1979, Munich,
Germany
12. Victor R. Basili , Barry T. Perricone, Software errors and
complexity: an empirical investigation0, Communications of
the ACM, v.27 n.1, p.42-52, Jan. 1984
Site Reference
http://www.waysys.com/ws_content_bl_pgssd_ch06.html
Notes
3E.253