180 likes | 460 Views
Learn about quality characteristics for software modules, including high cohesion and low coupling, to optimize module interactions. Understand different types of coupling and their impact on module design. Discover heuristics and guidelines for achieving optimal cohesion and coupling in software modules.
E N D
SOFTWARE DESIGN QUALITY COHESION and COUPLING (Part II)
Quality Characteristics for Modules • independent modules • avoid aggregation of multiple tasks per module • single-minded function ===> high COHESION • minimal interaction with other modules • simple interface ===> low COUPLING [Steven, Myers, Constantine]
Module COUPLING • quality of interaction between modules • based on module interfaces and types and number of connections • coupling should be low • types of coupling (high to low):
Content Coupling • characteristics: • direct reference into another module • modification of called module at run-time • example(s): • at calling time: jump to an address < > entry point • change local data of another module • problems: • modules rely on each others internal structure • no clear interface - side effects • high degree of interdependency
Common Coupling • characteristics: • sharing of a common, external data area • data area is unstructured • example(s): • FORTRAN “COMMON” • C external data types • problems: • M modules and N data elements: M x (M - 1) x N possible connections • high degree of (potential) interdependency
External Coupling • characteristics: • sharing of a common, external data area • data area is structured • example(s): • global data structures (variables) • communication to external tools and devices • problems: • high potential for side effects • missing access control • modules are “bound” to the global structure
Control Coupling • characteristics: • one module controls the execution path of another module via control flow (flag) • example(s): • control parameter selects from a set of functions • error-checking decides on further execution • problems: • the controlling module must have a minimum of knowledge about the controlled module • cohesion of the controlled module? (logical, procedural)
Control Coupling - control inversion read & check registration 1 reg_i error_reason reg_i reg_flag read registration check registration error-handler registration 1.1 1.2 1.3
Stamp (Data) Coupling • characteristics: • parameter passing of a complete data structure • only portions of the data structure are used • example(s): • global, imported data structure declarations • copying real life limitations into your system • problems: • change of data structure => change of module • module has to handle irrelevant information • module’s cohesion? (communicational, sequential, ...)
Data Coupling • characteristics: • parameter passing of (atomic) data elements • no unnecessary information • no control parameters • no external, shared data structures • independent and reusable • execute one single-minded function (good cohesion) • problems: • cannot always be achieved
A good system design exhibits HIGH COHESION and LOW COUPLING
Cohesion & Coupling • many times, high cohesion and low coupling complement and cause each other • sometimes, high cohesion and low coupling contradict each other ===> the designer decides on the trade-offs
Cohesion & Coupling • heuristics (sanitized experience) • relative measures • non-linear scale
Beyond Cohesion & Coupling • Module size • objective: “understood without flipping the pages” • guideline: module size < 30-50 statements on a page • Fan-out (span of control): • objective: ”boss” modules should control a reasonable number of workers; • guideline: number of modules controlled by a “boss” < 7 • Fan-in • objective:maximize fan-in, create generalized modules • guideline: modules must have strong or moderate cohesion (3) (4)