<?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:epf="http://www.eclipse.org/epf" epf:version="1.5.0" xmi:id="-SJrpVySJ2npYs8NwGvnHjw"
    name="arch_mech,_mzxI0A4LEduibvKwrGxWxA" guid="-SJrpVySJ2npYs8NwGvnHjw" authors="Mark Dickson"
    changeDate="2007-07-20T09:24:08.076-0700" changeDescription="Simplified text explaining mechanism concept"
    version="1.0.0">
  <mainDescription>&lt;p>&#xD;
    The value in defining architecture mechanisms is that they:&#xD;
&lt;/p>&#xD;
&lt;ol>&#xD;
    &lt;li>&#xD;
        Explicitly calls out aspects of the solution mechanics that are common across the system. This helps you plan.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Puts down markers for the developers to build those aspects of the system once, and then re-use them. This reduces&#xD;
        the workload.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Promotes the development of a consistent set of services. This makes the system easier to maintain.&#xD;
    &lt;/li>&#xD;
&lt;/ol>&#xD;
&lt;p>&#xD;
    An architectural mechanism can have three states: analysis, design, and nmplementation. These categories reflect the&#xD;
    maturity of the mechanism's description. The state changes as successive levels of detail are uncovered when you refine&#xD;
    architecturally significant requirements into working software. The categories are summarized in the table that&#xD;
    follows.&#xD;
&lt;/p>&lt;strong>States of an Architectural Mechanism&lt;/strong> &#xD;
&lt;table style=&quot;WIDTH: 806px; HEIGHT: 228px&quot; cellspacing=&quot;0&quot; cellpadding=&quot;2&quot; width=&quot;806&quot;&#xD;
summary=&quot;Types of Architectural Mechanism&quot; border=&quot;1&quot;>&#xD;
    &lt;tbody valign=&quot;top&quot;>&#xD;
        &lt;tr>&#xD;
            &lt;th scope=&quot;col&quot;>&#xD;
                State&#xD;
            &lt;/th>&#xD;
            &lt;th scope=&quot;col&quot;>&#xD;
                Description&#xD;
            &lt;/th>&#xD;
        &lt;/tr>&#xD;
        &lt;tr>&#xD;
            &lt;td>&#xD;
                Analysis&#xD;
            &lt;/td>&#xD;
            &lt;td>&#xD;
                A conceptual solution to a common technical problem. For example, persistence is an abstract solution to&#xD;
                the common requirement to store data. The purpose of this category is simply to identify the need to design&#xD;
                and implement an architectural mechanism, and to capture basic attributes for that mechanism.&#xD;
            &lt;/td>&#xD;
        &lt;/tr>&#xD;
        &lt;tr>&#xD;
            &lt;td>&#xD;
                Design&#xD;
            &lt;/td>&#xD;
            &lt;td>&#xD;
                Refining an analysis mechanism into a concrete technology (for example, an RDBMS). The purpose of this&#xD;
                category is to guide precise product or technology selection.&#xD;
            &lt;/td>&#xD;
        &lt;/tr>&#xD;
        &lt;tr>&#xD;
            &lt;td>&#xD;
                Implementation&#xD;
            &lt;/td>&#xD;
            &lt;td>&#xD;
                &lt;p>&#xD;
                    A further refinement from a design mechanism into a specification for the software. This can be&#xD;
                    presented as a design pattern or example code.&#xD;
                &lt;/p>&#xD;
            &lt;/td>&#xD;
        &lt;/tr>&#xD;
    &lt;/tbody>&#xD;
&lt;/table>&lt;br />&#xD;
&lt;p>&#xD;
    Be aware that these states are frequently referred to themselves as analysis, design, and implementation mechanisms.&#xD;
    These are synonyms, and merely represent the architectural mechanisms in different states of development. The&#xD;
    transition from one state to another can often be obvious or intuitive. Therefore, it can be achieved in a matter of&#xD;
    seconds. On the other hand, it can also require more considered analysis and design, thus take longer. The following&#xD;
    diagram illustrates the transition of architectural mechanisms from one state to another.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The important point here is that these categories of mechanisms apply to the same concept in different states. The only&#xD;
    difference between them is one of refinement or detail. Refer to&amp;nbsp;&lt;a class=&quot;elementLink&quot;&#xD;
    href=&quot;./../../../openup/guidances/concepts/arch_mech.html&quot; guid=&quot;_mzxI0A4LEduibvKwrGxWxA&quot;>Architectural&#xD;
    Mechanism&lt;/a>&amp;nbsp;for more background information. See &lt;a class=&quot;elementLinkWithType&quot;&#xD;
    href=&quot;./../../../openup/guidances/examples/architectural_mechanisms-3.html&quot; guid=&quot;_O39h0O9pEdu635i_iQ5Jag&quot;>Example:&#xD;
    Architectural Mechanisms&lt;/a>&amp;nbsp;for a list of typical mechanisms.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The main reason for using architecture mechanisms as an approach to analysis and design is that they facilitate the&#xD;
    evolution of architecturally significant aspects of the system. They allow the team to maintain a cohesive architecture&#xD;
    whilst enabling implementation details to be deferred until they really need to be made.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    &lt;strong>State Machine for Architectural Mechanisms&lt;/strong>&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    &lt;img style=&quot;WIDTH: 876px; HEIGHT: 115px&quot; height=&quot;113&quot; alt=&quot;Architectural Mechanism States&quot;&#xD;
    src=&quot;./resources/arch_mechanisms_state_machine.JPG&quot; width=&quot;600&quot; />&lt;br />&#xD;
&lt;/p>&lt;br />&#xD;
&lt;p>&#xD;
    Architectural mechanisms represent key aspects of the technical solution that need to be standardized across the&#xD;
    project. Everyone on the project should handle these concepts in the same way, and re-use the same mechanisms in their&#xD;
    code.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Architectural Mechanisms are used to satisfy architecturally significant requirements. They often equate to technical&#xD;
    services or framework components in the software, and form the basis for standardizing the way that the software works.&#xD;
    Therefore, they are an important element of the overall software architecture. Defining architectural mechanisms also&#xD;
    enables you to make decisions about whether existing software components can be reused to provide the required&#xD;
    behavior, or whether new software should be bought or built.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The key point to understand when discussing architectural mechanisms is that defining them is all about making choices&#xD;
    about &lt;b>what&lt;/b> technology will be used to satisfy architecturally significant requirements. It is not about&#xD;
    producing detailed design up front. This is a common misunderstanding. Creating detailed design and software that shows&#xD;
    &lt;b>how&lt;/b> specific mechanisms are satisfied is a development task.&#xD;
&lt;/p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>