Chapter 5: Software Design
Course: [Link]. - II Semester
Foundations of Software Design, Cohesion, Coupling, and Methodologies
Introduction & Overview
Definition: Software design is the process of transforming
user requirements (SRS) into a suitable form that guides
the programmer in coding and implementation.
SDLC Context: It forms the crucial bridge between
Requirements Analysis (the "What") and Implementation
(the "How").
Primary Objective: To conceptualize a system structure
that is modular, understandable, and maintainable.
Key Artifact: The phase culminates in the Software Design
Document (SDD).
The Software Design Process
The Process & Abstraction Software Design Document
The design process involves identifying modules, The SDD is the formal blueprint of the software
defining their control relationships, and specifying system containing architectural diagrams, module
internal data structures and algorithms. specifications, and interface designs.
Abstraction is the core principle of managing Target Audience: System architects use it for
complexity by deliberately hiding unnecessary review, while programmers use it as a direct
details at each architectural level. coding guide.
Classification of Design Activities
Architectural High-Level Detailed
Identifies the overall system Decomposes the system into Specifies the internal logic,
structure, major components, distinct modules and defines exact data structures, and
and their high-level interactions their interfaces representing a algorithms required for each
(e.g., Client-Server, MVC). "black box" view of the system. individual module to function.
Common Design Methodologies
Top-Down vs. Bottom-Up Structured vs. Object-Oriented
Top-Down: Starts with the main system, breaking Structured Design: Focuses on algorithmic
it down into sub-systems and lower-level modules decomposition and module hierarchy using data
iteratively. flow diagrams (DFDs).
Bottom-Up: Starts with existing low-level Object-Oriented Design: Models the system as
foundational modules, composing them to build interacting objects that encapsulate both data
higher-level systems. and behavior for better reuse.
Note: Hybrid approaches are most common in
industry.
Characteristics of Good Design
Modularity: The system is partitioned into distinct, logically independent components that can be
developed separately.
Maintainability: The code can be easily modified or extended without introducing new bugs or
breaking existing features.
Understandability: A new developer should easily comprehend the system's logic and data flow
without excessive documentation.
Reusability: Modules should be generic enough to be utilized in other projects, saving future
development time.
Scalability: The architecture should easily accommodate future growth in data volume or concurrent
user load.
Module Cohesion
Measuring the functional strength and internal relatedness of a
software module.
Introduction to Cohesion
Definition: Cohesion is a measure of the functional
strength or relatedness of elements within a single module.
The Goal: High Cohesion is always desirable in software
design.
Why it matters: Highly cohesive modules are robust,
reusable, and easier to understand because they focus on
a single, well-defined task.
Analogy: A cohesive module is like a dedicated expert
specialist, whereas a non-cohesive module is a confused
jack-of-all-trades.
The Cohesion Spectrum
Level Cohesion Type Description
1 (Worst) Coincidental Elements are grouped randomly with no meaningful relationship.
2 Logical Elements perform similar logical operations on different data.
3 Temporal Elements are grouped because they execute at the same time.
4 Procedural Elements are part of a sequence but do not share data.
5 Communicational Elements operate on the same core data structure.
6 Sequential Output data of one element serves as input for the next.
7 (Best) Functional Every element contributes to exactly one well-defined task.
Low to Medium Cohesion (Avoid)
Coincidental Logical Temporal
Random grouping of functions Similar logic but different data Elements execute at the same
(e.g., print_report, calc_root, (e.g., an Input_All() module time (e.g., Initialize_System()
close_db). Impossible to reuse handling mouse, keyboard, and opening files and connecting to
and very difficult to maintain. network based on a flag). DBs). Limits reusability.
Medium to High Cohesion
Procedural Communicational Sequential
Execution sequence matters, Functions operate on the same Output of one function is
but data is unshared. Ties data structure (e.g., using strictly the input to the next
unrelated logic together just Employee_Record to Print_Slip (e.g., Sort_Data ->
because one happens after and Update_Leave). Better Format_Data). Good, but
another. modularity. creates a tight chain.
Functional Cohesion (The Ideal)
1
Do One Thing, And Do It Well
Every element in a functionally cohesive module
contributes to executing exactly one well-defined task.
These modules are robust, highly reusable, and easy to
Real-world
test. Examples: Calculate_Income_Tax(salary) or
SINGLE TASK
Validate_Email(string).
The Rule: If you can describe the module's purpose using a
single active verb and object without using "and" or "or", it
is functionally cohesive.
Module Coupling
Measuring the degree of interdependence and communication
between software modules.
Introduction to Coupling
Definition: Coupling measures the degree of
interdependence between two or more modules.
The Goal: Low (Loose) Coupling is always desirable in
software architecture.
The Ripple Effect: If modules are tightly coupled, a change
in one module necessitates cascading changes in others,
making maintenance a nightmare.
Analogy: Low coupling is like a USB connection (standard
interface); high coupling is like soldering wires directly onto
a motherboard.
High Coupling (Avoid)
Content Coupling (Worst) Common Coupling
One module directly modifies or relies on the Multiple modules share access to the same global
internal workings or private data of another data space or global variables.
module. Example: Modules A, B, and C all read/write to a
Example: Module A directly changes a local global variable system_status.
variable inside Module B using memory pointers. Impact: Tracking data changes is difficult;
Impact: Total violation of information hiding; modules cannot be reused independently of the
catastrophic for maintenance and debugging. global data.
Medium to Low Coupling
Control Coupling Stamp Coupling
One module passes a control flag (boolean/enum) Modules pass entire composite data structures
to strictly dictate the execution logic of another when only a small portion is needed by the
module. receiving module.
Example: Calling calculate_pay(employee_id, Example: Passing the entire Employee_Object to
is_manager). a Print_Phone_Number() function.
Impact: The calling module must possess intimate Impact: Creates artificial dependencies. Changing
knowledge of the internal logic of the called the object structure requires unnecessary
module. recompilation.
Data Coupling (The Ideal)
100%
Strict Parameter Passing
In Data Coupling, modules communicate strictly by passing
only the necessary primitive data parameters required for
the operation.
Example: calculate_tax(base_salary, tax_rate).
INDEPENDENCE
Impact: Provides maximum independence, extremely high
reusability, and minimal ripple effect during future
maintenance cycles.
Layered Architecture
Separation of Concerns
In this design, the system is structured into hierarchical
layers, where each layer provides services strictly to the
layer immediately above it.
Standard Layers:
• Presentation Layer: Handles UI and user inputs.
• Business Logic: Core application rules.
• Data Access: Database communication.
• Storage: Physical data persistence.
This abstraction ensures ease of testing and maintenance.
Function-Oriented vs Object-Oriented
Feature Function-Oriented Design (FOD) Object-Oriented Design (OOD)
Basic Unit Function / Procedure Object / Class
Approach Top-Down algorithmic decomposition Bottom-Up modeling of real-world entities
Data Handling Centralized, shared among functions Encapsulated within objects (Data Hiding)
Reusability Low (functions are often system-specific) High (classes can be reused across projects)
Complexity Best for simpler, process-heavy systems Best for complex, large-scale systems
Summary & Questions
Golden Rule: High Cohesion + Low Coupling = Highly Maintainable Software.