Architectural Styles, Patterns, and Metaphors

What is the difference between an architectural style, an architectural pattern, and a system metaphor? The answer is not much. An architectural style (Bass et al. 1997) and an architectural pattern (Buschmann et al. 1996) are essentially synonymous. A system metaphor is similar but more conceptual than an architecture pattern or an architectural style, and it relates more to a real-world concept than to a software engineering concept. An architectural style and an architectural pattern are similar to a design pattern in that they both describe a solution to a problem in a particular context. The only difference is the granularity at which they describe the solution. In a design pattern, the solution is relatively fine grained and is depicted at the level of language classes. In an architectural pattern, the solution is coarser grained and is described at the level of subsystems or modules and their relationships and collaborations. Each subsystem or module within an architectural pattern consists of many language classes that are designed using design patterns.

Every system needs a central, organizing concept. The conceptual integrity of the system depends on how strong this organizing concept is for the system. So what is an organizing concept? Some examples of architectural styles and patterns (Buschmann et al. 1996) include the following:

1. Model-View-Controller (MVC) architecture pattern. The MVC architectural style is a popular organizing concept for systems. The model represents the data for the system, the view represents the way the data are presented to the user, and the controller handles the logic for the system.

2. Publish-subscribe. The publish-subscribe architecture pattern is a system in which a publisher publishes data on a bus. Subscribers subscribe to portions of the data that are published by publishers on the bus. They register for various topics. When a message appears on the bus that matches the topic in which a subscriber is interested, the bus notifies the subscriber. The subscriber can then read the message from the bus.

3. Pipes and filters. Anyone who is familiar with UNIX systems will recognize this architectural pattern. The pipe and filter pattern allows a system to be assembled from small programs called filters. A filter has an input and an output. The filters are assembled into a chain in which each filter gets data from the previous filter in the chain, processes the data, and passes the data to the next filter in the chain. The best example of a pipe and filter system is a compiler. The lexical analysis, syntax analysis, semantic analysis, intermediate code generation, and optimization occur in a pipe and filter style chain.

4. Layers. A layered system is one in which different layers of the system take care of a specific function of the system. Each layer in a layered architectural style is a package of software that has a well-defined interface and a few well-known dependencies with other layers. Each layer implements one technical function within the application. For example, a data access layer is responsible for encapsulating the technical means for accessing a database. All data access requests to a database go through the data access layer for that database. The data access layer has the responsibility of hiding the data access mechanism from upstream layers. In a closed layer system, a layer may only access adjacent layers. In an open layer system, layers may access any other layer in the system, not just the ones to which they are adjacent.

Many other popular architectural patterns are used to provide a conceptual basis for software architecture. An application can use one or more architectural patterns in its development. Different subsystems can be built using different patterns. Also, the methods for component interaction can follow one pattern, while the internal implementations of the components could use a different pattern.

Architectural patterns are meant for software people to use and understand. One must study the pattern and understand the concept. MVC or pipes and filters have little or no basis in real life. The difference between an architectural pattern and a system metaphor is that a system metaphor is understandable by software people and customers alike. For example, a publish-subscribe pattern is also a system metaphor. In a publish-subscribe system, a publisher provides the data like a newspaper publisher or a book publisher. Each newspaper article or book relates to a particular topic. Consumers subscribe to various topics. When a magazine article or a book in which suscribers are interested comes out, they buy the book or magazine article. As you can imagine, system metaphors are not always pure. Magazine subscribers subscribe to the entire magazine, not just articles within the magazine. In addition, consumers don't subscribe to books, they purchase them. A system metaphor usually starts out with "The system is designed like a. . . ."

Many products and concepts in software development come from metaphors. Following are a few examples:

• Library

• Stack

• Queue

• Desktop

• Account

• Directory

• Window

• Scheduler

• Dispatcher

A system can have many metaphors, but the metaphors have to make sense within the system to maintain its conceptual integrity. For example, Microsoft Windows has a desktop that contains windows. Would it have been better for windows to be placed on a wall? Are windows meant to move around on the wall? By combining multiple metaphors, some aspects of the metaphors must be forgotten and other must be emphasized. With time, the system itself can become a metaphor. We no longer think about the Windows desktop relating to a physical desktop or a window relating to an actual window. Products can become metaphors in themselves. For example, a new system could say that the user interface is like the Windows desktop.