Notes on Software Design and Architecture

1. Introduction to Design
• Definition: Design in software refers to the process of defining the architecture, components,
interfaces, and other characteristics of a system.
• Purpose: The goal is to create a blueprint that guides the development of the software, ensuring
it meets requirements and is maintainable.
2. Importance of Design
• Quality Assurance: Good design leads to high-quality software that is reliable, efficient, and easy
to maintain.
• Cost-Effectiveness: Investing time in design can reduce costs in the long run by minimizing
changes and rework during development.
• User Satisfaction: A well-designed system enhances user experience and satisfaction by being
intuitive and functional.
3. Difference Between Design and Architecture
• Design: Focuses on the implementation details and how components interact within the system.
• Architecture: Refers to the high-level structure of the software system, including its components
and their relationships. It sets the foundation for the design.
4. Course Structure
• Module 1: Introduction to Software Design
o Covers basic concepts of software design and architectural styles.
• Module 2: Detailed Design Phase
o Focuses on Object-Oriented Design and various design patterns, which are reusable
solutions to common design problems.
5. Motivation for Learning Design
• Understanding design principles is crucial for developing robust software systems.
• It prepares students for real-world challenges in software development and enhances problem-
solving skills.
6. Course Prerequisites
• Software Engineering I: A foundational course that provides an overview of software
development processes.
• Software Requirements Specification: Understanding requirements is essential for effective
design.
Explanation of Key Concepts
• Software Design: This is a critical phase in software development where the focus is on creating
a blueprint for the system. It involves making decisions about how the software will function and
how its components will interact. Good design is essential for ensuring that the software is not
only functional but also maintainable and scalable.
• Software Architecture: This is a higher-level concept that deals with the overall structure of the
software system. It defines the system's components and their relationships, serving as a
framework for the design phase. Understanding architecture helps in making informed decisions
about technology choices and system scalability.
• Design Patterns: These are standard solutions to common problems in software design. Learning
about design patterns is crucial for developing flexible and reusable code. They help in
addressing issues like object creation, structure, and behavior in a systematic way.

1. Definition of Software Engineering

 • Description: Software engineering is an engineering discipline that focuses on the systematic
design, development, testing, and maintenance of software systems. It integrates principles from
computer science, project management, and engineering to create software that is reliable,
efficient, and meets user needs.
• Significance: This definition emphasizes that software engineering is not just about coding; it
involves a comprehensive approach to software development that ensures quality and
effectiveness throughout the software lifecycle.
2. Importance of Software Engineering
• Description: Software engineering is vital for:
o Quality Assurance: Ensures that software meets specified requirements and is free of
defects.
o Cost Management: Helps in estimating costs accurately and managing budgets
effectively.
o Risk Reduction: Identifies potential risks early in the development process and mitigates
them.
o Team Collaboration: Facilitates better communication and collaboration among team
members.
• Significance: The importance of software engineering lies in its ability to produce high-quality
software that meets user expectations while minimizing risks and costs.
3. Software Engineering Methods
• Description: Various methodologies guide the software development process, including:
o Agile: An iterative approach that promotes flexibility and customer collaboration.
o Waterfall: A linear and sequential model where each phase must be completed before
the next begins.
o Spiral: Combines iterative development with systematic risk assessment.
o V-Model: Emphasizes verification and validation at each development stage.
• Significance: Understanding these methods allows teams to select the most appropriate
approach based on project requirements, team dynamics, and stakeholder needs.
4. Attributes of Good Software
• Description: Essential attributes include:
o Reliability: The software performs consistently under specified conditions.
o Efficiency: Optimal use of system resources, including memory and processing power.
o Usability: The software is user-friendly and easy to navigate.
o Maintainability: The ease with which software can be modified to correct defects or
improve performance.
o Portability: The ability to run on different platforms without modification.
• Significance: These attributes are critical for ensuring that software meets user needs and can
adapt to changing requirements over time.
5. Key Challenges in Software Engineering
• Description: Common challenges include:
o Rapid Technological Changes: Keeping up with new tools, languages, and frameworks.
o Managing Project Complexity: Coordinating large teams and multiple components.
o Ensuring Software Quality: Maintaining high standards throughout the development
process.
o Meeting User Requirements: Accurately capturing and implementing user needs.
• Significance: Recognizing these challenges helps teams prepare and implement strategies to
overcome them, leading to more successful projects.
6. Stakeholders in Software Engineering
 • Description: Key stakeholders include:
o Users: Individuals who will interact with the software.
o Developers: The technical team responsible for building the software.
o Project Managers: Individuals overseeing the project to ensure it stays on track.
o Clients: Organizations or individuals who commission the software.
• Significance: Engaging stakeholders throughout the development process is crucial for gathering
requirements, receiving feedback, and ensuring that the final product meets expectations.
7. Difficulties and Risks in Software Engineering
• Description: Common difficulties and risks include:
o Scope Creep: Uncontrolled changes or additions to project scope.
o Budget Overruns: Exceeding the allocated budget due to unforeseen issues.
o Technical Debt: Accumulating shortcuts that may lead to future problems.
o Security Vulnerabilities: Risks associated with potential breaches or attacks.
• Significance: Identifying and managing these risks is essential for delivering successful software
projects and maintaining the integrity and security of the software.

Lecture 2: Detailed Notes on Requirements Engineering

1. What is a Requirement?
A requirement can range from a simple, high-level statement of what a system should do to a detailed
technical specification. It defines the services or constraints of the system.
For example:
• High-level: "The software should allow users to book tickets online."
• Detailed: "The system must store user bookings in a database and generate confirmation emails
upon successful payment."
This dual nature of requirements serves two main purposes:
1. Basis for a Bid: Broad statements are used when different contractors bid for a project, allowing
flexibility in their approaches.
2. Basis for a Contract: Precise and measurable requirements form the foundation of agreements
between clients and developers.
Agile Perspective: In agile methods like Scrum, detailed requirement documents are often avoided
because requirements can change rapidly. Instead, short descriptions, called user stories, are used to
capture requirements incrementally.

2. Types of Requirements
2.1. Functional Requirements (FRs):
• These describe the services or functions the system must provide.
• Examples:
o "The system must authenticate users using a valid email and password."
o "The software must generate daily sales reports for administrators."
2.2. Non-Functional Requirements (NFRs):
• Define constraints or quality attributes of the system, such as:
o Performance: "The system must process 500 transactions per second."
o Security: "All sensitive data must be encrypted using AES-256 encryption."
o Reliability: "System uptime must be 99.99% annually."
2.3. Domain Requirements:
• Specific to the system’s operational environment.
 • Example: A hospital management system must comply with local healthcare regulations like
HIPAA (in the USA).
Note: NFRs and domain requirements are often more critical than FRs because failing to meet them can
make the system unusable.

3. Characteristics of Good Requirements

For requirements to be effective, they should be:
1. Unambiguous: Clearly stated to avoid multiple interpretations.
Example: Instead of "System should respond quickly", use "System should respond within 2
seconds."
2. Testable: Requirements must allow verification during testing.
3. Complete: Cover all system aspects, avoiding gaps.
4. Consistent: No conflicts between different requirements.
5. Feasible: Must be realistic to implement.

4. Requirements Engineering Process

The Requirements Engineering Process ensures that the software developed aligns with client needs. It
includes the following stages:

4.1. Requirements Elicitation

Gathering information from stakeholders about what they need.
Key Activities:
• Stakeholder Analysis: Identify all individuals/groups involved in the system, such as end-users,
clients, or regulators.
• Techniques for Gathering Requirements:
1. Interviews: Talking directly with stakeholders.
2. Questionnaires: Distributing structured forms to collect data.
3. Observation: Watching users perform tasks to identify pain points.
4. Prototyping: Building a basic version of the system for feedback.
5. Focus Groups: Stakeholders discuss system features in a group setting.
Challenges in Elicitation:
• Stakeholders may not articulate their needs clearly.
• Conflicting views among stakeholders.
• Changes in requirements during development.

4.2. Requirements Analysis

This stage involves refining and prioritizing the gathered requirements.
Steps in Analysis:
1. Classification: Organize requirements into categories (e.g., functional vs. non-functional).
2. Prioritization: Decide which requirements are most critical to the system.
3. Conflict Resolution: Address and negotiate conflicts between stakeholders' needs.
Challenges: Requirements often evolve during this phase due to new stakeholders or insights.

4.3. Requirements Specification

Documenting requirements in a clear, structured format.
The output of this stage is often a Software Requirements Specification (SRS) document, which serves
as a formal agreement.
SRS Document Components:
 1. Introduction: Overview of the project and goals.
2. User Requirements: High-level descriptions for non-technical audiences.
3. System Requirements: Detailed technical specifications for developers.
4. Constraints: Limitations like budget, legal regulations, or technology.

4.4. Requirements Validation

Ensures the requirements are complete, correct, and aligned with stakeholder expectations.
Validation Techniques:
1. Reviews: Formal walkthroughs with stakeholders.
2. Prototyping: Checking requirements by building a working model.
3. Test-Case Generation: Developing test cases to ensure requirements are verifiable.
Key Questions to Ask During Validation:
• Validity: Do requirements meet user needs?
• Consistency: Are there conflicts among requirements?
• Feasibility: Can they be implemented within budget and time constraints?

4.5. Requirements Management

Manages changes to requirements throughout the development lifecycle.
Why is it Important?
• Requirements often evolve due to changes in business needs, technology, or regulations.
• Poor management can lead to "scope creep," where unplanned features overwhelm the project.
Key Practices:
1. Version Control: Maintain a record of changes to requirements.
2. Traceability: Link requirements to design, implementation, and testing stages.
3. Change Control Board (CCB): A group that evaluates and approves/rejects changes.

5. Techniques for Gathering Requirements

Here are the most common techniques explained:
1. Interviews:
o Structured or unstructured conversations to understand user needs.
o Strength: Allows in-depth exploration of specific topics.
o Weakness: Time-consuming and subjective.
2. Questionnaires:
o Written surveys to collect information from multiple stakeholders quickly.
o Strength: Cost-effective for large groups.
o Weakness: Responses may lack depth.
3. Observation:
o Watch users interact with current systems to identify gaps.
o Strength: Real-world insight.
o Weakness: May not capture edge cases.
4. Prototyping:
o Develop a simplified version of the system to gather feedback.
o Strength: Tangible model for users.
o Weakness: Misleading expectations if the prototype differs from the final product.
5. Brainstorming:
o Collaborative sessions to generate ideas.
o Strength: Encourages creativity.
o Weakness: Needs moderation to remain focused.
Lecture 3: Software Design
1. What is Software Design?
Definition:
Software design is the process of defining the architecture, components, interfaces, and other
characteristics of a system to meet specified requirements. It bridges the gap between requirements
(what the system should do) and implementation (how it will be built).
Key Questions in Design:
1. How should the system components interact?
2. What tools and techniques should be used to implement the architecture?
3. How do we incorporate non-functional requirements (e.g., performance, reliability)?
Why is Design Important?
• A good design ensures the system:
1. Meets requirements.
2. Is maintainable and extendable.
3. Has low development cost and minimal defects.

2. Phases in the Software Design Process

The design process involves breaking down the system into manageable modules. This is achieved in two
stages:
1. High-Level (Architectural) Design:
o Focuses on identifying major components (subsystems) and their relationships.
o Example: Designing modules for a library system, such as user management, cataloging,
and borrowing.
2. Detailed Design:
o Focuses on the internal structure of modules, including:
▪ Data structures.
▪ Algorithms.
▪ Interface designs.
o Example: Designing how the user management module will handle login functionality.

3. The Design Process

The design process should involve multiple levels of abstraction to simplify complex systems.
Key Stages:
1. Architectural Design:
o Identifies the system's overall structure.
o Defines how components interact and communicate.
o Example: An e-commerce system might have subsystems like inventory, payment, and
user profiles.
2. Component Design:
o Breaks down subsystems into smaller, independent units.
o Example: The payment subsystem might have components for handling credit cards and
bank transfers.
3. Interface Design:
o Specifies how components will interact (e.g., APIs, user interfaces).
4. Algorithm Design:
o Focuses on defining logical steps to achieve specific tasks.
o Example: Sorting algorithms for displaying products in order of popularity.
4. From Requirements to Architecture
Transitioning from Requirements to Design involves these steps:
1. Understand the Problem:
o Use the Software Requirements Specification (SRS) to identify system objectives.
2. Decompose the System into Modules:
o Divide the system into subsystems or modules.
o Example: In a ticket booking system, create separate modules for booking tickets,
managing payments, and user accounts.
3. Make Trade-offs:
o Evaluate constraints like cost, performance, and security to decide the best design
approach.
o Example: Sacrificing speed for better fault tolerance in a healthcare system.
4. Define Interactions:
o Specify interfaces between modules.
o Example: Use APIs for modules to exchange data in a well-defined manner.

5. Characteristics of Good Software Design

A good design should have the following attributes:
1. High Cohesion:
o Related tasks are grouped within the same module.
o Example: A user authentication module handles only login and registration.
2. Low Coupling:
o Modules are minimally dependent on each other.
o Example: Changes in the payment module should not affect the user profile module.
3. Scalability:
o The design should support future growth.
o Example: Adding new payment methods without overhauling the entire payment
system.
4. Maintainability:
o The system should be easy to update or debug.
5. Reusability:
o Components should be generic enough to be used in other systems.

6. Key Trade-offs in Design

Design decisions often involve balancing competing factors:
1. Cost vs. Quality:
o High-quality designs might increase costs.
o Example: Using a microservices architecture improves scalability but increases
development costs.
2. Security vs. Usability:
o Adding multi-factor authentication improves security but complicates user experience.
3. Performance vs. Robustness:
o Building a highly fault-tolerant system might reduce speed.

7. Software Design Methodologies

Structured Analysis and Design (SAD):
• Suitable for stable, well-defined requirements.
• Uses techniques like Data Flow Diagrams (DFDs) and Entity-Relationship (ER) models.
Object-Oriented Analysis and Design (OOAD):
• Focuses on objects representing real-world entities.
• Common techniques:
o Use Case Diagrams: Show how users interact with the system.
o Class Diagrams: Define the attributes and behaviors of objects.
Comparison of SAD and OOAD:
Feature SAD OOAD
Approach Process-oriented Object-oriented
Reusability Low High
Methodology Sequential (e.g., Waterfall) Iterative/Incremental
Example ER diagrams, DFDs Use Case Diagrams, Classes

8. Architectural Design
Definition:
Architectural design specifies the major components of the system and their interactions.
Benefits:
1. Stakeholder Communication: Serves as a blueprint for discussing the system structure.
2. Reuse: A well-designed architecture can be applied to similar systems.
System Characteristics to Consider:
• Performance: Ensure the design meets speed requirements.
• Reliability: Address fault tolerance and error recovery.
• Security: Protect against unauthorized access.
• Maintainability: Design should support updates with minimal effort.

9. Stages of Design
1. Problem Understanding:
o Analyze requirements from multiple perspectives.
2. Identify Solutions:
o Brainstorm possible approaches and evaluate them.
3. Describe Abstractions:
o Use models like flowcharts or Unified Modeling Language (UML) diagrams.
4. Iterate:
o Refine the design based on stakeholder feedback.

Lecture 4: Design Principles and Patterns

1. Symptoms of Bad Design
A poorly designed software system can lead to the following issues:
1. Rigidity:
o The system is hard to modify because every change affects multiple parts of the code.
o Example: Adding a new feature in an e-commerce app (e.g., a "wishlist") requires
rewriting code in unrelated modules.
o Impact: Slows down development and increases costs.
2. Fragility:
o The system breaks unexpectedly when a change is made.
o Example: Fixing a bug in the checkout system unintentionally breaks the inventory
module.
o Impact: Increases testing and debugging time.
 3. Immobility:
o The system is difficult to reuse because useful parts are tightly coupled to unrelated
parts.
o Example: A library system’s user management module depends on specific database
tables, making it hard to use elsewhere.
4. Viscosity:
o It’s easier to implement a quick hack than to make changes that align with the design.
o Example: Adding a feature with a shortcut fix because the proper implementation is too
time-consuming.
Root Cause: Improper dependencies between modules lead to these problems.

2. Characteristics of Good Design

A good design has:
1. High Cohesion:
o Components should focus on a single responsibility.
o Example: A module for user authentication should not handle email notifications.
2. Low Coupling:
o Components should be minimally dependent on one another.
o Example: Changes in the payment gateway module should not affect the order tracking
module.

3. SOLID Principles
The SOLID principles guide developers in creating robust, maintainable software.
1. Single Responsibility Principle (SRP):
• Definition: A class should have only one reason to change.
• Explanation: Each class should handle a single functionality. Combining responsibilities increases
the risk of unexpected changes.
• Example:
Bad:
java
Copy code
class Employee {
public Pay calculatePay() {...}
public void save() {...}
public void generateReport() {...}
}
Problem: Pay calculation, saving, and report generation are unrelated responsibilities.
Solution: Separate into multiple classes.
java
Copy code
class Payroll { public Pay calculatePay() {...} }
class EmployeeData { public void save() {...} }
class ReportGenerator { public void generateReport() {...} }

2. Open-Closed Principle (OCP):

• Definition: Software entities should be open for extension but closed for modification.
• Explanation: You should be able to add new functionality without changing existing code.
 • Example:
Bad:
java
Copy code
void checkout(Receipt receipt) {
if (paymentMethod == "cash") { acceptCash(); }
else if (paymentMethod == "credit") { acceptCreditCard(); }
}
Problem: Adding a new payment method requires modifying the function.
Solution: Use abstraction:
java
Copy code
interface PaymentMethod { void acceptPayment(Money total); }
class Cash implements PaymentMethod { ... }
class CreditCard implements PaymentMethod { ... }
void checkout(Receipt receipt, PaymentMethod payment) { payment.acceptPayment(total); }

3. Liskov Substitution Principle (LSP):

• Definition: Subclasses should be substitutable for their base classes without altering program
behavior.
• Explanation: A derived class should extend functionality without breaking the parent class’s
expectations.
• Example:
Bad: Modeling a Square as a subclass of Rectangle.
java
Copy code
class Rectangle {
void setWidth(int width);
void setHeight(int height);
}
class Square extends Rectangle {
void setWidth(int width) { setHeight(width); }
}
Problem: The Square violates the Rectangle behavior because setting width unexpectedly changes
height.

4. Interface Segregation Principle (ISP):

• Definition: Clients should not be forced to depend on methods they don’t use.
• Explanation: Large interfaces should be split into smaller, specific ones.
• Example:
Bad:
java
Copy code
interface Worker {
void work();
void takeLunchBreak();
}
Problem: Robots implementing Worker would need to define takeLunchBreak, which they don’t use.
Solution:
java
Copy code
interface Workable { void work(); }
interface Breakable { void takeLunchBreak(); }
class HumanWorker implements Workable, Breakable {...}
class RobotWorker implements Workable {...}

5. Dependency Inversion Principle (DIP):

• Definition: High-level modules should not depend on low-level modules. Both should depend on
abstractions.
• Explanation: Avoid hard-coding dependencies; use interfaces to decouple.
• Example:
Bad:
java
Copy code
class Manager {
Worker worker = new Worker();
void manage() { worker.work(); }
}
Problem: The Manager is tightly coupled with Worker.
Solution: Use abstraction:
java
Copy code
interface IWorker { void work(); }
class Worker implements IWorker {...}
class Manager {
IWorker worker;
void setWorker(IWorker worker) { this.worker = worker; }
void manage() { worker.work(); }
}

4. Design Patterns
Definition:
Design patterns are proven solutions to recurring design problems. They provide templates for writing
code that is efficient, reusable, and maintainable.

Categories of Design Patterns:

1. Creational Patterns: Deal with object creation.
o Example: Factory Pattern, Singleton Pattern.
2. Structural Patterns: Deal with object relationships and composition.
o Example: Adapter Pattern, Composite Pattern.
3. Behavioral Patterns: Focus on communication between objects.
o Example: Observer Pattern, Strategy Pattern.

Example: Singleton Pattern

• Ensures a class has only one instance and provides a global access point.
 • Code:
java
Copy code
public class Singleton {
private static Singleton instance;
private Singleton() {} // Private constructor
public static Singleton getInstance() {
if (instance == null) {
instance = new Singleton();
}
return instance;
}
}
Benefits of Design Patterns:
1. Standardization: Common vocabulary for developers.
2. Reusability: Reduces development time.
3. Efficiency: Avoids reinventing the wheel.

Software Design and Architecture: Exam Preparation Notes

1. Core Concepts and Definitions

What is Software Architecture?
Software architecture is the high-level structure of a system, comprising its components, their
relationships, and the principles guiding its design and evolution. It ensures that the system’s
requirements are met while enabling scalability, maintainability, and performance.
Key Points:
• Components: Functional units (e.g., modules, services).
• Connectors: Define communication mechanisms between components.
• Relationships: Specify dependencies and interactions.
• Principles: Govern how components are organized and interact.
Roles of Software Architecture
1. Assessment and Evaluation:
o Ensures architectural trade-offs align with stakeholder requirements.
o Includes quality assessments for performance, security, and reliability.
2. Configuration Management:
o Uses architecture to manage software configurations and changes.
3. Dynamic Adaptability:
o Enables systems to reconfigure during runtime to meet changing requirements.

2. Architecture Design Process

The process transforms requirements into an architectural design.
Steps
1. Functionality-Based Design:
o Define the system’s boundaries and context.
o Identify core system archetypes (reusable patterns).
o Decompose the system into main components.
o Perform an initial validation of the architecture.
2. Quality Attributes Assessment:
 o Assess how well the architecture meets desired quality attributes (e.g., maintainability).
o Use tools like static analysis, metrics-based models, or scenario simulations.
3. Architecture Transformation:
o Refine the design to enhance quality attributes.
o This iterative process ensures all requirements are met.

3. Architectural Styles
3.1 Pipes and Filters
• Definition: The system is composed of filters (components) and pipes (connectors).
• Components:
o Filters: Transform input data to output.
o Pipes: Connect filters and handle data flow.
Advantages:
• Reusable filters.
• Easy to understand and extend.
Disadvantages:
• Batch processing limits interactive applications.
Examples:
• UNIX shell commands.
• Compilers (lexical analysis, syntax checking).

3.2 Two-Tier (Client/Server)

• Definition: Splits the application into two layers:
o Client handles presentation and application logic.
o Server handles database interactions.
Advantages:
• Simplicity for small-scale applications.
Disadvantages:
• Limited scalability compared to multi-tier systems.
Example:
• Google Search service with multiple client types accessing a central server.

3.3 N-Tier Architecture

• Definition: Extends the two-tier model to include additional layers, often categorized as:
1. Presentation Layer: Handles UI and user interactions.
2. Business Layer: Implements core application logic.
3. Data Layer: Manages databases and storage.
Advantages:
• Scalability and separation of concerns.
• Improved maintainability.
Disadvantages:
• Increased complexity and potential performance overhead.
Examples:
• E-commerce platforms.
• Web applications with separate front-end, middleware, and back-end layers.

3.4 Layered Architecture

• Definition: System is divided into hierarchical layers, each providing services to the layer above.
Advantages:
• High modularity and abstraction.
• Easy to replace or modify layers without affecting others.
Disadvantages:
• Performance issues due to inter-layer communication.
Examples:
• Network protocol stacks (e.g., TCP/IP).
• Operating systems.

3.5 Blackboard Architecture

• Definition: Central repository (blackboard) is used by various components to store and share
data.
Advantages:
• Components are independent, enabling flexibility and scalability.
Disadvantages:
• Centralized control can create bottlenecks.
Examples:
• AI systems.
• Integrated Development Environments (IDEs).

3.6 Model-View-Controller (MVC)

• Definition: Divides an application into three interconnected components:
o Model: Handles data and logic.
o View: Displays data to the user.
o Controller: Manages user interactions.
Advantages:
• Allows multiple views for the same data.
• Separates concerns for easier maintenance.
Disadvantages:
• Complexity for small-scale applications.
Examples:
• Web frameworks like Django, Ruby on Rails.
• Mobile apps with dynamic UIs.

3.7 Repository Architecture

• Definition: All components interact via a shared repository.
Advantages:
• Simplifies data consistency and backups.
• Decouples components for independent development.
Disadvantages:
• Central repository is a single point of failure.
Examples:
• Database-driven systems.
• IDE tools where components share project data.

4. Architectural Styles vs. Patterns

Architectural Styles
• High-level organizational principles for software design.
 • Examples: Pipes-and-filters, Layered Architecture, Client-Server.
Architectural Patterns
• Detailed solutions to specific problems within an architectural style.
• Examples: MVC (pattern within layered style), Microservices (pattern within distributed systems).
Key Differences:
• Scope: Styles provide broad guidelines, patterns address specific design issues.
• Granularity: Styles operate at the system level; patterns focus on subsystems.

Summary and Insights

• Software Architecture ensures that systems meet their functional and non-functional
requirements effectively.
• The choice of Architectural Style depends on the system’s needs, such as scalability,
performance, or maintainability.
•