Structured Design Methodology in
Software Engineering
Introduction to Design Phase
• • Major concern: Creating the software
system design
• • Purpose of design methodologies:
• - Provide discipline in managing complexity
• - Offer guidance, not mechanical steps
• - Aid designers during the design process
Structured Design Methodology
(SDM)
• • Developed to assist in creating large system
designs
• • Treats software as a transformation
function:
• - Converts inputs → desired outputs
• • Emphasizes function-oriented approach
Core Concepts of SDM
• • Functional Abstraction:
• - View of software in terms of functions
• • Functional Decomposition:
• - Breaking down system functions into sub-
functions
• • Goal: Simplify complex systems by
modularization
Structure of a Program
• • Central to structured design
• • Programs should be:
• - Hierarchical in structure
• - Made up of functionally cohesive modules
• - Have minimal inter-module
interconnections
Design Goals in SDM
• • Enhance modularity and clarity
• • Facilitate maintainability and scalability
• • Ensure well-structured and predictable
program behavior
Summary
• • SDM provides a systematic approach to
design
• • Focuses on functionality, hierarchy, and
modularity
• • Helps manage complexity in large software
systems
Starting with Data Flow Diagrams
(DFDs)
• • First step in SD methodology: Construct the
Data Flow Diagram (DFD)
• • DFDs help visualize how data flows through
the system
• • Differentiate between DFDs in Requirements
Analysis and Structured Design
DFDs in Requirements Analysis vs
Design
• • Requirements Analysis:
• - Models the *problem domain*
• - Extracts and represents existing information
• • Structured Design:
• - Models the *solution domain*
• - Represents how data will flow in the built
system
Creative Role of DFDs in Design
• • Design DFD is creative — the system doesn’t
exist yet
• • Designer visualizes major transforms and
data flow
• • Shows what functions are needed — not
how they are implemented
• • Designer has freedom to shape the system
to meet SRS goals
Example: Automated Teller
Machine (ATM)
• • ATM allows customers to withdraw money
• • DFD in design shows:
• - Input (card info, PIN, amount)
• - Transforms (authentication, balance check,
dispense cash)
• - Output (cash, receipt)
Basic Transformations in Systems
• • Systems often can't apply transformations
directly to physical inputs
• • Inputs are converted to a usable form before
transformation
• • Outputs from core modules are also
converted into desired physical form
Separating Input/Output
Transforms
• • Goal: Separate data formatting from core
transformations
• • Helps isolate logic that prepares
input/output data
• • Allows focus on actual system logic in central
transforms
Identifying Most Abstract Input
(MAI)
• • MAI: Farthest from physical inputs but still
considered input
• • Reached after error checking, validation,
formatting, etc.
• • Determined by tracing data flow from input
toward output
Identifying Most Abstract Output
(MAO)
• • MAO: Farthest from physical outputs but still
considered output
• • Identified by tracing backward from output
toward input
• • MAO = logical output; post-transforms
convert it to actual form
Role of Central Transforms
• • Central transforms lie between MAI and
MAO
• • Perform main functionality of the system
• • Free from concerns of data
formatting/validation
• • A '+' in output suggests major decision point
