Pattern language

From Wikipedia, the free encyclopedia

Jump to: navigation, search

A pattern language is a structured method of describing good design practices within a field of expertise. It is characterized by[citation needed]

  1. Noticing and naming the common problems in a field of interest,
  2. Describing the key characteristics of effective solutions for meeting some stated goal,
  3. Helping the designer move from problem to problem in a logical way, and
  4. Allowing for many different paths through the design process.


[edit] Origin

Christopher Alexander, an architect and author, coined the term pattern language. He used it to refer to common problems of civil and architectural design, from how cities should be laid out to where windows should be placed in a room. The idea was initially popularized in his book A Pattern Language.

Alexander's book The Timeless Way of Building describes what he means by pattern language and how it applies to the design and construction of buildings and towns. However, the system has been used in many fields of design, from designing computer programs to designing a classroom curriculum.

[edit] What is a pattern?

When a designer is designing something (whether it is a house or a computer program or a stapler), they must make many decisions about how to solve problems. A single problem, documented with its most common and recognized good solution seen in the wild, is a single design pattern. Each pattern has a name, a descriptive entry, and some cross-references, much like a dictionary entry. A documented pattern must also explain why that solution may be considered a good one for that problem, in the given context.

[edit] Many patterns form a language

Just as words must have grammatical and semantic relationships to each other in order to make a spoken language useful, design patterns must be related to each other in order to form a pattern language. Alexander's work does not specify how these relationships should be organized. However, he implies that the patterns should be organized so that they make intuitive sense to the designer. The actual organizational structure (hierarchical, iterative, etc.) is left to the discretion of the pattern author, depending on the topic. Each pattern should indicate its relationship to other patterns and to the language as a whole. This gives the designer using the patterns some guidance about the order in which problems should be solved.

[edit] Design problems in a context

An important aspect of design patterns is to identify and document the key ideas that make a good system different from a poor system (which may be a house, a computer program or an object of daily use), and to assist in the design of future systems. The idea expressed in a pattern should be general enough to be applied in very different systems within its context, but still specific enough to give constructive guidance.

The range of situations in which the problems and solutions addressed in a pattern apply is called its context. An important part in each pattern is to describe this context. Examples can further illustrate how the pattern applies to very different situation.

For instance, Alexander's pattern "A PLACE TO WAIT" addresses bus stops in the same way as waiting rooms in a surgery, while still proposing helpful and constructive solutions. The "Gang-of-Four" book by Gamma et al proposes solutions that are independent of the programming language, and the program's application domain.

Still, the problems and solutions described in a pattern can vary in their level of abstraction and generality on the one side, and specificity on the other side. In the end this depends on the author's preferences. However, even a very abstract pattern will usually contain examples that are, by nature, absolutely concrete and specific.

Patterns can also vary in how far they are proven in the real world. Alexander gives each pattern a rating by zero, one or two stars, indicating how well they are proven in real-world examples. It is generally claimed that all patterns need at least some existing real-world examples. It is, however, conceivable to document yet unimplemented ideas in a pattern-like format.

The patterns in Alexander's book also vary in their level of scale - some describing how to build a town or neighbourhood, others dealing with individual buildings and the interior of rooms. Alexander sees the low-scale artifacts as constructive elements of the large-scale world, so they can be connected to a hierarchic network.

[edit] Balancing of forces

A pattern must characterize the problems that it is meant to solve, the context or situation where these problems arise, and the conditions under which the proposed solutions can be recommended.

Often these problems arise from a conflict of different interests or "forces". A pattern will then help to balance the forces and finally make a decision.

For instance, there could be a pattern suggesting a wireless telephone. The forces would be the need to communicate, and the need to get other things done at the same time (cooking, inspecting the bookshelf). A very specific pattern would be just "WIRELESS TELEPHONE". More general patterns would be "WIRELESS DEVICE" or "SECONDARY ACTIVITY", suggesting that a secondary activity (such as talking on the phone, or inspecting the pockets of your jeans) should not interfere with other activities.

Though quite unspecific in its context, the forces in the "SECONDARY ACTIVITY" pattern are very similar to those in "WIRELESS TELEPHONE". Thus, the competing forces can be seen as part of the essence of a design concept expressed in a pattern.

[edit] Patterns contain their own rationale

Usually a pattern contains a rationale referring to some given values. For Christopher Alexander, it is most important to think about the people who will come in contact with a piece of architecture. One of his key values is making these people feel more alive. He talks about the "quality without a name" (QWAN).

More generally, we could say that a good system should be accepted, welcomed and happily embraced as an enrichment of daily life by those who are meant to use it, or - even better - by all people it affects. For instance, when discussing a street café, Alexander discusses the possible desires of a guest, but also mentions people who just walk by.

The same thinking can be applied to technical devices such as telephones and cars, to social structures like a team working on a project, or to the user interface of a computer program. The qualities of a software system, for instance, could be rated by observing whether users spend their time enjoying or struggling with the system.

Another possible value is the efficiency of a system, regarding a specific task. Here the happiness of the participants is less important, as long as they do their job. In software engineering, design patterns usually help to create object-oriented code that is easy to read, maintain, modify and reuse.

By focusing on the impacts on human life, we can identify patterns that are independent from changing technology, and thus find "timeless quality" (Alexander).

[edit] Generic structure and layout

Usually the author of a pattern language or collection chooses a generic structure for all the patterns it contains, breaking each into generic sections like context, problem statement, solution etc.

C. Alexander's patterns, for instance, each consist of a short name, a rating (up to two '*' symbols), a sensitizing picture, the context description, the problem statement, a longer part of text with examples and explanations, a solution statement, a sketch and further references. This structure and layout is sometimes referred to as the "Alexandrian form".

Alexander uses a special text layout to mark the different sections of his patterns. For instance, the problem statement and the solution statement are printed in bold font, the latter is always preceded by the "Therefore:" keyword. Some authors instead use explicit labels, which creates some degree of redundancy.

Different forms of structuring can be compared at Sally Fincher's Pattern gallery

[edit] Meaningful names

When design is done by a team, pattern names will form a vocabulary they can share. This makes it necessary for pattern names to be easy to remember and highly descriptive. Some examples from Alexander's works are WINDOW PLACE (helps define where windows should go in a room) and A PLACE TO WAIT (helps define the characteristics of bus stops and hospital waiting rooms, for example).

[edit] Aggregation in an associative network ("pattern language")

A pattern language, as thought by Alexander, contains links from one pattern to another, so when trying to apply one pattern in a project, a designer is pushed to other patterns that are considered helpful in its context.

In Alexander's book, such links are collected in the "references" part, and echoed in the linked pattern's "context" part - thus the overall structure is a directed graph. A pattern that is linked to in the "references" usually addresses a problem of lower scale, that is suggested as a part of the higher-scale problem. For instance, the "PUBLIC OUTDOOR ROOM" pattern has a reference to "STAIR SEATS".

Even without the pattern description, these links, along with meaningful names, carry a message: When building a place outside where people can spend time ("PUBLIC OUTDOOR ROOM"), consider to surround it by stairs where people can sit ("STAIR SEATS"). If you are planning an office ("WORKSHOPS AND OFFICES"), consider to arrange workspaces in small groups ("SMALL WORKING GROUPS"). Alexander argues that the connections in the network can be considered even more meaningful than the text of the patterns themselves.

The links in Alexander's book clearly result in a hierarchic network. Alexander draws a parallel to the hierarchy of a grammar - which is one argument for him to speak of a pattern language.

The idea of linking is generally accepted among pattern authors, though the semantic rationale behind the links may vary. Some authors, however, like Gamma et al in Design Patterns, make only little use of pattern linking - possibly because it did not make that much sense for their collection of patterns. In such a case we would speak of a pattern catalogue rather than a pattern language. [1]

[edit] Usage

Alexander encouraged people who used his system to expand his language with patterns of their own. In order to enable this, his books do not focus strictly on architecture or civil engineering; he also explains the general method of pattern languages. Consequently, his methods have been used to document expertise in diverse fields. Some examples are architectural patterns, computer science patterns, human computer interaction patterns, and educational patterns. Alexander's specifications for using pattern languages as well as creating new ones remain influential, and his books are referenced for style by experts in unrelated fields.

It is important to note that notations such as UML or the flowchart symbol collection are not pattern languages. They could more closely be compared to an alphabet: their symbols could be used to document a pattern language, but they are not a language by themselves. A recipe or other sequential set of steps to be followed, with only one correct path from start to finish, is also not a pattern language. However, the process of designing a new recipe might benefit from the use of a pattern language.

[edit] Simple example of a pattern

Name: ChocolateChipRatio

Context: You are baking chocolate chip cookies in small batches for family and friends

Consider these patterns first: SugarRatio, FlourRatio, EggRatio

Problem: Determine the optimum ratio of chocolate chips to cookie dough

Solution: Observe that most people consider chocolate to be the best part of the chocolate chip cookie. Also observe that too much chocolate may prevent the cookie from holding together, decreasing its appeal. Since you are cooking in small batches, cost is not a consideration. Therefore, use the maximum amount of chocolate chips that results in a sturdy cookie.

Consider next: NutRatio or CookingTime or FreezingMethod

[edit] Application domains

Christopher Alexander's idea has been adopted in other disciplines, often much more heavily than the original application to architecture as depicted the book A Pattern Language. Recent examples include in software engineering and, more generally, to computer science, as well as in interaction designs. Pedagogical patterns are used to document good practices in teaching. Chess strategy and tactics involve many patterns from opening to Checkmate.

[edit] See also

[edit] References

  1. ^ Andy Dearden, Janet Finlay (January 2006). "Pattern Languages in HCI: A critical review". Human Computer Interaction 21 (1). 

[edit] External links

[edit] About patterns in general

[edit] Online pattern collections

Personal tools