Module – 4

Computational photography: Object-Oriented Design

Principles – Introduction, SOLID Principles – SRP, OCP,
LSP, ISP, DIP, Design Pattern Introduction – Purpose,
Classification
Creational Pattern: Singleton, Creational Pattern:
Factory Method, Structural Pattern: Adapter,
Behavioral Pattern: Observer.
 System Design Introduction

System design is the process of planning, structuring and defining the architecture of Software System.
• Involves translating user requirements into a detailed blueprint that guides the implementation phase.

• The goal is to create a well-organized and efficient structure that meets the intended purpose while considering factors
like scalability, maintainability, and performance.

System Design in SDLC

• In System Design Life Cycle, without the designing phase,
one cannot jump to the implementation or the testing part.

• System Design is a vital step and also provides the

backbone to handle exceptional scenarios because it
represents the business logic of the software.
 System Design can be divided into two complementary parts
High-Level Design (HLD)
It lays out the overall architecture of the system — how major
components interact, what services or modules will exist, and
how data flows among them.
• Gives you the big picture: how the system fits together, its
core structure, and major decisions.

• Done by architects, stakeholders and managers

Topics Covered in HLD:

•System architecture overview: Defines the major components, modules, and how they interact (e.g., services, queues,
databases) .
•Data flow and component interaction: Illustrates how data moves between modules, along with key integrations and
interfaces.
•Technology stack and infrastructure: High-level decisions on frameworks, platforms, hardware, databases, and hosting
setups.
•Module responsibilities: Describes what each module does and how they relate to one another .
•Performance & trade-offs: Includes design trade-offs, performance considerations, scalability, security, cost and other
non-functional factors .
•Artifacts: Commonly includes architecture diagrams, component and deployment diagrams, data flow diagrams, and
possibly ER/DB schematic overviews.
Low-Level Design (LLD)
It covers how each part works & is implemented internally
• Gives developers a clear, actionable blueprint to build each component.
• Once a High Level Design is built by stakeholders, it is the job of senior developers and designers to create a low level design.

Prerequisites / What You Should Know First:

• Basic Coding Skills (Data Structures and Algorithms)

• Strong grasp of OOP concepts (Encapsulation, inheritance, polymorphism & abstraction)

Topics Covered:

• Component/module breakdown: Detailed internal logic for each module—with class responsibilities, methods, attributes,
interactions
• Database schema & structure: Designing tables, keys, indexes, relationships with SQL/NoSQL refinements
• API & interface definitions: Precise request/response formats, error codes, methods, endpoints, and internal interfacing
• Error handling & validation logic: Define how each module manages invalid inputs, failures, edge cases, and logging
• Design patterns & SOLID: Implement design patterns and solid principles to ensure clean, extensible, maintainable code
• UML and pseudocode artifacts: Class diagrams, sequence diagrams, pseudocode or flowcharts to clarify logic paths and method
calls
 Steps for getting started with System Design

• Understand Requirements
Gather and analyze business needs by consulting
stakeholders, users, and documentation.
• Define Architecture
Identify key system components and how they interact (e.g.,
services, APIs, databases).
• Choose Tech Stack
Select appropriate languages, databases, frameworks, and
tools based on requirements.
• Design Modules
Break the system into modules, defining their responsibilities
and data flow.
• Plan for Scalability
Design with growth in mind—anticipate load, optimize
bottlenecks, and use scalable patterns.
• Ensure Security & Privacy
Identify risks and implement measures like authentication,
encryption, and data protection.
• Test & Validate
Write test cases and simulate real-world usage to ensure the
system meets requirements.
 Important points to consider when designing a software system:
[Link]: The system should be designed to handle increased loads and be able to scale horizontally or vertically as
needed.

[Link]: The system should be designed to perform efficiently and effectively, with minimal latency and
response time.

[Link]: The system should be reliable and available, with minimal downtime or system failures.

[Link]: The system should be designed with security in mind, including measures to prevent unauthorized access
and protect sensitive data.

[Link]: The system should be designed to be easy to maintain and update, with clear documentation and
well-organized code.

[Link]: The system should be designed to work seamlessly with other systems and components, with clear
and well-defined interfaces.

[Link]: The system should be designed to be user-friendly and intuitive, with a clear and consistent user interface.

[Link]-effectiveness: The system should be designed to be cost-effective, with a focus on minimizing development and
operational costs while still meeting the requirements.
 System Design Life Cycle | SDLC (Design)
System Design Life Cycle is defined as the complete journey of a System from planning to deployment. The System
Design Life Cycle is divided into 7 Phases or Stages, which are:
1. Planning Stage
2. Feasibility Study Stage
3. System Design Stage
4. Implementation Stage
5. Testing Stage
6. Deployment Stage
7. Maintenance and Support

What is meant by System Design Life Cycle (SDLC)?

The system design life cycle is a process that involves planning, creating, testing, and implementing a system. It includes
defining system requirements, specifying how components will interact, and detailing the architecture. It ensures that the
final system meets user needs, is scalable, and can be maintained efficiently throughout its lifecycle.

Imagine it as a recipe for making a cake. You start by planning what kind of cake you want, gathering the ingredients,
mixing them together, baking the cake, making sure it tastes good, and finally, sharing it with others. Similarly, the
SDLC helps professionals in system development follow a clear plan from the beginning of the idea of a system to its
ongoing maintenance.
What are the Phases (Stages) of the System Design Life Cycle?
 Stage 1. Planning
•This is where the project starts! You decide what you want to achieve (goals), how much you can spend (budget), and who
will work on it (team).
•Example: A company plans to build a customer management system and outlines its key features and the team involved.

Stage 2. Feasibility Study

•Before starting, check if the idea is practical. Will it work technically? Is it affordable?
•Example: The company checks if building the system is worth the cost and effort and whether it can deliver the expected
benefits.

Stage 3. System Design

•This stage is all about planning how the system will work behind the scenes and how it will look to users.
•Imagine designing a house, before construction begins, architects create blueprints that show where every room, pipe, and
wire will go. Similarly, in system design, you create a detailed plan that developers will follow to build the system.

Stage 4. Implementation
•Transform the design into an operational system. Developers write the code to create the system based on the design.
•Example: The CRM system's features, like customer profiles and dashboards, are coded
 Stage 5. Testing
•Verify that the system meets the specified requirements and makes sure everything works as planned.
•The CRM system undergoes various testing procedures, such as unit testing, integration testing, and user acceptance testing,
to ensure its functionality, performance, and security.

Stage 6. Deployment
•All of the hard work concludes at the deployment phase, when the system is made accessible for real usage. After all the
planning, designing, and building is finished, it's similar like launching a new store.
•This stage involves transferring the system from a testing or development environment to a production environment where
actual users can access it.

Stage 7. Maintenance and Support

•Ensure the ongoing functionality and address any issues that arise.
•Regular updates, bug fixes, and user support for the CRM system to adapt to changing business requirements and address
any emerging issues.
Challenges in System Design Life Cycle
• Sometime, the initial requirements for a system might be unclear or ambiguous, leading to difficulties in designing the
system accurately.
• Requirements may change during the design process, posing a challenge to maintain consistency and ensuring that the
system still meets the user's needs.
• Rapid advancements in technology can make it challenging to choose the most suitable and up-to-date technologies for
system design.
• Ensuring seamless integration of various system components can be complex, especially when dealing with different
technologies and platforms.
• Designing a system within budgetary constraints can be challenging, as incorporating certain features or technologies
might be cost-productive.
Models Used for System Design Life Cycle
• Waterfall Model: A linear and sequential model where each phase must be completed before moving on to the next. It's a
straightforward approach but can be inflexible in the face of changing requirements.
• Iterative Model: Involves repeating cycles, with each iteration refining and improving the system based on feedback. It's
adaptable to changing requirements.
• Prototyping Model: Involves building a prototype (a preliminary version) of the system to gather feedback refine the
design before building the final product.
• Spiral Model: Incorporates elements of both iterative and prototyping models. It involves cycles of planning, designing,
constructing, and evaluating.
• Agile Model: Emphasizes flexibility and collaboration, with frequent iterations and continuous feedback. It's well suited
for projects where requirements may evolve.
 Goals and Objectives of System Design

The objective of system design is to create a plan for a software

or hardware system that meets the needs and requirements of a
customer or user. This plan typically
includes detailed specifications for the system, including its
architecture, components, and interfaces.
System design is an important step in the development process
of any system, as it serves as the foundation for the
implementation and deployment of the system. A well-designed
system can help ensure that the system is reliable, efficient,
and user-friendly.
 Objectives of System Design

[Link]: We need a system that should be targeting the set of audiences(users) corresponding to which they are
designing.

[Link]: Above system design should be designed in such a way it fulfills nearly all requirements around which it is
designed be it functional or non-functional requirements.

[Link]: System design should meet all user requirements

[Link]: The system design should be such that it should not overuse surpassing the cost of resources nor under use as it
will by now we know will result in low throughput (output) and less response time(latency).

[Link]: The system designed should be in proximity to a failure-free environment for a certain period of time.

[Link]: Time and space are just likely what we do for code chunks for individual components to work in a system.

[Link](flexibility): System design should be adaptable with time as per different user needs of customers which we know
will keep on changing on time. The best example here out is the well-known firm: Nokia. It is the most important aspect
while designing systems and is the result of why 1 of 100 startups succeed over the long run, the best example here out is
GeeksforGeeks.
 There are several key objectives of system design, including:
[Link] the needs and requirements of the user or customer: The first step in the system design process is to understand
the needs and requirements of the user or customer. This involves gathering information about the user's goals, needs, and
expectations for the system, as well as any constraints or limitations that need to be taken into account.

[Link] a plan for the system: Once the needs and requirements of the user have been identified, the next step is to develop
a plan for the system. This plan should detail the architecture, components, and interfaces of the system, as well as any
algorithms, data structures, or other components that will be used.

[Link] that the system is reliable and efficient: One of the key objectives of system design is to ensure that the system is
reliable and efficient. This means designing the system in a way that minimizes downtime and errors and maximizes
performance and speed.

[Link] the system user-friendly: Another important objective of system design is to make the system user-friendly. This
means designing the system in a way that is intuitive and easy to use, with a user interface that is clear and straightforward.

[Link] into account any constraints or limitations: In addition to meeting the needs and requirements of the user, the
system design must also take into account any constraints or limitations. For example, the system may need to be designed to
run on specific hardware or software platforms, or to comply with certain standards or regulations.
 Key Concepts and Terminologies – System Design

System Design is the core concept behind the design of any distributed systems. System Design is defined as a process of
creating an architecture for different components, interfaces, and modules of the system and providing corresponding
data helpful in implementing such elements in systems.

• Latency

• Throughput

• Availability

• Redundancy

• Time

• CAP Theorem

• Lamport's Logical Clock Theorem.

 Types of Systems in System Analysis and Design

Now that we have understood what is System Analysis and how System Analysis is different from System Design, it is
now imperitive that we analyze the types of systems in System Design. Generally, the systems can be categorised into two
broad categories:
[Link] Systems

[Link] Systems built with help of Microservices

Monolithic Systems
If all the functionalities of a project exist in a single codebase,
then that application is known as a monolithic application.

As the name suggests monolithic means a formation with large

single blocks only. Henceforth with monolithic systems, we
refer to a system where the whole web application is deployed
as a single unit. Here all components and functionality are
deployed in a single unit.
 Architecture of Monolithic systems

The Monolithic system architecture can be visualized by considering three sections or three layers:
[Link] Tier or User Layer or Presentation Layer: It is the closest layer to the user and hence it can be either a webpage or
a web application where the user gets things done. It takes input lead from the user, interacts with the server, and displays
the user result. Hence we call it a front-end layer.

[Link] Tier or Service Layer: It compromises all the logic behind the application and is there in the application server.
The application server includes the business logic, receives requests from the client, acts on them, and correspondingly
stores the data.

[Link] Tier or Persistence Layer: It includes a data persistence mechanism(DB) and communication with other applications.
It includes databases, message queues, etc. Database server will be used by application server for the persistence of data.
 Microservices Architecture
The Microservice architecture has a significant impact on the
relationship between the application and the database.
•Instead of sharing a single database with other microservices, each
microservice has its own database.

•It often results in duplication of some data, but having a database

per microservice is essential if you want to benefit from this
architecture, as it ensures loose coupling.

•Another advantage of having a separate database per microservice Advantages

is that each microservice can use the type of database best suited
for its needs. •Scalability.
•Each service offers a secure module boundary so that different •Flexibility
services can be written in different programming languages.
•Resilience
•There are many patterns involved in microservice architecture like
service discovery & registry, caching, API gateway & •Technology Heterogeneity
communication, observability, security, etc.
•Easy maintenance
 Distributed Systems
A distributive system is a collection of multiple individual
systems connected through a network sharing resources so as to
achieve common goals.

It is more likely seen in the real world as it has huge advantages

over monolithic architecture making it highly scalable and at the
same time with multiple systems sharing the same resource
solves our SPOF problem. (Single Point Of Failure)

As seen above media, in a distributive system, nodes are geographically distributed. So what if a node crashes due to power
failure? In Distributed systems, the data will not be lost as data has been shared across multiple servers. Hence
redundancy/replication helps us in saving data which is very essential as a backup is already there to take over justifying
SPOF.
 Advantages of Distributed Systems

[Link]: As it contains a collection of independent machines horizontal scaling can be done to achieve scalability.

[Link]: The distributed system solves SPOF while the monolithic does not because even if an individual unit fails to work
rest are operational making it more efficient to work most of the time and hence reliable.

[Link] latency: Because of multiple servers and more likely spread to get closer to the user to resolve a query, hence takes
very less time to resolve a user query.

Disadvantages of Distributed Systems

[Link]: Because of high scalability the number of network points and hardware makes the system quite complex and
challenging.

[Link]: Higher number of devices makes it difficult to integrate the data as it gets complex to synchronous application
states.

[Link] Failure: Communication and coordination between systems in distributed systems is carried via network calls. In
a network failure, conflicting information is passed or sometimes communication failure occurs leading to poor overall
system performance.
 Differences between System Analysis and System Design
System Analysis and System Design are two stages of the software development life cycle. System Analysis is a process of
collecting and analyzing the requirements of the system whereas System Design is a process of creating a design for the
system to meet the requirements. Both are important stages as it helps to create an effective system with all the features and
functions.
What is System Analysis?

System Analysis is a process of understanding the system requirements and its environment. It is one of the initial stages
of the software development life cycle. System analysis is the process of breaking the system down into its individual
components and understanding how each component interacts with the other components to accomplish the system’s
overall goal. In this process, the analyst collects the requirements of the system and documents them.
Characteristics
•It is the study of the existing system to identify the problem areas.
•It is a process of understanding the system requirements and its environment.
•It involves gathering and understanding the user’s requirements.
•It involves analyzing the system in terms of its current and future needs.
What is System Design?

System Design is the process of creating a design for the system to meet the requirements. System design is the process of
designing the architecture, components, modules, interfaces, and data for a system to satisfy the specified requirements. It
involves the design of the system architecture, components, modules, interfaces, and data.
Characteristics
•It is the process of creating a design for the system.

•It involves the design of the system architecture, components, modules, interfaces, and data.

•It involves identifying the modules and components of the system.

•It involves creating the user interface and database design.

 Differences between System Analysis and System Design
Factors System Analysis System Design
System Analysis is the process of gathering and analyzing information
System Design is the process of specifying elements of a system such
Purpose to assess the suitability of a current system and to determine the
as modules, architecture, components, and their interfaces.
requirements of a new system.

System Analysis is a top-down approach where the analyst looks at the System Design is a bottom-up approach where the analyst starts with
Approach
big picture first and then delves into the details. the details and moves up to the big picture.

System Analysis focuses on the needs of the user, the current system, System Design focuses on the design of the system, its architecture,
Scope
and the business processes that the system must support. and the components that make up the system.

System Analysis produces the requirements document that describes System Design produces the design document that describes the
Output
the desired system. architecture and components of the system.

System Analysis is a one-time process that occurs at the beginning of System Design is an ongoing process that occurs throughout the
Time
the project. project.

System Analysis relies on a structured approach such as the Waterfall

Methodology System Design relies on an iterative approach such as the Spiral Model.
Model or the Agile Methodology.

System Analysis utilizes tools such as interviews, surveys, System Design utilizes tools such as data flow diagrams and
Tools
questionnaires, and observation. object-oriented diagrams.
System Design is the second step in the software development
Process System Analysis is the first step in the software development process.
process.
The goal of System Analysis is to identify and understand the user
The goal of System Design is to create a design that meets the user
Goals requirements and the business processes that the system must
requirements and supports the business processes.
support.

System Design involves significant risk, as the design may not meet
Risk System Analysis involves minimal risk.
the user requirements or support the business processes.

Problem Solving System Analysis focuses on problem identification and definition. System Design focuses on problem-solving and finding solutions.
 Functional and Non Functional Requirements
Requirements analysis is an essential process in software development. It helps to determine whether a system or project
will meet its objectives and achieve success.
To make this analysis effective, requirements are generally divided into two categories:
What are Functional Requirements?
These are the requirements that describe the specific features and
operations that a system must provide to meet business and user needs.
They focus on what the system should do and outline the interactions
between the system and its users.
•Typical examples include user authentication, data entry and
processing, search functionality, payment handling, and report
generation.

•Unlike non-functional requirements, these are the features explicitly

requested by users and can be directly observed in the final product.

Examples of questions for Functional Requirements:

•What are the features that we need to design for this system?

•What are the possible edge cases we need to consider in our design?
What are Non-Functional Requirements?
These requirements define how a system should operate, rather than what it should do. They define how well the system
should perform its functions and ensure that the product is reliable, efficient, and user-friendly.
While they may not be directly visible as features, they play a vital role in shaping the user experience and ensuring the
system’s long-term success.
Key Aspects in NFRs include:
•Performance
•Security
•Usability
•Reliability
•Scalability
•Maintainability
•Portability
Examples for needs in NFRs:
•How fast should the system respond to user actions?
•System should be highly available.
•How secure should the system be against unauthorized access?
Differences between Functional Requirements and Non-Functional Requirements

Definition
•Functional requirements define what the system should do, the exact features, tasks, or operations.
•Non-functional requirements define how the system should perform, the qualities or attributes like speed, security, or
usability.
Purpose
•Functional Requirements focuses on the behavior and features of the system.
•Non-Functional Requirements focuses on the performance, usability, and overall quality of the system.

Scope

•Functional Requirements defines the actions and operations the system must support.
•Non functional Requirements defines constraints or conditions under which those actions should occur.

Measurement

•Functional requirements are easily measured by verifying outputs or results.

•Non-functional requirements are harder to measure, often validated against benchmarks, metrics, or SLAs.

Impact on Development

•Functional requirements drive the core design and features of the system.
•Non-functional requirements influence the system architecture and performance optimization.
 User Perspective
•Functional requirements are directly visible to users and tied to business needs.
•Non-functional requirements shape the user experience by ensuring efficiency, reliability, and smooth operation.

Documentation
•Functional requirements are documented in use cases, user stories, or functional specifications.
•Non-functional requirements are captured in performance criteria, technical specs, or design constraints.

Evaluation
•Functional requirements are validated through functional testing (unit, integration, or acceptance tests).
•Non-functional requirements are verified via performance, security, and usability testing.

Dependency

•Functional requirements define what must be built to meet user needs.

•Non-functional requirements define how well the system must operate once built.

Examples

•Functional requirements: login authentication, data input/output, transaction processing.

•Non-functional requirements: system scalability, security, response time, reliability, maintainability.
 High Level Design - System Design
High-level design or HLD is an initial step in the development of applications where the overall structure of a system is
planned.
• Focuses mainly on how different components of the system work together without getting to know about internal coding
and implementation.
• Helps everyone involved in the project to understand the goals and ensures good communication during development.
• Crucial for developers, architects, and product managers because it allows them to make sure that all stakeholders are
aligned with the project objectives. That's why it is also known as macro-level design.

Ex: The following is a sample high level design of a cab

booking service like Uber.
 Components of High-Level Design
Understanding the components of high-level design is very important for creating effective systems that meet user needs and
technical requirements. Below are the main components of high-level design:
[Link] Architecture: System architecture is an overview of the entire system that represents the structure and the
relationships between various components. It helps to visually represent how different parts interact and function.

[Link] and Components: High-level design breaks down the systems into modules or components, each with specific
roles and responsibilities, and has a distinct function that contributes to the entire system, helping in developing an efficient
system.

[Link] Flow Diagrams (DFDs): Data Flow Diagrams demonstrate the data movement within the system. They help to
understand how information is processed and pass from one end to another.

[Link] Design: It includes the design of application programming interfaces (APIs) for system integration and user
interfaces (UIs) for user interaction, ensuring seamless functionality and communication between components.

[Link] Stack: The technology stack is various technologies and tools that will be used in the development of the
system. This includes programming languages, frameworks, and databases.

[Link] Architecture: It includes how the system will be hosted and accessed. It includes server configurations, cloud
infrastructure, and network considerations.
Goal of High-Level Design(HLD)
The goal of HLD is to provide a detailed overview of the system's structure, components, and interactions, setting the
direction for the detailed design and implementation phases of the project. High-Level Design (HLD) is a crucial phase in
the software development lifecycle, where the overall architecture and design of a system are outlined broadly and
comprehensively.
1. System Understanding
The primary goal of HLD is to ensure that stakeholders, including developers, architects, and project managers, have a clear understanding of the overall system architecture and design.
This includes understanding the major components of the system, how they interact with each other, and the overall flow of data and control within the system.
2. Component Identification
HLD aims to identify the major components or modules of the system and define their roles and responsibilities. This helps in organizing the system into manageable parts, making it
easier to design, implement, and maintain.
3. Interface Specification
HLD defines the interfaces between the different components of the system. This includes specifying the data that is exchanged between components, the protocols used for
communication, and any other requirements for interaction between components.
4. Technology Selection
HLD outlines the technologies, frameworks, and tools that will be used to implement the system. This includes decisions about programming languages, databases, middleware, and
other software and hardware components.
5. Scalability and Performance
HLD considers the scalability and performance requirements of the system. This includes identifying potential bottlenecks and performance issues and outlining high-level strategies for
addressing these issues, such as using caching, load balancing, or database optimization techniques.
6. Risk Mitigation
HLD identifies potential risks and challenges in the design and implementation of the system. This includes risks related to technology, resources, schedule, and other factors. HLD
outlines strategies for mitigating these risks, such as using proven technologies, conducting thorough testing, and having contingency plans in place.
7. Alignment with Requirements
Finally, HLD ensures that the system design aligns with the requirements and objectives of the project. This includes ensuring that the design meets functional and non-functional
requirements, such as usability, security, and compliance requirements.
CAP Theorem in System Design
According to the CAP theorem, only two of the three desirable characteristics—consistency, availability, and partition
tolerance—can be shared or present in a networked shared-data system or distributed system.
•The theorem provides a way of thinking about the trade-offs involved in designing and building distributed systems.

•It helps to explain why certain types of systems may be more appropriate for certain use cases.

•The theorem states that a distributed system can have at most two of these guarantees.
Properties of CAP Theorem
The property of three distributed system characteristics to which CAP Theorem refers:

1. Consistency

Consistency defines that all clients see the same data

simultaneously, no matter which node they connect to in a
distributed system. For eventual consistency, the guarantees are
a bit loose. Eventual consistency gurantee means client will
eventually see the same data on all the nodes at some point of
time in the future.
2. Availability

Availabilty defines that all non-failing nodes in a distributed

system return a response for all read and write requests in a
bounded amount of time, even if one or more other nodes are
down.
3. Partition Tolerance

Partition Tolerance defines that the system continues to operate

despite arbitrary message loss or failure in parts of the system.
Distributed systems guranteeing partition tolerance can
gracefuly recover from partitions once the partition heals.
Trade-Offs in the CAP Theorem
1. CA System
A CA System delivers consistency and availiability across all
the nodes. It can't do this if there is a partition between any two
nodes in the system and therefore does't support partition
tolerance.

2. CP System
A CP System delivers consistency and partition tolerance at the
expense of availability. When a partition occurs between two
nodes, the systems shuts down the non-available node until the
partition is resolved. Some of the examples of the databases are
MongoDB, Redis, and HBase.

3. AP System
An AP System availabiiity and partition tolerance at the expense
of consistency. When a partition occurs, all nodes remains
available, but those at the wrong end of a partition might return
an older version of data than others. Example: CouchDB,
Cassandra and Dyanmo DB, etc.
Low Level Design or
LLD
Low-Level Design (LLD) plays a crucial role in software development,
transforming high-level abstract concepts into detailed, actionable
components that developers can use to build the system.
•LLD is the blueprint that guides developers on how to implement specific
components of a system, such as classes, methods, algorithms, and data
structures.
•Whether we are working on a microservice architecture, a web application,
or a mobile app, understanding LLD is essential for building scalable,
maintainable, and efficient systems.

How is LLD different from HLD?

While both HLD (High-Level Design) and LLD (Low-Level Design) are critical in system architecture, they serve
different purposes.
1. High-Level Design (HLD): Focuses on the overall architecture of the system. It addresses questions such as which
frameworks to use, what databases are suitable, how to integrate different components, and how the system will function
at a broader level.
2. Low-Level Design (LLD): Once the high-level structure is in place, LLD takes over by focusing on
specific components, modules, and interactions. It provides detailed design diagrams (like UML diagrams) and breaks
down how each component should behave, how it will interact with others, and what algorithms and data structures will
be used.
Concepts Needed to Create a LLD from given HLD
Step 1. Understanding Object-Oriented Principles

The user requirement is processed by using concepts of OOPS programming. OOP concepts serve as the foundation for
LLD, and having a deep understanding of them will help you design maintainable and scalable software components.
Hence it is recommended to have a strong grip on Object-Oriented Programming principles such as:
•Encapsulation: Bundling data and the methods that operate on that data within one unit.
•Inheritance: Mechanism where a new class can inherit the properties and methods of an existing class.
•Polymorphism: Ability of different classes to respond to the same method in different ways.
•Abstraction: Hiding the complex implementation details while showing only the essential features of an object.

Step 2. Analyzing and Designing Components

LLD requires you to analyze real-world problems and break them down into object-world problems using OOP
concepts. This is a critical step where real-world entities are modeled into objects and classes.
You should focus on:
•Identifying classes and objects based on the system requirements.
•Determining relationships (like associations, inheritance, etc.) between different entities.
•Using SOLID principles to ensure your design is clean, maintainable, and scalable.
Step 3. Implementing Design Patterns

Now the implementation of our above object oriented problem is carried out with the help of design patterns. Design patterns are reusable
solutions to common problems encountered in software design. They provide a structured approach to design by capturing best practices
and proven solutions, making it easier to develop scalable, maintainable, and efficient software. By using these patterns, developers can
solve problems more effectively while adhering to best practices.
•Creational Patterns (e.g., Singleton, Factory): These patterns deal with object creation mechanisms, trying to create objects in a way that is
appropriate to the situation.
•Behavioral Patterns (e.g., Observer, Strategy): Focus on communication between objects and how they interact with each other.
•Structural Patterns (e.g., Adapter, Composite): These patterns are concerned with simplifying the structure of the system and its
components.

Step 4. Use of UML Diagram in LLD

Unified Modeling Language is a visual representation used to design and model the system. UML diagrams play an important role in
converting HLD to LLD. They provide a proper and clear visual representation of the components and their relationships, which helps
developers significantly.S ome of the most important UML diagrams used in LLD include:
•Class Diagrams: Represent the structure of the system in terms of its classes and the relationships between them.
•Sequence Diagrams: Illustrate how objects interact over time, showing the sequence of method calls.
•Activity Diagrams: Show the workflow or activities of a system component.
•State Diagrams: Represent the different states of a component or object and the transitions between these states.
•Use Case Diagrams: Define the functional requirements of the system by showing different user interactions.
 5. Implementing SOLID Principles

These are sets of 5 principles(rules) that are strictly followed as per requirements of the system or requirements for optimal
designing. In order to write scalable, flexible, maintainable, and reusable code:
[Link]-responsibility principle (SRP)

[Link]-closed principle (OCP)

[Link]’s Substitution Principle(LSP)

[Link] Segregation Principle (ISP)

[Link] Inversion Principle (DIP)

It's important to keep in mind that SOLID principles are just guidelines and not strict rules to be followed. The key is to
strike a balance between following these principles and considering the specific needs and constraints of your business
requirement.
Object-Oriented Analysis and Design(OOAD)
OOAD is based on the concepts of object-oriented programming (OOP) and is an organized and systematic approach to
designing and developing software systems. It is a software engineering paradigm that integrates two distinct but closely
related processes: Object-Oriented Analysis (OOA) and Object-Oriented Design (OOD).
Important Aspects of OOAD
Below are some important aspects of OOAD:
• Object-Oriented Programming: In this the real-world items are represented/mapped as software objects with
attributes and methods that relate to their actions.
• Design Patterns: Design patterns are used by OOAD to help developers in building software systems that are more
efficient and maintainable.
• UML Diagrams: UML diagrams are used in OOAD to represent the different components and interactions of a
software system.
• Use Cases: OOAD uses use cases to help developers understand the requirements of a system and to design software
systems that meet those requirements.
Object-Oriented Analysis
Object-Oriented Analysis (OOA) is the process of understanding and analyzing the system requirements by looking at the
problem scenario in terms of objects.
•These objects represent real-world entities or concepts that are relevant to the system being developed.

•During OOA, the goal is to identify the objects, their attributes, behaviors, and relationships, without focusing on how the
system will be implemented.
Object-Oriented Design
In the object-oriented software development process, the analysis model, which is initially formed through object-oriented
analysis (OOA), undergoes a transformation during object-oriented design (OOD) i.e implementation of the conceptual
model developed in OOA. This evolution is crucial because it shapes the analysis model into a detailed design model.
Furthermore, as part of the object-oriented design process, it is essential to define specific aspects:
•Data Organization of Attributes:
• OOD involves specifying how data attributes are organized within the objects.
• This includes determining the types of data each object will hold and how they relate to one another.
•Procedural Description of Operations:
• OOD requires a procedural description for each operation that an object can perform.
• This involves detailing the steps or processes involved in carrying out specific tasks.
Real world applications of Object-Oriented Analysis and Design(OOAD)
Some examples of OOAD's practical uses are listed below:
•Banking Software: In banking systems, OOAD is frequently used to simulate complex financial transactions, structures, and
customer interactions. Designing adaptable and reliable financial apps is made easier by OOAD's modular and scalable
architecture.

•Electronic Health Record (EHR) Systems: Patient data, medical records, and healthcare workflows are all modeled using
OOAD. Modular and flexible healthcare apps that may change to meet emerging requirements can be made through
object-oriented principles.

•Flight Control Systems: OOAD is crucial in designing flight control systems for aircraft. It helps model the interactions
between different components such as navigation systems, sensors, and control surfaces, ensuring safety and reliability.

•Telecom Billing Systems: In the telecom sector, OOAD is used to model and build billing systems. It enables the modular
and scalable modeling of complex subscription plans, invoicing rules, and client data.

•Online Shopping Platforms: E-commerce system development frequently makes use of OOAD. Product catalogs, user
profiles, shopping carts, and payment procedures are all modeled, which facilitates platform maintenance and functionality
expansion.
 SOLID Principles with Real Life Examples

The SOLID principles are five essential guidelines that enhance

software design, making code more maintainable and scalable.
•The SOLID principles help in enhancing loose coupling. Loose
coupling means a group of classes are less dependent on one
another.

•Loose coupling helps in making code more reusable,

maintainable, flexible and stable. Now let's discuss one by one
these principles...

•Loosely coupled classes minimize changes in your code when

some changes are required in some other code.
1. Single Responsibility Principle
This principle states that "A class should have only one reason to change" which means every class should have a single
responsibility or single job or single purpose. In other words, a class should have only one job or purpose within the software
system.
Let's understand Single Responsibility Principle using an example:

Imagine a baker who is responsible for baking bread. The baker's role is to focus on the task of baking bread, ensuring that
the bread is of high quality, properly baked, and meets the bakery's standards.
• However, if the baker is also responsible for managing the inventory, ordering supplies, serving customers, and cleaning
the bakery, this would violate the SRP.
• Each of these tasks represents a separate responsibility, and by combining them, the baker's focus and effectiveness in
baking bread could be compromised.
• To adhere to the SRP, the bakery could assign different roles to different individuals or teams. For example, there could
be a separate person or team responsible for managing the inventory, another for ordering supplies, another for serving
customers, and another for cleaning the bakery.
// Class for baking bread public class Main {
class BreadBaker { public static void main(String[] args) {
public void bakeBread() { BreadBaker baker = new BreadBaker();
[Link]("Baking high-quality bread..."); InventoryManager inventoryManager = new InventoryManager();
}
SupplyOrder supplyOrder = new SupplyOrder();
}
// Class for managing inventory CustomerService customerService = new CustomerService();
class InventoryManager { BakeryCleaner cleaner = new BakeryCleaner();
public void manageInventory() {
[Link]("Managing inventory..."); // Each class focuses on its specific responsibility
} [Link]();
}
[Link]();
// Class for ordering supplies
class SupplyOrder { [Link]();
public void orderSupplies() { [Link]();
[Link]("Ordering supplies..."); [Link]();
} }
} }
// Class for serving customers In the above example:
class CustomerService {
public void serveCustomer() { • BreadBaker Class: Responsible solely for baking bread. This class focuses on ensuring the
[Link]("Serving customers...");
}
quality and standards of the bread without being burdened by other tasks.
} • InventoryManager Class: Handles inventory management, ensuring that the bakery has the
right ingredients and supplies available.
// Class for cleaning the bakery
class BakeryCleaner {
• SupplyOrder Class: Manages ordering supplies, ensuring that the bakery is stocked with
public void cleanBakery() { necessary items.
[Link]("Cleaning the bakery..."); • CustomerService Class: Takes care of serving customers, providing a focused approach to
}
}
customer interactions.
• BakeryCleaner Class: Responsible for cleaning the bakery, ensuring a hygienic environment.
2. Open/Closed Principle
This principle states that "Software entities (classes, modules, functions, etc.) should be open for extension, but closed for
modification" which means you should be able to extend a class behavior, without modifying it.
Let's understand Open/Closed Principle using an example:

Imagine you have a class called PaymentProcessor that processes payments for an online store. Initially, the PaymentProcessor class
only supports processing payments using credit cards. However, you want to extend its functionality to also support
processing payments using PayPal.
Instead of modifying the existing PaymentProcessor class to add PayPal support, you can create a new class
called PayPalPaymentProcessor that extends the PaymentProcessor class. This way, the PaymentProcessor class remains closed for
modification but open for extension, adhering to the Open-Closed Principle.
3. Liskov's Substitution Principle
The principle was introduced by Barbara Liskov in 1987 and according to this principle "Derived or child classes must be
substitutable for their base or parent classes". This principle ensures that any class that is the child of a parent class should
be usable in place of its parent without any unexpected behaviour.
Let's understand Liskov's Substitution Principle using an example:

One of the classic examples of this principle is a rectangle having four sides. A rectangle's height can be any value and width
can be any value. A square is a rectangle with equal width and height. So we can say that we can extend the properties of the
rectangle class into square class.
In order to do that you need to swap the child (square) class with parent (rectangle) class to fit the definition of a square
having four equal sides but a derived class does not affect the behavior of the parent class so if you will do that it will violate
the Liskov Substitution Principle.
4. Interface Segregation Principle
This principle is the first principle that applies to Interfaces instead of classes in SOLID and it is similar to the single responsibility principle. It
states that "do not force any client to implement an interface which is irrelevant to them". Here your main goal is to focus on avoiding fat
interface and give preference to many small client-specific interfaces. You should prefer many client interfaces rather than one general interface
and each interface should have a specific responsibility.
Let's understand Interface Segregation Principle using an example:

Suppose if you enter a restaurant and you are pure vegetarian. The waiter in that restaurant gave you the menu card which includes vegetarian
items, non-vegetarian items, drinks, and sweets.
• In this case, as a customer, you should have a menu card which includes only vegetarian items, not everything which you don't eat in your
food. Here the menu should be different for different types of customers.
• The common or general menu card for everyone can be divided into multiple cards instead of just one. Using this principle helps in reducing
the side effects and frequency of required changes.
5. Dependency Inversion Principle
The Dependency Inversion Principle (DIP) is a principle in object-oriented design that states that "High-level modules should not depend on
low-level modules. Both should depend on abstractions". Additionally, abstractions should not depend on details. Details should depend on
abstractions.
• In simpler terms, the DIP suggests that classes should rely on abstractions (e.g., interfaces or abstract classes) rather than concrete
implementations.
• This allows for more flexible and decoupled code, making it easier to change implementations without affecting other parts of the codebase.
Let's understand Dependency Inversion Principle using an example:
In a software development team, developers depend on an abstract version control system (e.g., Git) to manage and track changes to the
codebase. They don't depend on specific details of how Git works internally.
This allows developers to focus on writing code without needing to understand the intricacies of version control implementation.
Need for SOLID Principles in Object-Oriented Design
Below are some of the main reasons why solid principles are important in object oriented design:
• SOLID principles make code easier to maintain. When each class has a clear responsibility, it's simpler to find where to
make changes without affecting unrelated parts of the code.

• These principles support growth in software. For example, the Open/Closed Principle allows developers to add new
features without changing existing code, making it easier to adapt to new requirements.

• SOLID encourages flexibility. By depending on abstractions rather than specific implementations (as in the Dependency
Inversion Principle), developers can change components without disrupting the entire system
Unified Modeling Language (UML) Diagrams
Unified Modeling Language (UML) is a general-purpose modeling language. The main aim of UML is to define a standard
way to visualize the way a system has been designed. It is quite similar to blueprints used in other fields of engineering.
UML is not a programming language, it is rather a visual language.

•We use UML diagrams to show the behavior and structure of a system.
•UML helps software engineers, businessmen, and system architects with modeling, design, and analysis.
•The International Organization for Standardization (ISO) published UML as an approved standard in 2005. UML has been
revised over the years and is reviewed periodically.
Why do we need UML?
•Complex applications need collaboration and planning from multiple teams and hence require a clear and concise way to
communicate amongst them.
•Businessmen do not understand code. So UML becomes essential to communicate with non-programmers about essential
requirements, functionalities, and processes of the system.
•A lot of time is saved down the line when teams can visualize processes, user interactions, and the static structure of the
system.
Types of UML Diagrams
UML is linked with object-oriented design and analysis. UML makes use of elements and forms associations between them
to form diagrams. Diagrams in UML can be broadly classified as:

[Link]
 Design Patterns

Software design patterns are important tools developers, providing proven solutions to common problems encountered during
software development.
• Reusable solutions for typical software design challenges are known as design patterns.
• Provide a standard terminology and are specific to particular scenarios and problems.
• Not finished code but templates or blueprints only
• Software engineers use these to write more structured, manageable, and scalable code.
Key Characteristics of Design Patterns

• Reusability: Patterns can be applied to different projects and problems, saving time and effort in solving similar issues.
• Standardization: They provide a shared language and understanding among developers, helping in communication and
collaboration.
• Efficiency: By using these popular patterns, developers can avoid finding the solution to same recurring problems, which
leads to faster development.
• Flexibility: Patterns are abstract solutions/templates that can be adapted to fit various scenarios and requirements.

Types of Software Design Patterns

There are three types of Design Patterns:
• Creational Design Pattern
• Structural Design Pattern
• Behavioral Design Pattern
1. Creational Design Patterns
Creational Design Patterns focus on the process of object creation or problems related to object creation. They help in
making a system independent of how its objects are created, composed and represented.
 Types of Creational Design Patterns:
•Factory Method Design Pattern
• This pattern is typically helpful when it's necessary to separate the construction of an object from its implementation.
• With the use of this design pattern, objects can be produced without having to define the exact class of object to be created.
•Abstract Factory Method Design Pattern
• Abstract Factory pattern is almost similar to Factory Pattern and is considered as another layer of abstraction over factory
pattern.
• Abstract Factory patterns work around a super-factory which creates other factories.
•Singleton Method Design Pattern
• Of all, the Singleton Design pattern is the most straightforward to understand.
• It guarantees that a class has just one instance and offers a way to access it globally.
•Prototype Method Design Pattern
• Prototype allows us to hide the complexity of making new instances from the client.
• The concept is to copy an existing object rather than creating a new instance from scratch, something that may include
costly operations.
•Builder Method Design Pattern
• To “Separate the construction of a complex object from its representation so that the same construction process can create
different representations.” Builder pattern is used
• It helps in constructing a complex object step by step and the final step will return the object.
2. Structural Design Patterns
Structural Design Patterns solves problems related to how classes and objects are composed/assembled to form larger
structures which are efficient and flexible in nature. Structural class patterns use inheritance to compose interfaces or
implementations.
 Types of Structural Design Patterns:
•Adapter Method Design Pattern
• The adapter pattern convert the interface of a class into another interface clients expect.
• Adapter lets classes work together that couldn’t otherwise because of incompatible interfaces.
•Bridge Method Design Pattern
• The bridge pattern allows the Abstraction and the Implementation to be developed independently.
• The client code can access only the Abstraction part without being concerned about the Implementation part.
•Composite Method Design Pattern
• As a partitioning design pattern, the composite pattern characterizes a collection of items that are handled the same way as a single
instance of the same type of object.
• The intent of a composite is to “compose” objects into tree structures to represent part-whole hierarchies.
•Decorator Method Design Pattern
• It allows us to dynamically add functionality and behavior to an object without affecting the behavior of other existing objects within
the same class.
• We use inheritance to extend the behavior of the class. This takes place at compile-time, and all the instances of that class get the
extended behavior.
•Facade Method Design Pattern
• Facade Method Design Pattern provides a unified interface to a set of interfaces in a subsystem.
• Facade defines a high-level interface that makes the subsystem easier to use.
•Flyweight Method Design Pattern
• This pattern provides ways to decrease object count thus improving application required objects structure.
• Flyweight pattern is used when we need to create a large number of similar objects.
•Proxy Method Design Pattern
• Proxy means ‘in place of’, representing’ or ‘in place of’ or ‘on behalf of’ are literal meanings of proxy and that directly explains Proxy
Design Pattern.
• Proxies are also called surrogates, handles, and wrappers. They are closely related in structure, but not purpose, to Adapters and
Decorators.
3. Behavioral Design Patterns
Behavioral Patterns are concerned with algorithms and the assignment of responsibilities between objects. Behavioral
patterns describe not just patterns of objects or classes but also the patterns of communication between them. These
patterns characterize complex control flow that’s difficult to follow at run-time.
Types of Behavioral Design Patterns:

•Chain Of Responsibility Method Design Pattern

• Chain of responsibility pattern is used to achieve loose coupling in software design where a request from the client is
passed to a chain of objects to process them.
• Later, the object in the chain will decide themselves who will be processing the request and whether the request is
required to be sent to the next object in the chain or not.
•Command Method Design Pattern
• A behavioral design pattern called the Command Pattern transforms a request into an independent object with all of the
information's request
• This object can be passed around, stored, and executed at a later time.
•Interpreter Method Design Pattern
• Interpreter pattern is used to defines a grammatical representation for a language and provides an interpreter to deal
with this grammar.
•Mediator Method Design Pattern
• It enables decoupling of objects by introducing a layer in between so that the interaction between objects happen via the
layer.
•Memento Method Design Patterns
• It is used to return an object's state to its initial state.
• You might wish to create checkpoints in your application and return to them at a later time when it develops.
•Observer Method Design Pattern
• It establishes a one-to-many dependency between objects, meaning that all of the dependents (observers) of the
subject are immediately updated and notified when the subject changes.
•State Method Design Pattern
• When an object modifies its behavior according to its internal state, the state design pattern is applied.
• If we have to change the behavior of an object based on its state, we can have a state variable in the Object and use
the if-else condition block to perform different actions based on the state.
•Strategy Method Design Pattern
• It is possible to select an object's behavior at runtime by utilizing the Strategy Design Pattern.
• Encapsulating a family of algorithms into distinct classes that each implement a common interface is the foundation
of the Strategy pattern.
•Template Method Design Pattern
• The template method design pattern defines an algorithm as a collection of skeleton operations, with the child classes
handling the implementation of the specifics.
• The parent class maintains the overall structure and flow of the algorithm.
•Visitor Method Design Pattern
• It is used when we have to perform an operation on a group of similar kind of Objects. With the help of visitor
pattern, we can move the operational logic from the objects to another class.