Coursify

SOFTWARE ENGINEERING

Software Design Fundamentals and Quality Goals

This section introduces the purpose of software design, the attributes of good design, and the major strategies and methodologies used to transform requirements into robust software architectures and components.

Learning Goals

  • Identify the primary goals of good software design, including correctness, maintainability, scalability, reusability, and testability.
  • Differentiate between software design strategies and methodologies based on process, abstraction level, and intended outcomes.
  • Assess a proposed software design against quality criteria such as simplicity, modularity, and change tolerance.
  • Explain how design decisions influence downstream activities such as coding, testing, integration, and maintenance.
  • Produce a high-level design rationale that aligns selected design strategies with stated system requirements.

Software engineering relies heavily on translating user requirements into functional systems. This process is governed by Software Design, which serves as a blueprint for the construction phase . A well-engineered software design is not merely functional; it must satisfy a suite of quality goals that ensure the system remains resilient, adaptable, and cost-effective over its lifecycle.

Primary Quality Goals of Good Software Design

  • Correctness: The degree to which the software meets its specified functional and performance requirements .
  • Maintainability: The Maintainability of a system determines how easily it can be debugged, updated, or enhanced over time .
  • Scalability: The capacity of the architecture to handle growing amounts of work or transaction volume by adding computing resources .
  • Reusability: The design of modules in a manner that allows them to be reused in other applications or areas of the system without major modification .
  • Testability: The ease with which a program's modules can be executed under test conditions to reveal defects .

To achieve these goals, developers use Abstraction and Modularity to break down complex architectures.

Footnotes

  1. Semeraro, A. (2023). Principles of Software Quality: Correctness, Reliability, and Robustness - A detailed guide on fundamental software quality metrics. ↩ ↩2

  2. Tateeda. (2024). Fundamental Principles of Good Software Design - Key concepts regarding software design quality goals. ↩ ↩2 ↩3

  3. GeeksforGeeks. (2024). Coupling and Cohesion in Software Engineering - Analysis of modular metrics, coupling levels, and software design quality. ↩

Software Design Concepts and Principles

The Law of Demeter

To achieve low coupling, adhere to the Law of Demeter (Principle of Least Knowledge). A method MM of an object OO should only invoke methods of: OO itself, MM's parameters, any objects created within MM, or OO's direct component objects. Avoid chaining calls like object.getX().getY().getZ().

Modularity, Coupling, and Cohesion

A system design is highly modular when components are self-contained and interact through clearly defined interfaces. The quality of a system's modularity is measured via two key indicators :

  1. Cohesion (Aim: High Cohesion)
  2. Coupling (Aim: Low Coupling)

To quantify design quality, we use structural metrics:

  • Cyclomatic Complexity: Measures the control-flow complexity of a module . For a control graph GG, complexity V(G)V(G) is calculated as: V(G)=E−V+2PV(G) = E - V + 2P where EE represents the number of edges, VV represents the number of vertices, and PP represents the number of connected components .
  • Lack of Cohesion in Methods (LCOMLCOM): Measures how closely related the methods and attributes of a class are. Let a class have mm methods and aa attributes. If PP represents the set of method pairs that do not share any instance attributes, and QQ is the set of method pairs that do share at least one attribute, then : LCOM=max⁡(0,∣P∣−∣Q∣)LCOM = \max(0, |P| - |Q|) A high LCOMLCOM indicates poor cohesion, suggesting that the class should be split .

Applying Information Hiding ensures that internal module operations remain inaccessible to external components, maintaining low coupling and higher system stability .

Footnotes

  1. GeeksforGeeks. (2024). Coupling and Cohesion in Software Engineering - Analysis of modular metrics, coupling levels, and software design quality. ↩ ↩2 ↩3 ↩4

  2. Stack Overflow. (2012). Metrics for Cohesion and Coupling - Discussion on LCOM metrics and architectural quality attributes. ↩ ↩2

Function-Oriented Design (FOD)

  • Process: Focuses on the functions or processes that transform data. The system is decomposed hierarchically into sub-functions using techniques like Structured Analysis and Data Flow Diagrams (DFDs) .
  • Abstraction Level: High-level functional abstraction, decomposing complex procedures into simpler steps.
  • Intended Outcomes: A clean functional hierarchy where state is typically passed explicitly between functions.
  • Best Suited For: Computational engines, compiler design, and transaction processing systems.

Footnotes

  1. GeeksforGeeks. (2024). Coupling and Cohesion in Software Engineering - Analysis of modular metrics, coupling levels, and software design quality. ↩

Evaluating System Design Quality

  1. 1
    Step 1

    Identify the critical modules, subsystem boundaries, and integration interfaces to be evaluated. Map these components back to the core Software Requirement Specification (SRS) documents.

  2. 2
    Step 2

    Measure the dependency metrics by calculating the fan-in and fan-out of modules. The fan-in represents the number of modules calling a target module, while the fan-out represents the number of modules called by the target module. Strive for high fan-in and low fan-out at lower architectural levels.

  3. 3
    Step 3

    Compute the cyclomatic complexity V(G)V(G) for key procedures to verify simplicity. Calculate LCOMLCOM to identify classes that violate the Single Responsibility Principle (SRP).

  4. 4
    Step 4

    Inject hypothetical modification scenarios (e.g., changing the database schema or external API provider) and trace the ripple effect. If a single modification requires updates to more than NN modules, identify the tight coupling bottlenecks and plan refactoring patterns.

Coupling Levels vs. Design Undesirability

A visual comparison of coupling types, where higher scores represent higher interdependence and worse design quality.

Design Decisions and Their Downstream Impact

High-Level Architecture Design

Phase 1

Selecting patterns (e.g., Microservices vs. Monolith) sets the baseline for scalability and deployment. Mistakes here result in systemic integration bottlenecks downstream."

Detailed Module & Interface Specifications

Phase 2

Defining strict API contracts and encapsulation boundaries directly enables parallel team coding and simplifies unit testing setups."

Downstream Coding & Integration

Phase 3

Modules with high cohesion and low coupling are integrated with minimal merge conflicts, reducing the integration testing duration by up to 40%40\% ."

Footnotes

  1. Tateeda. (2024). Fundamental Principles of Good Software Design - Key concepts regarding software design quality goals. ↩

Maintenance & Long-term Operations

Phase 4

A change-tolerant design reduces the cost of resolving post-production bugs and implementing feature enhancements over the software lifecycle."

Beware of Over-Engineering

While reusability and scalability are critical design goals, design decisions must always be justified by stated system requirements. Implementing complex design patterns (e.g., abstract factories or microservices) to handle theoretical future scale without immediate justification introduces unnecessary complexity (V(G)V(G)) and degrades maintainability.

High-Level Design Rationale and Architectural Trade-offs

Knowledge Check

Question 1 of 4
Q1Single choice

If a software module AA accesses the internal data of module BB directly rather than through a public interface, what type of coupling exists between them?

Previous

Next