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