ITEC 4101 - L4: Architectural Styles & Patterns

Software architecture

Organization of a system in terms of components, connectors, configurations, and constraints that guide construction and evolution.

Component (architecture)

Unit that packages system functionality (computation, storage, control) as a building block.

Connector (architecture)

Mechanism that enables interaction between components (e.g., calls, messages, streams, shared data access).

Architectural style

Family of system organizations defined by a vocabulary of components/connectors plus topology and semantic constraints.

Style topology

Common structural arrangement describing how components are connected in the style.

Style semantic constraints

Rules that restrict how components and connectors may be combined or behave.

Pure architectural style

Idealized form of a style used for learning; real systems usually mix styles.

Heterogeneous architecture

Architecture that combines multiple styles within one system or across system viewpoints.

Good architecture properties

Guided by consistent principles, resilient to change, reusable engineering knowledge, and supports the system lifecycle.

Data flow style

Architecture where data is transformed as it flows through a sequence/network of processing steps.

Data-flow component

Transformation step that reads inputs, performs computation, and outputs results.

Data-flow connector

Data stream carrying items between transformations, often unidirectional and buffered.

Functional composition model

Computation viewed as composing transformations over streams or sequences of data.

Batch sequential

Data-flow variant where each processing step runs to completion on a batch before the next begins.

Batch sequential connector

Intermediate storage medium between batch steps (historically tape or files).

Batch sequential use case

Periodic processing tasks such as payroll, billing, and end-of-day reports.

Pipes and filters

Data-flow variant where filters process data incrementally and pipes stream data between them.

Filter

Processing element that consumes input stream items and produces output stream items.

Pipe

Connector that transports stream items between filters, often implemented as FIFO buffering.

Incremental processing

Processing items as they arrive rather than waiting for the entire input to be available.

Filter independence

Pipes-and-filters invariant: filters are independent and do not share global state.

Order independence goal

Pipes-and-filters goal: correctness should not depend on the order of filter execution.

Upstream/downstream transparency

Filters ideally do not know the identities of upstream or downstream filters.

Push data flow

Source-driven flow where upstream components push data to downstream components.

Pull data flow

Sink-driven flow where downstream components request/pull data from upstream components.

Push-pull mix

Combining push and pull mechanisms; can increase synchronization complexity.

Passive sink/source

Endpoint that neither actively pushes nor pulls; relies on the other side to drive flow.

Pipes-and-filters strength: reuse

Filters can be reused and recombined when they agree on a data format.

Pipes-and-filters strength: maintenance

Filters can be added, removed, or replaced with limited impact.

Pipes-and-filters strength: analysis

Supports throughput and deadlock analysis due to explicit flow structure.

Pipes-and-filters strength: parallelism

Filters can execute concurrently, improving throughput on multi-core/distributed systems.

Pipes-and-filters weakness: batch degeneration

Often degrades into batch behavior when filters require whole-input context.

Pipes-and-filters weakness: shared data

Global shared state is hard/expensive; style prefers stateless filters.

Pipes-and-filters weakness: incremental design

Designing truly incremental filters can be difficult for some problems.

Pipes-and-filters weakness: interactivity

Poor fit for highly interactive applications requiring rapid bidirectional control.

Pipes-and-filters weakness: error handling

Mid-pipeline failures are hard; recovery often requires restart or complex compensation.

Pipes-and-filters weakness: format constraints

Implementation may force a uniform representation (e.g., text) that can be inefficient.

Call-and-return style

Architecture organized around procedure calls where a caller transfers control to a callee and receives a return.

Main program and subroutines

Call-and-return variant where a central main program calls a hierarchy of subroutines.

Control flow (call-and-return)

Explicit control transfer: caller invokes callee and typically waits for completion.

Procedure call connector

Connector where control and data are passed via parameters and return values.

Data abstraction

Call-and-return variant where components encapsulate data representation and provide operations on it.

Object-oriented style

Architecture where objects/ADTs encapsulate state and behavior; interaction occurs via method calls/messages.

Encapsulation

Hiding internal representation behind an interface to preserve integrity and support change.

OO connector

Interaction via method call or message send between objects.

OO strength: implementation change

Internal implementation can change without affecting clients if the interface remains stable.

OO weakness: identity coupling

Objects often must know each other’s identities/references to interact.

OO weakness: side effects

Behavior can be affected by shared dependencies and indirect interactions across objects.

OO weakness: interaction complexity

Dynamic object collaborations can be difficult to analyze and predict.

Interacting processes style

Architecture where independent processes/components coordinate via events, messages, or shared data.

Implicit invocation

Event-based style where components announce events and registered handlers are invoked automatically.

Event announcement

Publishing an event without naming specific receivers.

Event registration

Subscribing a handler to be invoked when a specific event occurs.

Announcer anonymity

Implicit-invocation invariant: event announcers do not know which components will respond.

Order uncertainty

Implicit-invocation property: handler ordering and timing are not guaranteed unless enforced.

Implicit invocation strength: reuse

New functionality can be added by registering new handlers without changing announcers.

Implicit invocation strength: maintenance

Components can be replaced or modified with minimal impact if event contracts remain stable.

Implicit invocation weakness: loss of control

Announcers cannot predict who runs, in what order, or whether responses complete.

Implicit invocation weakness: context dependence

Correctness can depend on global handler set and interactions, complicating reasoning/testing.

Style combination (events + calls)

Event-based systems often combine implicit invocation with explicit calls for needed control.

Model–View–Controller (MVC)

Architecture separating model (data/logic), view (presentation), and controller (input handling).

Model

MVC element representing core data and business logic.

View

MVC element that presents model state to users (possibly multiple views).

Controller

MVC element that interprets user input and changes the model.

Change propagation

Mechanism (often observer-style) that updates views when the model changes.

MVC benefit

Improves maintainability by separating concerns and supporting multiple views.

Repository style

Architecture centered on a shared data store representing system state, accessed by independent components.

Data-centered architecture

Synonym emphasizing a central data repository that components read/write.

Repository connector

Data access operations such as query, update, and transaction commit/rollback.

Transactional database

Repository variant where the database is passive and processes execute in response to transactions.

Passive repository

Data store that does not trigger computation by itself; clients drive access via requests/transactions.

Blackboard architecture

Repository variant where knowledge sources cooperate via a shared blackboard whose state triggers computation.

Active repository

Repository that can trigger processing based on changes in shared state (blackboard-like behavior).

Knowledge source

Component in blackboard style that contributes partial solutions based on blackboard state.

Blackboard suitability

Useful when no deterministic solution strategy exists and multiple solvers contribute incrementally.

Blackboard example domain

Often used in AI-style problems such as speech or vision, and compiler structures like AST/symbol tables.

Hierarchical styles

Architectural styles organized in levels where higher-level elements use services of lower levels.

Layered system

Architecture with layers of abstraction; each layer provides services to the layer above.

Adjacent-layer rule

Pure layered invariant: a layer communicates only with its immediate neighbors.

Layer interface

Defined services offered by a layer to the layer above through a stable boundary.

Layered strength: abstraction

Partitions complexity by levels, making systems easier to understand and evolve.

Layered strength: maintainability

Changes can be isolated within a layer when interfaces remain stable.

Layered strength: reuse/standardization

Layer implementations can be swapped if they meet the same interface contract.

Layered weakness: performance

Extra overhead from traversing multiple layers; bypassing may occur in practice.

Layer violation (bypass)

Common optimization where a layer accesses a non-adjacent lower layer to reduce overhead.

Onion skin model

Metaphor for layers wrapping lower layers and exposing higher-level services.

OSI model

Seven-layer network reference model illustrating layered architecture concepts.

TCP/IP model

Four-layer networking model (in simplified presentations) illustrating layering in practice.

Operating system layering

Example layering from hardware → kernel → resource management → user services.

Interpreter style

Layered form where a component interprets instructions of a defined language (e.g., bytecode interpreter).

Virtual machine layer

Execution layer that runs an intermediate representation such as bytecode (e.g., JVM).

Tiered architecture

Enterprise layered variant where tiers are often deployed on separate nodes (client/app/db).

Two-tier architecture

Client tier (UI + some processing) communicates directly with a server tier (database + some processing).

Two-tier scalability

Typically scales to roughly around a hundred users in classic enterprise contexts.

Three-tier architecture

Adds a middle tier for business logic and processing management between client and database tiers.

Middle tier role

Holds business rules, coordination, and generic services (e.g., queuing, staging, transaction coordination).

Three-tier benefit

Improves maintainability, scalability, reuse, and flexibility compared to two-tier.

Hierarchical heterogeneous

System uses one style at the top level while internal components use other styles.

Locational heterogeneous

Same-level architecture combines multiple styles across different areas/regions of the system.

Simultaneously heterogeneous

Same system can be described by different styles depending on viewpoint or concern.