Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
SlideShare a Scribd company logo

software engineering

•Download as PPTX, PDF•
•
A
Abinaya B

The document discusses criteria for modularization in software design. It defines modules as named entities that can contain instructions, processing logic, and data structures. Modularization aims to minimize coupling between modules and maximize cohesion within modules. Strong coupling like content coupling is undesirable, while data and stamp coupling are more desirable. Cohesion within a module is best when elements are functionally related to a single function. Additional criteria for modularization include hiding design decisions and isolating machine dependencies.

1 of 16
MODULES AND MODULARIZATION CRITERIA BY, R.RAMADEVI, II-M.SC(CS&IT), Nadar Saraswathi College Of Arts and Science, Theni.
MODULES AND MODULARIZATION CRITERIA  Architectural design has the goal of producing well structured modular software system  We consider a software module to be a named entity following characteristics 1.Modules contain instruction , processing login and data structures 2.Modules can be separately compiled and stored in library 3.Modules can be included in program 4.Modules segment can be used by invoking a name 5.Modules can be other modules
Examples of modules: The include procedures , subroutines , function functional group of related procedures subroutiones and functions Modularization can be used to isolated machine dependencies to import the performance of software product or ease debugging testing integration tuning and modification of the system Depending on the criteria used different system structures may result
EXAMPLES OF MODLES  Which each module and its submodules correspond to a processing step  The execution sequence each module hides a difficult or changeable design decision from the other modules  Function that access and modify the data structures levels of abstraction
EXAMPLES OF MODLES  The modules and collection of modules provide a hierarchial set of increasingly complex services coupling cohesion  There are two version of problem modeling  The data structures match the problem structure and the visible function manipulate the data structures  The modules form a network of communicating processes
COUPLING AND COHESION  A fundamental goal of software design is structures the software product so the number and complexity of interconnection between modules is minimized  Coupling and cohesion were first described by stevents , constrantine and myers as part of the “structured design”  The strength of coupling between two modules is influenced by the complexity of the interface  Modification of a common data block or control may require modification of all routines that are coupling to the block  If modules communication only by parameters and the interface between modules remain fixed
COUPLING AND COHESION  coupling between modules can be ranked on of strongest to weakest 1.Content coupling 2.Common coupling 3.Control coupling 4.Stamp coupling 5.Data coupling Content coupling occurs one module modifies local data values or structions in another module
COUPLING AND COHESION  Control coupling involve passing control flags between modules so that one modules controls the sequence of processing steps in another module  Stamp coupling is similar to common coupling except that global data item  Named common block in FORTRAN and package in Ada support stamp coupling  Data coupling involves the use of parameter list to pass data items between routines
COHESION OF ELEMENTS OCCURS ON THE SCALE BINDING OF ELEMENT WITHIN MODULES  Coincidental cohesion  Logical cohesion  Temporal cohesion  Communication cohesion  Sequential cohesion  Functional cohesion  Informational cohesion
Content Coupling: Content coupling occurs when one module modifies local data values or instructions in another module. Common Coupling: Modules are bound together by global data structures. Control Coupling: Control coupling involves passing control flags(as parameters or globals) between modules so that one module controls the sequence of processing steps in another module.
Stamp Coupling: Stamp coupling is similar to common coupling, except that global data items are shared selectively among routines that require the data. Data Coupling: Data coupling involves the use of parameter lists to pass data items between routines. The most desirable form of coupling between modules is a combination of stamp and data coupling.
Coincidental Cohesion: Coincidental cohesion occurs when the elements within a module have no apparent relationship to one another. Logical Cohesion: Logical cohesion implies some relationship among the elements of the module. Ex: In a module that performs all input and output operations, or in a module that edits all data.
Temporal Cohesion: Modules with temporal cohesion exhibit many of the same disadvantages as logically bound modules. A typical example of temporal cohesion is a module that performs program initialization. Communication Cohesion: The elements of a module possessing communicational cohesion refer to the same set of input and/or output data. Ex: “Print and Punch the Output File” is communicationally bound.
Sequential Cohesion: Sequential cohesion of elements occurs when the output of one element is the input for the next element. Functional Cohesion: Functional cohesion is a strong, and hence desirable, type of binding of elements in a module because all elements are related to the performance of a single function. Informational Cohesion: Informational cohesion of elements in a module occurs when the module contains a complex data structure and several routines to manipulate the data structure.
Other Modularization Criteria Additional criteria for deciding which functions to place in which modules of a software system include: Hiding difficult and changeable design decisions Limiting the physical size of modules Structuring the system to improve observability and testability Isolating machine dependencies to a few routines Easing likely changes Providing general purpose utility functions Reducing the call return overhead of excessive subroutine calls.
software engineering

More Related Content

software engineering

  • 1. MODULES AND MODULARIZATION CRITERIA BY, R.RAMADEVI, II-M.SC(CS&IT), Nadar Saraswathi College Of Arts and Science, Theni.
  • 2. MODULES AND MODULARIZATION CRITERIA  Architectural design has the goal of producing well structured modular software system  We consider a software module to be a named entity following characteristics 1.Modules contain instruction , processing login and data structures 2.Modules can be separately compiled and stored in library 3.Modules can be included in program 4.Modules segment can be used by invoking a name 5.Modules can be other modules
  • 3. Examples of modules: The include procedures , subroutines , function functional group of related procedures subroutiones and functions Modularization can be used to isolated machine dependencies to import the performance of software product or ease debugging testing integration tuning and modification of the system Depending on the criteria used different system structures may result
  • 4. EXAMPLES OF MODLES  Which each module and its submodules correspond to a processing step  The execution sequence each module hides a difficult or changeable design decision from the other modules  Function that access and modify the data structures levels of abstraction
  • 5. EXAMPLES OF MODLES  The modules and collection of modules provide a hierarchial set of increasingly complex services coupling cohesion  There are two version of problem modeling  The data structures match the problem structure and the visible function manipulate the data structures  The modules form a network of communicating processes
  • 6. COUPLING AND COHESION  A fundamental goal of software design is structures the software product so the number and complexity of interconnection between modules is minimized  Coupling and cohesion were first described by stevents , constrantine and myers as part of the “structured design”  The strength of coupling between two modules is influenced by the complexity of the interface  Modification of a common data block or control may require modification of all routines that are coupling to the block  If modules communication only by parameters and the interface between modules remain fixed
  • 7. COUPLING AND COHESION  coupling between modules can be ranked on of strongest to weakest 1.Content coupling 2.Common coupling 3.Control coupling 4.Stamp coupling 5.Data coupling Content coupling occurs one module modifies local data values or structions in another module
  • 8. COUPLING AND COHESION  Control coupling involve passing control flags between modules so that one modules controls the sequence of processing steps in another module  Stamp coupling is similar to common coupling except that global data item  Named common block in FORTRAN and package in Ada support stamp coupling  Data coupling involves the use of parameter list to pass data items between routines
  • 9. COHESION OF ELEMENTS OCCURS ON THE SCALE BINDING OF ELEMENT WITHIN MODULES  Coincidental cohesion  Logical cohesion  Temporal cohesion  Communication cohesion  Sequential cohesion  Functional cohesion  Informational cohesion
  • 10. Content Coupling: Content coupling occurs when one module modifies local data values or instructions in another module. Common Coupling: Modules are bound together by global data structures. Control Coupling: Control coupling involves passing control flags(as parameters or globals) between modules so that one module controls the sequence of processing steps in another module.
  • 11. Stamp Coupling: Stamp coupling is similar to common coupling, except that global data items are shared selectively among routines that require the data. Data Coupling: Data coupling involves the use of parameter lists to pass data items between routines. The most desirable form of coupling between modules is a combination of stamp and data coupling.
  • 12. Coincidental Cohesion: Coincidental cohesion occurs when the elements within a module have no apparent relationship to one another. Logical Cohesion: Logical cohesion implies some relationship among the elements of the module. Ex: In a module that performs all input and output operations, or in a module that edits all data.
  • 13. Temporal Cohesion: Modules with temporal cohesion exhibit many of the same disadvantages as logically bound modules. A typical example of temporal cohesion is a module that performs program initialization. Communication Cohesion: The elements of a module possessing communicational cohesion refer to the same set of input and/or output data. Ex: “Print and Punch the Output File” is communicationally bound.
  • 14. Sequential Cohesion: Sequential cohesion of elements occurs when the output of one element is the input for the next element. Functional Cohesion: Functional cohesion is a strong, and hence desirable, type of binding of elements in a module because all elements are related to the performance of a single function. Informational Cohesion: Informational cohesion of elements in a module occurs when the module contains a complex data structure and several routines to manipulate the data structure.
  • 15. Other Modularization Criteria Additional criteria for deciding which functions to place in which modules of a software system include: Hiding difficult and changeable design decisions Limiting the physical size of modules Structuring the system to improve observability and testability Isolating machine dependencies to a few routines Easing likely changes Providing general purpose utility functions Reducing the call return overhead of excessive subroutine calls.