<?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.4/uma.ecore"
    xmlns:rmc="http://www.ibm.com/rmc"  xmlns:epf="http://www.eclipse.org/epf"
    epf:version="1.2.0" xmi:id="-8LfKJab2khAUjdmnImaXPA"
    name="architecture_mechanism_attributes,_eQ_s8Om5Edupia_tZIXEqg" guid="-8LfKJab2khAUjdmnImaXPA"
    changeDate="2007-06-24T15:15:17.390-0700">
  <mainDescription>&lt;p>&#xD;
    The following shows how to capture information for &lt;a class=&quot;elementLink&quot; href=&quot;./../../../openup/guidances/concepts/arch_mech_2932DFB6.html&quot; guid=&quot;_mzxI0A4LEduibvKwrGxWxA&quot;>Architectural Mechanism&lt;/a>s. This example shows two possible mechanisms; Persistence and Communication.&#xD;
&lt;/p>&#xD;
&lt;h3>&#xD;
    Persistence&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    For all classes with instances that may become persistent, you need to identify:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        &lt;p>&#xD;
            &lt;b>Granularity&lt;/b>&lt;strong>:&lt;/strong> What is the range of size of the objects to keep persistent?&#xD;
        &lt;/p>&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;p>&#xD;
            &lt;b>Volume&lt;/b>&lt;strong>:&lt;/strong> How many objects (number) do you need to keep persistent?&#xD;
        &lt;/p>&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;p>&#xD;
            &lt;b>Duration&lt;/b>&lt;strong>:&lt;/strong> How long does the object typically need to be kept?&#xD;
        &lt;/p>&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;p>&#xD;
            &lt;b>Retrieval mechanism&lt;/b>&lt;strong>:&lt;/strong> How is a given object uniquely identified and retrieved?&#xD;
        &lt;/p>&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;p>&#xD;
            &lt;b>Update frequency&lt;/b>&lt;strong>:&lt;/strong> Are the objects more or less constant? Are they permanently updated?&#xD;
        &lt;/p>&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;p>&#xD;
            &lt;b>Reliability&lt;/b>&lt;strong>:&lt;/strong> Do the objects need to survive a crash of the process, the processor, or&#xD;
            the whole system?&#xD;
        &lt;/p>&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;h3>&#xD;
    Communication&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    For all model elements that need to communicate with components or services that are running in other processes or&#xD;
    threads, you need to identify&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        &lt;p>&#xD;
            &lt;b>Latency&lt;/b>&lt;strong>:&lt;/strong> How fast must processes communicate with another?&#xD;
        &lt;/p>&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;p>&#xD;
            &lt;b>Synchronicity&lt;/b>&lt;strong>:&lt;/strong> Asynchronous communication.&#xD;
        &lt;/p>&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;p>&#xD;
            &lt;b>Size of message&lt;/b>&lt;strong>:&lt;/strong> A spectrum might be more appropriate than a single number.&#xD;
        &lt;/p>&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;p>&#xD;
            &lt;strong>Protocol:&lt;/strong> Flow control, buffering, and so on.&#xD;
        &lt;/p>&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    Notice that there is no design-level information or specification here. Instead, this is more about collating and&#xD;
    refining architecturally significant requirements.&#xD;
&lt;/p></mainDescription>
</org.eclipse.epf.uma:GuidanceDescription>