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