Creating and Documenting a New Style

In Section 6.3, we discussed the need to define a new style when combining two or more existing styles and the result was expected to be of enduring value to the current or future projects. There are also other reasons to define new styles. Style catalogs are by their nature incomplete. They grow as practitioners discover new styles that solve new problems or solve old problems in new ways. An architect designing the software for a system is likely to realize that he or she has used a new style or made a new twist on an existing style. What are the obligations for documenting a new style?

In broad terms, documenting a new architectural style is done by writing a style guide specifying a vocabulary of designas a set of element and relationship typesand rules for how that vocabulary can be used as a set of topological and semantic constraints. A second way is to define one or more architectural patterns. This is usually done by defining parameterized architectural fragments, or templates, which can be instantiated by filling in the missing parts.

Existing style catalogs prescribe different ways to catalog a style, but four key decisions must be made and documented.

  1. Vocabulary: What are the types of elements in the style? What relationships do they have? What are their properties? What are the rules of composition that determine how the vocabulary can be used?

  2. Semantics: What computational model do these elements support?

  3. Analyses: What forms of analysis are supported by the style?

  4. Implementation: What are the implementation strategies that allow one to produce an executable system?

In this book, Chapters 2, 4, and 5 use a slightly different catalog approach geared to the documentation of views discussed in those styles. The vocabulary section became Elements, Relations, and Properties, a good match. Semantics and analyses are manifested in What It's For and Not For, with a passing mention of computational models. Implementation was omitted from our descriptions as being of little interest in this context; in its place, we added a section on notations for the style.

ADVICE

When writing your own guide to a new style, you will probably want to pay more attention to implementation and computational models, as you will be writing for an audience that will be unfamiliar with the style and its usage. You may also want to follow our lead and indicate what the relationship is between the new style and other styles that have already been cataloged. This relationship information could include similarities to other styles, styles that are particularly useful for the new style to map to, or styles that the new style might be confused with.

Usually, the answers to the questions imposed by the style guide are interdependent. The choice of element vocabulary and the required properties may be driven by the kinds of analysis that one wants to perform. For instance, queuing-theoretic analysis depends on the use of connectors that support asynchronous, buffered messages, together with properties that indicate buffering capacity, latencies, and so on. Implementation strategies may exploit the fact that the architecture satisfies certain topological constraints. For example, a linear pipeline of filters can be optimized by combining the functions performed by several filters into one larger equivalent filter.

Getting all this working together is not an easy proposition. Consequently, architects often use three techniques to develop new styles.

  1. Combining styles: An architect mixes and matches elements from several existing styles to produce a new one. For example, you might combine the features of a peer-to-peer style and a publish-subscribe style, so that components can either synchronously invoke other components' methods or asynchronously publish events. Combining styles has the advantage of reuse. However, one must be careful that the features of one style do not violate the semantic assumptions and constraints of another. Consider, for example, combining repository and a pipe-and-filter style. In the new style, filters can communicate via either pipes or a shared database. Unfortunately, doing this means that filters can no longer be treated as asynchronous processes, as they may need to synchronize on shared-data access. Is this a problem? It depends on the kinds of analyses that you intend to perform and the implementation techniques you intend to use.

  2. Style specialization: Refining an existing style can be done in several ways. You can provide a more detailed, domain-specific vocabulary. For example, you might define a new style by specializing pipes and filters for process control by adding a set of special filter types for monitoring the environment and regulating set points. You might add new constraints. For example, you might define topological constraints in the process control style to enforce a closed-loop organization of the filters. You might add new properties to enable new forms of analysis.

  3. Analysis-driven styles: Choose a style to permit a particular form of analysis. Suppose that you want to be able to analyze a system for a certain quality attribute. You have a queuing theory that can do this. This analytic framework makes certain assumptions about the elements and their interactions, such as independent processes with buffered message queues. Embody those assumptions in the definition of the style.

COMING TO TERMS

Styles, Patterns

It must be clear by now that the concept of styles is fundamental to the engineering and documentation of an architecture. In the early 1990s, some in the software architecture community observed recurring coarse-grained problem solutions involving the use of specific kinds of elements arranged in specific kinds of relationships with each other. These architectural styles, as they were called, were recognized as providing glimpses into how architects went about their craft; they represented the results of early and fundamental design decisions. Except in matters of detail, architectural solutions to vastly different application problemslayering the system, employing clients and servers with message-passing, assigning the work to loosely coupled communicating processes, introducing a central data repository, delivering the data through pipes to be processed by filterscould be seen as identical.

At about the same time, the object-oriented programming community was discovering that they, too, could observe recurring solutions to problems in their realm. In 1995, the so-called "gang of four" design patterns book was published [Gamma+ 95], and is still the Bible of object-oriented design. Model-view-controller, abstract factory, adapter, builder, and other patterns entered our design vocabulary, and an entire community devoted to finding and describing patterns arose.

Both the style and the design patterns communities shared a common virtue. The goal, they made clear, was not to make up solutions but to capture solutions that were already in use. Various venues for describing these things had their own rules: Before being eligible for inclusion, the pattern or style has to occur in at least two systems, or in two different organizations, and so on. This mercifully headed off any temptation to catalog solutions for solutions' sake, and to concentrate instead on capturing provably useful design knowledge.

To its credit, the design patterns community became interested (if not obsessed) with more than just the patterns, but how the patterns should be described. They took their inspiration from Christopher Alexander, a building (not a software) architect who is at least as well known in our field as he is in his own. In 1977, Alexander published a book entitled A Pattern Language: Towns, Buildings, Construction (Oxford University Press, 1977). In it, he tried to codify rules for large-scale and small-scale building architecture that would result in homes, public buildings, and towns that people would find aesthetically and functionally pleasing. Computer scientists who read the book recognized an entire grammar for building architecture. Balconies should be at least 10 feet wide, or else people won't spend time on them. Entrances and public squares should be on the south side of buildings in the Northern Hemisphere, so as to be sunny. Breathtaking views shouldn't be squandered, but revealed suddenly and unexpectedly. Each rule was laid out in a prescribed form, giving its use, justification, and the circumstances in which it applied.

The gang of four used their own pattern language, a 13-part template with sections including "Name and classification," "also known as," "motivation," "applicability," "structure," "sample code," "known uses," and "related patterns." The template, wrote the authors, "lends a uniform structure to the information, making design patterns easier to learn, compare, and use."

In 1996, Buschmann, Meunier, Rohnert, Sommerlad, and Stal arranged the inevitable marriage between the two worlds. In Pattern-Oriented Software Architecture, Volume 1: A System of Patterns (John Wiley & Sons, 1996), they gave us a set of well-known architectural styles documented in a very design-pattern-like fashionthat is to say, using a pattern language. Thus came the first widely published catalog of architectural styles that was of general use to the in-the-trenches software architect.

So is there a difference between a style and a pattern? Yes and no. They are alike in that both are cataloged partial design solutions, captured in practice, and must be instantiated and completed before application to an actual system. They are different in that a style tends to refer to a coarser grain of design solution than a pattern, which tends to refer to a design solution localized within a few (or one) of a system's many architectural components. But many people treat architectural styles simply as patterns writ large. We concur.
Related

Категории