Download
1 / 15
180 likes | 422 Views
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
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)
