Google Git
Sign in
eclipse / epf / org.eclipse.epf.nl-libraries / 853e429f43a7d8294e63dacdec9cda1873f80c63 / . / OpenUP / OpenUP_SP / library / openup_basic / guidances / concepts / pattern.xmi
blob: 35b7540f2ad2ffe2c0ee0c48ee292cdbe9611aa0 [file] [log] [blame]
<?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" epf:version="1.0.0" xmi:id="_QvmkAMM1EdmSIPI87WLu3g" name="patterns,_0YJvUMlgEdmt3adZL5Dmdw" guid="_QvmkAMM1EdmSIPI87WLu3g" changeDate="2007-02-26T09:45:45.531+0000" version="1.0.0">
<mainDescription>&lt;h4&gt;
Origins
&lt;/h4&gt;
&lt;p&gt;
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, &lt;em&gt;A Pattern Language&lt;/em&gt; [&lt;a class=&quot;elementLinkWithUserText&quot;
href=&quot;./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html&quot;
guid=&quot;_9ToeIB83Edqsvps02rpOOg&quot;&gt;ALE77&lt;/a&gt;] and &lt;em&gt;The Timeless Way of Building&lt;/em&gt; [&lt;a class=&quot;elementLinkWithUserText&quot;
href=&quot;./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html&quot;
guid=&quot;_9ToeIB83Edqsvps02rpOOg&quot;&gt;ALE79&lt;/a&gt;] 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.
&lt;/p&gt;
&lt;h4&gt;
A definition of patterns
&lt;/h4&gt;
&lt;p&gt;
Today, the most commonly used definition of software patterns is from [&lt;a class=&quot;elementLinkWithUserText&quot;
href=&quot;./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html&quot;
guid=&quot;_9ToeIB83Edqsvps02rpOOg&quot;&gt;GAM95&lt;/a&gt;]:
&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;
&quot;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.&quot;
&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;
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, &lt;em&gt;A Timeless Way of Hacking&lt;/em&gt; [&lt;a class=&quot;elementLinkWithUserText&quot;
href=&quot;./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html&quot;
guid=&quot;_9ToeIB83Edqsvps02rpOOg&quot;&gt;ALU03&lt;/a&gt;], 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.
&lt;/p&gt;
&lt;h4&gt;
Describing patterns
&lt;/h4&gt;
&lt;p&gt;
It is commonplace to describe patterns&amp;nbsp;using the&amp;nbsp;format made popular by Erich Gamma and his three colleagues
[&lt;a class=&quot;elementLinkWithUserText&quot;
href=&quot;./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html&quot;
guid=&quot;_9ToeIB83Edqsvps02rpOOg&quot;&gt;GAM95&lt;/a&gt;]. They have come to be known as the Gang of Four (GoF); therefore, their
description is known as the &lt;strong&gt;GoF format&lt;/strong&gt;. The GoF format uses the following keywords to describe
object-oriented design patterns:
&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;
&lt;p&gt;
&lt;strong&gt;Pattern name and classification:&lt;/strong&gt; 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 &lt;strong&gt;Pattern catalogues&lt;/strong&gt; later in this section).
&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;
&lt;strong&gt;Intent:&lt;/strong&gt; An answer to questions such as: What does the pattern do? What problem does it
address?
&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;
&lt;strong&gt;Also known as:&lt;/strong&gt; Other names for the pattern.
&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;
&lt;strong&gt;Motivation:&lt;/strong&gt; A concrete scenario that illustrates a design problem and how the pattern solves
the problem.
&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;
&lt;strong&gt;Applicability:&lt;/strong&gt; Instructions for how you can recognize situations in which patterns are
applicable.
&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;
&lt;strong&gt;Structure:&lt;/strong&gt; A graphical representation of the classes in the pattern.
&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;
&lt;strong&gt;Participants:&lt;/strong&gt; The responsibilities of the classes and objects that participate in the pattern.
&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;
&lt;strong&gt;Collaborations:&lt;/strong&gt; How participants collaborate to fulfil their responsibilities.
&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;
&lt;strong&gt;Consequences:&lt;/strong&gt; The results, side effects and trade offs caused by using the pattern.
&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;
&lt;strong&gt;Implementation:&lt;/strong&gt; Guidance on the implementation of the pattern.
&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;
&lt;strong&gt;Sample code:&lt;/strong&gt; Code fragments that illustrate the pattern’s implementation.
&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;
&lt;strong&gt;Known uses:&lt;/strong&gt; Where to find real-world examples of the pattern.
&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;
&lt;strong&gt;Related patterns:&lt;/strong&gt; Synergies, differences, and other pattern relationships.
&lt;/p&gt;
&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;
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 &lt;em&gt;problem&lt;/em&gt;, &lt;em&gt;context&lt;/em&gt;, &lt;em&gt;forces&lt;/em&gt; and &lt;em&gt;solution&lt;/em&gt;.
&lt;/p&gt;
&lt;h4&gt;
Pattern catalogs
&lt;/h4&gt;
&lt;p&gt;
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, [&lt;a class=&quot;elementLinkWithUserText&quot;
href=&quot;./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html&quot;
guid=&quot;_9ToeIB83Edqsvps02rpOOg&quot;&gt;BUS96&lt;/a&gt;] 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:
&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;
&lt;p&gt;
&lt;strong&gt;Architectural patterns:&lt;/strong&gt; 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.
&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;
&lt;strong&gt;Design patterns:&lt;/strong&gt; Software architecture usually consists of smaller architectural units that
are described by design patterns. The GoF pattern is an example of a design pattern.
&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;
&lt;strong&gt;Idioms.&lt;/strong&gt; An idiom is the lowest-level pattern, and it is specific to a programming language.
&lt;/p&gt;
&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;
Buschmann and his colleagues introduced four groups for categorizing architectural patterns:
&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;
Structure
&lt;/li&gt;
&lt;li&gt;
Distributed systems
&lt;/li&gt;
&lt;li&gt;
Interactive systems
&lt;/li&gt;
&lt;li&gt;
Adaptable systems
&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;
The following table shows the categorization of their architectural patterns.
&lt;/p&gt;
&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;&gt;
&lt;caption&gt;
&lt;strong&gt;Categories for Architectural Patterns&lt;br /&gt;
&lt;/strong&gt;
&lt;/caption&gt;
&lt;tbody&gt;
&lt;tr&gt;
&lt;th scope=&quot;col&quot;&gt;
&lt;div align=&quot;center&quot;&gt;
&lt;strong&gt;Category&lt;/strong&gt;
&lt;/div&gt;
&lt;/th&gt;
&lt;th scope=&quot;col&quot;&gt;
&lt;div align=&quot;center&quot;&gt;
&lt;strong&gt;Pattern&lt;/strong&gt;
&lt;/div&gt;
&lt;/th&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;
Structure
&lt;/td&gt;
&lt;td&gt;
&lt;p&gt;
Layers&lt;br /&gt;
Pipes and filters&lt;br /&gt;
Blackboard
&lt;/p&gt;
&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;
Distributed systems
&lt;/td&gt;
&lt;td&gt;
Broker
&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;
Interactive systems
&lt;/td&gt;
&lt;td&gt;
Model view controller&lt;br /&gt;
Presentation abstraction control
&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;
&lt;p&gt;
Adaptable systems
&lt;/p&gt;
&lt;/td&gt;
&lt;td&gt;
&lt;p&gt;
Reflection&lt;br /&gt;
Micro kernel
&lt;/p&gt;
&lt;/td&gt;
&lt;/tr&gt;
&lt;/tbody&gt;
&lt;/table&gt;
&lt;p&gt;
For design patterns, Gamma's group categorized their design patterns by purpose, using three categories:
&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;
Creational
&lt;/li&gt;
&lt;li&gt;
Structural
&lt;/li&gt;
&lt;li&gt;
Behavioral
&lt;/li&gt;
&lt;/ul&gt;
&lt;h4&gt;
Pattern languages
&lt;/h4&gt;
&lt;p&gt;
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:
&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;
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.
&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;
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.&amp;nbsp; Alexander&amp;nbsp;states:
&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;
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.
&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;
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.
&lt;/p&gt;</mainDescription>
</org.eclipse.epf.uma:ContentDescription>