This book is about patterns for software architecture. A pattern for software architecture describes a particular recurring problem that arises in specific design contexts and presents a well proven generic scheme for its solution. The solution scheme is specified by describing its constituent components, their responsibilities and relationships, and the ways in which they collaborate. Patterns span several levels of abstraction- they range from high-level architectural patterns through design patterns to low-level idioms.

Architectural Patterns

An architectural pattern expresses a fundamental structural schema for software systems.  Architectural Patterns can be grouped into four categories
 

From Mud to Structure

Allows controlled decomposition of an overall system task into cooperating subtasks. Example: Layering, Pipes and Filters, Blackboard Architecture.

Layers

The Layers architectural pattern helps to structure applications that can be decomposed into groups of subtasks in which each group of subtasks is at a particular level of abstraction.

Pipes an Filters

The Pipes and Filters architectural pattern provides a structure for systems that process a stream of data. Each processing step is encapsulated in a filter component. Data is passed through the pipes between adjacent filters. Recombining filters allows to build families of related systems.

Blackboard

The Blackboard architectural pattern is useful for problems for which no deterministic solution strategies is known. In Blackboard several specialized subsystems assemble their knowledge to build a possibly partial or approximate solution.

Distributed Systems

Example: Broker pattern provides the complete infrastructure for distributed applications. Micro-kernel and Pipes and Filters are two other patterns referred to by this category.

Broker

It can be used to structure distributed software systems with decoupled components that interact by remote service invocations. A broker component is responsible for coordinating communication, such as forwarding requests as well as for transmitting results and exceptions.

Interactive systems

It features human-computer interaction. Example: MVC, Presentation-Abstractiopn Control Pattern.

Model-View-Controller

It divides an interactive application into three components. The model contains the core functionality and data. Views display information to the user. Controllers handle user input. Views and controllers together forms the user interface. A change propagation mechanism ensures consistency between the user interface and the model.


Presenation-Abstraction-Control

It defines a structure for interactive software systems in the form of a hierarchy of cooperating agents. Every agent is responsible for a specific aspect of the application's functionality and consists of three components: presentation, abstraction and control. This subdivision separates the human computer interaction aspects of the agent from its functional core and its communication with the other agents.

Adaptable systems

They support extension of applications and their adaptation to evolving technology. Example: Reflection and Microkernel pattern.

Microkernel

This pattern applies to software systems that must be able to adapt to changing system requirements. It separates a minimal functional core from extended functionality and customer-specific parts. The micro-kernel also serves as a socket for plugging in these extensions and coordinating their collaboration.

Reflection

This pattern provides a mechanism changing the structure and behavior of software systems dynamically. It supports the modification of fundamental aspects, such as type structures and function call mechanisms. In this pattern, an application is split into two parts. A meta level provides information about selected system properties and makes the software self-aware. A base level includes the application logic. Its implementation builds on the meta level. Changes to information kept in the meta level affect subsequent base-level behavior.

Design Patterns

A design pattern provides a schema for refining the subsystems or components of a software system, or the relationships between them.  The different categories of design patterns are shown below.
 

Structural Decomposition

This includes patterns that support a suitable decomposition of subsystems and complex systems into cooperating parts.

Whole-Part

The Whole-Part design pattern helps with the aggregation of components that together form a semantic unit. An aggregate component, the Whole encapsulates its constituent components, the Parts, organizes their collboration and provides a common interface to its functionality. Direct access to the parts are not possible.

Organization of Work

These patterns define how components collaborate together to solve a complex problem.

Master-Slave

The Master-Slave design pattern supports fault tolerance, parallel computaion and computaional accuracy. A master component distributes work to identical slave components and computes a final result from the results these slaves return.

Access Control

They guard and control access to services or components.

Proxy

The Proxy design pattern makes the clients of a component communicate with a representative rather than to the component itself. Introducing such a place holder can serve many purposes, including enhanced efficiency, easier access and protection from unauthorized access.

Management

These include patterns to handle homogenous collections of objects, services and components in their entirety.

Command Processor

The Command Processor design pattern separates the request for a service from its execution. A command processor component manages requests as separate objects, schedules their execution and provides additional services such as the storing of request objects for later undo.

View Handler

This pattern helps to manage all views that a software system provides. A view handler component allows clients to open, manipulate and dispose of views. It also coordinates dependencies between views and organizes their update.

Communication

Patterns in this category help to organize communication between components.

Forward-Receiver

The Forwarder-Receiver design pattern provides transparent inter-process communication for software systems with a peer-to-peer interaction model. It introduces forwarders and receivers to decouple peers from the underlying communication mechanisms.

Client-Dispatcher-Server

The Client-Dispatcher-Server design pattern introduces an intermediate layer between clients and servers, the dispatcher component. It provides location transparency by means of a name service and hides the details of the establishment of the communication connection between clients and servers.

Publisher-Subscriber

This pattern helps to keep the state of cooperating components synchronized. To achieve this it enables one-way propagation of changes; one publisher notifies any number of subscribers about changes to its state.

Idioms

Low level pattern specific to a programming language. It describes how to implement particular aspects of components or the relationships between them using the features of the given language. Example: Counted Pointer.

Counted Pointer

The Counted Pointer idiom makes memory management of dynamically allocated  shared objects in C++ easier. It introduces a reference counter to a body class that is updated by handle objects. Clients access body class objects only through handles via the overloaded operator->().

Pattern Systems

A pattern system for software architecture is a collection of patterns for software architecture , together with guidelines for their implementation, combination and practical use in software development. Its main objective is to support the development of high quality software systems.  Pattern systems provide an  overview of the patterns it includes by classifying them and thus supports the selection of a pattern by providing an appropriate search strategy.

In short, Patterns fit well with the existing approaches to software architecture by explicitly building on enabling techniques for constructing well defined software systems such as information hiding and the separation of interface and implementation, by stressing the importance of non-functional properties such as changeability and reliability and by complementing existing problem-independent software development processes and methods with guidelines for solving specific recurring design and implementation problems.