Anatomy of a Pattern Language
Parts and links.

A pattern language consists of a cascade or hierarchy of parts, linked together by patterns which solve generic recurring problems associated with the parts. Each pattern has a title and collectively the titles form a language for design.

In a pattern language individual patterns are not isolated. The structure of the language is composed of the links from larger patterns to smaller patterns, together creating a network. Thus, for a single pattern to work fully, it must not only be followed through by implementing the smaller patterns that complete it, it must if at all possible be connected to certain larger patterns.

The links from larger (predecessor) patterns to smaller (successor) patterns in this network define the order in which the patterns should be applied to a design. This is called the Pattern Language sequence, but the sequence is not mechanically linear.

Hierarchy of Parts

Parts can be composed with others to make up larger parts and decomposed into smaller parts, forming a type of system model called a structural hierarchy. For an example of a hierarchy of parts see our Ecopatterns or Cyberpatterns index pages.

A hierarchy of parts is not a formal part of a pattern language, but constructing such a hierarchy is a good way to begin defining a pattern language, as suggested by Alexander and others in some early treatises on the Pattern Language. Many parts are given, especially those of nature, and cannot be changed by design. But the existence of some other parts in a design are themselves patterns, because they help to resolve problematic forces at the interface of other parts, or they respond to a basic human need.

Pattern Components

A pattern is essentially a morphological law, a relationship among parts within a particular context. Specifically, a pattern expresses a relationship among parts that resolves problems that would exist if the relationship were missing. As patterns express these relationships, they are not formulae or algorithms, but rather loose rules of thumb or heuristics.

Some authors who have adopted the idea of a Pattern Language, such as some of those for object-oriented programming in software, have deviated from the format used in A Pattern Language. We also note that patterns are similar to documents used in Structured Planning, often referred to as Problem Elements or design factors. Indeed, these documents may evolve into full-fledged patterns. But without certain critical elements, a collection of patterns fall short of being a pattern language.

As noted above, linkage between patterns is critical for a set of patterns to become a language, rather than a collection of isolated standalone ideas for design. In particular, the predecessor and successor patterns cited at the beginning and end of each pattern make the patterns hang together as a network - as a whole. And each pattern must have successor patterns directly under it, and successor patterns under those in turn, so that together all of the problems that might come up are resolved, thus making the language functionally and morphologically complete.

Here we will stick very close to the anatomy of patterns as published in A Pattern Language by Alexander et al. However, we will also include some elements that existed in early incarnations of the Pattern Language, which we feel are particularly useful in constructing new pattern languages. We will also include some elements we find useful for managing a language under development, and for putting patterns on the World Wide Web.

1. A Title which is used to refer to the pattern. Titles are chosen to fit into the natural discourse of discussions about the design (per linguist Noam Chomsky), hence, a pattern language. On the Web it is advisable to repeat this title within the HTML <title> tag.
   
   
2. A key Visualization which illustrates the pattern. This may be a photo, diagram, sketch or anything else that captures the pattern's essence. Note that this is optional - not all patterns in A Pattern Language have a key visualization - but they help with memory and giving people an image that exemplifies the "goodness" of the pattern.
   
   
3. Parts/Contexts, i.e., a description of one or more parts and contexts to which the Pattern applies. A Pattern Language does not include this element in patterns, but we note that this work publishes the 253 patterns that Alexander et al deemed the most generic, the most universal. Many other patterns exist which apply to specific parts or social, cultural or ecological contexts. For example, the Center For Environmental Structure itself published other patterns for a multi-service center, and for housing in Peru.

   It is our opinion that citing the parts and contexts in which the pattern is relevant is useful for finding those applicable to one's situation, and on-line can be useful in searches.
   

4. Keywords to help determine the application of the pattern. This also is not an element of patterns published in A Pattern Language, but keywords would assist finding patterns that apply to a specific project, especially on-line. For patterns on the Web, we recommend also placing the same keywords inside a META tag for the benefit of search engines.
   
   
5. Predecessor Patterns describe how patterns that apply to larger parts, hence are implemented before this pattern if possible, relate to this pattern. This is the section in A Pattern Language that begins with an ellipsis (. . .) to indicate continuity from the predecessor patterns that refer to this pattern.

   Note that for a given project you may not have the ability to directly implement predecessor patterns. For example, in implementing patterns for a house, one likely has no control over the surrounding urban design. But one should review predecessor patterns nontheless to see how implementing this pattern can help complete them.

   On the Web make the predecessor pattern titles hyperlinks if they are also on the Web.
   

6. The Problem Summary, or headline states the essence of the generic problem. To get at the underlying forces bearing on the problem, the Problem Summary is often stated as a loosely dependent clause using conjunctions like if, because, while, where, unless or when.
   
   
7. The Analysis section contains information describing the context or circumstances in which the problem exists, an explication of the functions and forces involved, and analysis of experiments or other proofs of validity, etc.
   
   
8. The Solution Summary is an imperative statement that begins with Therefore that describes design action that would resolve the forces causing the problem.
   
   
9. Successor Patterns tells what patterns next in the language sequence apply to smaller parts, and are therefore implemented after this pattern to complete it. On the Web make the pattern titles hyperlinks if possible. In A Pattern Language successor patterns are followed by an ellipsis (. . .) to indicate continuity.
   
   
10. References/Sources can be personal observations or experiments as well as bibliographic entries.
    
    
11. Author/Date performs an administrative function in a team effort, and if the date is a revision date, it lets the user know when it has been updated.

    In early versions of the pattern language each pattern included a list of authors together with the statement:

    This pattern is tentative. If you have any evidence to support or refute its current formulation, please send it to the Center for Environmental Structure (address); we will add your comments to the next edition.

    We feel that such a statement is extremely useful for a pattern language that is under development.
    

12. Return to Pattern Index. For patterns on the Web this element provides a link to the master index or table of contents. This provides a navigational aid, supplementing the network of hyperlinks for predecessor and successor patterns.
    
    
13. Copyright Notice. In the spirit of "information should be free", we suggest a copyright notice that gives permission for non-profit academic use, for example:

    © Your Name, 1996. Permission to copy this pattern for non-profit academic use is granted so long as this copyright notice is retained. To copy otherwise requires specific permission.

    We note that early working versions of A Pattern Language encouraged copying in order to promote both the idea of a pattern language, as well as the individual patterns to help improve the environment.