Architectural Styles on CS446/CS646/ECE452 S26

Pipe-Filter

Mon, 01 Jan 0001 00:00:00 +0000

Pipe-Filter #

Pipe-Filter is suitable for applications that require a defined series of (mostly) independent computations to be performed on a stream of data entries.

Topology #

Example component diagram:

Component: Filters
- each filter transforms input data entry/entries to output data entry/entries.
- local transformations: no shared state between filters, and minimal knowledge of upstream/downstream.
- incremental processing: outputs can begin before all inputs are consumed.
Connector: Pipes
- carry data between filters (streams, files, in-memory queues).

Pros and cons #

Pros
- Maintainability: filters can be replaced or improved locally, as long as their input and output formats are stable.
- Efficiency (throughput): supports concurrency naturally by parallelization and stream processing.
- Observability: performing throughput and deadlock analyses is possible.
Cons
- Efficiency (latency): (de)serialization and data copying across pipes can be expensive.
  - variant: using different data formats for each pipe, improves efficiency but adds complexity.
- Complexity: debugging end-to-end behaviors across many stages can be non-trivial.
- Not ideal for interactive systems.

Variants #

Pipeline #

This variant requires a linear sequence of filters (i.e., each filter has exactly one input pipe and one output pipe). An example is the pipe operator | in Unix shells, e.g., the following component diagram shows the command ls | grep '.pdf' | wc -l:

Layered

Mon, 01 Jan 0001 00:00:00 +0000

Layered #

Layered architecture is suitable for applications that can be organized into a hierarchy of layers, where each layer provides services to the layer above and uses services from the layer below.

Topology #

Example component diagram:

Component: Layers
- each layer groups components at similar abstraction level (e.g., UI, domain/business, data/infrastructure).
- a layer usually only depends on layers below it.
Connector: method calls (or RPC) across layer boundaries, typically behind interfaces.
Configuration: a common constraint is that communication happens only between adjacent layers.

Pros and cons #

Pros
- Maintainability: it is often possible to swap implementations within a layer (e.g., replace storage) if contracts are kept; changes in one layer affects at most two adjacent layers.
- Readability: each layer has a consistent abstraction level, making the system easier to understand.
Cons
- Efficiency: abstractions in high-level functions can add overhead; performance requirements may force the coupling of high-level functions to their low-level implementations (breaking the encapsulation of the layers).
- Not all systems map cleanly to layered structures.

Variants #

Allowing non-adjacent layer communication (layer bypass) #

This variant relaxes the adjacent-layer constraint: a higher layer may call a lower layer directly (e.g., UI calling the data layer) to reduce overhead or boilerplate. It can improve efficiency and development speed for simple flows, but it tends to erode boundaries over time and makes testing/refactoring harder.

Repository

Mon, 01 Jan 0001 00:00:00 +0000

Repository #

Repository (a.k.a. data-centered) style is suitable when the central challenge is establishing, augmenting, and maintaining a shared body of information.

Topology #

Example component diagram:

Component:
- Repository: persistent central data store representing the current system state.
- Tools and services: independent components that can read and write the repository, monitor changes, and perform concurrent computations.
Connector: data CRUD operations and change notifications.

An example of this style is a code editor: many features interact through a shared document buffer.

Implicit Invocation

Mon, 01 Jan 0001 00:00:00 +0000

Implicit Invocation #

Implicit invocation is suitable when components producing events/data do not directly know which other components will consume them.

Topology #

Example component diagram:

Component
- Publishers: emit events/messages.
- Subscribers: register interest and react when events arrive.
Connector: Events/messages
- often grouped by topic/channel.
- publishers do not call subscribers directly; the runtime delivery mechanism handles the fan-out to current subscribers.

Pros and cons #

Pros
- Maintainability: add/remove subscribers without changing publishers; supports pluggable components at runtime.
- Scalability: asynchronous delivery and buffering can be scaled up to handle spikes.
Cons
- Readability: hidden dependencies between components and unpredictable ordering/timing of execution.
- Debugging/testing: often needs tracing, structured logging, and careful test harnesses to reason about the execution order.

Variants #

Event-based #

This variant introduces a shared event bus. Components publish events to the bus and subscribe to events from the bus. Compared to direct publish-subscribe, the bus makes routing and buffering explicit.

MVVM (MVC, MVP)

Mon, 01 Jan 0001 00:00:00 +0000

MVVM #

MVVM (Model–View–ViewModel) is a presentation-oriented architectural style commonly used in modern UI applications (including Android). The primary goal is to separate the UI logic (which usually needs to be real-time interactive), UI state, and business logic.

Topology #

Example package/class diagram:

Components
- View: renders UI; listens to user events; reacts to UI state changes.
- ViewModel: holds UI state; redirects user events to business logic; fills data into UI state.
- Model: business logic, network calls, data access, etc.
Connector:
- control flows from View to ViewModel to Model;
- data flows backwards.

Pros and cons #

Pros
- Maintainability: UI logic and business logic are easier to maintain separately.
- Separation of concerns: UI logic and business logic do not mix together; UI elements can have different (usually shorter) lifetimes than the ViewModel and Model classes.
- Reusability: one ViewModel can be shared by multiple Views when needed.
- Testability: ViewModel and Model can be easily unit-tested without rendering UI.
Cons
- Overkill for simple state: the extra abstraction may slow down simple projects.
- Debugging: reactive flows and state propagation can be harder to trace without good tooling.

Variants #

MVC and MVP are older versions of MVVM that aim for similar goals (separation of concerns) but differ in where UI logic/state lives and how tightly the “middle” component is coupled to the view.

Server-Client (Microservices, Serverless)

Mon, 01 Jan 0001 00:00:00 +0000

Server-Client #

Server-client is suitable for applications that involve distributed data and processing across multiple components over a network.

Topology #

Basic component diagram:

Component
- Clients: initiate requests.
- Servers: respond to requests and provide services/data.
Connector:
- request/response (HTTP, REST, RPC) or message-based communication (queues/streams).

Server-client is widely adopted in various applications:

Process-Control

Mon, 01 Jan 0001 00:00:00 +0000

Process-Control #

Process-control (aka feedback-control) style is suitable when the system’s purpose is to maintain certain properties of a process output near a desired reference value (set point), despite disturbances.

Topology #

Example component diagram:

Component
- Controller: computes actions based on the set point and feedback.
- Processor: the (physical or software) component being controlled; it usually comes with some observers/sensors to collect telemetry data as feedback.

Pros and cons #

Pros
- Robustness: can adapt to changing conditions and keep the system within acceptable bounds.
- Autonomy: supports self-correcting behaviors (within designed limits).
Cons
- Cost and complexity: requires monitoring/telemetry, calibration, and control logic.
- Sensitive to latency: delayed or noisy feedback can cause oscillations/instability.

Real-world examples #

Autonomous driving #

Many components in an autonomous driving system are built around the process-control style. Consider steering: given a desired steering angle to follow a trajectory (set point), the system (controller) computes the torque command needed to reach that angle and send it to the vehicle’s steering actuator (processor); a sensor continuously reports the actual angle (feedback) back to the controller, which can be different than the desired angle because of road conditions, so that the controller can adjust the torque command accordingly. The same style applies to other components like throttle and braking.