CSE320 Unit 2 Notes

Unit II: Issues in Software Design

Basic Issues in Software Design

Definition of Software Design

Software Design is a critical phase in the software development life cycle where software engineers transform the requirements and specifications gathered during the requirements engineering phase into a blueprint for constructing the software system. It involves:

• Conceptualizing Solutions: Envisioning various approaches to solve the identified problems.
• Defining System Architecture: Outlining the overall structure of the software, including components, modules, interfaces, and data flow.
• Creating Design Models: Utilizing diagrams and models to represent the system visually.

Key Aspects:

• Blueprint Creation: Provides a detailed plan that guides developers during implementation.
• Abstraction and Decomposition: Breaks down complex systems into manageable components.
• Balancing Constraints: Considers trade-offs between different design goals.

Key Design Considerations

Effective software design requires careful attention to several critical factors to ensure the final product meets user needs and operates efficiently.

Correctness

• Definition: The degree to which the design adheres to the specified requirements.
• Importance: Ensures that the system functions as intended and satisfies user expectations.
• Strategies:
  • Requirement Traceability: Mapping design elements back to requirements.
  • Validation Techniques: Reviewing designs with stakeholders.

Efficiency

• Definition: Optimal use of system resources such as CPU time, memory, bandwidth, and storage.
• Importance: Enhances performance and user satisfaction by providing fast and responsive software.
• Strategies:
  • Algorithm Optimization: Selecting the most efficient algorithms.
  • Resource Management: Minimizing wasteful use of resources.

Reliability

• Definition: The ability of the software to function correctly under specified conditions for a specified period.
• Importance: Reduces the risk of system failures and downtime.
• Strategies:
  • Error Handling: Designing robust mechanisms to handle exceptions and faults.
  • Redundancy: Incorporating backup systems to prevent single points of failure.

Maintainability

• Definition: The ease with which the software can be modified to correct defects, improve performance, or adapt to a changed environment.
• Importance: Reduces long-term costs and extends the software's useful life.
• Strategies:
  • Modular Design: Breaking the system into independent modules.
  • Clear Documentation: Providing detailed design documents and code comments.

Usability

• Definition: The degree to which the software is easy to use and learn for its intended users.
• Importance: Increases user satisfaction and productivity.
• Strategies:
  • User-Centered Design: Involving users in the design process.
  • Consistent Interfaces: Ensuring uniform design across all parts of the application.

Portability

• Definition: The ease with which software can be transferred from one environment or platform to another.
• Importance: Expands the potential user base and prolongs software relevance.
• Strategies:
  • Platform-Independent Languages: Using languages and libraries that support multiple platforms.
  • Abstraction Layers: Isolating system-dependent code.

Challenges in Software Design

Designing software is a complex task that involves navigating various challenges:

Managing Complexity

• Issue: Modern software systems are intricate, with numerous interacting components.
• Approach:
  • Abstraction: Hiding complex details behind simpler interfaces.
  • Decomposition: Breaking systems into smaller, manageable pieces.
  • Use of Design Patterns: Applying proven solutions to common problems.

Accommodating Change and Scalability

• Issue: Requirements and environments often change over time; systems may need to handle increased loads.
• Approach:
  • Flexible Design: Creating adaptable structures that can evolve.
  • Scalable Architectures: Designing for both vertical and horizontal scaling.
  • Modularity: Facilitating updates without overhauling the entire system.

Balancing Conflicting Requirements

• Issue: Different stakeholders may have requirements that conflict, such as security versus usability.
• Approach:
  • Prioritization: Determining which requirements are most critical.
  • Trade-off Analysis: Assessing the impact of emphasizing one requirement over another.
  • Stakeholder Engagement: Aligning expectations through communication.

Ensuring Security and Compliance

• Issue: Protecting the system from malicious attacks and adhering to legal regulations.
• Approach:
  • Security by Design: Incorporating security considerations from the outset.
  • Compliance Standards: Ensuring adherence to relevant laws and industry guidelines (e.g., GDPR, HIPAA).
  • Regular Audits: Reviewing the system for vulnerabilities and compliance issues.

Modularity

Definition

Modularity is a fundamental design principle that involves dividing a software system into separate, self-contained units called modules. Each module encapsulates a specific aspect of the system's functionality, allowing developers to manage complexity by focusing on one part of the system at a time.

• Characteristics:
  • Independence: Modules operate autonomously with minimal dependencies.
  • Encapsulation: Internal workings are hidden from other modules.
  • Interfaces: Well-defined points of interaction.

Benefits of Modularity

Ease of Maintenance

• Explanation: Changes can be made to one module without significantly impacting others.
• Impact: Simplifies bug fixes and updates.

Reusability

• Explanation: Modules can be reused across different parts of the system or in other projects.
• Impact: Saves development time and resources.

Parallel Development

• Explanation: Multiple teams can work on different modules simultaneously.
• Impact: Accelerates development timelines.

Reduced Complexity

• Explanation: Simplifies system understanding by allowing focus on one module at a time.
• Impact: Enhances productivity and reduces errors.

Principles of Modularity

Separation of Concerns

• Definition: Dividing a program into distinct features that overlap in functionality as little as possible.
• Application: Assigning specific responsibilities to each module.

Information Hiding

• Definition: Concealing the internal details of modules from others.
• Application: Exposing only necessary interfaces, preventing unintended interactions.

Inter-module Communication

• Definition: Establishing how modules interact with each other.
• Application:
  • Interfaces and APIs: Defining clear methods for data exchange.
  • Loose Coupling: Minimizing dependencies between modules.

Cohesion

Definition

Cohesion refers to the degree to which the elements within a module belong together. It is a measure of the strength of the relationship between the module's internal components. High cohesion within modules is desirable.

• Goal: Each module should perform a single task or a group of closely related tasks.

Types of Cohesion (From Highest to Lowest)

Functional Cohesion

• Definition: All elements contribute to a single, well-defined function.
• Example: A module that computes the mathematical factorial of a number.
• Benefits: Maximizes reusability and reliability.

Sequential Cohesion

• Definition: The output from one part serves as input to another within the module.
• Example: A module that processes data in stages (e.g., reads data, processes it, and writes output).
• Benefits: Logical flow of processing steps.

Communicational Cohesion

• Definition: Elements operate on the same data set or contribute to the same data output.
• Example: A module that updates various aspects of a customer record.
• Benefits: Improves efficiency by localizing related operations.

Procedural Cohesion

• Definition: Elements follow a specific sequence of execution but are not necessarily related.
• Example: A module that performs a sequence of unrelated tasks necessary in a specific order.
• Benefits: Enforces order but may group unrelated activities.

Temporal Cohesion

• Definition: Elements are grouped by the time they are executed.
• Example: Initialization routines that run at system startup.
• Benefits: Simplifies scheduling but may mix unrelated functions.

Logical Cohesion

• Definition: Elements perform similar activities but are not related functionally.
• Example: A module containing all I/O operations (reading files, printing, logging).
• Drawback: May lead to less clarity about module purpose.

Coincidental Cohesion

• Definition: Elements have little or no meaningful relationship.
• Example: A module that groups miscellaneous functions together.
• Drawback: Leads to confusion and difficulty in maintenance.

Importance of High Cohesion

• Enhances Clarity: Modules with a single, clear purpose are easier to understand.
• Facilitates Maintenance: Changes are localized, reducing the impact on other parts of the system.
• Improves Reliability: High cohesion reduces the likelihood of errors due to unintended interactions within a module.
• Encourages Reusability: Well-defined, cohesive modules can be easily reused in different contexts.

Coupling and Layering

Coupling

Definition

Coupling refers to the degree of interdependence between software modules. It measures how closely connected modules are within a system. Low coupling is preferred as it indicates less dependency between modules.

• Goal: Minimize coupling to achieve modularity and ease of maintenance.

Types of Coupling (From Highest to Lowest)

Content Coupling

• Definition: One module directly accesses or modifies the content of another module.
• Example: Module A modifies local data or instructions of Module B.
• Impact: Highly undesirable due to tight interdependence.

Common Coupling

• Definition: Modules share global data.
• Example: Multiple modules read and write to a global variable.
• Impact: Increases complexity and error potential.

Control Coupling

• Definition: One module controls the flow of another by passing it information on what to do.
• Example: Passing a control flag that dictates module behavior.
• Impact: Modules are dependent on the control logic of others.

Stamp/Data-Structured Coupling

• Definition: Modules share composite data structures, and use only parts of them.
• Example: Passing an entire record when only a field is needed.
• Impact: Can lead to unnecessary dependencies and data exposure.

Data Coupling

• Definition: Modules share data by passing parameters.
• Example: Module A calls Module B and passes necessary data.
• Impact: Preferred method; modules interact through well-defined interfaces.

Message Coupling

• Definition: Modules communicate through message passing or parameter lists.
• Example: Objects interacting via method calls in object-oriented design.
• Impact: Very low coupling; modules are independent and interact only through messages.

No Coupling

• Definition: Modules are completely independent with no interaction.
• Example: Stand-alone modules that do not communicate.
• Impact: Maximum independence but may not be practical in a functional system.

Importance of Low Coupling

• Reduces Dependencies: Changes in one module have minimal impact on others.
• Enhances Maintainability: Easier to update and fix modules without side effects.
• Improves Reusability: Modules can be reused in different systems with minimal adjustments.
• Facilitates Testing: Modules can be tested independently.

Layering

Definition

Layering is a design approach that organizes software into hierarchical layers, each providing a set of services to the layer above and utilizing services from the layer below. This separation helps manage complexity and promotes organized development.

Common Layers in Software Architecture

Presentation Layer

• Role: Handles user interfaces and user interaction.
• Components:
  • Graphical User Interface (GUI)
  • Command-line Interface (CLI)
• Responsibility: Presents data to the user and interprets user commands.

Application/Business Logic Layer

• Role: Contains the core functionality and processing logic of the system.
• Components:
  • Business Rules
  • Data Validation
  • Process Coordination
• Responsibility: Processes data inputs, makes decisions, and performs calculations.

Data Access Layer

• Role: Manages communication between the business logic layer and data storage.
• Components:
  • Data Access Objects (DAOs)
  • Repositories
• Responsibility: Executes queries, handles data transactions, and maps data between objects and database.

Database/Data Layer

• Role: Responsible for data storage and retrieval.
• Components:
  • Databases (SQL, NoSQL)
  • File Systems
• Responsibility: Stores data persistently, ensuring data integrity and security.

Benefits of Layering

• Separation of Concerns:
  • Each layer focuses on specific aspects, simplifying development and maintenance.
• Independent Development:
  • Teams can work on different layers simultaneously.
• Scalability:
  • Layers can be scaled independently to meet performance demands.
• Flexibility:
  • Changes in one layer (e.g., replacing a database) have minimal impact on others.

Function-Oriented Software Design

Definition

Function-Oriented Design is a methodology where the system is designed around functions or procedures that perform specific tasks. The focus is on identifying and organizing functions to achieve the desired system behavior.

• Emphasis: Processes and the flow of data between them.

Characteristics

Top-Down Approach

• Explanation: Starts with a high-level overview of the system and breaks it down into more detailed functions.
• Process: Decompose the system into main functions, sub-functions, and so on.

Process-Centric

• Explanation: Centers on the activities and operations that the system must perform.
• Outcome: A hierarchy of functions representing the system's behavior.

Design Process Steps

Understand the Requirements

• Activity: Analyze and comprehend the functional requirements specified by stakeholders.
• Outcome: A clear understanding of what the system needs to accomplish.

Develop a Data Flow Diagram (DFD)

• Activity: Create DFDs to model how data moves through the system and how it is processed.
• Outcome: Visual representation of the system's processes and data flow.

Identify Modules

• Activity: Decompose the system into smaller, manageable functions or modules based on the DFDs.
• Outcome: A set of modules that perform specific tasks.

Create Structure Charts

• Activity: Develop structure charts to illustrate the hierarchical organization and relationships between modules.
• Outcome: A blueprint of module interactions and control flow.

Advantages

• Clarity in Process Flow: Clearly depicts the sequence of operations.
• Structured Approach: Provides a systematic method for designing software.
• Suitability for Certain Systems: Ideal for transaction processing or batch processing systems with well-defined procedures.

Disadvantages

• Data Structure Challenges: Less adaptable to changes in data structures compared to object-oriented design.
• Poor at Handling Change: Modifying functionality can be difficult if it affects multiple functions.
• Not Ideal for Interactive Systems: Less effective for systems requiring high interactivity or those centered around data objects.

Data Flow Diagram (DFD)

Definition

A Data Flow Diagram (DFD) is a graphical tool that depicts the flow of data within a system, illustrating how data is processed by the system in terms of inputs and outputs.

• Purpose: Model the processes involved in a system and the data interchange among them.

Components

Processes

• Symbol: Circles or rounded rectangles.
• Function: Represent activities that transform data from inputs to outputs.
• Labeling: Verb phrases (e.g., "Process Order").

Data Flows

• Symbol: Arrows.
• Function: Indicate the direction of data movement between components.
• Labeling: Nouns (e.g., "Order Details").

Data Stores

• Symbol: Open-ended rectangles or parallel lines.
• Function: Represent where data is stored within the system.
• Labeling: Nouns, often plural (e.g., "Customer Records").

External Entities

• Symbol: Squares or rectangles.
• Function: Represent sources or destinations of data outside the system's scope.
• Labeling: Nouns (e.g., "Customer," "Bank").

Levels of DFD

Context Diagram (Level 0)

• Description: Represents the entire system as a single process.
• Purpose: Shows the system's interactions with external entities.
• Characteristics:
  • Simplest form of DFD.
  • Provides an overview without internal details.

Level 1 DFD

• Description: Breaks down the main process into major sub-processes.
• Purpose: Provides more detail about the system's functions.
• Characteristics:
  • Highlights key functions and data flows.
  • Still maintains a high-level perspective.

Level n DFDs

• Description: Further decompose sub-processes into more detailed processes.
• Purpose: Drill down into the specifics of each component.
• Characteristics:
  • Each level adds more detail.
  • Continues until processes are sufficiently detailed for implementation.

Purpose and Usage

• Requirement Analysis:
  • Helps analysts and stakeholders understand and clarify system requirements.
• System Design:
  • Guides developers in system implementation.
• Communication Tool:
  • Facilitates discussions between technical and non-technical stakeholders.

Best Practices

• Consistency: Ensure that inputs and outputs are consistent across different levels.
• Clarity: Keep diagrams simple and avoid overcrowding.
• Labeling: Use clear, descriptive names for all components.
• Balancing DFDs: Maintain input and output consistency when moving between levels.

Structure Chart

Definition

A Structure Chart is a top-down modular design tool that displays the breakdown of a system into its component modules. It illustrates the hierarchical structure and the relationships between modules in terms of control and data exchange.

• Purpose: Visualize the program structure and module interactions.

Components

Modules

• Symbol: Rectangles or boxes.
• Function: Represent individual units of code or functions.
• Labeling: Typically named with verbs or verb phrases.

Connections

• Symbol: Lines connecting modules.
• Function: Indicate calling relationships and hierarchy.
• Types:
  • Control Lines: Solid lines showing the flow of control.
  • Data Lines: Lines with arrows indicating data passing.

Coupling Indicators

• Symbols: Notations or annotations on connections.
• Function: Show the type of data or control information being passed.
• Examples:
  • Data Parameters: Indicated by empty circles.
  • Control Flags: Indicated by filled circles.

Creation Process

Identify Modules

• Activity: Based on functional decomposition, list all necessary modules.
• Outcome: A comprehensive list of system functions.

Establish Hierarchy

• Activity: Determine parent-child relationships among modules.
• Outcome: A hierarchical structure showing control flow.

Define Interactions

• Activity: Specify parameters and data passed between modules.
• Outcome: Clear depiction of module interfaces and dependencies.

Purpose and Benefits

• Visual Representation: Provides a clear picture of the software architecture.
• Facilitates Division of Work: Helps in assigning tasks to different team members.
• Identifies Reusability Opportunities: Highlights modules that can be reused.
• Simplifies Testing: Clarifies testing levels and dependencies.

Comparison with DFDs

• Data Flow Diagrams (DFDs):
  • Focus on the flow of data through processes.
  • Emphasize what happens to data as it moves through the system.
• Structure Charts:
  • Focus on the organization and hierarchy of modules.
  • Emphasize control flow and module relationships.