<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:GuidanceDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-giTBOvJczHXweRzBQEo-7A" name="new_template,_EOPcMAMUEdylNddAObilIA" guid="-giTBOvJczHXweRzBQEo-7A" changeDate="2008-08-14T08:20:04.000-0700" version="7.5.0">
  <mainDescription>&lt;p>&#xD;
    This template describes how the design can be organized to be understood from multiple perspectives. It also provides&#xD;
    suggestions for how patterns and descriptions of small, reusable interactions can be used to minimize redundancy.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    It is important not to think of design as &quot;a document.&quot; Design information that is worth keeping for some duration must&#xD;
    have a long-lived form. But that form might be as a repository in a visual modeling tool, or as subdirectories of&#xD;
    whiteboard diagrams captured with a digital camera, or as an actual document that provides structure for images taken&#xD;
    from a myriad of sources.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Designs are often organized into requirement realizations. A requirements realization is a part of the design that&#xD;
    shows how one or more requirements is implemented.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    This template describes the information that should be conveyed. Typically, it works best to convey the information&#xD;
    graphically (either with UML or another unambiguous notation), or at least in words, at an abstract level. You can&#xD;
    enhance this with code examples, but best not to render the design solely at the code level.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The structure of the design is suggested in this template.&#xD;
&lt;/p>&#xD;
&lt;h2>&#xD;
    Design structure&#xD;
&lt;/h2>&#xD;
&lt;p style=&quot;COLOR: #0000ff&quot;>&#xD;
    [Describe the design from the highest level. This is commonly done with a diagram that shows a layered architecture.]&#xD;
&lt;/p>&#xD;
&lt;h2>&#xD;
    Subsystems&#xD;
&lt;/h2>&#xD;
&lt;h3>&#xD;
    [Sub-system1]&#xD;
&lt;/h3>&#xD;
&lt;p style=&quot;COLOR: #0000ff&quot;>&#xD;
    [Describe the design of a portion of the system (a package or component, for instance). The design should capture both&#xD;
    static and dynamic perspectives.&#xD;
&lt;/p>&#xD;
&lt;p style=&quot;COLOR: #0000ff&quot;>&#xD;
    When capturing dynamic descriptions of behavior, look for reusable chunks of behavior that you can reference to&#xD;
    simplify the design of the requirement realizations.&#xD;
&lt;/p>&#xD;
&lt;p style=&quot;COLOR: #0000ff&quot;>&#xD;
    You can break this section down into lower-level subsections to describe lower-level, encapsulated subsystems.]&#xD;
&lt;/p>&#xD;
&lt;h2>&#xD;
    Patterns&#xD;
&lt;/h2>&#xD;
&lt;h3>&#xD;
    [Pattern1]&#xD;
&lt;/h3>&#xD;
&lt;h4>&#xD;
    Overview&#xD;
&lt;/h4>&#xD;
&lt;p style=&quot;COLOR: #0000ff&quot;>&#xD;
    [Provide an overview of the pattern in words in some consistent form. The overview of a pattern can include the intent,&#xD;
    motivation, and applicability.]&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Structure&#xD;
&lt;/h4>&#xD;
&lt;p style=&quot;COLOR: #0000ff&quot;>&#xD;
    [Describe the pattern from a static perspective. Include all of the participants and how they relate to one another,&#xD;
    and call out the&amp;nbsp;relevant data and behavior.]&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Behavior&#xD;
&lt;/h4>&#xD;
&lt;p style=&quot;COLOR: #0000ff&quot;>&#xD;
    [Describe the pattern from a dynamic perspective. Walk the reader through how the participants collaborate to support&#xD;
    various scenarios.]&#xD;
&lt;/p>Example &#xD;
&lt;p style=&quot;COLOR: #0000ff&quot;>&#xD;
    [Often, you can convey the nature of the pattern better with an additional concrete example.]&#xD;
&lt;/p>&#xD;
&lt;h2>&#xD;
    Requirement&amp;nbsp;realizations&#xD;
&lt;/h2>&#xD;
&lt;h3>&#xD;
    [Realization1]&#xD;
&lt;/h3>&#xD;
&lt;h4>&#xD;
    View of participants&#xD;
&lt;/h4>&#xD;
&lt;p style=&quot;COLOR: #0000ff&quot;>&#xD;
    [Describe the participating design elements from a static perspective, giving details such as behavior, relationships,&#xD;
    and attributes relevant to this realization.]&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Basic scenario&#xD;
&lt;/h4>&#xD;
&lt;p style=&quot;COLOR: #0000ff&quot;>&#xD;
    [For the main flow, describe how instances of the design elements collaborate to realize the requirements. When using&#xD;
    UML, this can be done with collaboration diagrams (sequence or communication).]&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Additional scenarios&#xD;
&lt;/h4>&#xD;
&lt;p style=&quot;COLOR: #0000ff&quot;>&#xD;
    [For other scenarios that must be described to convey an appropriate amount of information about how the requirement&#xD;
    behavior will be realized, describe how instances of the design elements collaborate to realize the requirement. When&#xD;
    using UML, you can do this with collaboration diagrams (sequence or communication).]&#xD;
&lt;/p></mainDescription>
</org.eclipse.epf.uma:GuidanceDescription>
