SE-381Software Engineering

BEIT-V

Lecture # 22

(Modularity – I - Coupling)

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

Component Size Versus Contact Interactions or Links

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

ModularityModules’ 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

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

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

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)

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

Coupling and Cohesion

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)

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

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

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

Global Data

Common Coupling Example

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)

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

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

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

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

Coupling Example

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