7 Architectural Patterns in Embedded Software Design

Architectural patterns are general reusable solutions to common problems in software architecture within a given context.

A pattern is a solution to a problem in a specific context.

However, many developers still struggle to understand the differences between various software architectural patterns, and some know very little about them.

Generally, there are seven main architectural patterns:

Layered Architecture
Multi-layer Architecture
Pipe/Filter Architecture
Client/Server Architecture
Model/View/Controller Architecture
Event-Driven Architecture
Microservices Architecture

1Layered Architecture Pattern

The most common architectural pattern is the layered architecture, also known as n-tier architecture.

Most software architects, designers, and developers are very familiar with this architectural pattern. Although there are no specific limits on the number and type of layers, most layered architectures consist of four layers: presentation layer, business layer, persistence layer, and database layer, as shown in the following diagram.

7 Architectural Patterns in Embedded Software Design

A popular n-tier architecture example

1 Context

All complex systems will experience the need for independent development and evolution of various parts of the system. For this reason, system developers need to clearly and logically separate concerns so that the various modules of the system can be developed and maintained independently.

2 Problem

Software needs to be divided in such a way that each module can be developed and evolved independently, with minimal interaction between parts, supporting portability, modifiability, and reusability.

3 Solution

To achieve separation of concerns, the layered pattern divides the software into units (called “layers”). Each layer is a set of modules that provides a set of highly cohesive services. Its use must be one-way. Layers partition a set of software as a complete unit, with each unit exposing a public interface.

The first concept is that each layer has specific roles and responsibilities. For example, the presentation layer is responsible for handling all user interfaces. This separation of concerns in layered architecture makes it very simple to build efficient roles and responsibilities.
The second concept is that the layered architecture pattern is a technical partitioning architecture rather than a domain partitioning architecture. They are composed of components, not domains.
The last concept is that each layer in the layered architecture is marked as closed or open. A closed layer means that requests moving from one layer to another must go through the layer directly beneath it to reach the next layer. Requests cannot skip any layers.

Closed layers and request access

4 Weaknesses

Layering can lead to performance degradation. This pattern is not suitable for high-performance applications because the efficiency of implementing a business request through multiple layers in the architecture is not high.

Layering also increases the upfront costs and complexity of the system.

5 Uses

We should apply this approach to small, simple applications or websites. It is a good choice for scenarios with tight budgets and time constraints.

2Multi-layer Pattern

1 Solution

An example of a multi-layer pattern: Consumer website J2EE

Many systems’ execution structures are organized into a series of logical component groups. Each group is called a layer.

1 Context

In a distributed deployment, it is often necessary to distribute the system’s infrastructure across different subsets.

2 Problem

How do we divide the system into multiple independently executing structures: software and hardware groups connected by some communication medium?

3 Weaknesses

High upfront costs and complexity.

4 Uses

Used in distributed systems.

3Pipe and Filter Architecture

A pattern that frequently appears in software architecture is the pipe-filter pattern.

Pipe-filter pattern

1 Context

Many systems need to transform discrete data flows from input to output. Many types of transformations frequently occur in practice, so it’s ideal to create them as independent reusable parts.

2 Problem

These systems need to be divided into reusable loosely-coupled components that have simple, common interaction mechanisms. This allows them to flexibly combine with each other. These common loosely-coupled components are easy to reuse. Those independent components can execute in parallel.

3 Solution

In this architecture, pipes constitute the communication channels between filters. The first concept is that, for performance reasons, each pipe is non-directional and point-to-point, accepting input from one source and often directly outputting to another source.

In this pattern, there are four types of filters.

producer (source): the starting point of a process.
transformer (map): transforms some or all data.
tester (reduce): tests one or more conditions.
consumer (sink): the endpoint.

4 Weaknesses

Not well-suited for interactive systems because of their transformation nature.

Excessive parsing and unparsing can lead to performance loss and increase the complexity of writing the filters themselves.

5 Uses

The pipe-filter architecture is used in various applications, especially for simplifying one-way processing tasks, such as EDI and ETL tools.

Compilers: consecutive filters perform lexical analysis, syntax analysis, semantic analysis, and code generation.

4Client-Filter Architecture

1 Context

There are many shared resources and services that a large number of distributed clients want to access, and we want to control access or service quality.

2 Problem

By managing a set of shared resources and services, we can improve modifiability and reusability by decomposing common services and modifying them in a single location or a few locations. We want to improve scalability and availability by centralizing control over these resources and services while distributing the resources themselves across multiple physical servers.

3 Solution

In the client-server pattern, the components and connectors have specific behaviors.

The component called “client” sends requests to the component called “server” and then waits for a reply.

The server component receives the client’s request and sends a reply.

4 Weaknesses

The server can become a performance bottleneck and a single point of failure.

After the system is built, decisions about functional locations (whether on the client or server) are often complex and costly to change.

5 Uses

For systems with many components (clients) sending requests to other components (servers) providing services, we can use the client-server pattern to model part of this system: online applications, such as email, shared documents, or banking services.

5Model-View-Controller Architecture (MVC)

1 Context

The user interface is often the most frequently modified part of an interactive application. Users often want to view data from different perspectives, such as bar charts or pie charts. These representations should reflect the current state of the data.

2 Problem

How can user interface functionality be independent of application functionality while still responding to user input or changes in underlying application data?

When underlying application data changes, how can multiple views of the user interface be created, maintained, and coordinated?

3 Solution

The Model-View-Controller (MVC) pattern divides application functionality into three types of components:

Model, which contains the application data.
View, which displays part of the underlying data and interacts with the user.
Controller, which mediates between the model and the view and manages notifications of state changes.

4 Weaknesses

For simple user interfaces, the complexity may not be worth it.

The model, view, and controller abstractions may not apply to certain user interface toolkits.

5 Uses

MVC is a commonly used architectural pattern for developing user interfaces for websites or mobile applications.

6Event-Driven Architecture

1 Context

It is necessary to provide computing and information resources to process incoming application-generated independent asynchronous events, which can scale with increasing demand.

2 Problem

Building distributed systems that can serve asynchronously arriving event-related information and can scale from simple small systems to complex large ones.

3 Solution

Deploy independent event processes or handlers for event processing. Incoming events enter a queue. The scheduler pulls events from the queue according to the scheduling policy and assigns them to the appropriate event handlers.

4 Weaknesses

Performance and error recovery may be issues.

5 Uses

In e-commerce applications using this pattern, the workflow would be as follows:

Order Service creates an Order, which is in a pending state, and then publishes anOrderCreatedevent.

Customer Service receives this event and attempts to charge credit for this Order. It then publishes a Credit Reserved event orCreditLimitExceeded (exceeded credit limit) event.
Order Service receives the event sent by Customer Service and changes the order status to approved or canceled.

7Microservices Architecture

1 Context

Deploy server-based enterprise applications that support various browsers and native mobile clients. The application processes client requests by executing business logic, accessing databases, exchanging information with other systems, and returning responses. This application may expose a third-party API.

2 Problem

Integrated applications can become too large and complex to effectively support and deploy for optimal distributed resource utilization, such as in cloud environments.

3 Solution

Build the application as a suite of services. Each service is independently deployable and scalable, with its own API boundaries. Different services can be written in different programming languages, manage their own databases, and be developed by different teams.

4 Weaknesses

The system design must be tolerant of service failures and requires more system monitoring. Service orchestration and event collaboration overhead can be significant.

Of course, we also need more money.

5 Uses

Many use cases can apply microservices architecture, especially those involving a large number of data pipelines. For example, a microservices system for reporting sales of a company’s retail stores would be ideal. Each step of the data presentation process would be handled by a microservice: data collection, cleaning, normalization, aggregation, reporting, etc.

Source: Internet, copyright belongs to the original author. If there is any infringement, please contact to delete.

END

Scan to join the embedded WeChat group

▼

Previous Highlights

▼

Are embedded systems and microcontrollers the same thing?

Common uses of precompiled directives in embedded software

Embedded communication protocol transmission, surprisingly simple?

Essential drawing tools for embedded development

How can embedded devices display IP locality?

Leave a Comment Cancel reply