7.
MODULAR
AND
STRUCTURED
DESIGN
Module Specification
Modularization is the decomposition of a system into
subcomponents or small units
A module is a collection of instructions & data
structure
Modules should be such that it can be separately
compiled & stored
Module should be such that it can be use by other
modules
It makes process of debugging, testing, integration of
system easy
Criteria to evaluate a program module
Function decomposition approach software is
partitioned into independent modules so that
each module is small enough to be manageable
Objectives of modular software design
1. Functional partitioning into discrete scalable ,
reusable modules
2. Rigorous use of well-defined modular interface
3. Ease of change to achieve technology
transparency and to the extent possible make use
of industry standards for key interfaces
Modularity is the principle of keeping separate the various unrelated
aspects of a system, so that each aspect can be studied in isolation
(also called separation of concerns)
If the principle is applied well, each resulting module will have a single
purpose and will be relatively independent of the others
each module will be easy to understand and develop
easier to locate faults (because there are fewer suspect modules per
fault)
Easier to change the system (because a change to one module affects
relatively few other modules
Cohesion & Coupling (v. imp)
Cohesion is a measure of the functional strength
of a module whereas the
Coupling between two modules is a measure of
degree of interdependence or interaction
between two modules
A module having High Cohesion and Low Coupling
is said to be functional Independent
Classification of Cohesiveness
coincide Logical Tempora Procedur Commun Sequenti Function
ntal l al icational al al
Low High
1. Coincidental – if a module performs a set of tasks that
relate to other very loosely
2. Logical- if all elements of the module performs similar
operations such as error handling, data input, etc
3. Temporal- When a module contains functions that are
related by the fact that all the functions must be
executed in the same time span. Eg start or shut down of
any process
4. Procedural – If the set of functions of the module are all
part of procedure in which certain sequence of steps
has to be carried out for achieving an objective
Eg login(), place order() ,check order(), print bill().
5. Communicational- if all functions of the module
refer to or update the same data structure.
Eg in student management system all modules
such as admissions, exam, consist of a named
student which is to be updated
Classification of Cohesiveness
coincide Logical Tempora Procedur Commun Sequenti Function
ntal l al icational al al
Low High
6. Sequential- if the elements of a module from the parts of a
sequence where the output from one element of the sequence
is input to next
7. Functional- If all element of a module cooperate to achieve a
single function
Classification of Coupling
1. Data- two modules are data coupled if they communicate using an
elementary data items that is passed as a parameter between the two.
Eg int, float
2. Stamp coupling : Stamp coupling occurs when modules share a
data structure and use only parts of it, possibly different parts (e.g.,
passing a whole record to a function that only needs one field of it).
In this situation, a modification in a field that a module does not need
may lead to changing the way the module reads the record.
3.External coupling: External coupling occurs when
two modules share an externally imposed data
format, communication protocol, or device interface.
This is basically related to the communication to
external tools and devices.
4. Control- If data from one module is used to direct the order of
instruction execution in other module.
5. Common- If they share some global data items
6. Content- If there code is shared. Example:
Component directly modifies another’s data
Component modifies another’s code, e.g., jumps (goto) into the middle of
a routine
Characteristics of Good Design
Component independence
High cohesion
Low coupling
Exception identification and handling
Fault prevention and fault tolerance
Design for change
Top Down Design
We know that a system is composed of more than one sub-
systems and it contains a number of components.
Further, these sub-systems and components may have their
own set of sub-system and components and creates hierarchical
structure in the system.
Top-down design takes the whole software system as one entity
and then decomposes it to achieve more than one sub-
system or component based on some characteristics.
Each sub-system or component is then treated as a system and
decomposed further.
This process keeps on running until the lowest level of system
in the top-down hierarchy is achieved.
Top-down design is more suitable when the software solution
needs to be designed from scratch and specific details are
unknown.
Bottom-up Design
The bottom up design model starts with most specific and basic
components.
It proceeds with composing higher level of components by using basic or
lower level components.
It keeps creating higher level components until the desired system is not
evolved as one single component. With each higher level, the amount of
abstraction is increased.
Bottom-up strategy is more suitable when a system needs to be created
from some existing system, where the basic primitives can be used in
the newer system.
Both, top-down and bottom-up approaches are not practical individually.
Instead, a good combination of both is used.
