Page 135 - DCAP305_PRINCIPLES_OF_SOFTWARE_ENGINEERING

Unit 6: Functional Design

Software architecture embodies modularity, that is, software is divided into unconnectedly Notes
named and addressable components, often called modules that are integrated to satisfy problem
requirements. It has been stated that “modularity is the single attribute of software that allows a
program to be intellectually manageable”. Monolithic software (i.e., a large program composed
of a single module) cannot be easily grasped by a reader. The number of control paths, span
of reference, number of variables, and overall complexity would make understanding close to
impossible. To illustrate this point, consider the following argument based on observations of
human problem solving. Modularity is an important Software Engineering principle. It is a
practical application of the principle of “Separation of Concerns” by dividing a complex system
into simpler and more manageable modules. The ubiquitous television set is an example of a
system made up of a number of modules–speakers, projection tube, channel buttons, volume
buttons, etc. Each module has its own defined functionality but when they are put together
synergistically, the complete functionalities of a television are realized. Modularization can take
place in two ways: composition or decomposition. The composition or bottom-up approach takes
modules and puts them together to form a larger system. An application of such an approach
is in the assembly of a television set. The composition process begins with the assembling of
electronic components such as projection tube, buttons, speakers, control board, etc. into a
complete television. The alternative approach is to take a complete system and decompose it
into its modules. This approach is known as the decomposition or top-down approach. A car,
for example, can be decomposed into a number of sub-systems: Body, fuel system, electrical
system, transmission, etc. The electrical system can be further decomposed into modules such
as battery, alternator, lights, etc. The Lights module can in turn be decomposed into light
bulb, reflector, brackets, etc. This decomposition process repeats itself until all the elementary
components are identified.
The measure of inter-module relation is known as coupling. Design goals require modules to
have low-coupling and high cohesion. Cohesion is a measure of the inter-relatedness of elements
(statements, procedures, declarations) within a module. A module is said to have high cohesion
if all the elements in the module are strongly connected with one another. Tight coupling of
modules makes analysis, understanding, modification and testing of modules difficult. Reuse
of modules is also hindered.

• 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.

• 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.
6.4.1 Modularity Helps in System

The modularity helps the system in the following way:
• Debugging—Isolating the system problem to a component is easier if the system is modular.
• In system repair—Changing a part of the system is easy as it affects few other parts;

• In system building—A modular system can be easily built by “putting its modules
together.”

• 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.

LOVELY PROFESSIONAL UNIVERSITY 129