This document discusses modularity and coupling in software engineering. It defines that programs are comprised of components that communicate to achieve program goals. Component size can vary, but should generally be 5-9 statements to fit in human working memory. Modularity partitions a system into components to improve design, maintenance, testing and more. Coupling describes the interaction between components, with loose/weak coupling like data coupling being preferred over tight/strong coupling like content coupling. The document provides examples to illustrate different types of coupling and how modularity improves software engineering.

1. SE-381
Software Engineering
BEIT-V
Lecture # 22
(Modularity – I - Coupling)

2. Program and its Components
– Like all other engineering artifacts, programs
are comprised of components.
– Components can be small or large, but all
communicate with each other to achieve the
goal of the program
– A program can have various program
structures; one having small number of Large
components having few links or another
having large number of Small components
having a large number of links between them
to achieve the assigned goal of the program

3. Component Size Versus Contact
Interactions or Links

4. How Large Should be a
Component?
– One page (40-50 statements)?
– Only 5-9 statements long? as a human mind
can store 7 2 items in its active memory – a
research from cognitive and psychological
sciences areas.
– Or in between the two sizes.
– Size of components ∞ (no. of Components) - 1

5. Modularity
Modules’ Cost Vurses Size
Larger the module size higher the cost and vice versa, overall cost of
system is dependent on other costs as well, like Module Integration cost

7. Why Modularity?
• Modularity is to partition the software system into
number of components, whereas a Component
could be a method, a class, a package or a
module.
• Modularity is important throughout the SD
including Design and Maintenance.
• Ideally each component should be self
contained and have as few references to other
modules as possible.
• Correlation with other Engineering artifacts

8. • Modularity has consequences for
– Architectural Design
– Component or Detailed Design
– Debugging
– Testing
– Maintenance
– Independent Development
– Damage Control and
– Software Reuse

9. Types of Components
• Generically for sake of discussion,
components could be classified as per
their roles as:
– Computation Only (retain no data, math
methods or filters in Unix)
– Memory (persistent data maintenance & use)
– Manager
– Controller
– Link (UI or Main Pipes)

10. Coupling and Cohesion
• Coupling and Cohesion are the terms that
describe the character of the interaction
between components and within components
respectively.
• These are complimentary.
• Strong Coupling and Weak Cohesion are bad,
Weak Coupling and Strong Cohesion are good
• These terms provide a terminology for
qualitative analysis of Modularity

11. Coupling and Cohesion

12. Coupling
• Coupling is the degree of interaction
between two modules.
• It is of 5 types
1. Content Coupling (Bad or Undesirable)
2. Common Coupling
3. Control Coupling
4. Stamp Coupling
5. Data Coupling (Good or the Desirable)
6. Data Stream Coupling (Good and Desirable)

13. Content Coupling
• The two modules are Content-Coupled if
one can change the others contents
• Earlier programming languages had constructs to
perform such tricky things, but realizing problems
this sort of coupling may cause, these constructs
have been abolished, Eg alter in earlier versions of
COBOL has now been removed. Currently only
Assembly Language can do it.
• Maintainability and reuse problems

14. Global Data (Common) Coupling
• When two or more modules have (read as
well as write) access to global data they are
said to be Common Coupled
• ‘Common’ comes from FORTRAN COMMON
statement, initiated to relinquish long
parameter lists, and to share data; COMMON
in FORTRAN and global in COBOL-80,
Public data or methods in modern languages
• Problems:
• Most data (Shared data) passed to the modules thru
COMMON blocks not thru the parameter lists, so
modules are difficult to comprehend and read
• Any module having access can change it so difficult to
determine ‘who changed when’ in case of problem, so
difficult to debug and maintain

15. Common Coupling .
• Data is un-necessarily exposed to modules where it should
not be, thus compromising the Security
• Maintenance changes made in one of the modules to the
declaration (say array size) of a global variable, then that
change has to be made in every module that has access to
that variable
• Common-coupled modules are difficult to reuse, since
identical list of global variables has to be supplied each time
the module is reused
– Despite problems, one can benefit from the gains of
COMMON statement, if applied carefully and
Access levels of different modules to different
blocks are well documented, and the set
guidelines for Common use are strictly
implemented by the Management

16. Global Data

17. Common Coupling Example

18. Control Coupling
• When a module passes control or switch to
another module then it explicitly controls the
logic of the other module, then these are called
as control-coupled modules
– Ex
• Call io (command, device, buffer, length), where command
can have values 0, 1 and 2 for operations read, write and
open
• This called module io and its calling module will be control-
coupled, calling module needs to know the internal structure
of io, or it’s controlling the logic of called module
• Instead io should be replaced by three modules of read, write
and open like
Call read(device, buffer, length)

19. Control coupling.
• Two modules are not independent, the calling has
to be aware of internal structure and the logic of
the called module, reuse not possible
• Generally Control Coupling is associated with
modules that have logical Cohesion, and so
difficulties with logical cohesion are also present

20. Stamp Coupling
• Two modules are Stamp-coupled if the calling
module passes on data structure to the called
module, which uses only some individual
components of the data structure
– Eg
• Calculate withholding (employee_record), where
employee_record data structure contains all data related to
employee, his name, contact, qualification, but only salary is
used to calculate withholding
• Insecurity, called module will have access to not
needed data
• Use of data structures as arguments is
recommended provided they are fully used

21. Data Coupling
• Two modules are data-coupled if all arguments
are homogeneous data items. Every item can
either be a data structure or a simple element,
but should be used in called module
– Ex
• Calculate withholding (employee_salary), where
employee_salary is the salary of employee
• This is the most desired coupling, results in
independent, easily maintainable and re-usable
modules

22. Stream Coupling
• Passing of a serial data stream,
• This is the weakest or the best coupling
achieved without any transfer of control between
components.
• It is like one component is out puting information
to a serial file and other component is reading
from there.
• New languages like Java have library functions
like java.io.PipedInputStream and
java.io.PipedOutputStream; Ada also have
similar constructs

23. Coupling Example

25. References
1. Douglas Bell (2005); Software Engineering for Students; 4th
Edition, Pearson Education, Ch-6, Modularity, pp 67-86
2. Stephen R Schach (2007); Software Engineering, 7th Edition,
Tata McGraw-Hill Publishing Company Limited, New Delhi,
Ch-7 From Modules to Objects, pp 177 - 218
3. Pankaje Jalote (2004); An Integrated Approach to Software
Engineering, 2nd Edition; Narosa Publishing House, New Delhi;
Ch – 5
4. S A Kelkar (2007); Software Engineering – A Concise Study;
Prentice-Hall of India, New Delhi, pp 548-550