# UNIT 4: Software Design: Design Fundamentals, Effective Modular Design, Data Architectural & Procedural Design, Design Documentation ## 4.1 Fundamentals of Software Design Software design transforms SRS specifications into detailed operational blueprints ready for implementation. ### Key Design Principles 1. **Abstraction**: Procedural abstraction (named sequence of operations) and Data abstraction (named collection of data attributes). 2. **Refinement (Stepwise Refinement)**: Top-down process of decomposing high-level statements into detailed lower-level procedural steps. 3. **Modularity**: Dividing system logic into independently named and addressable software components. 4. **Software Architecture**: Macro-structure organizing modules, relationships, and global control flow. 5. **Information Hiding**: Designing modules such that internal algorithms and data structures are inaccessible to other modules. --- ## 4.2 Effective Modular Design: Cohesion & Coupling ### The Core Architectural Rule Achieve **HIGH Cohesion** within individual modules and **LOW Coupling** between modules. --- ### Module Cohesion (Internal Module Strength) Cohesion measures the functional closeness of processing elements within a single module. (Ranked from Lowest/Worst to Highest/Best): 1. **Coincidental Cohesion (Worst)**: Elements are combined randomly without meaningful functional relationship. 2. **Logical Cohesion**: Elements are logically categorized together (e.g., a module containing all I/O routines) but execute different tasks based on input parameters. 3. **Temporal Cohesion**: Elements are grouped because they execute at the same point in time (e.g., system initialization routine `InitSystem()`). 4. **Procedural Cohesion**: Elements execute in a specific order to accomplish a multi-step procedure. 5. **Communicational Cohesion**: Elements operate on the same input data or produce the same output dataset. 6. **Sequential Cohesion**: Output of one processing element serves as direct input to the next element in a pipeline sequence. 7. **Functional Cohesion (Best)**: Module performs exactly **ONE targeted, well-defined single function** (e.g., `CalculateTax()`). --- ### Module Coupling (Inter-Module Interdependence) Coupling measures the degree of interdependence between separate software modules. (Ranked from Best/Lowest to Worst/Highest): 1. **Data Coupling (Best)**: Modules communicate strictly by passing simple scalar data parameters through function calls. 2. **Stamp (Data Structure) Coupling**: Modules communicate by passing composite data structures (e.g., passing a full `StudentRecord` struct when only `Age` is needed). 3. **Control Coupling**: One module passes control flags/signals to another module to dictate its internal execution logic. 4. **External Coupling**: Modules share an external interface schema or hardware device communication protocol. 5. **Common Coupling**: Modules share access to global data spaces or global shared memory. 6. **Content Coupling (Worst)**: One module directly modifies or accesses internal data, state, or code inside another module, violating encapsulation completely. --- ## 4.3 Cyclomatic Complexity (McCabe) Developed by Thomas McCabe in 1976, Cyclomatic Complexity is a quantitative software metric measuring the number of linearly independent paths through a program's control flow graph $G=(V,E)$. ### Calculating Cyclomatic Complexity $V(G)$ #### Method 1: Edge-Node Formula $$V(G) = E - N + 2P$$ where $E$ = number of edges, $N$ = number of nodes, $P$ = number of connected components (typically $P=1$). #### Method 2: Predicate Node Formula $$V(G) = P_{pred} + 1$$ where $P_{pred}$ = number of decision/predicate nodes (e.g., `if`, `while`, `for`, `case` statements). #### Method 3: Bounded Region Formula $$V(G) = \\text{Number of enclosed bounded regions} + 1$$ ### Risk Threshold Interpretation - $V(G) = 1 \\text{ to } 10$: Simple, low risk, highly testable code. - $V(G) = 11 \\text{ to } 20$: Moderate complexity and risk. - $V(G) = 21 \\text{ to } 50$: High complexity, high risk, difficult to test. - $V(G) > 50$: Untestable, unstable code; mandatory refactoring required. --- ## 4.4 Data, Architectural & Procedural Design ### Data Design Translates data model entities into low-level data structures, database schemas, and object attributes. ### Architectural Design Defines structural organization of system components using established architectural styles: - **Data-Centered Architecture**: Central repository (database) surrounded by independent client applications. - **Data-Flow Architecture**: Pipe-and-filter processing pipeline. - **Call-and-Return Architecture**: Main program/subroutine hierarchy and object-oriented layers. - **Layered Architecture**: Outer user interface layers communicating only with adjacent lower service layers. ### Procedural Design Translates structural design elements into step-by-step procedural logic using Flowcharts, Decision Tables, and Program Design Language (PDL/Pseudocode). --- ---