CIS 375 SOFTWARE ENGINEERING

UNIVERSITY OF MICHIGAN-DEARBORN

DR. BRUCE MAXIM, INSTRUCTOR

Date: 10/20/97

Week 7

NO NOTES; EXAM

Date: 10/22/97

Week 7

COUPLING:

  • Definition: degree of inter-module dependence.

    • FACTORS:

    1. Type of connection between modules.
    2. Complexity of the interface.
    3. Type of information flow.
    4. Binding time with the connection.

    TYPES OF COUPLING:

  • (Low is good)
    1. No direct coupling.
    2. Data coupled (data structures).
    3. Stamped coupling (parts of data structure).
    4. Central coupling (flags, etc.).
    5. External coupling (file format, database).
    6. Common coupling.
    7. Contact coupling.

    DECOUPLE:

    1. Early in design.
    2. Convert implicit references.
    3. Standardize connections.
    4. Localize your variables.
    5. Use buffers to moderate I/O to modules.
  • (Avoid race conditions, no waiting)

    • COHESION:

  • (High is good)
    1. Coincidental cohesion.
    2. Logical cohesion.
    3. Temporal cohesion.
    4. Procedural cohesion.
    5. Communicational cohesion.
    6. Sequential cohesion.
    7. Functional cohesion.

    TECHNIQUES TO COHESION AND COUPLING:

    1. Small modules.
    2. Control "fan out" (degree to which tree is wide).
    3. Focus on "fan in" (fan in = reuse).
    4. Scope of effect should be a subset of scope of control.
    5. (Don't make a major decision in the lower modules)
    6. Depth.

    DESIGN HEURISTICS:

    1. Evaluate "first cut" and reduce coupling and increase cohesion.
    2. Minimize "fan out" and focus on "fan in".
    3. Scope of effect should be subset of scope of control.
    4. Reduce complexity of interfaces and improve consistency.
    5. Define modules with predictable behavior, don't be overly restrictive.
    6. Strive for single entry, single exit modules.
    7. Package software based on design constraints and portability requirements (package = how the modules go together).

    DATA DESIGN:

    1. Systematic analysis applied to functional behavior, can be applied to data.
    2. Data structures and operations should be identified.
    3. Establish a data dictionary and use it to guide both data and program design.
    4. Defer low level data structure decisions until late in the design.
    5. Information hiding.
    6. Libraries of useful data structures and operators is developed.
    7. Environment must support ADT's.

    ARCHITECTURAL DESIGN:

  • Develop a modular program structure and represent control relations between modules.
  • Unifies the program structure and data structures by defining information flow through module interfaces.

    • PROCEDURAL DESIGN:

    1. Structured programming theorem.
    2. Flow charts.

    1. Box diagrams.