Unit 2: Issues in Software Design
1. Basic Issues in Software Design
Definition
Software design is the process of defining the architecture, components, modules, interfaces, and data for
a software system to satisfy specified requirements.
Key Design Issues
1.1 Complexity Management
Problem: Software systems are inherently complex
Solutions: Decomposition, abstraction, hierarchy
Strategies: Divide and conquer, information hiding, modularity
1.2 Flexibility and Maintainability
Design for Change: Anticipating future modifications
Extensibility: Ability to add new features easily
Adaptability: Adjusting to changing requirements
1.3 Reliability and Quality
Error Handling: Graceful degradation and recovery
Fault Tolerance: System continues operating despite failures
Performance: Meeting response time and throughput requirements
1.4 Reusability
Component Reuse: Using existing components in new contexts
Design Patterns: Standard solutions to common problems
Framework Development: Creating reusable architectures
1.5 Design Trade-offs
Performance vs. Maintainability
Flexibility vs. Simplicity
Cost vs. Quality
Time to Market vs. Robustness
2. Modularity
Definition
Modularity is the degree to which a system is composed of discrete components such that changes to
one component have minimal impact on other components.
Key Concepts
2.1 Module Characteristics
Well-defined Interface: Clear input/output specifications
Single Responsibility: Each module has one primary function
Information Hiding: Internal details are hidden from other modules
Independence: Minimal dependencies on other modules
2.2 Benefits of Modularity
Easier Maintenance: Changes isolated to specific modules
Parallel Development: Teams can work on different modules simultaneously
Testing: Individual modules can be tested in isolation
Reusability: Modules can be used in different contexts
Understandability: Smaller, focused components are easier to comprehend
2.3 Module Design Principles
High Cohesion: Elements within a module work together toward a common goal
Low Coupling: Minimal interdependencies between modules
Appropriate Size: Not too large (complex) or too small (overhead)
Clear Interfaces: Well-defined communication mechanisms
3. Cohesion
Definition
Cohesion measures how closely related the elements within a single module are to each other.
Types of Cohesion (from strongest to weakest)
3.1 Functional Cohesion (Strongest)
Definition: All elements contribute to a single, well-defined task
Example: A module that calculates square root
Characteristics: Single entry, single exit, clear purpose
3.2 Sequential Cohesion
Definition: Elements form a sequence where output of one is input to next
Example: Module that reads data, validates it, then processes it
Data Flow: Linear progression through processing steps
3.3 Communicational Cohesion
Definition: Elements operate on the same data structure
Example: Module that adds, deletes, and updates customer records
Shared Resource: Common data structure or file
3.4 Procedural Cohesion
Definition: Elements follow a specific sequence of execution
Example: Module handling initialization sequence
Control Flow: Specific order of operations
3.5 Temporal Cohesion
Definition: Elements executed at the same time
Example: System initialization module
Timing: Elements grouped by when they execute
3.6 Logical Cohesion
Definition: Elements perform similar logical functions
Example: All input/output operations in one module
Selection: Usually involves case statements or conditionals
3.7 Coincidental Cohesion (Weakest)
Definition: Elements have no meaningful relationship
Example: Utility module with unrelated functions
Problems: Difficult to maintain, understand, and reuse
4. Coupling
Definition
Coupling measures the degree of interdependence between modules.
Types of Coupling (from loosest to tightest)
4.1 Data Coupling (Loosest)
Definition: Modules communicate through parameters
Example: Passing integers, strings, or simple data structures
Advantages: Independence, easy testing, maintainability
4.2 Stamp Coupling
Definition: Modules share composite data structures
Example: Passing entire record when only few fields needed
Consideration: Potential for unnecessary dependencies
4.3 Control Coupling
Definition: One module controls execution of another
Example: Passing control flags or function codes
Issues: Modules must know about each other's internal logic
4.4 External Coupling
Definition: Modules share externally imposed data formats
Example: File formats, communication protocols
Constraint: External standards dictate interface
4.5 Common Coupling
Definition: Modules share global data
Example: Global variables, shared memory
Problems: Side effects, difficult debugging
4.6 Content Coupling (Tightest)
Definition: One module modifies another's data directly
Example: Direct access to another module's variables
Severe Problems: Extremely difficult to maintain and understand
5. Layering
Definition
Layering is an architectural pattern that organizes system functionality into horizontal layers, where each
layer provides services to the layer above it.
Characteristics
Hierarchical Structure: Clear level-based organization
Service Abstraction: Each layer provides services to upper layers
Implementation Hiding: Lower-level details hidden from upper layers
Unidirectional Dependencies: Upper layers depend on lower layers only
Common Layered Architectures
5.1 Three-Tier Architecture
1. Presentation Layer: User interface and user interaction
2. Business Logic Layer: Application logic and business rules
3. Data Access Layer: Database operations and data management
5.2 OSI Network Model (7 Layers)
1. Physical, 2. Data Link, 3. Network, 4. Transport, 5. Session, 6. Presentation, 7. Application
5.3 Operating System Layers
1. Hardware, 2. Kernel, 3. System Calls, 4. Application Programs
Benefits and Drawbacks
Benefits: Clear separation of concerns, maintainability, portability Drawbacks: Performance overhead,
complexity in cross-layer communication
6. Function-Oriented Software Design
Definition
Function-oriented design focuses on decomposing the system into functional modules based on the
functions the system needs to perform.
Key Concepts
6.1 Top-Down Approach
Process: Start with main function, decompose into subfunctions
Hierarchy: Tree-like structure of function calls
Refinement: Each level provides more detail
6.2 Functional Decomposition
Main Function: Overall system objective
Subfunctions: Detailed operations required
Leaf Functions: Elementary operations
6.3 Design Principles
Single Responsibility: Each function has one clear purpose
Minimal Interface: Functions communicate through well-defined parameters
No Side Effects: Functions don't modify global state unexpectedly
Advantages
Natural problem-solving approach
Easy to understand and implement
Good for algorithmic problems
Clear traceability from requirements to implementation
Disadvantages
Difficult to handle complex data relationships
Poor support for code reuse
Challenges with evolving requirements
Global data can become problematic
7. Data Flow Diagram (DFD)
Definition
DFD is a graphical representation showing the flow of data through a system and the processing
performed on the data.
Components
7.1 External Entity (Terminator)
Symbol: Rectangle or oval
Purpose: Source or destination of data outside system boundary
Examples: Customer, supplier, other systems
7.2 Process
Symbol: Circle or rounded rectangle
Purpose: Transforms input data into output data
Labeling: Verb + noun (e.g., "Calculate Tax")
7.3 Data Store
Symbol: Open rectangle or parallel lines
Purpose: Repository for data at rest
Examples: Database, file, memory structure
7.4 Data Flow
Symbol: Arrow with label
Purpose: Movement of data between components
Labeling: Noun describing the data
DFD Levels
7.1 Context Diagram (Level 0)
Scope: Entire system as single process
Purpose: System boundary and external interactions
Detail: Highest level overview
7.2 Level 1 DFD
Scope: Major processes within the system
Purpose: Main functional areas
Detail: First level of decomposition
7.3 Level 2+ DFDs
Scope: Detailed breakdown of individual processes
Purpose: Detailed process specification
Detail: Progressively more detailed levels
Rules and Guidelines
Data Conservation: All inputs to process must be used
Process Numbering: Hierarchical numbering system
Balancing: Child DFD must match parent process
No Miracles: Outputs must be derivable from inputs
8. Structure Chart
Definition
Structure chart is a graphical representation of the hierarchical organization of modules in a software
system, showing the calling relationships between modules.
Components
8.1 Module
Symbol: Rectangle
Content: Module name and brief description
Types: Control modules, worker modules, library modules
8.2 Module Call
Symbol: Arrow connecting modules
Direction: From calling module to called module
Hierarchy: Parent-child relationships
8.3 Data Flow
Symbol: Arrow with open circle
Purpose: Data passed between modules
Direction: Can be input or output
8.4 Control Flow
Symbol: Arrow with filled circle
Purpose: Control information (flags, switches)
Usage: Coordinate module execution
Design Principles
Top-Down Structure: Main module at top, detailed modules below
Span of Control: Number of immediate subordinates (typically 5-9)
Depth: Number of levels in hierarchy
Fan-In: Number of modules calling a given module
Fan-Out: Number of modules called by a given module
9. Microservices Architecture
Definition
Microservices architecture structures an application as a collection of small, independent services that
communicate over well-defined APIs.
Key Characteristics
9.1 Service Independence
Deployment: Each service can be deployed independently
Development: Separate teams can work on different services
Technology: Each service can use different tech stack
Scaling: Individual services can be scaled based on demand
9.2 Business Capability Focus
Domain-Driven Design: Services organized around business domains
Single Responsibility: Each service has specific business function
Autonomous: Services own their data and business logic
9.3 Decentralized
Data Management: Each service manages its own database
Governance: Distributed decision-making
Infrastructure: Services run in separate processes/containers
Benefits
Scalability: Scale individual services independently
Technology Diversity: Use best tool for each service
Fault Isolation: Failure in one service doesn't crash entire system
Team Autonomy: Small teams can work independently
Faster Development: Parallel development and deployment
Challenges
Complexity: Distributed system complexity
Network Communication: Latency and reliability issues
Data Consistency: Managing transactions across services
Testing: Integration testing becomes more complex
Monitoring: Need comprehensive monitoring and logging
Design Patterns
API Gateway: Single entry point for client requests
Service Discovery: Mechanism for services to find each other
Circuit Breaker: Prevent cascading failures
Saga Pattern: Manage distributed transactions
10. Layered Architecture
Definition
Layered architecture organizes system into horizontal layers where each layer provides services to the
layer above it and uses services from the layer below.
Common Layers
10.1 Presentation Layer
Responsibility: User interface and user experience
Components: Web pages, mobile apps, desktop interfaces
Technologies: HTML/CSS/JavaScript, mobile frameworks
10.2 Business Logic Layer
Responsibility: Application logic and business rules
Components: Business objects, workflow, validation
Purpose: Core application functionality
10.3 Data Access Layer
Responsibility: Data persistence and retrieval
Components: DAOs, repositories, ORM mappings
Abstraction: Hide database-specific details
10.4 Database Layer
Responsibility: Data storage and management
Components: RDBMS, NoSQL databases, file systems
Services: CRUD operations, transactions, backup
Variations
10.1 N-Tier Architecture
Physical Separation: Layers deployed on different servers
Benefits: Scalability, security, maintainability
Challenges: Network latency, complexity
10.2 Clean Architecture
Dependency Inversion: Dependencies point inward toward core
Independence: Core business logic independent of external concerns
Testability: Easy to test business logic in isolation
Advantages
Separation of Concerns: Clear responsibility boundaries
Maintainability: Changes isolated to specific layers
Reusability: Layers can be reused across applications
Testability: Each layer can be tested independently
Disadvantages
Performance: Multiple layer calls can impact performance
Rigidity: Changes might require modifications across layers
Over-engineering: Simple applications might be over-complicated
11. Serverless Computing
Definition
Serverless computing is a cloud execution model where the cloud provider manages the infrastructure,
and developers focus on writing code without managing servers.
Key Characteristics
11.1 Function as a Service (FaaS)
Event-Driven: Functions triggered by events
Stateless: Functions don't maintain state between invocations
Short-Lived: Functions execute for limited time
Auto-Scaling: Platform automatically scales based on demand
11.2 Backend as a Service (BaaS)
Managed Services: Database, authentication, storage provided by cloud
APIs: Access to services through APIs
No Infrastructure Management: Provider handles scaling, availability
Serverless Platforms
AWS Lambda: Amazon's serverless platform
Azure Functions: Microsoft's serverless solution
Google Cloud Functions: Google's FaaS offering
Vercel: Serverless deployment platform
Benefits
No Server Management: Infrastructure handled by provider
Automatic Scaling: Scales from zero to thousands of instances
Pay-per-Use: Only pay for actual execution time
Fast Time-to-Market: Focus on business logic, not infrastructure
High Availability: Built-in redundancy and fault tolerance
Challenges
Cold Start: Initial latency when function hasn't been used
Vendor Lock-in: Tight coupling to specific cloud provider
Limited Execution Time: Functions have maximum execution duration
Debugging: Difficult to debug distributed serverless applications
State Management: Stateless nature requires external state storage
Use Cases
API Backends: REST APIs and GraphQL endpoints
Data Processing: ETL pipelines, file processing
Event Processing: Real-time data processing
Scheduled Tasks: Cron jobs, batch processing
Microservices: Individual business functions
Design Considerations
Function Granularity: Right size for functions
Error Handling: Robust error handling and retry logic
Security: Proper authentication and authorization
Monitoring: Comprehensive logging and monitoring
Performance: Optimize for cold start and execution time
Sample MCQ Questions
Q1. Which type of cohesion is considered the strongest? a) Sequential Cohesion b) Functional Cohesion
c) Communicational Cohesion d) Procedural Cohesion
Answer: b) Functional Cohesion
Q2. Data coupling is characterized by: a) Modules sharing global data b) Modules communicating
through parameters c) One module controlling another's execution d) Modules sharing composite data
structures
Answer: b) Modules communicating through parameters
Q3. In a Data Flow Diagram, a data store is represented by: a) Circle b) Rectangle c) Arrow d) Open
rectangle
Answer: d) Open rectangle
Q4. Which is NOT a characteristic of microservices architecture? a) Service independence b) Centralized
data management c) Business capability focus d) Decentralized governance
Answer: b) Centralized data management
Q5. In layered architecture, which layer is responsible for business rules? a) Presentation Layer b) Business
Logic Layer c) Data Access Layer d) Database Layer
Answer: b) Business Logic Layer
Q6. Cold start is a challenge associated with: a) Microservices b) Layered architecture c) Serverless
computing d) Function-oriented design
Answer: c) Serverless computing
Q7. Structure charts primarily show: a) Data flow between processes b) Hierarchical organization of
modules c) User interface design d) Database relationships
Answer: b) Hierarchical organization of modules
Q8. Which coupling type is considered the loosest? a) Content coupling b) Common coupling c) Control
coupling d) Data coupling
Answer: d) Data coupling
Q9. The main benefit of modularity is: a) Faster execution b) Reduced memory usage c) Easier
maintenance d) Better user interface
Answer: c) Easier maintenance
Q10. In DFD, external entities represent: a) Internal processes b) Data stores c) Sources or destinations of
data outside system d) Control flows
Answer: c) Sources or destinations of data outside system
Q11. Function-oriented design follows which approach? a) Bottom-up b) Top-down c) Middle-out d)
Random
Answer: b) Top-down
Q12. Which is a key characteristic of serverless computing? a) Manual server management b) Fixed server
allocation c) Pay-per-use pricing d) Always-on servers
Answer: c) Pay-per-use pricing
