<?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="-SJrpVySJ2npYs8NwGvnHjw" name="arch_mech,_mzxI0A4LEduibvKwrGxWxA" guid="-SJrpVySJ2npYs8NwGvnHjw" authors="Mark Dickson" changeDate="2007-02-26T13:36:32.171+0000" changeDescription="Simplified text explaining mechanism concept" version="1.0.0">
  <mainDescription>&lt;p&gt;
    Architectural Mechanisms are&amp;nbsp;used to satisfy architecturally significant requirements.&amp;nbsp;When fully described,
    Architectural Mechanisms show patterns of structure and behavior in the software. They&amp;nbsp;form the basis
    of&amp;nbsp;common software&amp;nbsp;that will be&amp;nbsp;consistently applied&amp;nbsp;across the product being developed. They also
    form the basis for standardizing the way that the software works; therefore, they are an important element of the
    overall software architecture. The definition of architecture mechanisms also enable decisions on whether existing
    software components can be leveraged to provide the required behaviour; or whether new software should be bought or
    built.
&lt;/p&gt;
&lt;p&gt;
    The key point to take on board when discussing architecture mechanisms is that the defining them is all about making
    choices about *what* technology will be used to satisfy architecturally significant requirements. It is not about
    producing detailed design or software. This is a common misunderstanding. The creation of detailed design
    and&amp;nbsp;software that&amp;nbsp;shows&amp;nbsp;*how* specific mechanisms&amp;nbsp;are satisfied&amp;nbsp;is&amp;nbsp;a development task.
&lt;/p&gt;
&lt;p&gt;
    The value in defining architecture mechanisms is that it
&lt;/p&gt;
&lt;ol&gt;
    &lt;li&gt;
        explicitly calls out&amp;nbsp;aspects of the solution mechanics that are common across the system. This aids planning.
    &lt;/li&gt;
    &lt;li&gt;
        puts down markers for the developers to build those aspects of the system once and then re-use them. This reduces
        the workload.
    &lt;/li&gt;
    &lt;li&gt;
        promotes the development of a consistent set of services. This makes the system easier to maintain.
    &lt;/li&gt;
&lt;/ol&gt;
&lt;p&gt;
    An&amp;nbsp;Architectural Mechanism can have three states: Analysis, Design and Implementation.&amp;nbsp;These
    categories&amp;nbsp;reflect the state of the architectural mechanism over time. The state changes as successive levels of
    detail are uncovered during the refinement of architecturally significant requirements into working software. The
    categories are summarized in the table that follows.
&lt;/p&gt;
&lt;strong&gt;States of an Architectural Mechanism&lt;/strong&gt; 
&lt;table style=&quot;WIDTH: 806px; HEIGHT: 228px&quot; cellspacing=&quot;0&quot; cellpadding=&quot;2&quot; width=&quot;806&quot;
summary=&quot;Types of Architectural Mechanism&quot; border=&quot;1&quot;&gt;
    &lt;tbody valign=&quot;top&quot;&gt;
        &lt;tr&gt;
            &lt;th scope=&quot;col&quot;&gt;
                State
            &lt;/th&gt;
            &lt;th scope=&quot;col&quot;&gt;
                Description
            &lt;/th&gt;
        &lt;/tr&gt;
        &lt;tr&gt;
            &lt;td&gt;
                Analysis
            &lt;/td&gt;
            &lt;td&gt;
                A conceptual solution to a common technical problem. For example,&amp;nbsp;persistence is an abstract solution
                to the common requirement to store data. The purpose of this category is simply to identify the need for an
                Architectural Mechanism to be designed and implemented; and capture basic attributes for that mechanism.
            &lt;/td&gt;
        &lt;/tr&gt;
        &lt;tr&gt;
            &lt;td&gt;
                Design
            &lt;/td&gt;
            &lt;td&gt;
                A refinement of an Analysis Mechanism into a concrete technology (for example, RDBMS). The purpose of this
                category is to enable initial design specifications to be produced and to guide precise product or
                technology selection.
            &lt;/td&gt;
        &lt;/tr&gt;
        &lt;tr&gt;
            &lt;td&gt;
                Implementation
            &lt;/td&gt;
            &lt;td&gt;
                &lt;p&gt;
                    A further refinement of a Design Mechanism into a&amp;nbsp;specific technology or product that implements
                    the required Architectural Mechanism. For example, MySQL, as a database product, implements the
                    Analysis Mechanism &lt;strong&gt;Persistence&lt;/strong&gt; and Design Mechanism &lt;strong&gt;RDBMS.&lt;/strong&gt;
                &lt;/p&gt;
                &lt;p&gt;
                    This essentially represents the point at which the decision is made to re-use, buy or build specific
                    software to provide the services defined by the mechanism.
                &lt;/p&gt;
            &lt;/td&gt;
        &lt;/tr&gt;
    &lt;/tbody&gt;
&lt;/table&gt;
&lt;br /&gt;
&lt;p&gt;
    Be aware that these states are frequently referred to themselves as Analysis, Design and Implementation
    mechanisms.&amp;nbsp;These are synonyms and merely represent the architecture mechanisms in different states of
    development. The transition from one state to another&amp;nbsp;can often be obvious or intuitive. Therefore, it can be
    achieved in a matter of seconds. It can also require more considered analysis and design, thus take longer. The
    following diagram illustrates the transition of Architectural Mechanisms from one state to another.
&lt;/p&gt;
&lt;p&gt;
    &lt;strong&gt;State Machine for Architectural Mechanisms&lt;/strong&gt;
&lt;/p&gt;
&lt;p&gt;
    &lt;img style=&quot;WIDTH: 876px; HEIGHT: 115px&quot; height=&quot;113&quot; alt=&quot;Architectural Mechanism States&quot;
    src=&quot;./resources/ArchMechanismsStatemachine.JPG&quot; width=&quot;600&quot; /&gt;&amp;nbsp;&lt;br /&gt;
&lt;/p&gt;
&lt;br /&gt;</mainDescription>
</org.eclipse.epf.uma:ContentDescription>