| <?xml version="1.0" encoding="UTF-8"?> |
| <org.eclipse.epf.uma:ContentDescription xmi:version="2.0" |
| xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.5/uma.ecore" |
| xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.0" xmi:id="_QvmkAMM1EdmSIPI87WLu3g" |
| name="patterns,_0YJvUMlgEdmt3adZL5Dmdw" guid="_QvmkAMM1EdmSIPI87WLu3g" changeDate="2007-02-26T01:45:45.531-0800" |
| version="1.0.0"> |
| <mainDescription><h4>
 |
| Origins
 |
| </h4>
 |
| <p>
 |
| The idea of patterns as it is now applied to software design comes from the work of Christopher Alexander. He has
 |
| written widely on the subject of applying patterns to the design and construction of towns and buildings. Two of his
 |
| books, <em>A Pattern Language</em> [<a class="elementLinkWithUserText" href="./../../../openup/guidances/supportingmaterials/references_6CCF393.html#ALE77" guid="_9ToeIB83Edqsvps02rpOOg">ALE77</a>] and <em>The Timeless Way of Building</em> [<a class="elementLinkWithUserText" href="./../../../openup/guidances/supportingmaterials/references_6CCF393.html#ALE79" guid="_9ToeIB83Edqsvps02rpOOg">ALE79</a>] have had the greatest impact on the software community and the adoption of
 |
| software patterns for the design of software. His concepts of patterns and pattern language provide a model for the
 |
| capture of software design expertise in a form that can then be reapplied in recurring situations.
 |
| </p>
 |
| <h4>
 |
| A definition of patterns
 |
| </h4>
 |
| <p>
 |
| Today, the most commonly used definition of software patterns is from [<a class="elementLinkWithUserText" href="./../../../openup/guidances/supportingmaterials/references_6CCF393.html#GAM95" guid="_9ToeIB83Edqsvps02rpOOg">GAM95</a>]:
 |
| </p>
 |
| <blockquote>
 |
| <p>
 |
| "A design pattern describes the problem, a solution to the problem consisting of a general arrangement of objects
 |
| and classes, when to apply the solution, and the consequences of applying the solution."
 |
| </p>
 |
| </blockquote>
 |
| <p>
 |
| This definition often serves only as a starting point, however. A richer definition, based on Alexander’s work, is
 |
| offered by Gabriel in his book, <em>A Timeless Way of Hacking</em> [<a class="elementLinkWithUserText" href="./../../../openup/guidances/supportingmaterials/references_6CCF393.html#ALU03" guid="_9ToeIB83Edqsvps02rpOOg">ALU03</a>], in which each pattern is a three-part rule that expresses relationships
 |
| among a certain context, a certain system of forces that occur repeatedly in that context, and a certain software
 |
| configuration that allows these forces to resolve themselves.
 |
| </p>
 |
| <h4>
 |
| Describing patterns
 |
| </h4>
 |
| <p>
 |
| It is commonplace to describe patterns&nbsp;using the&nbsp;format made popular by Erich Gamma and his three colleagues
 |
| [<a class="elementLinkWithUserText" href="./../../../openup/guidances/supportingmaterials/references_6CCF393.html#GAM95" guid="_9ToeIB83Edqsvps02rpOOg">GAM95</a>]. They have come to be known as the Gang of Four (GoF); therefore, their
 |
| description is known as the <strong>GoF format</strong>. The GoF format uses the following keywords to describe
 |
| object-oriented design patterns:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| <p>
 |
| <strong>Pattern name and classification:</strong> Naming the pattern allows design to work at a higher level of
 |
| abstraction, using a vocabulary of patterns. Gamma says that finding a good name is one of the hardest problems
 |
| of developing a catalogue of patterns (see <strong>Pattern catalogues</strong> later in this section).
 |
| </p>
 |
| </li>
 |
| <li>
 |
| <p>
 |
| <strong>Intent:</strong> An answer to questions such as: What does the pattern do? What problem does it
 |
| address?
 |
| </p>
 |
| </li>
 |
| <li>
 |
| <p>
 |
| <strong>Also known as:</strong> Other names for the pattern.
 |
| </p>
 |
| </li>
 |
| <li>
 |
| <p>
 |
| <strong>Motivation:</strong> A concrete scenario that illustrates a design problem and how the pattern solves
 |
| the problem.
 |
| </p>
 |
| </li>
 |
| <li>
 |
| <p>
 |
| <strong>Applicability:</strong> Instructions for how you can recognize situations in which patterns are
 |
| applicable.
 |
| </p>
 |
| </li>
 |
| <li>
 |
| <p>
 |
| <strong>Structure:</strong> A graphical representation of the classes in the pattern.
 |
| </p>
 |
| </li>
 |
| <li>
 |
| <p>
 |
| <strong>Participants:</strong> The responsibilities of the classes and objects that participate in the pattern.
 |
| </p>
 |
| </li>
 |
| <li>
 |
| <p>
 |
| <strong>Collaborations:</strong> How participants collaborate to fulfil their responsibilities.
 |
| </p>
 |
| </li>
 |
| <li>
 |
| <p>
 |
| <strong>Consequences:</strong> The results, side effects and trade offs caused by using the pattern.
 |
| </p>
 |
| </li>
 |
| <li>
 |
| <p>
 |
| <strong>Implementation:</strong> Guidance on the implementation of the pattern.
 |
| </p>
 |
| </li>
 |
| <li>
 |
| <p>
 |
| <strong>Sample code:</strong> Code fragments that illustrate the pattern’s implementation.
 |
| </p>
 |
| </li>
 |
| <li>
 |
| <p>
 |
| <strong>Known uses:</strong> Where to find real-world examples of the pattern.
 |
| </p>
 |
| </li>
 |
| <li>
 |
| <p>
 |
| <strong>Related patterns:</strong> Synergies, differences, and other pattern relationships.
 |
| </p>
 |
| </li>
 |
| </ul>
 |
| <p>
 |
| Although the GoF format is specifically intended for object-oriented development, you can use it, with slight
 |
| modification, to address other software patterns. A more general keyword format for software patterns based on
 |
| Alexander’s principles uses keywords such as <em>problem</em>, <em>context</em>, <em>forces</em> and <em>solution</em>.
 |
| </p>
 |
| <h4>
 |
| Pattern catalogs
 |
| </h4>
 |
| <p>
 |
| To assist with the identification and selection of patterns, various classification schemes have been proposed. One of
 |
| the early schemes, proposed by Buschmann and his associates, [<a class="elementLinkWithUserText" href="./../../../openup/guidances/supportingmaterials/references_6CCF393.html#BUS96" guid="_9ToeIB83Edqsvps02rpOOg">BUS96</a>] uses three classifiers: granularity, functionality, and structured
 |
| principles. Of those three classifiers, it is their granularity classifier that has remained popular. Granularity
 |
| classifies patterns into three levels of abstraction:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| <p>
 |
| <strong>Architectural patterns:</strong> Architectural patterns express the fundamental structure of a software
 |
| scheme. Examples of architectural pattern include: layers, pipes and filters, and the model view controller
 |
| pattern.
 |
| </p>
 |
| </li>
 |
| <li>
 |
| <p>
 |
| <strong>Design patterns:</strong> Software architecture usually consists of smaller architectural units that
 |
| are described by design patterns. The GoF pattern is an example of a design pattern.
 |
| </p>
 |
| </li>
 |
| <li>
 |
| <p>
 |
| <strong>Idioms.</strong> An idiom is the lowest-level pattern, and it is specific to a programming language.
 |
| </p>
 |
| </li>
 |
| </ul>
 |
| <p>
 |
| Buschmann and his colleagues introduced four groups for categorizing architectural patterns:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| Structure
 |
| </li>
 |
| <li>
 |
| Distributed systems
 |
| </li>
 |
| <li>
 |
| Interactive systems
 |
| </li>
 |
| <li>
 |
| Adaptable systems
 |
| </li>
 |
| </ul>
 |
| <p>
 |
| The following table shows the categorization of their architectural patterns.
 |
| </p>
 |
| <table cellspacing="0" cellpadding="2" width="85%" summary="Categories for Architectural Patterns [BUS96]" border="1" valign="top">
 |
| <caption>
 |
| <strong>Categories for Architectural Patterns<br />
 |
| </strong>
 |
| </caption>
 |
| <tbody>
 |
| <tr>
 |
| <th scope="col">
 |
| <div align="center">
 |
| <strong>Category</strong>
 |
| </div>
 |
| </th>
 |
| <th scope="col">
 |
| <div align="center">
 |
| <strong>Pattern</strong>
 |
| </div>
 |
| </th>
 |
| </tr>
 |
| <tr>
 |
| <td>
 |
| Structure
 |
| </td>
 |
| <td>
 |
| <p>
 |
| Layers<br />
 |
| Pipes and filters<br />
 |
| Blackboard
 |
| </p>
 |
| </td>
 |
| </tr>
 |
| <tr>
 |
| <td>
 |
| Distributed systems
 |
| </td>
 |
| <td>
 |
| Broker
 |
| </td>
 |
| </tr>
 |
| <tr>
 |
| <td>
 |
| Interactive systems
 |
| </td>
 |
| <td>
 |
| Model view controller<br />
 |
| Presentation abstraction control
 |
| </td>
 |
| </tr>
 |
| <tr>
 |
| <td>
 |
| <p>
 |
| Adaptable systems
 |
| </p>
 |
| </td>
 |
| <td>
 |
| <p>
 |
| Reflection<br />
 |
| Micro kernel
 |
| </p>
 |
| </td>
 |
| </tr>
 |
| </tbody>
 |
| </table>
 |
| <p>
 |
| For design patterns, Gamma's group categorized their design patterns by purpose, using three categories:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| Creational
 |
| </li>
 |
| <li>
 |
| Structural
 |
| </li>
 |
| <li>
 |
| Behavioral
 |
| </li>
 |
| </ul>
 |
| <h4>
 |
| Pattern languages
 |
| </h4>
 |
| <p>
 |
| In addition to the concept of patterns, Alexander also gave the software community the concept of a pattern language.
 |
| The purpose of developing a pattern language was to provide a vocabulary of design principles (patterns) that would
 |
| allow those who work, study, or live in buildings to communicate effectively with the planners and designers of those
 |
| buildings. Alexander explains that when using a pattern language:
 |
| </p>
 |
| <blockquote>
 |
| <p>
 |
| We always use it as a sequence, going through the patterns, moving always from the larger patterns to the smaller,
 |
| always from the ones that create structure to the ones which then embellish those structures, and then to those
 |
| that embellish the embellishments.
 |
| </p>
 |
| </blockquote>
 |
| <p>
 |
| In applying patterns in this way, Alexander advocated the use of generative pattern languages, ones that, given an
 |
| initial context, would always lead to good design.&nbsp; Alexander&nbsp;states:
 |
| </p>
 |
| <blockquote>
 |
| <p>
 |
| 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 satisfies the rules.
 |
| </p>
 |
| </blockquote>
 |
| <p>
 |
| In the application of software patterns, pattern names provide a vocabulary for the communication of software ideas.
 |
| The sequential application of patterns finds application in software design processes, both waterfall and iterative,
 |
| that successively apply architectural patterns, and then design patterns, and, finally, idioms to design and implement
 |
| a software system. Software processes, however, rely on the skills of the Architect and Developer roles to guide the
 |
| application of patterns, rather than a generative pattern language.
 |
| </p></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |
