“Summarize design heuristics for effective modularity.” The question of SMU MBA assignment for Software Engineering (MI0024) has to solve students. It is one more solved assignment for students of Sikkim Manipal University with Information System (IS) specialty MBA MI0024. There are already some assignments of MBA MI0024 for students of SMU - Formal technical reviews, COCOMOL model and Linear Sequential Model.
Once the program structure has been developed, effective modularity can be achieved by applying the design concepts introduced earlier in this chapter. The program structure can be manipulated according to the following set of heuristics:
Evaluate the “first iteration” of the program structure to reduce coupling and improve cohesion. Once the program structure has been developed, modules may be exploded or imploded with an eye toward improving module independence. An exploded module becomes two or more modules in the final program structure. An imploded module is the result of combining the processing implied by two or more modules.
Attempt to minimize structures with high fan-out; strive for fan-in as depth increases. The structure shown inside the cloud does not make effective use of factoring. All modules are “packed” below a single control module. In general, a more reasonable distribution of control is shown in the upper structure.
Keep the scope of effective a module within the scope of control of that module.
The scope of effect of module is defined as all other modules that are affected by a decision made in module. The scope of control of module is all modules are subordinate and ultimately subordinate to module; if module makes a decision that affects module we have a violation of this heuristic, because module lies outside the scope of control module.
Evaluate module interfaces to reduce complexity and redundancy and improve consistency. Module interface complexity is a prime cause of software errors. Interfaces should be designed to pass information simply and should be consistent unrelated data passed via an argument list or other technique is an indication of low cohesion.
Define modules whose function is predictable, but avoid modules that are overly restrictive. A module is predictable when it can be treated as a black box; that is, the same external data will be produced regardless of internal processing details. Modules that have internal “memory” can be unpredictable unless care is taken in their use.
Strive for “controlled entry” modules by avoiding “pathological connections.” This design heuristic warns against content coupling. Software is easier to understand and therefore easier to maintain when module interfaces are constrained and controlled.
Once the program structure has been developed, effective modularity can be achieved by applying the design concepts introduced earlier in this chapter. The program structure can be manipulated according to the following set of heuristics:
Evaluate the “first iteration” of the program structure to reduce coupling and improve cohesion. Once the program structure has been developed, modules may be exploded or imploded with an eye toward improving module independence. An exploded module becomes two or more modules in the final program structure. An imploded module is the result of combining the processing implied by two or more modules.
Attempt to minimize structures with high fan-out; strive for fan-in as depth increases. The structure shown inside the cloud does not make effective use of factoring. All modules are “packed” below a single control module. In general, a more reasonable distribution of control is shown in the upper structure.
Keep the scope of effective a module within the scope of control of that module.
The scope of effect of module is defined as all other modules that are affected by a decision made in module. The scope of control of module is all modules are subordinate and ultimately subordinate to module; if module makes a decision that affects module we have a violation of this heuristic, because module lies outside the scope of control module.
Evaluate module interfaces to reduce complexity and redundancy and improve consistency. Module interface complexity is a prime cause of software errors. Interfaces should be designed to pass information simply and should be consistent unrelated data passed via an argument list or other technique is an indication of low cohesion.
Define modules whose function is predictable, but avoid modules that are overly restrictive. A module is predictable when it can be treated as a black box; that is, the same external data will be produced regardless of internal processing details. Modules that have internal “memory” can be unpredictable unless care is taken in their use.
Strive for “controlled entry” modules by avoiding “pathological connections.” This design heuristic warns against content coupling. Software is easier to understand and therefore easier to maintain when module interfaces are constrained and controlled.
0 comments:
Post a Comment