CHENNAI INSTITUTE OF TECHNOLOGY

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING

CS3405-SOFTWARE ENGINEERING
UNIT III SOFTWARE DESIGN 9
Software Design Process and concepts – Design Principles: Coupling, Cohesion, Functional
Independence- Design Patterns: Model-view-controller, Publish – Subscribe, Adapter,
Command, Strategy, Observer, Proxy, façade -Architectural Styles : Layered, Client-
server, Tiered, Pipe and Filter – User Interface Design – Modern design Practices ;
Microservices Architecture, RESTful Services.

Software Design:
Software design is the process of transforming user requirements into a suitable form, which
helps the programmer in software coding and implementation. During the software design phase,
the design document is produced, based on the customer requirements as documented in the SRS
document. Hence, this phase aims to transform the SRS document into a design document.

The following items are designed and documented during the design phase:
1. Different modules are required.
2. Control relationships among modules.
3. Interface among different modules.
4. Data structure among the different modules.
5. Algorithms are required to be implemented among the individual modules.

Objectives of Software Design

1. Correctness: A good design should be correct i.e., it should correctly implement all the
functionalities of the system.
2. Efficiency: A good software design should address the resources, time, and cost optimization
issues.
4. Flexibility: A good software design should have the ability to adapt and accommodate
changes easily. It includes designing the software in a way, that allows for modifications,
enhancements, and scalability without requiring significant rework.
5. Understandability: A good design should be easily understandable, it should be modular,
and all the modules are arranged in layers.
5. Completeness: The design should have all the components like data structures,
modules, external interfaces, etc.
6. Maintainability: A good software design aims to create a system that is easy to understand,
modify, and maintain over time. This involves using modular and well-structured design

1
 principles Maintainability in Software and design also enables developers to fix bugs, enhance
features, and adapt the software to changing requirements without excessive effort or introducing
new issues.

Software Design Concepts:

software design concepts are fundamental principles that guide the development and
structure of software. These concepts help ensure that software is well-organized, efficient,
maintainable, and scalable.

Abstraction :
Abstraction simply means to hide the details to reduce complexity and increase efficiency or
quality. Different levels of Abstraction are necessary and must be applied at each stage of the
design process so that any error that is present can be removed to increase the efficiency of the
software solution and to refine the software solution.
Modularity (subdivide the system):
Modularity simply means dividing the system or project into smaller parts to reduce the
complexity of the system or project. In the same way, modularity in design means subdividing a
system into smaller parts so that these parts can be created independently and then use these parts
in different systems to perform different functions. It is necessary to divide the software into
components known as modules.
Architecture (design a structure of something): Architecture simply means a technique to
design a structure of something. Architecture in designing software is a concept that focuses on
various elements and the data of the structure. These components interact with each other and
use the data of the structure in architecture.

2
Refinement- (removes impurities)
Refinement simply means to refine something to remove any impurities if present and
increase the quality. The refinement concept of software design is actually a process of
developing or presenting the software or system in a detailed manner that means to elaborate a
system or software. Refinement is very necessary to find out any error if present and then to
reduce it.
Pattern- (a Repeated form)
The pattern simply means a repeated form or design in which the same shape is repeated
several times to form a pattern. The pattern in the design process means the repetition of a solution
to a common recurring problem within a certain context.
Information Hiding – Hide the Information
Information hiding simply means to hide the information so that it cannot be accessed by an
unwanted party. In software design, information hiding is achieved by designing the modules in
a manner that the information gathered or contained in one module is hidden and can’t be
accessed by any other modules.
Refactoring-( Reconstruct something )
Refactoring simply means reconstructing something in such a way that it does not affect the
behavior of any other features. Refactoring in software design means reconstructing the design
to reduce complexity and simplify it without impacting the behavior or its functions. Fowler has
defined refactoring as “the process of changing a software system in a way that it won’t impact
the behavior of the design and improves the internal structure”.
Software Design Process:
The design phase of software development deals with transforming the customer requirements
as described in the SRS documents into a form implementable using a programming language.
The software design process can be divided into the following three levels or phases of design:
✓ Interface Design
✓ Architectural Design
✓ Detailed Design

Elements of a System
1. Architecture: This is the conceptual model that defines the structure, behavior, and views of
a system. We can use flowcharts to represent and illustrate the architecture.
2. Modules: These are components that handle one specific task in a system. A combination of
the modules makes up the system.
3. Components: This provides a particular function or group of related functions. They are
made up of modules.
4. Interfaces: This is the shared boundary across which the components of a system exchange

3
 information and relate.
5. Data: This is the management of the information and data flow.

Interface Design in the Software Process

Interface design in software engineering refers to the process of defining how different
system components, users, and external systems interact with the software. A well-designed
interface ensures seamless communication between various parts of the system, improves
usability, and enhances the overall user experience.
Types:
User Interface (UI)
• The visual and interactive part of the software that users interact with.
• Includes elements like buttons, menus, forms, and dashboards.
• Example: A mobile banking app’s user interface.
Application Programming Interface (API)
• Defines how software components communicate programmatically.
• Example: RESTful APIs used for web applications.
Software-to-Software Interface
• Allows different software systems to communicate and exchange data.
• Example: A payment gateway integrating with an e-commerce platform.
Hardware Interface
• Defines interactions between software and hardware components.
• Example: Drivers that allow an operating system to communicate with a printer.

4
Principles of Good Interface Design
• Simplicity – Keep the interface clean and user-friendly.
• Consistency – Maintain uniform design patterns across the application.
• Responsiveness – Ensure the interface adapts to different devices and screen sizes.
• Feedback Mechanisms – Provide clear responses to user actions (e.g., loading indicators,
error messages).
• Error Prevention and Handling – Guide users to prevent mistakes and provide meaningful
error messages.
Architectural design :
Architectural design in software engineering refers to the high-level structure of a software
system. It defines how different components interact, ensuring the system is scalable,
maintainable, and efficient. Architectural design serves as a blueprint for software development,
guiding implementation and integration.

Importance of Architectural Design:

• Scalability – Supports future growth.
• Maintainability – Simplifies debugging and updates.
• Performance – Ensures efficient system operation.
• Security – Helps define secure access and communication.
• Reusability – Encourages component reuse across projects.

Detailed Design:
This Phase involves defining the internal logic of modules, specifying data structures,
designing algorithms, and detailing interfaces between system components. This phase follows
architectural design, where the system's overall structure is established, and precedes
implementation, where actual coding takes place.

Benefits of Detailed Design

Reduces complexity by breaking down high-level architecture.

Improves code maintainability by ensuring clarity in implementation.

Enhances reusability by defining modular and reusable components.

Prevents future issues by incorporating security and error handling early.

5
Design Principles:
There are several principles that are used to organize and arrange the structural components
of Software design. Software Designs in which these principles are applied affect the content and
the working process of the software from the beginning.

Principles Of Software Design :

1. Should not suffer from “Tunnel Vision”
While designing the process, it should not suffer from “tunnel vision” which means that is
should not only focus on completing or achieving the aim but on other effects also.
2. Traceable to analysis model
The design process should be traceable to the analysis model which means it should satisfy all
the requirements that software requires to develop a high-quality product.
3. Should not “Reinvent The Wheel”
The design process should not reinvent the wheel that means it should not waste time or effort
in creating things that already exist. Due to this, the overall development will get increased.
4. Minimize Intellectual distance –
The design process should reduce the gap between real-world problems and software solutions
for that problem meaning it should simply minimize intellectual distance.
5. Exhibit uniformity and integration –
The design should display uniformity which means it should be uniform throughout the process
without any change. Integration means it should mix or combine all parts of software i.e.
subsystems into one system.

6
6. Accommodate change
The software should be designed in such a way that it accommodates the change implying
that the software should adjust to the change that is required to be done as per the user’s need.
7. Degrade gently –
The software should be designed in such a way that it degrades gracefully which means it should
work properly even if an error occurs during the execution.
8. Assessed or quality –
The design should be assessed or evaluated for the quality meaning that during the evaluation,
the quality of the design needs to be checked and focused on.
9. Review to discover errors –
The design should be reviewed which means that the overall evaluation should be done to check
if there is any error present or if it can be minimized.
10. Design is not coding and coding is not design –
Design means describing the logic of the program to solve any problem and coding is a type of
language that is used for the implementation of a design.

Coupling:

Couling refers to the degree of interdependence between software modules. High coupling means
that modules are closely connected and changes in one module may affect other modules. Low
coupling means that modules are independent, and changes in one module have little impact on other
modules.
ie.,)Coupling is the measure of the degree of interdependence between the modules. A good software
will have low coupling.
• Data Coupling: If the dependency between the modules is based on the fact that they
communicate by passing only data, then the modules are said to be data coupled. In data
coupling, the components are independent of each other and communicate through data. Module
communications don’t contain tramp data. Example-customer billing system.
• Stamp Coupling In stamp coupling, the complete data structure is passed from one module to
another module. Therefore, it involves tramp data. It may be necessary due to efficiency factors-
this choice was made by the insightful designer, not a lazy programmer.
• Control Coupling: If the modules communicate by passing control information, then they are
said to be control coupled. It can be bad if parameters indicate completely different behavior and
good if parameters allow factoring and reuse of functionality. Example- sort function that takes
comparison function as an argument.
• External Coupling: In external coupling, the modules depend on other modules, external to the
software being developed or to a particular type of hardware. Ex- protocol, external file, device
format, etc.

7
• Common Coupling: The modules have shared data such as global data structures. The changes
in global data mean tracing back to all modules which access that data to evaluate the effect of
the change. So it has got disadvantages like difficulty in reusing modules, reduced ability to
control data accesses, and reduced maintainability.
• Content Coupling: In a content coupling, one module can modify the data of another module,
or control flow is passed from one module to the other module. This is the worst form of coupling
and should be avoided.
• Temporal Coupling: Temporal coupling occurs when two modules depend on the timing or
order of events, such as one module needing to execute before another. This type of coupling
can result in design issues and difficulties in testing and maintenance.
• Sequential Coupling: Sequential coupling occurs when the output of one module is used as the
input of another module, creating a chain or sequence of dependencies. This type of coupling
can be difficult to maintain and modify.
• Communicational Coupling: Communicational coupling occurs when two or more modules
share a common communication mechanism, such as a shared message queue or database. This
type of coupling can lead to performance issues and difficulty in debugging.
• Functional Coupling: Functional coupling occurs when two modules depend on each other’s
functionality, such as one module calling a function from another module. This type of coupling
can result in tightly-coupled code that is difficult to modify and maintain.
• Data-Structured Coupling: Data-structured coupling occurs when two or more modules share
a common data structure, such as a database table or data file. This type of coupling can lead to
difficulty in maintaining the integrity of the data structure and can result in performance iss ues.
• Interaction Coupling: Interaction coupling occurs due to the methods of a class invoking
methods of other classes. Like with functions, the worst form of coupling here is if methods
directly access internal parts of other methods. Coupling is lowest if methods communicate
directly through parameters.
• Component Coupling: Component coupling refers to the interaction between two classes where
a class has variables of the other class. Three clear situations exist as to how this can happen. A
class C can be component coupled with another class C1, if C has an instance variable of type
C1, or C has a method whose parameter is of type C1,or if C has a method which has a local
variable of type C1. It should be clear that whenever there is component coupling, there is likely
to be interaction coupling.

8
 Cohesion :
Cohesion refers to the degree to which elements within a module work together to fulfill a
single, well-defined purpose. High cohesion means that elements are closely related and focused
on a single purpose, while low cohesion means that elements are loosely related and serve
multiple purposes.

Both coupling and cohesion are important factors in determining the maintainability, scalability,
and reliability of a software system. High coupling and low cohesion can make a system difficult
to change and test, while low coupling and high cohesion make a system easier to maintain and
improve.

9
Types of Cohesion
• Functional Cohesion: Every essential element for a single computation is contained in the
component. A functional cohesion performs the task and functions. It is an ideal situation.
• Sequential Cohesion: An element outputs some data that becomes the input for other element,
i.e., data flow between the parts. It occurs naturally in functional programming languages.

• Communicational Cohesion: Two elements operate on the same input data or contribute
towards the same output data. Example- update record in the database and send it to the printer.
• Procedural Cohesion: Elements of procedural cohesion ensure the order of execution. Actions
are still weakly connected and unlikely to be reusable. Ex- calculate student GPA, print student
record, calculate cumulative GPA, print cumulative GPA.
• Temporal Cohesion: The elements are related by their timing involved. A module connected
with temporal cohesion all the tasks must be executed in the same time span. This cohesion
contains the code for initializing all the parts of the system. Lots of different activities occur, all
at unit time.
• Logical Cohesion: The elements are logically related and not functionally. Ex- A component
reads inputs from tape, disk, and network. All the code for these functions is in the same
component. Operations are related, but the functions are significantly different.
• Coincidental Cohesion: The elements are not related(unrelated). The elements have no
conceptual relationship other than location in source code. It is accidental and the worst form of
cohesion. Ex- print next line and reverse the characters of a string in a single component.
• Procedural Cohesion: This type of cohesion occurs when elements or tasks are grouped
together in a module based on their sequence of execution, such as a module that performs a set
of related procedures in a specific order. Procedural cohesion can be found in structured
programming languages.
• Communicational Cohesion: Communicational cohesion occurs when elements or tasks are
grouped together in a module based on their interactions with each other, such as a module that
handles all interactions with a specific external system or module. This type of cohesion can be
found in object-oriented programming languages.
• Temporal Cohesion: Temporal cohesion occurs when elements or tasks are grouped together
in a module based on their timing or frequency of execution, such as a module that handles all
periodic or scheduled tasks in a system. Temporal cohesion is commonly used in real-time and
embedded systems.
• Informational Cohesion: Informational cohesion occurs when elements or tasks are grouped
together in a module based on their relationship to a specific data structure or object, such as a
module that operates on a specific data type or object. Informational cohesion is commonly used
in object-oriented programming.

10
• Functional Cohesion: This type of cohesion occurs when all elements or tasks in a module
contribute to a single well-defined function or purpose, and there is little or no coupling between
the elements. Functional cohesion is considered the most desirable type of cohesion as it leads
to more maintainable and reusable code.
• Layer Cohesion: Layer cohesion occurs when elements or tasks in a module are grouped
together based on their level of abstraction or responsibility, such as a module that handles only
low-level hardware interactions or a module that handles only high-level business logic. Layer
cohesion is commonly used in large-scale software systems to organize code into manageable
layers.
Advantages of low coupling
• Improved maintainability: Low coupling reduces the impact of changes in one module on
other modules, making it easier to modify or replace individual components without affecting
the entire system.
• Enhanced modularity: Low coupling allows modules to be developed and tested in isolation,
improving the modularity and reusability of code.
• Better scalability: Low coupling facilitates the addition of new modules and the removal of
existing ones, making it easier to scale the system as needed.
Disadvantages of high coupling
• Increased complexity: High coupling increases the interdependence between modules,
making the system more complex and difficult to understand.
• Reduced flexibility: High coupling makes it more difficult to modify or replace individual
components without affecting the entire system.
• Decreased modularity: High coupling makes it more difficult to develop and test modules in
isolation, reducing the modularity and reusability of code.

Advantages of high cohesion

• Improved readability and understandability: High cohesion results in clear, focused modules
with a single, well-defined purpose, making it easier for developers to understand the code
and make changes.
• Better error isolation: High cohesion reduces the likelihood that a change in one part of a
module will affect other parts, making it easier to
• Improved reliability: High cohesion leads to modules that are less prone to errors and that
function more consistently,
• leading to an overall improvement in the reliability of the system.

11
Disadvantages of low cohesion
• Increased code duplication: Low cohesion can lead to the duplication of code, as elements
that belong together are split into separate modules.
• Reduced functionality: Low cohesion can result in modules that lack a clear purpose and
contain elements that don’t belong together, reducing their functionality and making them
harder to maintain.
• Difficulty in understanding the module: Low cohesion can make it harder for developers to
understand the purpose and behavior of a module, leading to errors and a lack of clarity.

Functional independence:
Functional independence in software design refers to creating self-contained and minimally
dependent modules. Each module should perform a single, well-defined task and interact with
other modules only when necessary. This makes the system more modular, scalable, and easier
to maintain.
Functional independence is achieved by:
• High Cohesion (modules focus on one task)
• Low Coupling (modules have minimal dependencies)

How to Achieve Functional Independence in Software Design?

Follow Modular Design – Break the system into small, independent units.
Apply the Single Responsibility Principle (SRP) – Each module should have one reason to
change.
Use Well-Defined Interfaces – Modules should communicate through APIs instead of direct access.
Minimize Data Sharing – Pass only required parameters, avoid global variables.
Adopt Dependency Injection – Provide dependencies instead of hardcoding them.

Advantages of functional independence:

Error isolation
When a module is functionally independent then it performs most of its task independently without
interacting with other modules much. This reduces the chances of error getting propagated to other
modules. This helps in easily isolating and tracing the error.

Its because if there occurs an error then one is sure that its only because of this particular module
as it doesn't have any dependency on other module. And it can be traced and located easily without
thinking much about other modules.

12
 Module reusability
A functionally independent module performs some well defined and specific task. So it becomes
easy to reuse such modules in different program requiring same functionality.

3. Understandability
A functionally independent module is less complex thus easy to understand. Since such modules
are having less interaction with other modules so it can be understood in isolation.

Design Patterns :
Design patterns in software engineering are reusable solutions to common problems that arise
in software design. They provide a structured approach to designing software, improving
maintainability, scalability, and flexibility.
Design patterns provide a standard terminology and are specific to particular scenarios and
problems.
Key Characteristics of Design Patterns

o Reusability
o Standardization
o Efficiency
o Flexibility
Types of Software Design Patterns
There are three types of Design Patterns:
• Creational Design Pattern
• Structural Design Pattern
• Behavioral Design Pattern

Creational Patterns (Deals with object creation)

These patterns provide various ways to instantiate objects while keeping the code flexible and
scalable.

13
It focuses 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 :
• Singleton – Ensures a class has only one instance and provides a global access point.
• Factory Method – Provides an interface for creating objects but allows subclasses to alter the
type of objects that will be created.
• Abstract Factory – Provides an interface for creating families of related or dependent objects
without specifying their concrete classes.
• Builder – Separates object construction from its representation to allow the same construction
process to create different representations.
• Prototype – Creates new objects by copying an existing object (cloning).

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:
• Adapter – Allows incompatible interfaces to work together by converting one interface into
another.
• Bridge – Decouples an abstraction from its implementation, allowing both to evolve
independently.
• Composite – Treats individual objects and compositions of objects uniformly.
• Decorator – Adds functionality to objects dynamically without modifying their structure.
• Facade – Provides a simplified interface to a complex subsystem.
• Flyweight – Reduces memory usage by sharing objects instead of creating new ones.

14
• Proxy – Provides a surrogate or placeholder for another object to control access to it.

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
The Chain of Responsibility is a behavioral design pattern that allows multiple objects to
handle a request without specifying the receiver explicitly. Instead, the request is passed along a
chain of handlers until one of them processes it.
Key Features
• Decouples senders and receivers of requests.
• Avoids coupling the sender to a single receiver.
• Allows multiple handlers to process a request.
• Enables runtime configuration of handler chains.
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.

15
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.

16
MVC (Model-View-Controller) Architecture
MVC is a software design pattern commonly used for developing user interfaces that separates
an application into three interconnected components. This separation allows for better
organization, scalability, and maintainability of code.
Features of MVC
• It provides a clear separation of business logic, UI logic, and input logic.
• It offers full control over your HTML and URLs which makes it easy to design web
application architecture.
• It is a powerful URL-mapping component using which we can build applications that have
comprehensible and searchable URLs.
• It supports Test Driven Development (TDD).
Components of MVC
The MVC framework includes the following 3 components:
• Controller
• Model
• View
Controller
The controller is the component that enables the interconnection between the views and the model
so it acts as an intermediary. The controller doesn’t have to worry about handling data logic, it
just tells the model what to do. It processes all the business logic and incoming requests,
manipulates data using the Model component, and interact with the View to render the final
output.
Responsibilities:
• Receiving user input and interpreting it.
• Updating the Model based on user actions.
• Selecting and displaying the appropriate View.
Example: A User Controller that handles user-related requests and updates the UI accordingly.
View:
The View component is used for all the UI logic of the application. It generates a user interface
for the user. Views are created by the data which is collected by the model component but these
data aren’t taken directly but through the controller. It only interacts with the controller.
Responsibilities:
• Rendering data to the user in a specific format.
• Displaying the user interface elements.
• Updating the display when the Model changes.

17
Example:
In a bookstore application, the View would display the list of books, book details, and provide
input fields for searching or filtering books.

Model
• Represents the application's data, business logic, and rules.
• It directly manages the data, logic, and rules of the application.
• Can interact with the database or external APIs to retrieve, update, and delete data.
Responsibilities:
• Managing data: CRUD (Create, Read, Update, Delete) operations.
• Enforcing business rules.
• Notifying the View and Controller of state changes.
Example:
In a bookstore application, the Model would handle data related to books, such as the book title,
author, price, and stock level.

Working of the MVC framework

18
1.User Interaction (Request)
• The End User interacts with the application (e.g., clicking a button, submitting a form).
• This action generates a request, which is sent to the Controller.
2. Controller Handles the Request
• The Controller receives the request and determines what needs to be done.
• It never handles data logic directly.
• Instead, it interacts with the Model to fetch or update data.
3. Model Handles Data Logic
• The Model represents the data and business logic of the application.
• It interacts with the Database to fetch, update, or delete data as needed.
• After processing, it sends the data back to the Controller.
4. View Handles Presentation
• The Controller then forwards the retrieved data to the View.
• The View is responsible for dynamically rendering the data for the user.
• It handles UI/UX and ensures the data is displayed in a readable format.
5. Response Sent Back to User
• The View sends the final UI back to the Controller, which then delivers it to the End User.
• The user sees the updated page/interface with the requested data.
Example Scenario
Imagine a user logging into a website:
1.User Action: The user enters credentials and clicks "Login".
2.Controller: The request goes to the Controller, which validates the input.
3.Model: The Controller asks the Model to check the database for matching credentials.
4.Database Interaction: The Model queries the database and returns the result.
5.View Update: If credentials are correct, the View displays a success message or redirects the
user.
6.Response: The Controller sends the updated View back to the user.
Advantages of MVC:
❖ Codes are easy to maintain and they can be extended easily.
❖ The MVC model component can be tested separately.
❖ The components of MVC can be developed simultaneously.
❖ It reduces complexity by dividing an application into three units. Model, view, and controller.
❖ It supports Test Driven Development (TDD).
❖ Search Engine Optimization (SEO) Friendly.

19
 Disadvantages of MVC :
❖ Complexity
❖ Increased Development Time
❖ Requires Skilled Developers
❖ Performance Overhead
❖ Difficult Data Binding

Publish-Subscribe (Pub-Sub):
The Publish-Subscribe (Pub-Sub) pattern is a messaging pattern where senders
(publishers) do not send messages directly to receivers (subscribers). Instead, messages are
sent to an intermediary (message broker or event bus), which then distributes them to
interested subscribers.
Key points of the Pub/Sub model include:
• Publishers: Entities that generate and send messages.
• Subscribers: Entities that receive and consume messages.
• Topics: Channels or categories to which messages are published.
• Message Brokers: Intermediaries that manage the routing of messages between publishers
and subscribers.

How Pub-Sub Works?

1. Publisher: Generates and sends messages (events) to a central broker.
2. Broker (Message Bus): Receives messages and distributes them to all interested subscribers.
3. Subscriber: Registers interest in specific types of messages and processes them when
received.

20
Components of Pub/Sub Architecture
Publisher
• The Publisher is responsible for creating and sending messages to the Pub/Sub
system.
• Publishers categorize messages into topics or channels based on their content.
They do not need to know the identity of the subscribers.
Subscriber
• The Subscriber is a recipient of messages in the Pub/Sub system. Subscribers
express interest in receiving messages from specific topics.
• They do not need to know the identity of the publishers. Subscribers receive
messages from topics to which they are subscribed.
Topic
• A Topic is a named channel or category to which messages are published. Publishers
send messages to specific topics, and subscribers can subscribe to one or more topics
to receive messages of interest.
• Topics help categorize messages and enable targeted message delivery to interested
subscribers.
Message Broker
• The Message Broker is an intermediary component that manages the routing of
messages between publishers and subscribers.
• It receives messages from publishers and forwards them to subscribers based on their
subscriptions.
• The Message Broker ensures that messages are delivered to the correct subscribers
and can provide additional features such as message persistence, scalability, and
reliability.
Message
• A Message is the unit of data exchanged between publishers and subscribers in
the Pub/Sub system.
• Messages can contain any type of data, such as text, JSON, or binary data.
Publishers create messages and send them to the Pub/Sub system, and subscribers
receive and process these messages.
Subscription
• A Subscription represents a connection between a subscriber and a topic.
Subscriptions define which messages a subscriber will receive based on the topics
to which it is subscribed.
• Subscriptions can have different configurations, such as message delivery

21
 guarantees (e.g., at-most-once, at-least-once) and acknowledgment mechanisms.

Key Characteristics
Decoupling: Publishers and subscribers do not directly interact, making the system more
flexible.
Asynchronous Communication: Messages are sent without waiting for an immediate
response.
Scalability: Can handle a large number of messages and subscribers efficiently.

Real-World Example of Pub/Sub Architecture :

Notification Systems (Social Media & Messaging Apps)
Example: Facebook, Twitter, WhatsApp, and Slack
When a user posts an update, all their followers (subscribers) receive a notification without
the poster needing to notify them individually.
Pub-Sub Components:
• Publisher: User posts a status update.
• Broker: Notification system (e.g., Firebase Cloud Messaging, Kafka).
• Subscribers: Followers who receive the update.
Advantages :

Loose Coupling: Components can be modified independently.

Improved Scalability: Handles multiple publishers and subscribers efficiently.

Asynchronous Processing: Enhances system performance by avoiding blocking operations.

Disadvantages :

Complexity: Requires a broker and proper event handling.

Message Delivery Challenges: Messages might be lost if not properly configured.

Debugging Difficulty: Tracing issues can be hard due to the decoupled nature.

22
Adapter Design Pattern
The Adapter Pattern is a structural design pattern that allows objects with incompatible
interfaces to work together. It acts as a bridge between two incompatible interfaces by
converting one interface into another that a client expects.
How It Works?
• The Adapter translates requests from the Client into a format that the Adaptee (existing
class) understands.
• This allows legacy code or third-party libraries to be used without modification.
• ie) Step 1: The client initiates a request by calling a method on the adapter via the target
interface.
• Step 2: The adapter maps or transforms the client’s request into a format that the adaptee can
understand using the adaptee’s interface.
• Step 3: The adaptee does the actual job based on the translated request from the adapter.
• Step 4: The client receives the results of the call, remaining unaware of the adapter’s presence
or the specific details of the adaptee.

Components of Adapter Design Pattern

Below are the components of adapter design pattern:
• Target Interface: Defines the interface expected by the client. It represents the set of
operations that the client code can use. It’s the common interface that the client code interacts
with.
• Adaptee: The existing class or system with an incompatible interface that needs to be
integrated into the new system. It’s the class or system that the client code cannot directly use
due to interface mismatches.
• Adapter: A class that implements the target interface and internally uses an instance of the
adaptee to make it compatible with the target interface. It acts as a bridge, adapting the
interface of the adaptee to match the target interface.
• Client: The code that uses the target interface to interact with objects. It remains unaware of
the specific implementation details of the adaptee and the adapter. It’s the code that benefits
from the integration of the adaptee into the system through the adapter.
Advantages of Adapter Pattern
❖ Reusability: Allows old/incompatible code to be used without modification.
❖ Flexibility: Works as a bridge between new and legacy systems.
❖ Decoupling: Promotes loose coupling between components.

23
 Disadvantages
❖ Overhead: Adds an extra layer, which can affect performance.
❖ Complexity: Might increase complexity when multiple adapters are required.

Command Design Pattern

The Command Pattern is a behavioral design pattern that encapsulates a request as an object,
allowing parameterization of clients, queuing of requests, and logging of operations. It helps
decouple the sender (Invoker) from the receiver (Receiver) by using a command interface.

• The Command Pattern encapsulates a request as an object, allowing for the separation of sender
and receiver.
• Commands can be parameterized, meaning you can create different commands with different
parameters without changing the invoker.
• It decouples the sender from the receiver, providing flexibility and extensibility.
• The pattern supports undoable operations by storing the state or reverse commands.

24
 Components of the Command Design Pattern
The Command Pattern consists of the following key components:
1. Command (Interface/Abstract Class)
✓ Declares the execute() method.
✓ Represents an action to be performed.
2. Concrete Command (Implements Command)
✓ Implements the execute() method by calling the appropriate method on the Receiver.
✓ Stores a reference to the Receiver.
3. Receiver (Performs the Actual Action)
✓ Contains the actual business logic to execute the request.
✓ The command calls the appropriate method of the receiver.
4. Invoker (Triggers the Command Execution)
✓ Stores the command and triggers its execution.
✓ Decouples the Client from the Receiver.
Challenges :
• Devices can have different functionalities, so designing a remote control that can easily
handle different device types with varying functionalities without becoming highly
complex.
• Implementing a remote control that supports various commands without tightly coupling
ensuring the remote control can execute commands for different devices without needing
extensive modifications for each new command.
• Designing a system that allows users to customize the behavior of the remote control
dynamically.
How Command Pattern help to solve above challenges?
The Command Pattern can be employed to address these challenges. It introduces a
level of abstraction between the sender of a command (remote control) and the receiver of
the command (electronic devices).
• The Command Pattern decouples the sender (Invoker) from the receiver (Devices).
• The remote control doesn’t need to know the specific details of how each device operates;
it only triggers commands.
• New devices or commands can be added without modifying existing code.
• The remote control can work with any device that implements the common command
interface.

25
Strategy Design Pattern
The Strategy Pattern is a behavioral design pattern that allows you to define a family of
algorithms, encapsulate them, and make them interchangeable. This pattern helps in
choosing the algorithm dynamically at runtime.
Characteristics of this design pattern
This pattern exhibits several key characteristics, such as:
• Defines a family of algorithms: The pattern allows you to encapsulate multiple algorithms
or behaviors into separate classes, known as strategies.
• Encapsulates behaviors: Each strategy encapsulates a specific behavior or algorithm,
providing a clean and modular way to manage different variations or implementations.
• Enables dynamic behavior switching: The pattern enables clients to switch between
different strategies at runtime, allowing for flexible and dynamic behavior changes.
• Promotes object collaboration: The pattern encourages collaboration between a context
object and strategy objects, where the context delegates the execution of a behavior to a
strategy object.
Components of the Strategy Design Pattern :

The Strategy Pattern consists of the following key components:

1) Strategy (Interface/Abstract Class)
• Defines a common interface for all strategies.
• Declares a method that all concrete strategies must implement.
2) Concrete Strategies (Implementations of the Strategy Interface)
• Implements the Strategy Interface.
• Provides different variations of the algorithm.
3) Context (Uses a Strategy)
• Maintains a reference to a Strategy object.
• Allows switching between different strategies dynamically.
• Delegates execution to the chosen strategy.
4) Client (Assigns a Strategy)
o Selects the appropriate Strategy.
o Passes the selected strategy to the Context.

26
Observer Design Pattern :
The Observer Pattern is a behavioral design pattern where an object (Subject) maintains
a list of its dependents (Observers) and notifies them of any state changes, usually by calling
one of their methods.

Components of Observer Design Pattern

Below are the main components of Observer Design Pattern:
Subject:
o The subject maintains a list of observers (subscribers or listeners).
o It Provides methods to register and unregister observers dynamically and defines a
method to notify observers of changes in its state.
Observer:
o Observer defines an interface with an update method that concrete observers must
implement and ensures a common or consistent way for concrete observers to receive
updates from the subject.
ConcreteSubject:
o ConcreteSubjects are specific implementations of the subject. They hold the actual
state or data that observers want to track. When this state changes, concrete subjects
notify their observers.
o For instance, if a weather station is the subject, specific weather stations in different
locations would be concrete subjects.

27
Concrete Observer:
o Concrete Observer implements the observer interface. They register with a concrete
subject and react when notified of a state change.
o When the subject’s state changes, the concrete observer’s update() method is invoked,
allowing it to take appropriate actions.
For example, a weather app on your smartphone is a concrete observer that reacts to changes
from a weather station.

Advantages of Observer Pattern

❖ Loose Coupling – The subject and observers are independent of each other.
❖ Easy to Extend – New observers can be added without modifying existing code.
❖ Automatic Updates – Observers automatically receive state changes from the
subject.
Disadvantages
❖ Increased Complexity – Managing multiple observers can add complexity.
❖ Potential Performance Issues – If too many observers exist, updates can be
expensive.
Real-World Use Cases :
o Social Media Notifications – Followers get notified when someone posts a new
update.
o Stock Market Tracking – Investors (observers) get notified about stock price
changes.
o News Applications – Users receive notifications for breaking news.
o Event Listeners in GUI Programming – Button clicks trigger event handlers.

Proxy Design Pattern

The Proxy Pattern is a structural design pattern that provides a surrogate or
placeholder for another object to control access to it. The proxy object acts as an intermediary
between the client and the real object, adding functionalities like lazy initialization, access
control, logging, or caching.

28
Chaining of Proxies
Chaining proxies in the Proxy Design Pattern means connecting them in a sequence, where
each proxy adds its behavior or checks before passing the request to the next proxy or the real
object. It’s like forming a chain of guards, each responsible for a specific task.
Components :
• Subject
• Real Subject
• Proxy
How It Works?

1. Subject (Interface)
o Defines the common interface for both the Real Object and Proxy.
2. Real Subject (Actual Implementation)
o Contains the actual logic that needs to be executed.
3. Proxy (Surrogate Object)
o Controls access to the Real Subject by adding additional behavior like security,
caching, or lazy initialization.
4. Client
o Uses the Proxy instead of directly interacting with the Real Subject.
Advantages :
❖ Lazy Initialization – The real object is created only when needed, reducing resource usage.
❖ Access Control – Adds security by restricting unauthorized access.
❖ Logging & Monitoring – Proxies can log method calls or track object access.
❖ Caching – Reduces redundant operations by storing previous results.
Disadvantages :
❖ Increased Complexity – Adds an extra layer of abstraction.
❖ Performance Overhead – If not implemented properly, proxies may slow down execution.\
How to implement Proxy Design Pattern?
Below are the simple steps to implement the Proxy Design Pattern:
1. Create the Real Object Interface: Define an interface or abstract class that represents the
operations the real object will provide. Both the real object and proxy will implement this
interface.
2. Create the Real Object: This class implements the interface and contains the actual logic or
operation that the client wants to use.

29
3. Create the Proxy Class: The proxy class also implements the same interface as the real
object. It holds a reference to the real object and controls access to it. The proxy can add extra
logic like logging, caching, or security checks before calling the real object’s methods.
4. Client Uses the Proxy: Instead of creating the real object directly, the client interacts with
the proxy. The proxy decides when and how to forward the client’s request to the real object.

Facade Design Pattern

The Facade Pattern is a structural design pattern that provides a simplified and unified
interface to a complex system of classes, libraries, or APIs. It hides the system's complexity
and provides a high-level interface for clients to interact with.

Components of the Facade Design Pattern

The Facade Pattern consists of the following key components:
Facade (Main Interface)
• The central class that provides a simplified, high-level interface to the client.
• Delegates requests to the underlying subsystems without exposing their complexities.
Subsystem Classes (Complex System)
• Perform the actual work but are hidden from the client.
• Each subsystem class represents a separate module or component in the system.
• The Facade interacts with these classes to complete the required operations.
Client
• Interacts only with the Facade, without needing to know about the complex subsystems.
• Sends a request to the Facade, which processes it and forwards it to the appropriate Subsystem
Classes.

How It Works?
1. Facade (Main Entry Point)
o Provides a simple interface to the client.
o Delegates complex tasks to underlying subsystems.
2. Subsystem Classes
o Perform the actual operations.
o Can be multiple independent components working together.
3. Client
o Interacts with the system using the Facade, without needing to know the system's
internal details.

30
Advantages :
❖ Simplifies Complexity – Provides a single access point for a complex system.
❖ Improves Code Maintainability – Changes in subsystem components do not affect clients.
❖ Reduces Coupling – The client only depends on the Facade, not the complex internal
subsystems.
❖ Encapsulates Subsystems – Hides implementation details from the client.
Disadvantages :
❖ Limited Flexibility – If a client needs advanced functionality, it may need to bypass the
Facade.
❖ Can Introduce Overhead – If not designed properly, it may become an unnecessary layer.

Real-World Use Cases :

✓ Library Management System – A single API for handling book issuance, returns, and
member registration.
✓ E-Commerce Checkout – A facade manages payment processing, inventory updates, and
order confirmation.
✓ Operating System API – Simplifies access to hardware resources like printers and network
connections.
✓ Web Services – A unified API simplifies interactions with multiple microservices.

Architectural Styles :
In software engineering, architectural styles define high-level patterns for
structuring software systems. These styles provide templates for organizing components,
relationships, and interactions within a system.
Why ?
Architectural styles define a structured approach to designing software systems. They
provide standardized solutions to common problems and improve software scalability,
maintainability, and efficiency.
Key Reasons for Using Architectural Styles
❖ Maintainability & Modularity
❖ Scalability & Performance
❖ Reusability & Standardization
❖ Flexibility & Adaptability
❖ Security & Reliability

31
Why to choose architectural styles?

❖ Better Code Organization

❖ Easier Maintenance & Scaling
❖ Efficient Communication & Integration
❖ Enhanced Security & Performance
❖ Faster Development & Cost Savings

Common Architectural Styles :

Layered Architecture:
The Layered Architecture (also known as N-Tier Architecture) organizes software into
multiple logical layers, each with a specific responsibility. Each layer communicates only with
adjacent layers, promoting separation of concerns and modularity.

Key Characteristics
Separation of Concerns.
Modularity
Scalability
Security
Flexibility
Features of Layered Architecture
• Use of Layered architecture in computer network provides with the feature of modularity and
distinct interfaces.
• Layered architecture ensures independence between layers, by offering services to higher
layers from the lower layers and without specifying how these services are implemented.
• Layered architecture segments as larger and unmanageable design into small sub tasks.
Elements of Layered Architecture
There are three different types of elements of a layered architecture.
Service: Service is defined as a set of functions and tasks being provided by a lower layer to
a higher layer. Each layer performs a different type of task. Therefore, actions provided
by each layer are different.
Protocol: Protocol is defined as a set rule used by the layer for exchanging and transmission
of data with its peer entities. These rules can consists details regarding a type of content
and their order passed from one layer to another

32
 Interface: Interface is defined as a channel that allows to transmit the messages from one
layer to the another.

Significance of Layered Architecture

• Divide and Conquer Approach: Layered architecture supports divide and conquer
approach. The unmanageable and complex task is further divided into smaller sub tasks. Each
sub task is then carried out by the different layer. Therefore, using this approach reduces the
complexity of the problem or design process.
• Easy to Modify: The layers are independent of each other in layered architecture. If any
sudden change occurs in the implementation of one layer, it can be changed. This change
does not affect the working of other layers involved in the task. Therefore, layered
architectures are required to perform any sudden update or change.
• Modularity: Layered architecture is more modular as compared to other architecture models
in computer network. Modularity provides with more independence between the layers and
are easier to understand.
• Easy to Test: Each layer in layered architecture performs a different and dedicated task.
Therefore, each layer can be analyzed and tested individually. It helps to analyze the problem
and solve them more efficiently as compared to solving all the problems at a time.
• Scalability: As networks grow in size and complexity, additional layers or protocols may be
added to meet new requirements while maintaining existing functionality.

33
 Challenges in Layered Architecture
✓ Performance Overhead
✓ Complexity in Implementation
✓ Resource Utilization
✓ Debugging and Troubleshooting
✓ Protocol Overhead
Real-World Applications and Examples
✓ Internet Browsing
✓ Email Communication
✓ Video Streaming
✓ Online Gaming

Client Server Architecture:

The Client-Server Architectural Style is a distributed system design where clients
request services from centralized servers, which process the requests and send responses. It
is commonly used in web applications, cloud computing, and enterprise systems.

Key Characteristics :
Two Roles: Client (Requester) & Server (Provider)
Centralized Server: Handles business logic, data processing, and responses.
Scalability: Multiple clients can interact with a single or multiple servers.
Security: Data and services are managed centrally.
Network-Based Communication: Uses HTTP, TCP/IP, WebSockets for client-server
interactions.
Key Components of Client Server Architecture
Client-server architecture in system design involves several key components that work
together to ensure efficient communication, resource management, and service delivery. Here are
the main components:
• Client: The client is a device or application that requests services or resources from the
server. It initiates communication with the server and processes the results returned by the
server.
• Server: The server is a powerful machine or application that provides services or resources
to clients. It processes client requests, performs the necessary computations or data retrieval,
and sends back the appropriate responses.

34
• Network: The network facilitates communication between clients and servers. It enables data
exchange using various protocols and ensures reliable connectivity.
• Protocols: Protocols are standardized rules that govern data transmission and communication
between clients and servers. They ensure that data is transmitted in a secure, reliable, and
understood manner.
• Middleware: Middleware is software that acts as an intermediary between clients and
servers. It provides additional functionalities like authentication, logging, message queuing,
and transaction management.
• Database: A database is a structured collection of data stored on the server. It stores and
manages data that clients request, ensuring data consistency, integrity, and security.
• User Interface (UI): The UI is the part of the client application that interacts with the user.
It provides a means for users to input data and view results returned by the server.
• Application Logic: Application logic refers to the code and algorithms that define the
application's functionality. It processes user inputs, interacts with the server, and manages the
flow of data between the client and the server.

Types of Client-Server Architecture

Two-Tier Architecture
• Client ↔ Server (Direct communication).
• Example: A desktop application directly interacts with a database server.
Three-Tier Architecture
• Client ↔ Application Server ↔ Database Server.
• Example: A web app with a frontend, backend (business logic), and database.
Multi-Tier (N-Tier) Architecture
• Adds more layers for scalability and security (e.g., load balancer, caching).
• Example: Large-scale web apps like Amazon, Netflix, Google Cloud.
Some are some real-world examples of Client Server Architecture are :
✓ Banking Systems
✓ Telecommunications
✓ Internet of Things (IoT)
✓ Healthcare Systems

This architecture ensures scalability, security, and reliability in handling user interactions
and data management.

35
 Tiered Architecture:
Tiered Architecture (also known as N-Tier Architecture) is a software design pattern that
separates an application into multiple layers or tiers, each handling a specific responsibility.
Modular Design → Improves scalability, security, and maintainability.
Separation of Concerns → Each tier focuses on a distinct function.
Scalability & Performance → Load can be distributed among tiers.

Key Components
Presentation Tier
Application (Business Logic) Tier
Data Tier
Types of Tiered Architecture
Two-Tier Architecture
• Client ↔ Server (Database)
• The client directly communicates with the database server.
• Used in desktop applications.
Limitation: Poor scalability & security.
Example: Banking system
Three-Tier Architecture
• Client ↔ Application Server ↔ Database
• Introduces an Application Layer between UI and Database.
• mproves security, performance, and maintainability.
• Common in Web Applications.
Example: E-commerce Websites (Amazon, Flipkart)
Multi-Tier (N-Tier) Architecture
• Expands three-tier by adding more layers for better security & scalability.
• Includes Load Balancers, API Gateways, Microservices, Caching Layers.
• Used in Enterprise & Cloud Applications.
Example: Netflix, Google Cloud
Advantages :
❖ Scalability
Security
❖ Maintainability.
Reusability

36
 Disadvantages
❖ Complexity
❖ Latency
❖ Deployment Cost
Usage :
1. Web Applications (E-commerce, Social Media)
2. Enterprise Software (Banking, ERP Systems)
3. Cloud Computing (AWS, Azure, Google Cloud)
4. Streaming Platforms (Netflix, YouTube)

Pipe and Filtered Architecture:

The Pipe and Filter Architectural Style is a design pattern where data flows through a
sequence of processing units (Filters) connected by Pipes. Each filter processes the input,
transforms it, and passes it to the next filter.

Data flows through these filters via pipes, which carry the output of one filter to the
input of another.
• This architecture enhances modularity, as each filter operates independently and concentrates
on a singular function. It also promotes reusability, allowing filters to be utilized across
different systems or applications.
• Moreover, it is both flexible and scalable; filters can be added, removed, or rearranged with
little effect on the overall system, and multiple instances of filters can function concurrently
to manage larger data sets.
• The architecture is highly modular, with each filter functioning independently, simplifying
system comprehension, maintenance, and expansion. Filters can be added, removed, or
rearranged without significant impact on the overall system, and parallel pipelines can boost
throughput for larger data volumes.

37
• Pumps: These components initiate the process by acting as data sources, injecting data into
the system and starting the flow through the pipeline.
• Filters: Each filter carries out a specific, standalone task, whether it be transforming,
validating, or processing data before forwarding it. In the setup, there are two levels of filters;
the first one processes data from the pump and hands it to the second filter, which continues
the processing before passing it on.
• Pipes: Pipes serve as the channels for data movement between filters, linking each
component in sequence and ensuring a smooth transfer of data. In diagrams, pipes are
depicted as arrows connecting the components.
• Sinks: These are the endpoints where the processed data is ultimately collected or utilized.
After passing through all filters, the data arrives at the sink, completing its pipeline journey.
• Parallel Processing: The architecture also supports a parallel structure, where two
independent pipelines operate side by side. Each pipeline begins with its own pump,
processes data through a series of filters, and concludes at separate sinks. This indicates the
capability for simultaneous processing of different data streams without conflict

How Pipe and Filter Architecture Works ?

1. Input Data enters the first Filter.
2. The Filter processes data and passes it through a Pipe to the next filter.
3. This process continues until the data reaches the final Output (Sink).
Example: A Data Processing Pipeline where raw data is:
Filtered → Cleaned → Transformed → Stored

Characteristics :
• Modularity
• Reusability
• Composability
• Scalability
• Maintainability

Challenges
• Performance Overhead
• Complex Error Handling
• Resource Utilization
• State Management

38
 User Interface Design :
The user interface is the front-end application view to which the user interacts to use the
software. The software becomes more popular if its user interface is:
1. Attractive
2. Simple to use
3. Responsive in a short time
4. Clear to understand
5. Consistent on all interface screens
UI Design Process
1. User Research.
2. Wireframing & Prototyping
3. Visual Design
4. Development & Implementation
5. Testing & Feedback

Types of User Interface :

1. Command Line Interface: The Command Line Interface provides a command prompt,
where the user types the command and feeds it to the system. The user needs to remember
the syntax of the command and its use.
2. Graphical User Interface: Graphical User Interface provides a simple interactive interface
to interact with the system. GUI can be a combination of both hardware and software. Using
GUI, the user interprets the software.

Key Principles for Designing User Interfaces

1. User-centered design: User interface design should be focused on the needs and preferences
of the user. This involves understanding the user’s goals, tasks, and context of use, and
designing interfaces that meet their needs and expectations.
2. Consistency: Consistency is important in user interface design, as it helps users to understand
and learn how to use an application. Consistent design elements such as icons, color schemes,
and navigation menus should be used throughout the application.
3. Simplicity: User interfaces should be designed to be simple and easy to use, with clear and
concise language and intuitive navigation. Users should be able to accomplish their tasks
without being overwhelmed by unnecessary complexity.
4. Feedback: Feedback is significant in user interface design, as it helps users to understand the
results of their actions and confirms that they are making progress towards their goals.
Feedback can take the form of visual cues, messages, or sounds.

39
5. Accessibility: User interfaces should be designed to be accessible to all users, regardless of
their abilities. This involves considering factors such as color contrast, font size, and assistive
technologies such as screen readers.
6. Flexibility: User interfaces should be designed to be flexible and customizable, allowing
users to tailor the interface to their own preferences and needs.

Modern Design Practices:

Modern software design practices have become essential due to technological
advancements, increasing complexity, and evolving user expectations. These practices
improve scalability, security, maintainability, and user experience, making software more
efficient and future-proof.

Microservice Architecture:

A microservices architecture results in an application designed as a set of small,

independent services. Each one represents a business capability in itself. The services loosely
couple with one another and communicate over the network, typically making use of
lightweight protocols such as HTTP or messaging queues.
• Each service is responsible for a single functionality or feature of the application and can be
developed, deployed, and scaled independently.
• The Microservice architecture has a significant impact on the relationship between the
application and the database.

40
 This diagram represents a Microservices Architecture, which is a modern approach
to building scalable and maintainable applications by breaking them into smaller,
independently deployable services. Let’s break it down step by step.

API Gateway
• The API Gateway acts as a single entry point for client applications.
• Responsibilities:
o Routing: It forwards client requests to the appropriate microservice.
o Authentication & Security: Ensures requests are secure.
o Load Balancing: Distributes traffic evenly to prevent overload.
o Request Aggregation: Combines responses from multiple microservices into a single
response.
o Rate Limiting & Logging: Controls request limits and monitors traffic.
Microservices
Each microservice is a self-contained unit with its own database, allowing independent
development and deployment.
Microservices in the Diagram
1. Catalog Microservice
o Manages product listings and details.
o Retrieves product information from its database.
2. Shopping Cart Microservice
o Handles adding/removing items in the shopping cart.
o Stores cart details in its dedicated database.
3. Discount Microservice
o Applies discounts, promotions, or coupon codes.
o Stores discount policies in its own database.
4. Ordering Microservice
o Manages order processing, payments, and order history.
o Interacts with other services for order validation and confirmation.
o Stores order details in its database.

41
 Databases
• Each microservice has its own database (also known as Database per Microservice
pattern).
• This ensures:
o Data Isolation: Services operate independently.
o Scalability: Each database can scale separately based on demand.
o Fault Tolerance: A failure in one database does not affect the entire system.

Message Broker
• The Message Broker facilitates asynchronous communication between microservices.
• Responsibilities:
o Event-Driven Communication: Instead of making direct calls, microservices
publish messages/events that other services subscribe to.
o Decoupling Services: Services do not directly depend on each other.
o Improved Scalability: Handles high loads without blocking operations.
Key Benefits / Advantages :
• Scalability
• Flexibility
• Faster Development
• Easy Maintenance
• Improved Fault Tolerance
• Enhanced Security

RESTful Services :
RESTful services (or REST APIs) are web services that follow the Representational
State Transfer (REST) architectural style. They enable communication between client and
server applications over the internet using standard HTTP methods.
Key Principles:
Client-Server Architecture
• Separates frontend (client) from backend (server), allowing independent development.
Statelessness
• Each request from a client must contain all the information needed to process it.
• The server does not store client state between requests.

42
 Uniform Interface
• Uses standardized HTTP methods:
o GET → Retrieve data
o POST → Create new data
o PUT → Update existing data
o DELETE → Remove data
Resource-Based
• Everything is treated as a resource (e.g., users, products, orders) and identified by a URL.
• Example:
o GET /users/123 → Fetch user with ID 123
o POST /orders → Create a new order
RESTful Architecture:
1. Division of State and Functionality: State and functionality are divided into distributed
resources. This is because every resource has to be accessible via normal HTTP commands.
That means a user should be able to issue the GET request to get a file, issue the POST or
PUT request to put a file on the server, or issue the DELETE request to delete a file from the
server.
2. Stateless, Layered, Caching-Support, Client/Server Architecture: A type of architecture
where the web browser acts as the client, and the web server acts as the server hosting the
application, is called a client/server architecture. The state of the application should not be
maintained by REST. The architecture should also be layered, meaning that there can be
intermediate servers between the client and the end server. It should also be able to implement
a well-managed caching mechanism.

Why Are RESTful Services Used?

*Scalability
*Interoperability
*Lightweight & Fast.
*Flexibility Security
*Ease of Integration

-----------------------------------------------------------------------------------------

43