Software Design Concepts: Modularity

1
Software Design Concepts Modularity

• What about global data?
• Global data is harmful!
• To understand A we must know about B C because
  of the global data
• To change 1 of the modules, if we need to change
  the data
• Local data is better because
• easier to read study
• easier to remove a procedure
• maintenance is easier
• reusability

Global data shared
A
B
C
2
Software Design Concepts Modularity

• Modularity - Cohesion and Coupling
• (ref Bell et al ch. 5)
• Cohesion - the degree of interaction within a
  module
• Coupling - the degree of interaction between
  modules
• COHESION
• Coincidental Cohesion - tasks which are unrelated
• difficult to maintain (no advantage in
  modularization)
• no reusability
• Logical Cohesion - tasks in a module are
  logically related
• e.g. all the tasks are to do with input.
• interface is difficult to understand
• difficult to maintain if code for individual
  tasks is related

3
Software Design Concepts Modularity

• Temporal Cohesion - tasks in a module are related
  by the fact they are done at the same time
• e.g. initialisation module
• tasks are not related and so if changes are to be
  made in this module, other parts will have to be
  changed also.
• modules name may not adequately describe its
  purpose
• Procedural Cohesion - tasks are related because
  they are done in a sequence.
• e.g. read item price, calculate amount due,
  update stock file
• better than temporal since actions are related
• but still module is likely not to be reusable
  since this relation is weak
• since all parts of the module do not deal with
  the same data, it may be difficult to find
  associated pieces

4
Software Design Concepts Modularity

• Communicational Cohesion - tasks are related
  procedurally but also are on the same data.
• e.g. read item price, calculate amount due, print
  total
• better than procedural cohesion
• still not very reusable
• Sequential Cohesion - output of one component of
  the module forms input for the next.
• e.g. read transaction file, update master file
  (pipe-lined tasks!)
• not reusable
• Functional Cohesion - All components contribute
  to a single function of the module.
• e.g. calculate VAT (one verb and one noun)
• reusable
• easily maintained

5
Software Design Concepts Modularity

• Summary of Cohesion Types (He, Z. Nov. 1999)

6
Software Design Concepts Modularity
Compute average daily temperatures at various
sites

• Example

coincidental
functional
coincidental
functional
initialise sums and open files
create new temperature record
store temperature record
close files and print average temperatures
logical
functional
read in site, time, and temperature
store record for specific site
logical
edit site, time or temperature field
7
Software Design Concepts Modularity

• COUPLING
• Content Coupling - One module directly affects
  the working of another. Calling module can modify
  the called module or refer to an internally
  defined data element.
• e.g. GOTO.
• makes maintenance very difficult as program will
  be difficult to understand.
• never allow this type of coupling!
• Common Coupling - Two modules accesses the same
  global data.
• E.g. Data division in COBOL
• resulting code is difficult to read
• side affects e.g has another module changed a
  variable?
• programs are costly to maintain as a change to a
  global variable means the whole program has to be
  searched to find its affect
• reusability is poor
• security problems. A module has access to more
  data than it needs

8
Software Design Concepts Modularity

• Control Coupling - One module passes information
  (e.g. flag) which will affect the logic of the
  other module.
• modules are not independent and so reuse is
  limited
• violates principle of information hiding (see
  later)
• calling module must know how the called module
  works

Remove the flag by having two modules, one for
increasing stock level, the other for decreasing
stock levels
9
Software Design Concepts Modularity

• Stamp Coupling - complete data structures are
  passed from one module to another, with the data
  structure being defined in both but not all
  components of the data structure are changed
• more data than is necessary is passed
• Data Coupling - data required by a module is
  passed from another (parameters)

Desirable - HIGH COHESION (functional cohesion)
LOW COUPLING (data coupling)
10
Software Design Concepts Information Hiding

• Information hiding
• Each module has information which other modules
  have no access to
• Hence a change to this cannot affect any other
  module
• increases cohesion, since the information hide
  binds the components of the module together
• design decisions that may change at a later date
  should be hidden from other modules. In this
  maintainability is increased since only that
  module needs to know about the change