Architectural Styles

An architectural style defines a class of architectures determined by:

  • A set of component types that perform some function
  • A topological layout of the components
  • A set of semantic constraints on the components
  • A set of connectors

An architectural style does not define the number of components involved, often does not define the mechanisms for component interaction and does not define the function of the system…


Independent component architecture

Independent component architecture consists of a number of independent processes/objects communicating via messages. The messages may be passed to named or unnamed participants (the latter established via publish/subscribe paradigms).
The components send data to each other by typically do not control each other. This is good for modifiability as it decouples the components.

Examples: Event systems and communication processes are subsystems of this type.

Event systems

This paradigm decouples component implementation from the knowledge of component names / locations. The publisher/subscriber pattern is used, where:

  • Publisher(s): announce data they wish to share with other components
  • Subscriber(s): register interest in receiving published data.

A message manager is used to manage communication between the components. Publishers send messages to the manager, who redistributes them to subscribers.

Communication process

The Communication Process architecture style is also known as the Client-Server architecture.

  • Client: initiates a call to the server requesting some service.
  • Server: serves data to clients.
    • Returns control along with data if the server works synchronously

Data-centred Architectures

These forms of architectural styles are based on the idea of a central data store which is accessed by clients. There are two types of shared-data in data-centred architectures;

  • Repository; a passive store, typically a database / persistent store.
  • Blackboard; an active store which may send notifications to subscribing clients when changes occur.
    • Advantages of the blackboard type include; client and data-store independence (scalability and modifiability) and data integration in component-based development can be achieved via the blackboard (integrable).

Data flow architectures

These architectures view the system as a series of transformations on successive pieces of data input. Data enters the system and flows through the components until they reach the final destination.

Examples: Batch sequential (each step runs to completion before the next starts) and Pipe-and-filter (incremental transformations of data) are the two implementations of this.

Pipe-and-Filter

In Pipe-and-filter architectures data is incrementally transformed. Very little contextual information is used (filters do not know the identify of other filters) and no state is maintained between transformations. Variants include:

  • Pipelines; the topology is a linear sequence of filters
  • Bounded pipes; there is a restriction placed on the amount of data that can reside on a pipe
  • Typed pipes; restricts the data passed between two filters

There are a number of advantages to pipe-and-filter styles:

  • Understandability; the i/o behaviour of the system can be described as a composition of the behaviours of individual filters
  • Reuse; any combination of filters can be used if they agree on the data-type
  • Maintainability & scalability; additional filters are easily inserted and old ones easily replaced.
  • Analysis; things such as throughput, deadlock detection, etc. are easily monitored
  • Parallelisation; each filter can be a separate process

There are also some disadvantages of pipe-and-filter styles:

  • Interactivity is often hard to implement
  • No way for cooperation between filters
  • Performance can be poor (usually streams are used; these suffer from parsing/unparsing and the fact that a filter cannot proceed until data is provided from the previous one)

Virtual machine architectures

Software 'virtual machines' can execute programs as if they were physical machines. The primary goal here is the achievement of high portability. This is done by simulating functionality not native to the underlying hardware / software (ie: OS's). Can be used to simulate test platforms or dangerous environments.

Examples: Interpreters, rule-based systems, command language processors

Call and return architectures

Call and return architectures are the dominate style in large systems. Typically there are three types of these.

  1. Main-program-subroutine architectures; (ie: "structured programming")
    • Advantages: the functional decomposition is often easy
    • Disadvantages: reuse is restricted to procedures
  2. Remote-procedure call architectures; similar to main-program-subroutine architectures except that the procedure call and procedure return do not need to occur on the same computer.
  3. Object-oriented architectures; implements encapsulation of data and processing, information hiding (well-defined interfaces) and hiearchical sharing (inheritance).
    • Advantages: reusability, modifiability, etc.
    • Disadvantages: discovery of classes/objects is not easy and object granularity is too fine for large systems

Layered architectures

Components are assigned to layers. Inter-component interaction is then controlled at the layer level, whereby each layer communicates only with its neighbours below.
* Advantages: portability, maintainability
* Disadvantages: layer bridging may be required and not all systems fit into the layered style

Three-tier architecture

Three-tiered architecture divides the system into three disparate sections.

  • Presentation
  • Application logic
  • Storage

By dividing the system is this way the application/business logic (control) is separated from the data, and the data is
separated from the way it is displayed. Three-tiered architecture typically appears in the form of the Model/View/Controller pattern.

  • Model is responsible for maintaining domain knowledge
  • View is responsible for displaying information to the user
  • The Controller coordinates events and manages the sequence of interactions with the user.

Heterogeneous architectures

This method combines different architectural styles. There are three kinds of heterogeneity:

  • Locational heterogeneity; where for example, a branch of a main-program-subroutine system might have a shared data repository
  • Hierarchical heterogeneity; where a further decomposition of a component can reveal a different style. For example, a component if further decomposed can show a layered architecture.
  • Simultaneous heterogeneity; where several styles may appropriate explain a structure.

Exploiting Patterns in Software Architecture

Façade patterns in layered architecture

Using layers in a system can help to reduce the overall complexity. To minimise communication and dependencies between layers, an object called the façade object is introduced to provide a single simplified interface to the more general facilities of a layer. This encapsulates a layer's service details and reduces coupling (increases modifiability and reusability).

AbstractFactory pattern

We can decouple a client class from an anticipated change by introducing a level of abstraction. This is good for portability.


Organising architectural styles

Constituent parts

In a architecture style we have:

  • Components; are units of software that perform some function at runtime.
  • Connectors; are mechanisms that mediates communication or coordination among components. They often do not correspond with elements of the running system (ie: RPC, message passing protocols)

Control issues

Control issues describe how control passes among components and how the components work together temporally.

  • Topology: what geometric form does the control flow for the system take? (linear = pipeline, hierarchical = main-program-and-subroutine, star = server system, arbitrary = communicating processes)
  • Synchronicity: how dependent are components' actions upon each others' states

Data issues

These issues are concerned with how data moves around a system.

  • Topology: geometric shape of the system's data-flow diagram
  • Mode: how data is made available throughout the system (passed, shared, broad/multi-cast)
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License