| <?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.3/uma.ecore" rmc:version="7.1.0" epf:version="1.0.0" xmi:id="-U-5cLUk-mdaO518lh5CxTQ" name="using_patterns,_0cr7cACrEdu8m4dIntu6jA" guid="-U-5cLUk-mdaO518lh5CxTQ" changeDate="2006-09-21T15:38:16.868-0700" version="1.0.0"> |
| <mainDescription><p> |
| In software design, it is primarily the development method and not the pattern and its pattern language that influences |
| the process of pattern selection and use. As discussed in <a class="elementLinkWithType" href="./../../../openup_basic/guidances/concepts/patterns,_0YJvUMlgEdmt3adZL5Dmdw.html" guid="_0YJvUMlgEdmt3adZL5Dmdw">Concept: Patterns</a>, Alexander developed the concept of generative pattern languages |
| to guide a designer’s application of individual patterns to the entire design. In software design, however, as |
| Alexander observed [<a class="elementLinkWithUserText" href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html" guid="_9ToeIB83Edqsvps02rpOOg">OOP96</a>] there is little evidence of using generative pattern languages. |
| </p> |
| <p> |
| For iterative development methods, software patterns and pattern languages support the development method through their |
| ability to be applied incrementally, or by piecemeal growth, and by providing extensible structures. From an |
| architectural perspective, these two qualities allow software architecture to be designed and refactored incrementally, |
| thus so avoid the need for a so-called "big, up-front design." |
| </p> |
| <h4> |
| Piecemeal growth |
| </h4> |
| <p> |
| The term <strong>piecemeal growth</strong>, as it applies to patterns, originates in Alexander's work. It refers to a |
| top-down design process in which a design starts from a high-level structure that is embellished or refined through the |
| implementation of lower-level patterns. For software development, this corresponds to using hierarchies of |
| architectural and design patterns and idioms like those proposed by Buschmann et. al. [<a class="elementLinkWithUserText" href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html" guid="_9ToeIB83Edqsvps02rpOOg">BUS96</a>]. Using the idea of piecemeal growth, an architect can start with one or more |
| architectural patterns to provide an architectural vision for the design, and then progressively extend the design |
| using design patterns. For example, an interactive application may use the Model-View-Controller pattern as its |
| architectural vision, then during implementation the Command pattern may be selected to implement the Controller |
| component. |
| </p> |
| <h4> |
| Extensibility |
| </h4> |
| <p> |
| A key aspect of object oriented design patterns is their ability to support extension without causing the rewriting of |
| existing code. This feature allows a bottom up approach to the design process through code refactoring. When a problem |
| is encountered during coding such as duplicate code, the developer can weighed up various patterns and their tradeoffs |
| and select the appropriate solution in the context of the application. |
| </p></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |