Se 381 - lec 22 - 24 - 12 may15 - modularity - i - coupling


Published on

Software Engineering, Lectures

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Se 381 - lec 22 - 24 - 12 may15 - modularity - i - coupling

  1. 1. SE-381 Software Engineering BEIT-V Lecture # 22 (Modularity – I - Coupling)
  2. 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. 3. Component Size Versus Contact Interactions or Links
  4. 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. 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
  6. 6. 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
  7. 7. • Modularity has consequences for – Architectural Design – Component or Detailed Design – Debugging – Testing – Maintenance – Independent Development – Damage Control and – Software Reuse
  8. 8. 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)
  9. 9. 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
  10. 10. Coupling and Cohesion
  11. 11. 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)
  12. 12. 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
  13. 13. 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
  14. 14. 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
  15. 15. Global Data
  16. 16. Common Coupling Example
  17. 17. 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)
  18. 18. 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
  19. 19. 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
  20. 20. 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
  21. 21. 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 and; Ada also have similar constructs
  22. 22. Coupling Example
  23. 23. 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