Unit-2

Architectural Styles and Patterns

Overview
2.1 Common architectural styles (Layered, Client-server, Microservices,
Event-driven, SOA)
2.2 Architectural patterns (MVC, Broker, Pipe and Filter)
2.3 Design patterns (Singleton, Factory, Observer, Strategy)
2.4 Choosing appropriate architectural styles and patterns based on system
requirements
2.5 Impact of architecture on non-functional requirements (performance,
scalability, security)

2
Software Architecture
• A high-level structure of software system that includes the set of rules, patterns,
and guidelines that dictate the organization, interactions and the component
relationships.
• Serves as blueprint ensuring that the system meets it’s requirements and also
maintainable, scalable and flexible.

3
Common Architectures
1. Layered Architecture
– Organizes system components into separate layers, where each layer has a
specific role
– Commonly includes layers such as Presentation, Business Logic, Data Access, and
Database
– Layers are stacked, and each layer only interacts with the layer directly below it

Key Benefits:
✓Separation of Concerns: Clear division between layers enhances modularity
✓Maintainability: Changes in one layer (e.g., data storage) don’t affect other layers
✓Testability: Easier to test in isolation due to modular structure
4
Common Architectures…
Drawbacks:
• Rigidity: Can be difficult to adapt or expand to meet scaling demands
• Performance: Extra layers can introduce latency

Common Use Cases:

Web applications, desktop applications with complex logic, and enterprise
applications

5
Common Architectures…
User interface, when user
interaction occurs

Core Application Logic

Manages data transactions

and storage

Physical storage of data

Fig: Layered Architecture Style

6
Common Architectures…
2. Client-Server Architecture:
– A distributed model with clients (users or applications) making requests, and
servers responding to them
– Clients and servers are separate; clients do not communicate directly with each
other

Key Benefits:
• Centralized Control: Servers handle main data and resources, making it easier to
manage
• Scalability: Supports multiple clients, as server can handle concurrent requests
• Security: Centralization makes it easier to implement security measures
7
Common Architectures…
Drawbacks:
• Server Overload: If demand is high, server can become a bottleneck
• Single Point of Failure: If the server goes down, clients lose access

Common Use Cases:

Web applications, file sharing systems, networked games, email servers

Fig: Client-Server Architecture

8
Common Architectures…
3. Microservices:
• An approach where the application is structured as a collection of loosely
coupled, independently deployable services
• Each service handles a specific business function and communicates over a
network (often via REST APIs)

Key Benefits:
• Scalability: Individual services can be scaled as needed
• Fault Isolation: Failure in one service doesn’t impact the entire system
• Flexibility: Allows for independent updates and deployments of services

9
Common Architectures…
Drawbacks:
• Complexity: More challenging to manage, monitor, and secure multiple services
• Deployment Overhead: Requires strong DevOps practices to handle continuous
integration and deployment
• Common Use Cases:
Large-scale applications, systems requiring rapid iteration, e-commerce
platforms

10
Common Architectures…

Fig: Microservices Architecture

11
Common Architectures…
4. Event-Driven Architecture:
– Architecture where components respond to events or triggers, processing them
in real-time or near-real-time
– Typically includes event producers, event processors, and event consumers
– Events may be processed through a central message broker, like Kafka or
RabbitMQ
Key Benefits:
• Scalability: Easily scales with high loads and multiple event sources
• Real-time Processing: Ideal for applications needing instant data processing
• Loose Coupling: Components are highly decoupled, improving flexibility

12
Common Architectures…
Drawbacks:
• Complexity in Error Handling: Difficult to ensure consistency, especially with
distributed components
• Latency in Event Processing: Real-time might lag if events queue up

Common Use Cases:

IoT applications, stock trading platforms, notification systems, e-commerce
events

13
Common Architectures…

Fig: Event-Driven Architecture

14
Common Architectures…
5. Service-Oriented Architecture:
• A modular style that organizes functions as independent, reusable services, often
communicating over a network
• Each service provides a business capability and is loosely coupled, typically with a
centralized service bus for interaction
Key Benefits:
• Reusability: Services can be reused across different applications
• Flexibility: Easy to adapt, scale, or replace services
• Scalability: Can scale services based on need

15
Common Architectures…
Drawbacks:
• Complex Governance: Requires careful design and management of services and
communication
• Latency: Network-based communication can introduce delays

Common Use Cases:

Large enterprises, applications with complex business requirements, and
systems needing interoperability (e.g., integrating legacy and new applications)

16
Common Architectures…

Fig: Service-Oriented-Architecture

17
Architectural patterns
– Reusable Solutions to recurring design problems within a specific architectural
style.
– Gives the organization of high level system components.

18
Architectural patterns…
1. MVC =>(UI Intensive)
– Modular architecture for interactive systems.
– Promotes separation of concerns, improving testability and parallel development.
Components:
• Model: Encapsulates core data and logic
• View: Presents data to the user
• Controller: Manages input and coordinates between model and view.
Uses:
• Application with user interface (e.g. desktop, mobile, web)
• Scenarios where updates to UI and business logic occurs independently.
19
Architectural patterns…

Fig: MVC Architecture

20
Architectural patterns…
Example: Django (Python), Laravel (PHP), ASP.NET(C#)
Strengths:
• Modular design simplifies debugging and testing.
• Encourages separation of responsibilities.
• Flexible for UI changes.
Weaknesses:
• Complexity in coordination between components.
• Overhead in small projects.

21
Architectural patterns…
2. Broker Pattern
• Suitable for systems where services are distributed across different locations.
Components:
• Clients: Request services.
• Broker: Mediates requests and locates service providers.
• Service Providers: Execute requests and return results.
Uses:
• Middleware-based systems.
• Distributed applications where components are loosely coupled.

22
Architectural patterns…

Fig: Broker pattern

23
Architectural patterns…
Example: Remote Procedure Calls (RPC), CORBA, and gRPC.
Strengths:
• Supports distributed system scalability.
• Decouples client and service logic.
• Centralized management improves service discovery.
Weaknesses:
• Broker failure can affect the entire system.
• Latency due to indirection.

24
Architectural patterns…
3. Pipe and Filter Pattern
• Suitable for systems processing data streams in a series of transformations.
Key Components:
Filters: Process and transform data.
Pipes: Connect filters and pass data between them.
Uses: Systems requiring modular processing, e.g., data analytics, compilers.

Data Source Data Sink

Fig: Pipe and Filter Architecture 25

Architectural patterns…
Example: Linux Command pipelines (cat|grep|sort)
Strengths:
• High modularity and reusability.
• Easy to scale and parallelize.
• Simplifies debugging by isolating issues in individual filters.
Weaknesses:
• Overhead in data transfer between filters.
• Latency in long pipelines.

26
Design patterns
Software design patterns are important tools for developers, providing proven
solutions to common problem encountering during software development.
Benefits:
• Improves code maintainability
• Enhances scalability and flexibility
• Promotes best practices
Types
– Creational Design Pattern
– Structural Design Pattern
– Behavioral Design Pattern

27
Design patterns…
1. Creational Design Pattern
• 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
• Singleton Pattern
• Factory Method Pattern
• Abstract Factory Method Pattern
• Builder Pattern
• Prototype Pattern

28
Design patterns…
2. Structural Design pattern
• 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 Pattern
Bridge Pattern
Composite Pattern
Decorator Pattern
Façade pattern
Proxy Pattern
Flyweight Pattern 29
Design patterns…
3. Behavioral Design Pattern
• concerned with algorithms and the assignment of responsibilities between
objects.
• 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:
• Observer Pattern • Interpreter Pattern
• Strategy Pattern • Visitor Pattern
• State Pattern • Mediator Pattern
• Command Pattern • Memento Pattern
• Template Pattern
30
Singleton Pattern
• Ensures a class has only one instance and provides a global access
point to it.
Intent:
• Prevent multiple instances of a class.
• Save memory and avoid inconsistencies.

new

Fig: Singleton Pattern 31

Singleton Pattern…
Key Features:
• Private constructor.
• Static instance variable.
• Thread-safety considerations (e.g., double-checked locking).
Use Case:
• Logging services.
• Configuration settings.

32
Singleton Pattern…
Example:
public class Singleton {
private static Singleton instance;

private Singleton() { }

public static Singleton getInstance() {

if (instance == null) {
instance = new Singleton();
}
return instance;
}
}
33
Factory Pattern
• Creates objects without exposing the information logic to the client,
allowing more flexibility.
• Provide an interface for creating objects without specifying their
concrete classes.
Intent:
• Delegates instantiation logic.
• Promotes loose coupling.

34
Factory Pattern…

Fig: Factory Pattern 35

Factory Pattern…
public interface Shape { public class ShapeFactory {
void draw(); public static Shape getShape(String type) {
} if (type.equals("Circle")) return new Circle();
if (type.equals("Rectangle")) return new Rectangle();
public class Circle implements Shape { return null;
public void draw() { }
System.out.println("Drawing a Circle"); }
}
}

public class Rectangle implements Shape {

public void draw() {
System.out.println("Drawing a Rectangle");
}
}
36
Factory Pattern…
• Key Features:
• Abstracts object creation.
• Reduces code duplication.
• Use Case:
• GUI frameworks (e.g., buttons, text fields).
• Database connections.

37
Observer Pattern
• Defines a one-to-many dependency between objects so that when
one object changes state, all its dependents are notified.
• Intent:
• Decouple subject and observers.
• Enable dynamic subscription.

Fig: Observer Design Pattern 38

Observer Pattern…

Fig: Observer Design Pattern

39
Observer Pattern…
subject interface

interface Subject {
void addObserver(Observer o);
void removeObserver(Observer o);
void notifyObservers();
}
observer interface

interface Observer {
void update(String weather);
}

40
Observer Pattern…
WeatherStation Class (Concrete Subject) @Override
public void removeObserver(Observer o) {
import java.util.ArrayList;
observers.remove(o);
import java.util.List; }

class WeatherStation implements Subject { @Override

private List<Observer> observers; // List to hold observers public void notifyObservers() {
private String weather; // Current weather information for (Observer o : observers) {
o.update(weather);
public WeatherStation() { }
observers = new ArrayList<>(); }
}
// Method to update weather and notify observers
@Override public void setWeather(String weather) {
public void addObserver(Observer o) { this.weather = weather;
observers.add(o); notifyObservers();
} }
}

41
Observer Pattern…
PhoneDisplay Class (Concrete Observer)
class PhoneDisplay implements Observer {
private String weather; // Stores the current weather

@Override
public void update(String weather) {
this.weather = weather;
display();
}

public void display() {

System.out.println("Phone Display: Current weather is " + weather);
}
}
42
Observer Pattern…
TVDisplay Class (Concrete Observer)

class TVDisplay implements Observer {

private String weather; // Stores the current weather

@Override
public void update(String weather) {
this.weather = weather;
display();
}

public void display() {

System.out.println("TV Display: Current weather is " + weather);
}
}

43
Observer Pattern…
Testing Observer pattern // Add observers to the subject
public class Main { weatherStation.addObserver(phoneDisplay);
public static void main(String[] args) { weatherStation.addObserver(tvDisplay);
// Create the subject
WeatherStation weatherStation = new // Simulate weather updates
WeatherStation(); weatherStation.setWeather("Sunny");
weatherStation.setWeather("Rainy");
// Create observers }
PhoneDisplay phoneDisplay = new }
PhoneDisplay();
TVDisplay tvDisplay = new TVDisplay();

44
Observer Pattern…
• Key Features:
• Subject and Observer interfaces.
• Push or pull model.
• Use Case:
• Event-driven systems (e.g., GUI listeners).
• Messaging services.

45
Strategy Pattern
• Defines a family of algorithms, encapsulates each one, and makes
them interchangeable.
• Enables selecting an algorithm’s behavior at runtime.
• Different algorithms can be swapped in and out without altering the
code that uses them.
Intent:
• Eliminate conditional logic.
• Promote open/closed principle.

46
Strategy Pattern…

Fig: Strategy Pattern

47
Strategy Pattern…
public interface Strategy { public class Context {
int execute(int a, int b); private Strategy strategy;
}
public Context(Strategy strategy) {
public class AddStrategy implements Strategy { this.strategy = strategy;
public int execute(int a, int b) { }
return a + b;
} public int executeStrategy(int a, int b) {
} return strategy.execute(a, b);
}
public class MultiplyStrategy implements Strategy { }
public int execute(int a, int b) {
return a * b;
}
}

48
Strategy Pattern…
• Key Features:
• Encapsulation of algorithms.
• Dependency injection.
• Use Case:
• Payment processing systems.
• Sorting algorithms.

49
Discussions…
Q 1. How do design patterns differ from algorithms?
Design patterns focus on solving recurring design problems at the architectural
or structural level, emphasizing the organization of code. Algorithms, on the
other hand, are step-by-step procedures for solving specific problems at the
computational level.
Q 2. Are design patterns language-specific?
No, design patterns are not tied to a specific programming language. They are
conceptual solutions that can be implemented in various languages. However,
the syntax and implementation details may vary.
Q 3. How do design patterns differ from architectural patterns?
Design patterns address specific design issues at a lower level, focusing on
object creation, composition, and interaction. Architectural patterns, on the
other hand, deal with higher-level structures of an entire application or system.
50
Choosing appropriate architectural styles and pattern
based on system requirements

51
Choosing Architectural Styles and Pattern…
How?
1. Understand Functional and Non-Functional requirement
2. Identify constraints(budget, time, technology stack)
3. Map requirements to appropriate patterns(architectural & design)

52
Choosing Architectural Styles and Pattern…
Example 1 - E-commerce Platform
• Functional:
• User authentication, product browsing, and checkout.
• Real-time inventory updates.
• Non-functional:
• Scalability to handle high traffic.
• High availability and minimal downtime.

53
Choosing Architectural Styles and Pattern…
Example 2 - Real-Time Messaging App
• Functional:
• Instant messaging with typing indicators.
• User presence status and file sharing.
• Non-functional:
• Performance: Low-latency message delivery.
• Scalability: Handle millions of concurrent users.

54
Choosing Architectural Styles and Pattern…
Example 3 - Online Banking System
• Functional:
• User authentication and account management.
• Real-time fund transfers and transaction history.
• Non-functional:
• Security: Protect sensitive user data.
• Reliability: Ensure transactions are never lost.

55
56
Impact of architecture on non-functional requirements

• Performance – will architecture handle expected loads?

• Scalability – can it grow with the user base?
• Security – strengthened by isolation
• Maintainability – how easy is it to update and modify?
• Deployment – what are the deployment complexities?

Proper Architectural Choice

Ensure a system needs both current and future needs

57
Architecture styles evaluation
• The evaluation results are displayed in Table Next Slide. The method of measuring
architecture styles utilized by Galster et al., (2010) has been replicated.
• “++” represent a architecture style perform very well with some specific
Quality Attribute;
• “+” stands for some support;
• “−” indicates that the style has negative impact on some specific Quality
Attributes;
• “--” indicates that very negative impact on a Quality Attributes;
• “o” means no support, neutral or unsure.

58
59