Effective modular design is a critical aspect of software development, contributing to the overall success and maintainability of a software system.

1. Effective Modular
Unit IV
Lecture no. 28
By Dr. Shweta Saraswat

2. What is Modular Design?
Definition:
A design based on modular units that can be
assembled in a variety of ways.

8. Now What is Modularity?
Definition of Modularity:
• Software is divided into separately named an addressable
components, called modules, that are integrated to
satisfy problem requirements.
• The graph shown refers to the question of Modularity
and Software Cost, and is a useful tool to consider when
modularity is to be implemented. In this graph, the cost
or effort drops as more modules are considered, but the
cost to interface modules increases as we have more
modules. Thus, we must take care to stay in the region of
minimum cost, i.e. a balance between the number of
modules and the cost or effort.

9. Example

10. Effective Modular Design
• Modularity is an accepted approach in all
engineering disciplines
• Reduces complexity and facilitates changes
in modules
• Easier implementation

11. Effective Modular Design
• Modularity The real power of partitioning comes if a
system is partitioned into modules so that the modules
are solvable and modifiable separately.
• It will be even better if the modules are also separately
compliable (then, changes in a module will not require
recompilation of the whole system).
• A system is considered modular if it consists of discreet
components so that each component can be
implemented separately, and a change to one
component has minimal impact on other components.

12. Effective Modular Design
• Modularity is a clearly a desirable property in a
system.
• Modularity helps in system debugging. Isolating the
system problem to a component is easier if the
system is modular.
• In system repair, hanging a part of the system is easy
as it affects few other parts and in system building, a
modular system can be easily built by “putting its
modules together.”

13. Effective Modular Design
• A software system cannot be made modular by simply
chopping it into a set of modules.
• For modularity, each module needs to support a well-
defined abstraction and have a clear interface through
which it can interact with other modules.
• Modularity is where abstraction and partitioning come
together.
• For easily understandable and maintainable systems,
modularity is clearly the basic objective; partitioning and
abstraction can be viewed as concepts that help achieve
modularity.

14. Desirable Characteristics of Module
• The attributes of a good module are as follows:
• A small program that can be invoked by the operating
system, or it could be a sub-program invoked by another
module(shareable)
• The statement are collectively referred to by a
descriptive name called the module name
• A module must return to its caller i.e. have a single entry
and exit; (single entry and exit module to ensure that
modules are closed and simplify program maintenance)
• The module should be relatively small in size (small
modules allow for more easily amended programs,
estimating and project control more accurate and
exhaustive testing are easier)
• It should be easy to read, modify and use
• A module should preferably have a single function

15. Advantages of Modularity
• Rationale for Modularity
• Allow large program to be written by several or
different people
• Encourage creation of commonly used routines to be
placed in library and/or be used by other programs
• Simplify overlay procedure of loading large program
into main storage
• Provide more check point to measure progress
• Simplify design, making program easy to modify and
reduce maintenance costs
• Provide a framework for more complete testing,
easier to test
• Produces well-designed and more readable program

16. Disadvantages of Modularity
• Rational Against Modularity
• Execution time may be, but not necessarily,
longer
• Storage size may be, but is not necessarily,
increased
• Compilation and loading time may be longer
• Intermodule communication problems may be
increased
• Demands more initial design time
• More linkage required, run-time may be longer,
more source lines must be written and more
documentation has to be done

17. Top-Down and Bottom-Up Strategies
• A system consists of components, which have components of
their own; indeed, a system is a hierarchy of components.
• The highest-level component corresponds to the total system.
• To design such a hierarchy there are two possible approaches:
top-down and bottom-up.
• The top-down approach starts from the highest-level
component of the hierarchy and proceeds to lower levels.
• By contrast, a bottom-up approach starts with the lowest-
level component of the hierarchy and proceeds through
progressively higher levels to the top-level component.

18. Module-Level Concepts
• A module is a logically separable part of a program. It is a
program unit that is discreet and identifiable with respect to
compiling and loading. In terms of common programming
language constructs, a module can be a macro, a function, a
procedure (or subroutine), a” process, or a package. In
systems using functional abstraction, a module is usually a
procedure of function or a collection of these.
• To produce modular designs, some criteria must be used to
select modules so that the modules support well-defined
abstractions and are solvable and modifiable separately. In a
system using functional abstraction, coupling and cohesion
are two modularization criteria, which are often used
together.

19. Functional Independence
• The concept of functional independence is a direct outgrowth of
modularity and the concepts of abstraction and information hiding.
• Functional independence is achieved by developing modules with “single-
minded’ function and an “aversion” to excessive interaction with other
modules.
• Stated another way, we want to design software so that each module
addresses a specific sub-function of requirements and has a simple
interface, when viewed from other parts of the program structure. It is fair
to ask, why independence is important.
• Software with effective modularity, that is, independent modules, is
easier to develop because functions may be compartmentalized and
interfaces are simplified (consider the ramifications when development is
conducted by a team).
• Independent modules are easier to maintain (and test) because
secondary effects caused by design or code modification are limited, error
propagation is reduced, and reusable modules are possible.
• To summarize, functional independence is a key to good design, and
design is the key to software quality.

20. Data Structure
• Data structure is a representation of the logical relationship
among individual elements of data.
• Because the structure of information will invariably affect the
final procedural design, data structure is as important as
program structure to the representation of software
architecture.
• Data structure dictates the organization, methods of access,
degree of associativity, and processing alternatives for
information.
• Entire texts have been dedicated to these topics, and a
complete discussion is beyond the scope of this book.
• However, it is important to understand the classic methods
available for organizing information and the concepts that
underlie information hierarchies.

21. Coupling
• A fundamental goal of software design is to structure the software
product so that the number and complexity of interconnections between
modules is minimized.
• An appealing set of heuristics, for achieving this goal, involves the
concepts of coupling and cohesion.
• Two modules are considered independent if one can function completely
without the presence of other.
• Obviously, if two modules are independent, they are solvable and
modifiable separately.
• However, all the modules in a system cannot be independent of each
other, as they must interact so that together, they produce the desired
external behavior of the system.
• The more connections between modules, the more dependent they are in
the sense that more knowledge about one module is required to
understand or solve the other module.
• Hence, the fewer and simpler the connections between modules, the
easier it is to understand one without understanding the other. The notion
of coupling attempts to capture this concept of “how strongly” different
modules are interconnected.

22. Cohesion
• The internal cohesion of a module is measured in terms of the strength of binding
elements within the module. Cohesion of elements occurs on the scale of weakest
(least desirable) to strongest (most desirable).
• We have seen that coupling is reduced, when the relationships among elements, in
different modules are minimized. That is, coupling is reduced when elements in
different modules have little or no bonds between them. Another way of achieving this
effect is to strengthen the bond between elements of the same module by maximizing
the relationship between elements of the same module. Cohesion is the concept that
tries to capture this intramodule. With cohesion, we are interested in determining how
closely the elements of a module are related to each other.
• Cohesion of a module represents how tightly the internal elements of the module are
bound to one another. Cohesion of a module gives the designer an idea about whether
the different elements of a module belong together in the same module. Cohesion and
coupling are clearly related. Usually, the greater the cohesion of each module in the
system, the lower the coupling between modules is. This correlation is not perfect, but
it has been observed in practice. There are several levels of cohesion:
• Coincidental
• Logical
• Temporal
• Procedural
• Communicational
• Sequential
• Functional

23. Cohesion
• Coincidental is the lowest level, and functional is the highest. These levels do not form a
linear scale. Functional binding is much stronger than the rest, while the first two are
considered much weaker than others.
• Coincidental cohesion occurs when there is no meaningful relationship among the
elements of a module. Coincidental cohesion can occur if an existing program is
“modularized”, by chopping it into pieces and making different piece modules.
• A module has logical cohesion if there is some logical relationship between the elements
of a module, and the elements perform functions that fall in the same logical class.
• Temporal cohesion is the same as logical cohesion, except that the elements are also
related in time and are executed together
• A procedurally cohesive module contains elements that belong to a common procedural
unit. For example, a loop or a sequence of decision statements in a module may be
combined to form a separate module.
• A module with communicational cohesion has elements that are related by a reference to
the same input or output data.
• When the elements are together in a module, because the output of one forms the input
to another, we get sequential cohesion.
• Functional cohesion is the strongest cohesion. In a functionally bound module, all the
elements of the module are related to performing a single function.

24. Conclusion
• A software system cannot be made modular by simply
chopping it into a set of modules.
• For modularity, each module needs to support a well-
defined abstraction and have a clear interface through
which it can interact with other modules.
• Modularity is where abstraction and partitioning come
together.
• For easily understandable and maintainable systems,
modularity is clearly the basic objective; partitioning and
abstraction can be viewed as concepts that help achieve
modularity.

25. Thank You