●​ Module: A task/process in the system

Software Design ○​ Control Module: Has branches to

multiple sub-modules
●​ Input: SRS (Software Requirement Specification) ○​ Sub Module: Child module under a
●​ Output: SDD (Software Design Document) parent module
●​ Key Point: Most creative phase of software ○​ Library Module: Reusable and callable
engineering – actual solution architecture is from any module
planned here. ●​ Conditional Call: Control module calls
●​ Purpose: Converts what to build (SRS) into how sub-modules based on conditions
to build (SDD) ●​ Loop (Repetitive Call): A curved arrow shows
module is executed repeatedly by sub-module
●​ Data Flow: Directed arrow with empty circle (○)
Characteristics of a Good SDD
– shows data transfer
●​ Control Flow: Directed arrow with filled circle
●​ Completeness: Covers all requirements from the (●) – shows control transfer
SRS ●​ Physical Storage: Represents where system data
●​ Clarity: Should be readable and easy to is stored
understand
●​ Maintainability: Easy to update and manage over
Benefits of Design Structure Charts (DSC)
time
●​ Coverage: Must clearly describe:
○​ Data domain ●​ Improves understanding of overall system
○​ Functional domain architecture
○​ Behavioral domain ●​ Enhances communication among team
members
●​ Helps in identifying issues and dependencies
Steps of Software Design (3 Stages)
early
●​ Promotes modular, maintainable, and
1.​ Interface Design structured design
○​ System treated as a black box
○​ Focus on input/output based on user
Pseudocode
needs (from SRS)
○​ Defines system–environment
interactions, not internal logic ●​ Definition: Informal, language-independent way
2.​ Architectural Design to represent algorithms
○​ Identify major modules, their ●​ Uses a mix of natural language and
responsibilities, and interactions programming logic
○​ Emphasis on coupling (between ●​ Purpose:
modules) and cohesion (within modules) ○​ Illustrates high-level structure and logic
○​ Modules also treated as black boxes (no ○​ Easier to plan, discuss, and later
internal details) convert to real code
●​ Benefit: Simplifies algorithm design before
implementation
Detailed Design (Low-Level Design)
Coupling and Cohesion
●​ Focuses on internal structure of each module
●​ Specifies:
○​ Functions and their logic ●​ Purpose: Measure quality of modularity in
○​ Processing methods software design
○​ Data structures ●​ Coupling: Degree of interdependence between
○​ Algorithms modules (lower is better)
●​ Provides a blueprint for coding
Types of Coupling (Best to Worst):
Modularity in Software Design

●​ Modular Architecture: System is built from

1.​
✅
Data Coupling: Modules share only data (via
parameters) – Most desired
○​ Example: Function call by value
simple, independent units with well-defined
interfaces 2.​ Stamp Coupling: Passes entire data
●​ Advantages: structures unnecessarily
○​ Easy to understand and explain ○​ Example: Function call by reference
○​ Simplifies design and documentation 3.​ Control Coupling: Modules share control
signals (like flags)
○​ Facilitates coding and testing
4.​ External Coupling: Modules depend on
○​ Enhances maintainability
external systems/hardware
○​ Example: CPU, memory, buses
Design Structure Charts (DSC) 5.​ Common Coupling: Modules share global data
○​ Example: Global variables causing
●​ Purpose: Represents hierarchical breakdown synchronization issues

❌
of the system into modules and sub-modules 6.​ Content Coupling: One module directly
●​ Emphasizes functions, their relationships, and modifies or uses the code of another – Worst
interaction type
●​ Uses black-box approach: user knows
input/output, not internal details

Key Symbols in DSC:

Cohesion

●​ Purpose: Measures the strength of

relationship between functions within a module
(higher is better)

Types of Cohesion (Worst to Best):

1.​ Coincidental Cohesion: Functions have

random or no logical relationship –
type
❌ Worst

2.​ Logical Cohesion: Functions perform similar

tasks but not directly related
○​ Example: Mouse, printer, and scanner
functions in one module
3.​ Temporal Cohesion: Functions that must run at
the same time
○​ Example: Exception handling followed by
an error message
4.​ Procedural Cohesion: Functions are related by a
flow control or procedure
○​ Example: File access check followed by
opening the file
5.​ Communicational Cohesion: Functions operate
on the same data
○​ Example: Push and pop functions on the
same stack
6.​ Sequential Cohesion: Functions depend on data
flow between them
○​ Example: Function 1 provides data,
function 2 processes it
7.​ Functional Cohesion: Functions work together
to perform one specific task
○​ Example: Mouse module handling

–✅
position, decoding, and cursor movement
Best type

Design Approaches

1. Top-Down Approach

●​ Process: Divide the problem into smaller

sub-problems based on user requirements,
simplifying the problem until it becomes solvable
directly.
●​ Advantages:
○​ More systematic
○​ Easier to understand and modular
architecture
○​ Cost and time prediction possible
(aligns with user requirements)
○​ Best for small to medium-size
projects
●​ Disadvantages:
○​ Not ideal for large or very complex
problems (hard to understand the entire
problem at once)

2. Bottom-Up Approach

●​ Process: Solve smaller sub-problems and build up

the solution incrementally until the entire problem
is solved.
●​ Advantages:
○​ Ideal for large projects
○​ Incremental development process makes
it easier to handle
●​ Disadvantages:
○​ Results in complex architecture
○​ Difficult to understand and manage