| <?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><p> |
| Architectural Mechanisms are&nbsp;used to satisfy architecturally significant requirements.&nbsp;When fully described, |
| Architectural Mechanisms show patterns of structure and behavior in the software. They&nbsp;form the basis |
| of&nbsp;common software&nbsp;that will be&nbsp;consistently applied&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. |
| </p> |
| <p> |
| 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&nbsp;software that&nbsp;shows&nbsp;*how* specific mechanisms&nbsp;are satisfied&nbsp;is&nbsp;a development task. |
| </p> |
| <p> |
| The value in defining architecture mechanisms is that it |
| </p> |
| <ol> |
| <li> |
| explicitly calls out&nbsp;aspects of the solution mechanics that are common across the system. This aids planning. |
| </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&nbsp;Architectural Mechanism can have three states: Analysis, Design and Implementation.&nbsp;These |
| categories&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. |
| </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,&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. |
| </td> |
| </tr> |
| <tr> |
| <td> |
| Design |
| </td> |
| <td> |
| 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. |
| </td> |
| </tr> |
| <tr> |
| <td> |
| Implementation |
| </td> |
| <td> |
| <p> |
| A further refinement of a Design Mechanism into a&nbsp;specific technology or product that implements |
| the required Architectural Mechanism. For example, MySQL, as a database product, implements the |
| Analysis Mechanism <strong>Persistence</strong> and Design Mechanism <strong>RDBMS.</strong> |
| </p> |
| <p> |
| 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. |
| </p> |
| </td> |
| </tr> |
| </tbody> |
| </table> |
| <br /> |
| <p> |
| Be aware that these states are frequently referred to themselves as Analysis, Design and Implementation |
| mechanisms.&nbsp;These are synonyms and merely represent the architecture mechanisms in different states of |
| development. The transition from one state to another&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. |
| </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/ArchMechanismsStatemachine.JPG" width="600" />&nbsp;<br /> |
| </p> |
| <br /></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |