Unit 2: Software Design Principles & System Architecture

1. Basic Principles of Software Design

Software design is the process of transforming the user requirements (from the SRS) into a suitable form that helps the programmer in coding and implementation.

Key Principles

1. Abstraction: Hiding low-level details and focusing on essential characteristics.
   • Functional Abstraction: Specifying what a module does without stating how.
   • Data Abstraction: Specifying data objects and operations without detailing data structure implementation.
2. Refinement: The stepwise process of elaboration. It is the complementary process to abstraction. A high-level concept is decomposed into detailed steps.
3. Information Hiding: Proposed by David Parnas. Modules should be specified and designed so that information (algorithms and data) contained within a module is inaccessible to other modules that have no need for such information.
4. Refactoring: Organizing the design to reduce complexity without changing the external behavior (e.g., removing redundancy).
5. Separation of Concerns: Dividing a complex problem into smaller, distinct pieces that can be solved independently.

2. Modularity

Modularity is the single attribute of software that allows a program to be intellectually manageable. It involves dividing software into separately named and addressable components, called modules, that are integrated to satisfy problem requirements.

Benefits of Modularity

• Manageability: Complexity is reduced (Divide and Conquer).
• Maintainability: Changes in one module affect a limited scope.
• Reusability: Modules can be used in other programs.
• Parallel Development: Different teams can work on different modules simultaneously.

3. Cohesion and Coupling (Measuring Module Independence)

Module Independence is the primary goal of structured design. It is achieved by developing modules with a "single-minded" function and low interaction with other modules. Independence is measured using two qualitative criteria: Cohesion and Coupling.

A. Cohesion (Internal Glue)

Cohesion measures the strength of relationships between elements within a single module.
Goal: High Cohesion.

Types of Cohesion (Ordered from Best to Worst):

1. Functional Cohesion (Best): All elements in the module contribute to the execution of a single, specific task (e.g., CalculateNetSalary()).
2. Sequential Cohesion: The output of one element within the module serves as input to the next element.
3. Communicational Cohesion: Elements operate on the same input data or produce the same output data (e.g., a module that prints a record and saves it to a database).
4. Procedural Cohesion: Elements are grouped because they are part of a specific sequence of execution (e.g., a function that checks permissions, then opens a file, then reads logs).
5. Temporal Cohesion: Elements are grouped because they are processed at the same time (e.g., System Initialization or Shutdown routines).
6. Logical Cohesion: Logically related activities are grouped, and a control parameter selects which one to execute (e.g., a generic Input() module handles keyboard, mouse, and network input inside one big switch statement).
7. Coincidental Cohesion (Worst): Elements are grouped arbitrarily with no meaningful relationship (e.g., a "Utilities" module containing random functions).

B. Coupling (External Dependency)

Coupling measures the degree of interdependence between different modules.
Goal: Low Coupling.

Types of Coupling (Ordered from Best to Worst):

1. Data Coupling (Best): Modules communicate by passing only the necessary atomic data items (parameters).
2. Stamp Coupling: Modules share a composite data structure (like a Record or Struct), but the called module uses only a part of it.
3. Control Coupling: One module passes a control element (like a flag or switch) to another module, explicitly directing its logic. This breaches information hiding.
4. Common (Global) Coupling: Multiple modules access shared global data areas. If one module changes the format of the global data, all others must be modified.
5. Content Coupling (Worst): One module modifies or relies on the internal workings of another module (e.g., jumping into the middle of another function's code or modifying its private data).

Design Trade-offs

• Performance vs. Modularity: Excessive modularization can introduce overhead (call stack management). However, monolithic code is harder to optimize locally.
• Development Cost vs. Maintenance Cost: Investing time in high cohesion/low coupling increases initial development time but drastically reduces long-term maintenance costs.
• Reuse vs. Specificity: Highly generic modules are reusable but may be more complex to integrate than highly specific, coupled modules.

4. Function-Oriented Design: Data Flow Diagrams (DFD)

Function-oriented design (Structured Design) views the system as a collection of functions (processes) transforming data. The primary tool is the Data Flow Diagram.

DFD Overview

A DFD maps out the flow of information for any process or system. It shows inputs, outputs, storage points, and the routes between each destination.

Symbols and Notations (Gane & Sarson / Yourdon)

Leveling (Decomposition)

DFDs are hierarchical. They start high-level and drill down.

1. Context Diagram (Level 0):
   • Represents the entire system as a single bubble.
   • Shows interaction with external entities only.
   • No data stores are usually shown at this level unless they are external to the system.
2. Level 1 DFD:
   • Explodes the single Context bubble into major sub-processes (usually 3 to 7).
   • Reveals internal data stores.
3. Level 2+ DFD:
   • Further decomposition of Level 1 processes into smaller sub-processes.

Rules for Constructing DFDs

1. Conservation of Data (Balancing): The inputs and outputs of a parent bubble must match the combined inputs and outputs of the child diagram.
2. No "Black Holes": A process cannot have only inputs (it must produce output).
3. No "Miracles": A process cannot have only outputs (it must have input to generate the output).
4. Data Store Rule: Data cannot move directly from one data store to another; it must pass through a process.
5. Entity Rule: Data cannot move directly from an external entity to a data store; it must be processed first.
6. Unique Naming: All processes and data stores must have unique names.

5. Structure Charts

While DFDs model data flow, Structure Charts model the architectural hierarchy and control flow of the software modules. It is the blueprint of the code structure.

Components and Notation

• Module: Represented by a rectangle.
• Connection (Call): An arrow pointing from the caller to the callee.
• Data Couple: An arrow with an empty circle at the tail. Represents passing data parameters.
• Control Couple (Flag): An arrow with a filled circle at the tail. Represents passing control information (e.g., EndOfFile, ErrorFound).
• Selection: A diamond symbol indicating a conditional call (If/Else).
• Iteration: A curved arrow crossing the connection lines indicating a loop.

Structure Chart Strategies (Transitioning from DFD)

A. Transform Analysis

Used when the system follows a clear "Input Process Output" flow.

1. Identify the Central Transform in the DFD (the part of the system performing the core logic, independent of input/output format).
2. Create a root module (Controller).
3. Create three branches:
   • Afferent Branch: Input modules (Get Data).
   • Transform Branch: Worker modules (Process Data).
   • Efferent Branch: Output modules (Display/Save Data).

B. Transaction Analysis

Used when a single input triggers one of several mutually exclusive paths (like a menu system).

1. Identify the Transaction Center (the dispatcher).
2. Create a dispatcher module.
3. Create subordinate modules for each transaction type (e.g., "Add User," "Delete User," "Update User").

6. Design Documentation and Review

Design Documentation (SDD)

The Software Design Document (SDD) (often based on IEEE 1016) describes the system architecture and detailed design.

Key Sections of an SDD:

1. Data Design: Structures (DB schema, file layouts).
2. Architectural Design: Module hierarchy, patterns used (MVC, Client-Server).
3. Interface Design: Human-Computer Interface (HCI) and internal module interfaces.
4. Procedural/Component Design: Algorithms, pseudo-code, and flowcharts for individual modules.

Design Review Techniques

Reviews are Quality Assurance (QA) activities to detect errors before coding begins.

1. Informal Reviews

• Casual discussions between designers.
• "Desk checks" (developer checking their own design).

2. Formal Technical Reviews (FTR)

Structured meetings with specific roles (Moderator, Author, Scribe, Reviewer).

• Walkthroughs:

  • Led by the Author of the design.
  • The author "walks through" the document/diagrams while peers ask questions.
  • Goal: Education and basic error detection.
  • Tone: Collaborative and semi-formal.

• Inspections (Fagan Inspection):

  • Led by a trained Moderator (not the author).
  • Rigorous, step-by-step examination against a checklist.
  • Goal: Find defects using metrics.
  • Metrics recorded: Preparation time, errors found per hour, etc.

• Audits:

  • External review to ensure compliance with standards or regulations.