IMSE Week 8 Refinement of Design - Coupling

1
IMSE Week 8Refinement of Design - Coupling
Cohesion

• a first cut Structure Chart and its corresponding
  PDL functions have been designed
• now inspect the Structure Chart for quality,
  using various criteria
• modularity
• information hiding
• coupling cohesion
• no clear, systematic method for achieving a high
  quality design
• instead guidelines, eg avoid global data

2
Modularity

• for manageability
• reduces complexity
• facilitates change (always needed)
• encourages parallel development of different
  parts of the system
• encourages reusability
• How many modules and how small should they be?
• When do we stop stepwise refinement?
• How much communication of information?
• In general we want one module to perform one task
  i.e. single-minded modules

3
Information Hiding

• a module should be designed so that its internal
  data is
• unwanted by other modules
• inaccessible to other modules
• where communication is essential use a carefully
  designed interface providing and returning the
  minimum amount of information necessary for the
  module to do its job
• produces great benefits
• maintainability (if modifications are made, there
  is no cascade effect in distant modules sharing
  the data)
• data security (hidden information cant be
  corrupted)
• reusability

4
Coupling Cohesion

• coupling is a measure of how independent or
  inter-dependent modules are
• has the module everything it needs or does it
  depend on any other module(s) to complete its
  task?
• cohesion (or binding) is a measure of how much
  the internal elements logically belong together
• has the module nothing more than it needs to do
  one task well, or does it contain extra
  undesirable elements?
• does it have more than one role?
• a module should encapsulate
• all the elements it needs (nothing missing) for
  loose coupling
• only the elements it needs (nothing extra) for
  high cohesion

5
Coupling

• measures the strength of the relationships
  between modules
• modules should be loosely coupled i.e.
  independent, interacting as little as possible
• the looser the coupling the easier it is to adapt
  the design

6
Cohesion

• each module should have one role
• all parts of a module should contribute to this
  one role
• it should not be made up of unrelated operations

7
Normal Coupling and Data Coupling

• Normal coupling
• one module calls another with no parameter
  passing nor return values (i.e. no data
  communication)
• e.g.clearScreen
• Data coupling
• data is passed between modules
• achieved via parameter passing
• and/or return values
• simple example

8
Stamp Coupling

• unnecessary data passed between modules
• e.g. whole personnel record sent to calc_age
  module when only the date of birth is needed
• makes the called module do more than it needs to
• makes it less reusable in programs with different
  record structures

9
Control Coupling

• procedure PrintRec is begin
  Display Name (name, sex)
• ..... end PrintRec
• procedure DisplayName (in name, sex) is
  begin if sex m
• then
• print Mr.
• else
• print Ms print
  the name end DisplayName

• one module passes a piece of information intended
  to control the internal logic of another -this
  may be data or a flag

10
Common (Global) and Content (Pathological)
Coupling

• Common (global) coupling - very undesirable
• communication via shared or global data
• Suppose modules A, B C each access some global
  data.
• Module A reads it and then invokes B, which
  alters it incorrectly.
• Later C reads it, attempts to process it, fails,
  and the program crashes.
• Apparent cause is module C, actual cause is
  module B.
• Content (pathological) coupling
• the highest and worst degree of coupling,
  occurring when either
• one module makes use of data or control
  information held within another module, or
• one module branches into the middle of another
  (gotos!)

11
Types of cohesion

• Functional - best type of cohesion
• all the modules elements are necessary for the
  single, specific task
• module contains all elements required for the
  task, and no more
• single minded modules
• Sequential
• the elements are related by sequence the output
  from one is the input for some other
• e.g. the 3 modules
• calc_gross_pay, calc_deductions,
  calc_net_pay
• Communicational
• all of the elements in a module operate on the
  same input data or produce the same output data

12
Types of cohesion (contd)

• Procedural
• the elements make up a single control sequence
  usually occurs if flowcharting has been used as a
  design technique
• Temporal
• the elements are all executed at the same time
  (e.g. initialization or close down)
• Logical
• the elements perform a set of logically related
  tasks e.g. different types of error handling
• Coincidental - the weakest type of cohesion
• no significant relationship between the elements
  of a module, they are simply bundled together by
  coincidence producing scatterbrained modules

13
An example of low cohesion

• consider an error processing module, called when
  a calculation is outside acceptable bounds
• its tasks are
• compute supplementary data
• display graphical error message on users screen
• perform additional user-requested calculations
• update database
• display menu for continuing
• these are loosely related tasks which should be
  decomposed or factored out into separate modules
  to avoid possible errors introduced by system
  changes

14
Hints for achieving Functional Cohesion

• write down a sentence describing the purpose of
  each function and then analyse it
• if it cannot be phrased without a comma or more
  than one verb it probably has sequential or
  communicational cohesion
• if it contains words concerning time (first,
  next, then, after, when, etc) then it probably
  has sequential or temporal cohesion
• if the verb is not followed by a simple, single
  noun then it probably has logical binding e.g.
  edit all data
• words such as initialise, clean up, etc suggest
  temporal cohesion

15
Features of a Good Design

• well designed systems have
• modularity
• loose coupling between modules
• high cohesion within modules
• in such systems a module may be more easily
• tested, maintained, understood, documented...
• re-used in other systems/programs
• replaced by a more efficient implementation
• in addition different modules can be developed,
  tested etc in parallel with other modules by a
  team of software engineers, saving development
  time

16
Refining Structure Charts

• we are now ready to return to the student marks
  program to refine our first cut structure chart
• we will apply our newly gained theoretical
  knowledge of coupling and cohesion to make any
  improvements that we can to the first cut
  structure chart
• our starting point is the set of PDL notations,
  one for each of the structure chart modules

17
4 Step Method of Refining

• step 1 - add pre-written modules
• e.g. library calls such as openFile, sqRoot
• step 2 - cohesion
• factor out any modules with more than one
  role
• step 3 - coupling
• alter a modules tasks to loosen any
  over-tight coupling,
• then look out for any hidden 2-way data
  communication, where data is passed to and
  returned from a submodule
• step 4 - add symbols
• include any necessary control constructs from
  the PDL, e.g. white diamonds for conditional
  invocation of submodules

18
And Finally

• double check that your refined structure chart
  still meets the requirements of the original DFD
• make any alterations to your PDLs to make them
  correspond to the revised structure chart
• be aware that there is not one single correct
  structure chart and set of PDLs for a given DFD -
  design is subjective and many interpretations of
  the workings of a system are possible