New Brief 8/13/97, 2:12:20PM by NetAttaché Light

Introducing Patterns!

One of the first things that any science or engineering discipline must have is a vocabulary for expressing its concepts and a language for relating them together. The goal of patterns within the software community is to create a body of literature to help software developers resolve common difficult problems encountered throughout all of software engineering and development. Patterns help create a shared language for communicating insight and experience about these problems and their solutions. Formally codifying these solutions and their relationships lets us successfully capture the body of knowledge which comprises our understanding of good architectures that meet the needs of their users. Forming a common pattern language for conveying the structures and mechanisms of our architectures allows us to intelligibly reason about them. The primary focus is not so much on technology as it is on creating a culture to document and support sound engineering architecture and design.

Pattern Origins

The current use of the term "pattern" is derived from the writings of the architect Christopher Alexander who has written several books on the topic as it relates to urban planning and building architecture:

• Notes on the Synthesis of Form, Harvard University Press, 1964
  (hereafter referred to as "[Notes]")
• The Oregon Experiment, Oxford University Press, 1975
  (hereafter referred to as "[Oregon]")
• A Pattern Language: Towns, Buildings, Construction, Oxford University Press, 1977
  (hereafter referred to as "[APL]")
• The Timeless Way of Building, Oxford University Press, 1979
  (hereafter referred to as "[TTWoB]")

Although these books are ostensibly about architecture and urban planning, they are applicable to many other disciplines, including software development. In [Notes], Alexander argues that current architectural methods result in products that fail to meet the real demands and requirements of its users, society and its individuals, and are unsuccessful in fulfilling the quintessential purpose of all design and engineering endeavors: to improve the human condition. Alexander wanted to create structures that are good for people and have a positive influence on them by improving their comfort and their quality of life. He concluded that architects must constantly strive to produce work products that better fit and adapt to the needs of all their inhabitants and users and their respective communities. In [APL] Alexander describes some timeless design ideas to try and realize these goals. In [TTWoB] Alexander proposes a paradigm for architecture based on three concepts: the quality, the gate, and the way:

The Quality (a.k.a. "the Quality Without a Name")

This is the essence of all things living and useful that imparts unto them qualities such as: freedom, wholeness, completeness, comfort, harmony, habitability, durability, openness, resilience, variability, and adaptability. It is what makes us feel "alive" and "sated", gives us satisfaction, and ultimately improves the human condition.

The Gate

This is the mechanism that allows us to reach the quality. It is manifested as a living common pattern language that permits us to create multiform designs which fulfill multifaceted needs. It is the universal "ether" of patterns and their relationships that permeate a given domain. The gate is the conduit to the quality.

The Way (a.k.a. "the Timeless Way")

Using the way, patterns from the gate are applied using a technique of differentiating space in an ordered sequence of piecemeal growth: progressively evolving an initial architecture, which then flourishes into a "live" design possessing the quality. Alexander likens it to "a process of unfolding, like the evolution of an embryo, in which the whole precedes its parts, and actually gives birth to them, by splitting." ([TTWoB] p. 365). By following the way, one may pass through the gate to reach the quality.

A Bit of Patterns History

In 1987, Ward Cunningham and Kent Beck were working with Smalltalk and designing user interfaces. They decided to use some of Alexander's ideas to develop a small five pattern language for guiding novice Smalltalk programmers. They wrote up the results and presented them at OOPSLA'87 in Orlando in the paper "Using Pattern Languages for Object-Oriented Programs".

Soon afterward, Jim Coplien (more affectionately referred to as "Cope") had begun compiling a catalog of C++ idioms (which are one kind of pattern) and later published them as a book in 1991, Advanced C++ Programming Styles and Idioms.

From 1990 to 1992, various members of the Gang of Four had met one another and had done some work compiling a catalog of patterns. Discussions of patterns abounded at OOPSLA'91 at a workshop given by Bruce Andersen (which was repeated in 1992). Many pattern notables participated in these workshops, including Jim Coplien, Doug Lea, Desmond D'Souza, Norm Kerth, Wolfgang Pree, and others.

In August 1993, Kent Beck and Grady Booch sponsored a mountain retreat in Colorado, the first meeting of what is now known as the Hillside Group. Another patterns workshop was held at OOPSLA'93 and then in April of 1994, the Hillside Group met again (this time with Richard Gabriel added to the fold) to plan the first PLoP conference.

Shortly thereafter, the GoF book was published, and the rest, is history.

What is a pattern anyway?

Each pattern is a three-part rule, which expresses a relation between a certain context, a certain system of forces which occurs repeatedly in that context, and a certain software configuration which allows these forces to resolve themselves.

Alexander describes it a bit more colorfully in [TTWoB]:

Each pattern is a three-part rule, which expresses a relation between a certain context, a problem, and a solution. The pattern is, in short, at the same time a thing, which happens in the world, and the rule which tells us how to create that thing, and when we must create it. It is both a process and a thing; both a description of a thing which is alive, and a description of the process which will generate that thing. (p. 247)

In Software Patterns, esteemed pattern laureate Jim Coplien writes:

I like to relate this definition to dress patterns. I could tell you how to make a dress by specifying the route of a scissors through a piece of cloth in terms of angles and lengths of cut. Or, I could give you a pattern. Reading the specification, you would have no idea what was being built or if you had built the right thing when you were finished. The pattern foreshadows the product: it is the rule for making the thing, but it is also, in many respects, the thing itself.

So we see that a pattern involves a general description of a recurring solution to a recurring problem replete with various goals and constraints. But a pattern does more than just identify a solution, it also explains why the solution is needed! For better or for worse however, the meteoric rise in popularity of software patterns has caused them to be frequently overhyped. Patterns have achieved buzzword status: It is immensely popular to use the word "pattern" in order to garner an audience. However, not every solution, algorithm, best practice, maxim, or heuristic constitutes a pattern (one or more key pattern ingredients may be absent). Even if something appears to have all the requisite pattern components, it should not be considered a pattern until it has been verified to be a recurring phenomenon (preferably in at least three existing systems -- this is often called the rule of three). A "pattern in waiting" that is not yet known to recur is sometimes called a proto-pattern. Many also feel it is inappropriate to decisively call something a pattern until it has undergone some degree of scrutiny or review by others.

To quote Cope once again (this time from the Patterns Definitions page), a good pattern will do the following:

• It solves a problem: Patterns capture solutions, not just abstract principles or strategies.
• It is a proven concept: Patterns capture solutions with a track record, not theories or speculation.
• The solution isn't obvious: Many problem-solving techniques (such as software design paradigms or methods) try to derive solutions from first principles. The best patterns generate a solution to a problem indirectly -- a necessary approach for the most difficult problems of design.
• It describes a relationship: Patterns don't just describe modules, but describe deeper system structures and mechanisms.
• The pattern has a significant human component .... All software serves human comfort or quality of life; the best patterns explicitly appeal to aesthetics and utility.

Many examples of software patterns may be found on-line at the Portland Pattern Repository and at the Patterns Home Page. (If you've never seen a software pattern before, you really should take a moment here to look at a few of them before trying to read too much more of this document.)

Generative Patterns

These patterns in our minds are, more or less, mental images of the patterns in the world: they are abstract representations of the very morphological rules which define the patterns in the world. However, in one respect they are very different. The patterns in the world merely exist. But the same patterns in our minds are dynamic. They have force. They are generative. They tell us what to do; they tell us how we shall, or may, generate them; and they tell us too, that under certain circumstances, we must create them. Each pattern is a rule which describes what you have to do to generate the entity which it defines. (pp. 181-182)

Generative patterns are active and dynamic: they tell us how to create something and can be observed in the resulting system architectures they helped shape. Non-generative patterns are static and passive: they describe recurring phenomena without necessarily saying how to reproduce them. We should strive to document generative patterns because they not only show us the characteristics of good systems, they teach us how to build them!

For Alexander, however, the "instructive" element is only one facet of what he calls generativity. He wants patterns, and especially pattern languages, to be capable of generating whole, living structures. Part of the desire to create architectures that emulate life lies in the remarkably unique ability of living things to evolve and adapt to their ever-changing environments (not only for the sake of individual survival, but also for survival of the species). Alexander wants to impart these same qualities into his architectures. Similarly, in software, good software architectures are all about being adaptable and resilient to change. So another aspect of generativity is about striving to create "living" architectures which are capable of dynamically adapting to fulfill changing needs and demands.

But there is still more to "generativity" than teaching and adaptability. The successive application of several patterns, each encapsulating its own problem and forces, unfolds a larger solution which emerges indirectly as a result of the smaller solutions. It is the generation of such emergent behavior that appears to be what is meant by generativity. In this fashion, a pattern language should guide its users to generate whole architectures which possess the quality. This particular aspect of Alexander's paradigm seems a bit too mystical for some people's tastes.

Anti-Patterns

1. Those that describe a bad solution to a problem which resulted in a bad situation.
2. Those that describe how to get out of a bad situation and how to proceed from there to a good solution.

The study of anti-patterns is an important research activity. The presence of "good" patterns in a successful system is not enough; you also must show that those patterns are absent in unsuccessful systems. Likewise, it is useful to show the presence of certain patterns (anti-patterns) in unsuccessful systems, and their absence in successful systems.

Kinds of Patterns

Design Patterns and Frameworks

The difference between a framework and an ordinary programming library is that a framework employs an inverted flow of control between itself and its clients. When using a framework, one usually just implements a few callback functions or specializes a few classes, and then invokes a single method or procedure. At this point, the framework does the rest of the work for you, invoking any necessary client callbacks or methods at the appropriate time and place. For this reason, frameworks are often said to abide by the Hollywood Principle ("Don't call us, we'll call you.") or the Greyhound Principle ("Leave the driving to us.").

Design patterns may be employed both in the design and the documentation of a framework. A single framework typically encompasses several design patterns. In fact, a framework can be viewed as the implementation of a system of design patterns. Despite the fact that they are related in this manner, it is important to recognize that frameworks and design patterns are two distinctly separate beasts: a framework is executable software, whereas design patterns represent knowledge and experience about software. In this respect, frameworks are of a physical nature, while patterns are of a logical nature: frameworks are the physical realization of one or more software pattern solutions; patterns are the instructions for how to implement those solutions.

Kinds of Design Patterns

Architectural Patterns

An architectural pattern expresses a fundamental structural organization schema for software systems. It provides a set of predefined subsystems, specifies their responsibilities, and includes rules and guidelines for organizing the relationships between them.

Design Patterns

A design pattern provides a scheme for refining the subsystems or components of a software system, or the relationships between them. It describes commonly recurring structure of communicating components that solves a general design problem within a particular context.

Idioms

An idiom is a low-level pattern specific to a programming language. An idiom describes how to implement particular aspects of components or the relationships between them using the features of the given language.

The difference between these three kinds of patterns are in their corresponding levels of abstraction and detail. Architectural patterns are high-level strategic patterns that concern large-scale components and the global properties and mechanisms of a system. They have wide-sweeping implications which effect the overall skeletal structure and organization of a software system. Design patterns are medium-scale tactical patterns that flesh out some of the structure and behavior of entities and their relationships. They do not influence overall system structure, but instead define micro-architectures of subsystems and components. Idioms are paradigm and language-specific programming techniques that fill in low-level internal or external details of a component's structure or behavior.

Components of a Pattern

Name

It must have a meaningful name. This allows us to use a single word or short phrase to refer to the pattern, and the knowledge and structure it describes. It would be very unwieldy to have to describe or even summarize the pattern every time we used it in a discussion. Good pattern names form a vocabulary for discussing conceptual abstractions. Sometimes a pattern may have more than one commonly used or recognizable name in the literature. In this case it is common practice to document these nicknames or synonyms under the heading of Aliases or Also Known As. Some pattern forms also provide a classification of the pattern in addition to its name.

Problem

A statement of the problem which describes its intent: the goals and objectives it wants to reach within the given context and forces. Often the forces oppose these objectives as well as each other (one might think of this as a "wicked problem" reminiscent of DeGrace and Stahl, in their book Wicked Problems, Righteous Solutions).

Context

The preconditions under which the problem and its solution seem to recur, and for which the solution is desirable. This tells us the pattern's applicability. It can be thought of as the initial configuration of the system before the pattern is applied to it.

Forces

A description of the relevant forces and constraints and how they interact/conflict with one another and with goals we wish to achieve (perhaps with some indication of their priorities). Forces reveal the intricacies of a problem and define the kinds of trade-offs that must be considered in the presence of the tension or dissonance they create. A good pattern description should fully encapsulate all the forces which have an impact upon it. A list of prospective pattern forces for software may be found in the answer to question 11 of Doug Lea's Patterns-Discussion FAQ.

Solution

Static relationships and dynamic rules describing how to realize the desired outcome. This is often equivalent to giving instructions which describe how to construct the necessary work products. The description may encompass pictures, diagrams and prose which identify the pattern's structure, its participants, and their collaborations, to show how the problem is solved. A concrete scenario which serves as the motivation for the pattern is frequently employed (see also Examples). The solution should describe not only static structure but also dynamic behavior. The static structure tells us the form and organization of the pattern, but often it is the behavioral dynamics that make the pattern "come alive". The description of the pattern's solution may indicate guidelines as well as traps and pitfalls to be wary of when attempting a concrete implementation of the solution. Sometimes possible variants or specializations of the solution are also described.

Examples

One or more sample applications of the pattern which illustrate a specific initial context, how the pattern is applied to and transforms that context, and the resulting context left in its wake. Examples help the reader understand the pattern's use and applicability. Visual examples and analogies can often be especially illuminating. An example may be supplemented by a sample implementation to show one way the solution might be realized. Easy-to-comprehend examples from known systems are usually preferred (see also Known Uses).

Resulting Context

The state or configuration of the system after the pattern has been applied, including the consequences of applying the pattern, and other problems and patterns that may arise from the new context. It describes the postconditions and side-effects of the pattern. This is sometimes called resolution of forces because it describes which forces have been resolved, which ones remain unresolved, and which patterns may now be applicable (see the answer to question 12 of Doug Lea's Patterns-Discussion FAQ for an excellent discussion of resolution of forces). Documenting the resulting context produced by one pattern helps you correlate it with the initial context of other patterns (a single pattern is often just one step towards accomplishing some larger task or project).

Rationale

A justifying explanation of steps or rules in the pattern, and also of the pattern as a whole in terms of how and why it resolves its forces in a particular way to be in alignment with desired goals, principles, and philosophies. It explains how the forces and constraints are orchestrated in concert to achieve a resonant harmony. This tells us how the pattern actually works, why it works, and why it is "good". The solution component of a pattern may describe the outwardly visible structure and behavior of the pattern, but the rationale is what provides insight into the deep structures and key mechanisms that that are going on beneath the surface of the system.

Relationships

The static and dynamic relationships between this pattern and others within the same pattern language or system. Related patterns often share common forces. They also frequently have an initial or resulting context that is compatible with the resulting or initial context of another pattern. Such patterns might be predecessor patterns whose application leads to this pattern; successor patterns whose application follows from this pattern; alternative patterns that describe a different solution to the same problem but under different forces and constraints; and codependent patterns that may (or must) be applied simultaneously with this pattern.

Known Uses

Describes known occurrences of the pattern and its application within existing systems. This helps validate a pattern by verifying that it is indeed a proven solution to a recurring problem. Known uses of the pattern can often serve as instructional examples (see also Examples).

Although it is not strictly required, good patterns often begin with an Abstract that provides a short summary or overview. This gives readers a clear picture of the pattern and quickly informs them of its relevance to any problems they may wish to solve. A pattern should identify its target audience and make clear what it assumes of the reader.

Patterns, Rules, and Creativity

Rules aren't commonly supported by a rationale, nor put in context. A rule may be part of the solution in a pattern description, but a rule solution is neither sufficient nor necessary. Patterns aren't designed to be executed or analyzed by computers, as one might imagine to be true for rules: patterns are to be executed by architects with insight, taste, experience, and a sense of aesthetics.

A pattern is the process that generates a solution, but it may generate any one of a vast number of variant solutions (conceivably without repeating the same solution twice). The human element of patterns is what chiefly contributes to their variability and adaptability, and usually requires a greater degree of creativity in their application and combination. So, just as the processes of architecture and design are creative endeavors, so too is the application of patterns. In the same paper quoted above, Cope goes on to say:

If design is codified in patterns, does the need for creativity go away? Can we replace high-priced expensive designers with less sophisticated programmers who are guided by patterns? The answer is that creativity is still needed to shape the patterns to a given context. Just as a dressmaker tailors a pattern to an individual customer, and perhaps to a specific event where the dress is to be worn, so designers must be creative when using patterns. Patterns channel creativity; they neither replace nor constrain it.

Patterns and Algorithms

Of course software developers need to be concerned both with finding appropriate architectures and with finding appropriate solutions to computational problems. So there will always be a need for patterns as well as for algorithms and data structures (and their use together).

Qualities of a Pattern

Encapsulation and Abstraction

Each pattern encapsulates a well-defined problem and its solution in a particular domain. Patterns should provide crisp, clear boundaries that help crystallize both the problem space and the solution space into a lattice of intertwined, recognizable chunks. They also serve as abstractions which embody domain knowledge and experience, and may occur at varying hierarchical levels of abstraction and granularity within the domain.

Openness and Variability

Each pattern should be open for extension or parametrization by other patterns so that they may work together to solve a larger problem. A pattern solution should be also capable of being realized by an infinite variety of implementations (in isolation, as well as in conjunction with other patterns).

Generativity and Composability

Each pattern, once applied, generates a resulting context which matches the initial context of one or more other patterns in a pattern language. These subsequent patterns may then be applied to progress further toward the final goal to generate a "whole" or complete overall solution. "Patterns are applied by the means of piecemeal growth. Applying one pattern provides a context for the application of the next pattern." (from the PLoP'97 Call for Papers) But patterns are not simply linear in nature, more like fractals in that patterns at a particular level of abstraction and granularity may each lead to or be composed with other patterns at varying levels of scale.

Equilibrium

Each pattern must realize some kind of balance among its forces and constraints. This may be due to one or more invariants or heuristics that are used to minimize conflict within the solution space. The invariants often typify an underlying problem solving principle or philosophy for the particular domain, and provide a rationale for each step/rule in the pattern.

The aim is that, if well written, each pattern describes a whole that is greater than the sum of its parts, due to skillful choreography of its elements working together to meets all its varying demands.

The Quality Without a Name

• universally recognizable aesthetic beauty and order
• recursively nested centers of symmetry and balance
• life and wholeness
• resilience, adaptability, and durability
• human comfort and satisfaction
• emotional and cognitive resonance

Alexander proposes the existence of an objective quality of aesthetic beauty that is universally recognizable. He claims there are certain timeless attributes and properties which are considered beautiful and aesthetically pleasing to all people in all cultures (not just "in the eye of the beholder"). It is these fundamental properties which combine to generate the QWAN, and which make a structure feel "whole" and "alive".

Alexander conducted some experiments and research using configurations of colored beads, and also using the design of carpets and tapestries. Those results, combined with his own architectural experience with the users of his buildings, suggested the presence of this "objective beauty" was closely tied to the presence of symmetries and subsymmetries that balance the use of contrasting space, light, and color to form fields of visual centers. Feelings of beauty and order would increase when these visual centers unfolded recursively at multiple hierarchical levels of granular scale throughout a design (much like fractals). However, if the symmetries are too pure (too perfect or exact), it seems to be less desirable than if slight irregularities and imperfections exist. Apparently some imperfections are not only palatable, but can also be utilitarian (just as doped imperfections in precious stones can actually enhance their crystalline structure).

In The Laws of Architecture from a Physicist's Perspective, artist and mathematician Nikos A. Salingaros (who has worked closely with Alexander over the past ten years) discusses the rules of beauty and order in past times and proposes three corresponding laws of architecture:

1. Order on the smallest scale is established by paired contrasting elements, existing in a balanced visual tension.
2. Large-scale order occurs when every element relates to every other element at a distance in a way that reduces entropy.
3. The small scale is connected to the large scale through a linked hierarchy of intermediate scales with scaling factor approximately equal to e = 2.718.

Salingaros goes on to say that these laws don't govern beauty in architecture, they govern life in architecture: "They are extracted from physics and mathematics by looking at how nature is put together. I discovered these laws by observing how fundamental particles come together to form a structure." He says that when structures conform to these architectural laws, those who enter them feel a kind of resonant harmony, an almost emotional connection to the structure which feels peaceful and nourishing. This connection between life and architecture is due to the thermodynamics of living forms, but the idea of building structures which possess these intrinsic qualities of living biological organisms comes from Alexander. In Reengineering the Application Development Process, Michael Beedle tries to succinctly describe the QWAN as something that:

is created when the attributes in the design makes that design "live". That is, designs that are flexible, extensible, adaptable, reusable and have other qualities of living things; except of course self-reproduction and metabolism.

According to this definition, the QWAN is attained when the pattern or pattern language generates a "live" architectural solution; one which emulates the capability of living things to dynamically adapt to fulfill changing needs and demands. This is closely related to Alexander's idea of generativity. In "Christopher Alexander: an Introduction for Object-Oriented Designers" , Doug Lea attempts to describe the QWAN as follows:

... "the quality without a name", the possession of which is the ultimate goal of any design product. It is impossible to briefly summarize this. Alexander presents a number of partial synonyms: freedom, life, wholeness, comfortability, harmony, But no single term or example fully conveys meaning or captures the force of Alexander's writings on the reader, especially surrounding the human impact of design, the feelings and aesthetics of designers and users, the need for commitment by developers to obtain and preserve wholeness, and its basis in the objective equilibrium of form.

So another crucial aspect of the QWAN is the effect it has upon the architecture's inhabitants and designers that makes them feel alive, whole, and comfortable. It is this kind of "habitability" that improves user comfort and quality of life (what TQM circles might refer to as "total customer satisfaction", and what Tom Peters means by "to thrill and delight" the customer in the pursuit of "Wow!").

Of course this "ultimate goal" of achieving the QWAN is very elusive. This particular aspect of patterns seems to borrow concepts from Zen Buddhism, Taoism, and Platonic ideals. There are those who feel the whole idea of the QWAN is just a bit too whimsical and metaphysical; that it is not scientific or tangible enough to have a place in true engineering disciplines (especially if it is something that cannot be measured or quantified). The notion of a universal, objective feeling of beauty can be a trifle hard for some to swallow.

But in many respects, an individual's sense of the QWAN is also about cognitive judgement. Every master designer develops their own highly honed intuition which is borne from extensive experience. Although this "intuition" may be subjective, it can be uncannily accurate and give the designer an almost instinctive sense of what will work and what wont (even before the measures are brought to bear to try and verify it). This stems from the designer being intimate with the design and internalizing it at a visceral level, almost to the point of becoming an inhabitant whose sensory network is "plugged-in" to the system. If a pattern can impart to its readers and users, this same "plugged-in" feeling of being connected to the design and deeply comprehending it, then in theory it will impart to the reader the same cognitive feeling of its aptness that the designer experienced. If a pattern succeeds in this attempt, then all who see and use it should experience the resonant feeling of beauty and harmony that the QWAN is supposed to evoke.

Pattern Languages

Good pattern languages guide the designer toward useful architectures and away from architectures whose literary analogies are gibberish or unartful writing. Good architectures are durable, functional, and aesthetically pleasing, and a good combination of patterns can balance the forces on a system to strive towards these three goals. A good pattern language gives designers freedom to express themselves and to tailor the solution to the particular needs of the context where the patterns are applied.

Unlike a mere pattern compilation or catalog, a pattern language includes rules and guidelines which explain how and when to apply its patterns to solve a problem which is larger than any individual pattern can solve. These rules and guidelines suggest the order and granularity for applying each pattern in the language. A pattern language may be regarded as a lexicon of patterns plus a grammar that defines how to weave them together into valid sentences (or artful tapestries if you will). Ideally, good pattern languages are generative, capable of generating all the possible sentences from a rich and expressive pattern vocabulary.

A pattern language forms a gestalt in which each of its patterns collaborate to solve a more fundamental problem that is not explicitly addressed by any individual pattern. This helps a pattern language to achieve an organic order, which Alexander describes in [Oregon] as "the kind of order that is achieved when there is a perfect balance between the needs of the parts and the needs of the whole." So in a sense, a pattern language is like an ecosystem of patterns, all of which are inherently related at some level. This "ecological quality" of pattern languages contributes to their "wholeness" and their ability to help us generate "live" architectures" possessing the QWAN.

Throughout The Timeless Way of Building, Alexander remarks on what a pattern language truly embodies:

• "Thus, as in the case of natural languages, the pattern language is generative. It not only tells us the rules of arrangement, but shows us how to construct arrangements -- as many as we want -- which satisfy the rules." (p. 186)

• "A pattern language gives each person who uses it, the power to create an infinite variety of new and unique buildings, just as his ordinary language gives him the power to create an infinite variety of sentences." (p. 167)

• "The structure of the language is created by the network of connections among individual patterns: and the language lives, or not, as a totality, to the degree these patterns form a whole." (p. 305)

• "Each pattern then, depends both on the smaller patterns it contains and on the larger patterns within which it is contained." (p. 312)

• "The language is a good one, capable of making something whole, when it is morphologically and functionally complete." (p. 316)

Michael Beedle, author of Reengineering the Application Development Process, likens the effects of using pattern languages to the generation of emergent behaviors: spontaneously recurring patterns of dense local interaction between entities, resulting in dynamic, self-organizing systems that are adaptive, open, and capable of multi-scale effects. In other words, pattern languages provide a dynamic process for the orderly resolution of problems within their domain which indirectly leads to the resolution of a much broader problem. The patterns and rules in a pattern language combine to form an architectural style. In this manner, pattern languages guide system analysts, architects, designers, and implementors to produce workable systems that solve common organizational and development problems at all levels of scale and diversity.

Piecemeal Growth

Large lump development hinges on a view of the environment which is static and discontinuous; piecemeal growth hinges on a view of the environment which is dynamic and continuous.... According to the large lump point of view, each act of design or construction is an isolated event which creates an isolated building -- "perfect" at the time of construction, and then abandoned by its builders and designers forever. According to the piecemeal point of view, every environment is changing and growing all the time, in order to keep its use in balance; and the quality of the environment is a kind of semi-stable equilibrium in the flux of time.... Large lump development is based on the idea of replacement. Piecemeal growth is based on the idea of repair.

Those familiar with software development lifecycles might see some similarities between large lump development and the waterfall model, and between piecemeal growth, and the spiral models which involve prototyping and incremental/evolutionary development (or what Booch calls "round-trip gestalt design").

The relationship between patterns and piecemeal growth is that pattern languages are intended to grow and evolve whole architectures through this process of piecemeal growth. The various sequences in which a pattern language instructs the user in the application of the patterns therein should unfold a complete architecture which gradually emerges from the successive application of individual patterns in the appropriate order.

Pattern Catalogs and Systems

Pattern Catalogs

A pattern catalog is a collection of related patterns (perhaps only loosely or informally related). It typically subdivides the patterns into at least a small number of broad categories and may include some amount of cross referencing between patterns.

Pattern Systems

A pattern system is a cohesive set of related patterns which work together to support the construction and evolution of whole architectures. Not only is it organized into related groups and subgroups at multiple levels of granularity, it describes the many interrelationships between the patterns and their groupings and how they may be combined and composed to solve more complex problems. The patterns in a pattern system should all be described in a consistent and uniform style and need to cover a sufficiently broad base of problems and solutions to enable significant portions of complete architectures to be built.

A pattern catalog adds a modicum of structure and organization to a pattern collection, but doesn't usually go very far beyond showing only the most outwardly visible structure and relationships (if in fact it shows any of them). A pattern system adds deep structure, rich pattern interaction, and uniformity to a pattern catalog. Both pattern systems and pattern languages form coherent sets of tightly interwoven patterns for describing and solving problems in a particular domain. But a pattern language adds robustness, comprehensiveness, and wholeness to a pattern system. The primary difference is that, ideally, pattern languages are computationally complete, showing all possible combinations of patterns and their variations to produce complete architectures. In practice however, the difference between pattern systems and pattern languages can be extremely difficult to ascertain.

While a pattern system may be a cohesive collection of patterns about a very broad topic, a pattern language has to be about more than just a "broad topic". A pattern language ultimately corresponds to a single-minded collective that forms a kind of "mega pattern" or "super pattern" in that the entire language possesses an underlying, shared problem and its context, forces, solution, resulting context, and rationale (which each pattern in the language addresses at some level or another). This coherence of purpose is what gives the pattern language a sense of closure. A pattern system does not necessarily have all of these pattern components. It may focus on an equally broad or narrow topic, but it may not necessarily have a clear mission or agenda (and may result in many relationships between patterns being harder to see or find), or it leaves several important gaps unfilled in the problem space (and hence may not attain overall resolution or closure).

But perhaps the most important difference between pattern languages and pattern systems is that pattern languages are not created all at once. They evolve from pattern systems through the process of piecemeal growth (and a pattern system may, in turn, evolve from a pattern catalog in a similar manner). So just as pattern languages help to incrementally grow whole architectures, pattern systems may serve to incrementally grow into whole pattern languages.

Writing Patterns

The best way to learn how to recognize and document useful patterns is by learning from others who have done it well! Pick up several books and articles which describe patterns (don't choose just one) and try and see if you can recognize all the necessary pattern components and desirable qualities that were mentioned earlier in this paper. When you see one that appeals to you, ask yourself why it is good. If you see one you don't like, try and figure out exactly what it is about the pattern that leaves you unsatisfied. Read as much as you can, and try to learn from the masters. Numerous resources for learning more about patterns are given near the end of this paper. Most importantly, be introspective about everything you read! Examine how it is meaningful to you and how it will help you accomplish future goals. After you have been exposed to a wealth of pattern literature, choose one of the various pattern formats and see if you can flesh out some of your earlier ideas for things you thought might be patterns. If you are trying to compose a language of patterns, start by examining the forces and context of each pattern and try to identify any simple underlying principles that seem to help organize the patterns together into useful configurations.

How do the experts decide what makes a good pattern? The PLoP conferences have several criteria which they feel submitted pattern papers should meet. These are as follows (summarized from Buschmann et. al. in Pattern-Oriented Software Architecture):

• Focus on practicability: Patterns should describe proven solutions to recurring problems rather than the latest scientific results.

• Aggressive disregard of originality: Pattern writers do not need to be the original inventor or discoverer of the solutions that they document.

• Non-anonymous review: Pattern submissions are shepherded rather than reviewed. The shepherd contacts the pattern author(s) and discusses with them how the patterns might be clarified or improved upon.

• Writer's workshops instead of presentations: Rather than being presented by the individual authors, the patterns are discussed in writer's workshops: an open forum where all attending seek to improve the patterns presented by discussing what they like about the patterns as well as other areas in which they are lacking.

• Careful editing: The pattern authors have the opportunity to incorporate all the comments and insights during the shepherding and writer's workshops before presenting the patterns in their finished form.

Pattern Futures

Alexander develops a comprehensive theory of how matter comes together to form coherent structures. Paralleling, but not copying, recent results from complexity theory, he argues that the same laws apply to all structures in the universe; from atoms, to crystals, to living forms, to galaxies.

This book encompasses all the concepts and theories discussed in Alexander's earlier works and extends them to develop a much broader paradigm for creating architectures. It discusses a new concept of wholeness that emerges from fields of centers (which are constructed from small pattern languages) with universal recursive properties, and from dynamic processes called sequences (which relate the order in which to visit centers and apply patterns) that employ structure-preserving transformations. Alexander presents his new architectural paradigm with concepts like:

• the degrees of life and how life comes from wholeness
• the fifteen fundamental properties of wholeness and life
• the principle of unfolding wholeness
• structure-preserving transformations
• the fundamental process for creating life
• achieving comfortable, habitable living spaces
• defining and designing essential centers for working out structure
• the emergence of living order and the face of god

Many in the patterns community are awaiting publication of this book with enormous anticipation as it promises to be a work of monumental significance for all walks of architecture.

Concluding Remarks

Patterns represent distilled experience which, through their assimilation, convey expert insight and knowledge to inexpert developers. They help forge the foundation of a shared architectural vision, and collective of styles. If we want software development to evolve into a mature engineering discipline, then these proven "best practices" and "lessons learned" must be aggressively and formally documented, compiled, scrutinized, and widely disseminated as patterns (and anti-patterns). Once a solution has been expressed in pattern form, it may then be applied and reapplied to other contexts, and facilitate widespread reuse across the entire spectrum of software engineering artifacts such as: analyses, architectures, designs, implementations, algorithms and data structures, tests, plans, and organization structures.

Patterns are not a "silver bullet"! They are extremely valuable tools for capturing and communicating acquired knowledge and experience to improve software quality and productivity by addressing fundamental issues in the development of software. By employing these tools we are better suited to meet challenges like "communication of architectural knowledge among developers; accommodating a new design paradigm or architectural style; resolving nonfunctional forces such as reusability, portability, and extensibility; and avoiding development traps and pitfalls that have traditionally been learned only by experience." (quoted from the PLoP'96 Call for Papers.)

Perhaps the final remarks from Pattern-Oriented Software Architecture best describe the significance of patterns for software:

Patterns expose knowledge about software construction that has been gained by many experts over many years. All work on patterns should therefore focus on making this precious resource widely available. Every software developer should be able to use patterns effectively when building software systems. When this is achieved, we will be able to celebrate the human intelligence that patterns reflect, both in each individual pattern and in all patterns in their entirety.

Further Information

• Doug Lea's "Patterns-Discussion FAQ" at
  http://g.oswego.edu/dl/pd-FAQ/pd-FAQ.html
• Doug Lea's paper, "Christopher Alexander: An Introduction for Object-Oriented Designers", available at
  http://gee.cs.oswego.edu/dl/ca/ca/ca.html
• Doug Schmidt and Ralph Johnson's introduction to Software Patterns from the October 1996, CACM Special Issue on patterns, at
  http://www.cs.wustl.edu/~schmidt/CACM-editorial.html
• Excerpts from Jim Coplien's SIGS management briefing Software Patterns at
  http://www.sigs.com/books/wp_patterns_5pp.html
• Jim Coplien's paper "Software Design Patterns: Common Questions and Answers", available at
  ftp://st.cs.uiuc.edu/pub/patterns/papers/PatQandA.ps
• John Vlissides' article "Patterns: The Top 10 Misconceptions" in the March 1997 issue of Object Magazine Online located at:
  http://www.sigs.com/publications/docs/objm/9703/9703.vlissides.html
• The "History of Patterns" on Ward Cunningham's WikiWiki Web at
  http://c2.com/cgi-bin/wiki?HistoryOfPatterns
• "Pattern Definitions" from the Patterns Home page at
  http://st-www.cs.uiuc.edu/users/patterns/definition.htm
• Steve Berczuk's "Finding solutions through pattern languages" at
  http://world.std.com/~berczuk/pubs/Dec94ieee.html
• "Some Notes on Christopher Alexander", by Nikos A. Salingaros, located at
  http://www.math.utsa.edu/sphere/salingar/Chris.text.html
• "Design Patterns: Elements of Reusable Architectures", by Linda Rising at
  http://www.agcs.com/techpapers/patterns.htm
• Brian Kurotsuchi's Design Patterns Tutorial at
  http://www.csc.calpoly.edu/~dbutler/tutorials/winter96/patterns/
• Ravi Palepu's "Modelling the Real World: Application of Patterns to Reduce Complexity in the Software Development Process" at
  http://www.scs.carleton.ca/~palepu/pat.html
• Doug Schmidt's "Pattern Writer's Workshop Tutorial" at
  http://www.cs.wustl.edu/~schmidt/writersworkshop.html
• "Tips for Writing Pattern Languages" on the WikiWiki Web at
  http://c2.com/cgi/wiki?TipsForWritingPatternLanguages
• Richard Gabriel's article "Developing Patterns Studies" from InfoWorld on-line at
  http://www.infoworld.com/cgi-bin/displayArchives.pl?dt_iwe05-97_72.htm
• A "Patterns BookList" on the WikiWiki Web at
  http://c2.com/cgi/wiki?BookList

Other more general patterns resources on the web are:

• The Patterns Home Page at
  http://st-www.cs.uiuc.edu/users/patterns/patterns.html
• The Portland Pattern Repository at
  http://www.c2.com/ppr
• Ward Cunningham's wonderful WikiWiki Web at
  http://c2.com/cgi/wiki?WelcomeVisitors
• Patlets FrontPage - a Patterns Database at
  http://st-www.cs.uiuc.edu/users/patterns/patlet/?FrontPage
• Cetus Links: Patterns, hundreds of links to pattern-related pages, located at
  http://www.objenv.com/cetus/oo_patterns.html
• Brad Appleton's "Software Patterns Links" located at
  http://www.enteract.com/~bradapp/links/sw-pats.html
• AG Communications Systems Patterns Pages at
  http://www.agcs.com/patterns
• The OrganizationPatterns FrontPage at
  http://www.bell-labs.com/cgi-user/OrgPatterns/OrgPatterns
• The "Design Patterns Mailing Lists by thread" at
  http://iamwww.unibe.ch:80/~fcglib/WWW/OnlineDoku/archive/DesignPatterns/
• The "Organization-patterns Mail Archive by thread" at
  http://www.bell-labs.com/~cope/Patterns/organization-patterns-archive/

Acknowledgements

About the Author

Index of Terms and Concepts