coupling and cohesion in software engineering


Coupling

  • The degree of interdependence between two modules”
  • We aim to minimise coupling – to make modules as independent as possible
    Low coupling can be achieve by:
  • eliminating unnecessary relationships
  • reducing the number of necessary relationships
  • easeing the ‘tightness’ of necessary relationships

Types of Coupling

  • Data coupling       (Most Required)   
  • Stamp coupling
  • Control coupling
  • Hybrid coupling
  • Common coupling
  • Content coupling  (Least Required)

Data Coupling 

  • Modules communicate by parameters
  • Each parameter is an elementary piece of data
  • Each parameter is necessary to the communication
  • Nothing extra is needed

Data coupling problems

  • Too many parameters – makes the interface difficult to understand and possible error to occur
  • Tramp data – data ‘traveling’ across modules before being used

Stamp coupling

  • A composite data is passed between modules
  • Internal structure contains data not used
  • Bundling – grouping of unrelated data into an artificial structure

Control coupling

  • A module controls the logic of another module through the parameter
  • Controlling module needs to know how the other module works – not flexible!

Hybrid coupling

  • A subset of data used as control
  • Example: account numbers 00001 to 99999
  • If 90000 – 90999, send mail to area code of last 3 digit (000 – 999)

Common coupling

  • Use of global data as communication between modules
  • Dangers of
  • ripple effect
  • inflexibility
  • difficult to understand the use of data

Content coupling

  • A module refers to the inside of another module
  • Branch into another module
  • Refers to data within another module
  • Changes the internal workings of another module
  • Mostly by low-level languages

Cohesion

  • “The measure of the strength of functional relatedness of elements within a module”
  • Elements: instructions, groups of instructions, data definition, call of another module
  • We aim for strongly cohesive modules
  • Everything in module should be related to one another – focus on the task
  • Strong cohesion will reduce relations between modules – minimise coupling

      Types of Cohesion

  • Functional cohesion (Most Required)
  • Sequential cohesion
  • Communicational cohesion
  • Procedural cohesion
  • Temporal cohesion
  • Logical cohesion
  • Coincidental cohesion (Least Required)

Functional cohesion

  • All elements contribute to the execution of one and only one problem-related task
  • Focussed – strong, single-minded purpose
  • No elements doing unrelated activities
  • Examples of functional cohesive modules:
  • Compute cosine of angle
  • Read transaction record
  • Assign seat to airline passenger

Sequential cohesion

  • Elements are involved in activities such that output data from one activity becomes input data to the next
  • Usually has good coupling and is easily maintained
  • Not so readily reusable because activities that will not in general be useful together
  • Example of Sequential Cohesion
  • module format and cross-validate record
  •    use raw record
  •     format raw record
  •    cross-validate fields in raw record
  •    return formatted cross-validated record
                 end module

Communicational Cohesion

  • Elements contribute to activities that use the same input or output data
  • Not flexible, for example, if we need to focus on some activities and not the others
  • Possible links that cause activities to affect each other
  • Better to split to functional cohesive ones
  • Example of Communicational Cohesion
  • module determine customer details
  •    use customer account no
  •    find customer name
  •    find customer loan balance
  •    return customer name, loan balance
end module

Procedural cohesion

  • Elements are related only by sequence, otherwise the activities are unrelated
  • Similar to sequential cohesion, except for the fact that elements are unrelated
  • Commonly found at the top of hierarchy, such as the main program module
  • Example of Procedural Cohesion
  • module write read and edit something
  •    use out record
  •    write out record
  •    read in record
  •    pad numeric fields with zeros
  •    return in record
         end module

Temporal cohesion

  • Elements are involved in activities that are related in time
  • Commonly found in initialization and termination modules
  • Elements are basically unrelated, so the module will be difficult to reuse
  • Good practice is to initialise as late as possible and terminate as early as possible
  • Example of Temporal Cohesion
  • module initialise
  •    set counter to 0
  •    open student file
  •    clear error message variable
  •    initialise array
       end module

Logical cohesion

  • Elements contribute to activities of the same general category (type)
  • For example, a report module, display module or I/O module
  • Usually have control coupling, since one of the activities will be selected
  • Example of Logical Cohesion
  • module display record
      use record-type, record
      if record-type is student then
             display student record
      else if record-type is staff then
             display staff record
end module

Coincidental cohesion

  • Elements contribute to activities with no meaningful relationship to one another
  • Similar to logical cohesion, except the activities may not even be the same type
  • Mixture of activities – like ‘rojak’!
  • Difficult to understand and maintain, with strong possibilities of causing ‘side effects’ every time the module is modified
  • Example of Coincidental Cohesion
module miscellaneous functions
   use customer record
   display customer record
   calculate total sales
   read transaction record
   return transaction record
end module