<?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:rmc="http://www.ibm.com/rmc" rmc:version="7.5.0" xmlns:epf="http://www.eclipse.org/epf"
    epf:version="1.5.0" xmi:id="_S8KCcMP2EdmWKcx6ixEiwg"
    name="analysis_mechanism,_0gvqoMlgEdmt3adZL5Dmdw" guid="_S8KCcMP2EdmWKcx6ixEiwg"
    changeDate="2008-02-09T13:19:23.718-0800" version="1.0.0">
  <mainDescription>&lt;p>&#xD;
    An Analysis Mechanism is a conceptual representation of an &lt;a class=&quot;elementLink&quot; href=&quot;./../../../core.tech.common.extend_supp/guidances/concepts/arch_mechanism_2932DFB6.html&quot; guid=&quot;_mzxI0A4LEduibvKwrGxWxA&quot;>Architectural Mechanisms&lt;/a>. Over time, Analysis Mechanisms are refined into &lt;a class=&quot;elementLink&quot; href=&quot;./../../../core.tech.common.extend_supp/guidances/concepts/design_mechanism_CE197B4E.html&quot; guid=&quot;_w2ACwA4LEduibvKwrGxWxA&quot;>Design Mechanism&lt;/a>s&amp;nbsp;and, later, into &lt;a class=&quot;elementLink&quot; href=&quot;./../../../core.tech.common.extend_supp/guidances/concepts/implementation_mechanism_C92E670B.html&quot; guid=&quot;_0LcUkA4LEduibvKwrGxWxA&quot;>Implementation Mechanism&lt;/a>s.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Analysis Mechanisms&amp;nbsp;allow the developer to focus on understanding the requirements without getting distracted by&#xD;
    the specifics of a complex implementation. They are a way of abstracting away the complexity of the solution, so people&#xD;
    can better comprehend the problem.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Analysis Mechanisms are described in simple terms:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        &lt;strong>Name:&lt;/strong> Identifies the mechanism.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;strong>Basic attributes:&lt;/strong> Define the requirements of the mechanism.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    You can identify Analysis Mechanisms top-down, from previous knowledge, or bottom-up, meaning that you discover them as&#xD;
    you proceed.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    In the top-down mode, you are guided by experience -- you know that certain problems are present in the domain and will&#xD;
    require certain kinds of solutions. Examples of common architectural problems that might be expressed as mechanisms&#xD;
    during analysis are: persistence, transaction management, fault management, messaging, and inference engines. The&#xD;
    common aspect of all of these is that each is a general capability of a broad class of systems, and each provides&#xD;
    functionality that interacts with or supports the basic application functionality. The Analysis Mechanisms support&#xD;
    capabilities required in the basic functional requirements of the system, regardless of the platform that it is&#xD;
    deployed upon or the implementation language. Analysis Mechanisms also can be designed and implemented in different&#xD;
    ways. Generally, there will be more than one design mechanism that corresponds with each Analysis Mechanism. There may&#xD;
    also be more than one way of implementing each design mechanism.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The bottom-up approach is where Analysis Mechanisms ultimately originate. They are created as the you see, perhaps&#xD;
    faintly at first, a common theme emerging from a set of solutions to various problems. For example: There is a need to&#xD;
    provide a way for elements in different threads to synchronize their clocks, and there is a need for a common way of&#xD;
    allocating resources. &lt;a class=&quot;elementLink&quot; href=&quot;./../../../core.tech.common.extend_supp/guidances/concepts/analysis_mechanism_8369C159.html&quot; guid=&quot;_0gvqoMlgEdmt3adZL5Dmdw&quot;>Analysis Mechanism&lt;/a>s, which simplify the language of analysis, emerge from these&#xD;
    patterns.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Identifying an Analysis Mechanism means that you identify a common, perhaps implicit&amp;nbsp;subproblem, and you give it a&#xD;
    name. Initially, the name might be all that exists. For example, the system will require a persistence&#xD;
    mechanism.&amp;nbsp;Ultimately, this mechanism will be implemented through the collaboration of various classes, some of&#xD;
    which do not deliver application functionality directly, but exist only to support it. Very often these support classes&#xD;
    are located in the middle or lower layers of a layered architecture, thereby providing a common support service to all&#xD;
    application-level classes.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    If the subproblem that you identify is common enough, perhaps a pattern exists from which the mechanism can be&#xD;
    instantiated, probably by binding existing classes and implementing new ones, as required by the pattern. An Analysis&#xD;
    Mechanism produced this way will be abstract, and it will require further refinement throughout design and&#xD;
    implementation work.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    You can see examples of how Architectural Mechanisms can be represented in &lt;a class=&quot;elementLinkWithType&quot; href=&quot;./../../../core.tech.common.extend_supp/guidances/examples/architectural_mechanism_attributes_B0ECA2F7.html&quot; guid=&quot;_eQ_s8Om5Edupia_tZIXEqg&quot;>Example: Architectural Mechanism Attributes&lt;/a>.&#xD;
&lt;/p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>