| <?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" xmlns:rmc="http://www.ibm.com/rmc" |
| rmc:version="7.5.0" xmi:id="-SJrpVySJ2npYs8NwGvnHjw" |
| name="arch_mechanism,_mzxI0A4LEduibvKwrGxWxA" guid="-SJrpVySJ2npYs8NwGvnHjw" authors="Mark Dickson" |
| changeDate="2009-08-14T15:33:43.942-0700" changeDescription="Simplified text explaining mechanism concept" |
| version="1.0.0"> |
| <mainDescription><h3>
 |
| What are Architectural Mechanisms?
 |
| </h3>
 |
| <p>
 |
| Architectural Mechanisms are common solutions to common problems that can be used during development to minimize
 |
| complexity.&nbsp; They represent key technical concepts that&nbsp;will be standardized across the solution.&nbsp;
 |
| Architecture mechanisms facilitate the evolution of architecturally significant aspects of the system. They allow the
 |
| team to maintain a cohesive architecture while enabling implementation details to be deferred until they really need to
 |
| be made.
 |
| </p>
 |
| <p>
 |
| Architectural Mechanisms are&nbsp;used to satisfy architecturally significant requirements. Usually those are
 |
| non-functional requirements such as performance and security issues.&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 behavior; or whether new software should be bought or built.
 |
| </p>
 |
| <p>
 |
| The value in defining architecture mechanisms is that they:
 |
| </p>
 |
| <ol>
 |
| <li>
 |
| Explicitly call out&nbsp;aspects of the solution mechanics that are common across the system. This helps you plan.
 |
| </li>
 |
| <li>
 |
| Put down markers for the developers to build those aspects of the system once and then re-use them. This reduces
 |
| the workload.
 |
| </li>
 |
| <li>
 |
| Promote 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 maturity of the mechanism's description. The state changes as successive levels of detail
 |
| are uncovered during when you refine <a class="elementLink"
 |
| href="./../../../core.tech.common.extend_supp/guidances/concepts/arch_significant_requirements_1EE5D757.html"
 |
| guid="_HrZGIA4MEduibvKwrGxWxA">Architecturally Significant Requirements</a>&nbsp;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" border="1" cellspacing="0" summary="Types of Architectural Mechanism"
 |
| cellpadding="2" width="806">
 |
| <tbody valign="top">
 |
| <tr>
 |
| <th scope="col">
 |
| State
 |
| </th>
 |
| <th scope="col">
 |
| Description
 |
| </th>
 |
| </tr>
 |
| <tr>
 |
| <td>
 |
| Analysis
 |
| </td>
 |
| <td>
 |
| <p>
 |
| 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.
 |
| </p>
 |
| </td>
 |
| </tr>
 |
| <tr>
 |
| <td>
 |
| Design
 |
| </td>
 |
| <td>
 |
| <p>
 |
| A refinement of an Analysis Mechanism into a concrete technology (for example, RDBMS). The purpose of
 |
| this category is to guide precise product or technology selection.
 |
| </p>
 |
| </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>
 |
| For more information on these different types of mechanisms, see the attached concepts.
 |
| </p>
 |
| <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.&nbsp;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.
 |
| </p>
 |
| <p>
 |
| 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" alt="Architectural Mechanism States" src="./resources/arch_mech_states.jpg"
 |
| width="600" height="113" />&nbsp;
 |
| </p>
 |
| <h3>
 |
| What Information Should be Captured for Architectural Mechanisms?
 |
| </h3>
 |
| <p>
 |
| The information captured for each architectural mechanism category/state is different (though the information can be
 |
| seen as refinements of each other):
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| <strong>Analysis Mechanisms</strong>, which give the mechanism a name, brief description and some basic
 |
| attributes&nbsp;derived from&nbsp;the project requirements
 |
| </li>
 |
| <li>
 |
| <strong>Design Mechanisms</strong>, which are more concrete and assume some details of the implementation
 |
| environment
 |
| </li>
 |
| <li>
 |
| <strong>Implementation Mechanisms</strong>, which specify the&nbsp;exact implementation of&nbsp;each mechanism
 |
| </li>
 |
| </ul>
 |
| <p>
 |
| When&nbsp;a mechanism is&nbsp;initially identified, it can be considered a marker that says to the team, "We are going
 |
| to handle this aspect of the system in a standard way. We'll figure out the details later." As the project proceeds,
 |
| the architectural mechanisms are gradually refined until they become part of the software.
 |
| </p>
 |
| <h4>
 |
| Analysis Mechanisms
 |
| </h4>
 |
| <p>
 |
| Analysis mechanisms&nbsp;are the initial state for an architectural mechanism. They are identified early in the project
 |
| and represent&nbsp;bookmarks for future software development. They allow the&nbsp;team to focus on understanding the
 |
| requirements without getting distracted by the specifics of a complex implementation. Analysis mechanisms are
 |
| discovered by surveying the requirements and looking for recurrent technical concepts.&nbsp;Security, persistence and
 |
| legacy interface are some examples of these. In effect, the analysis mechanism is where the requirements that
 |
| describe&nbsp;architecturally significant topics&nbsp;are collated and brought&nbsp;together in a single list. This
 |
| makes them easier to manage.
 |
| </p>
 |
| <p>
 |
| Analysis mechanisms are described in simple terms:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| <strong>Name:</strong> Identifies the mechanism.
 |
| </li>
 |
| <li>
 |
| <strong>Basic attributes:</strong> Define the requirements of the mechanism. These attributes can vary depending
 |
| upon the mechanism being analyzed. Refer to <a class="elementLinkWithType"
 |
| href="./../../../core.tech.common.extend_supp/guidances/examples/architectural_mechanism_attributes_B0ECA2F7.html"
 |
| guid="_eQ_s8Om5Edupia_tZIXEqg">Example: Architectural Mechanism Attributes</a>&nbsp;for more guidance.
 |
| </li>
 |
| </ul>
 |
| <p>
 |
| Once the list of analysis mechanisms has been defined it can be prioritized and the mechanisms refined in line
 |
| with&nbsp;iteration&nbsp;objectives. It is not necessary to develop the entire set of architecture mechanisms into
 |
| working software in a single pass. It is often more sensible to develop only those mechanisms required to support the
 |
| functionality to be delivered in the current iteration.
 |
| </p>
 |
| <h4>
 |
| Design Mechanisms
 |
| </h4>
 |
| <p>
 |
| Design mechanisms&nbsp;represent decisions about the concrete technologies that are going to be used to&nbsp;develop
 |
| architectural mechanisms. For example, the decision to use an RDBMS for persistence. It's often no more complicated
 |
| than that (though of course, the effort involved in making the decision can sometimes be quite complex).
 |
| </p>
 |
| <p>
 |
| The decision on when to refine an architectural mechanism from an analysis state to a design state is largely
 |
| arbitrary. Often there will be constraints on the project that&nbsp;force the decision on some of these issues. For
 |
| example, there may be a corporate standard for databases which mean that the decision&nbsp;for the&nbsp;persistence
 |
| mechanism can be made on day 1 of the project.
 |
| </p>
 |
| <p>
 |
| On other occasions the decision may point to products that the project team has not yet acquired.&nbsp;If so,&nbsp;the
 |
| decision needs to be made in time to enable the required products to be made available to the team.
 |
| </p>
 |
| <p>
 |
| It can often be useful to develop some prototype code to prove that these decisions are sound. The architect should be
 |
| confident that the technologies being selected are able to fulfill the requirements. The attributes captured against
 |
| the corresponding analysis mechanisms should be used as criteria to prove the validity of the decisions.
 |
| </p>
 |
| <h4>
 |
| Implementation Mechanism
 |
| </h4>
 |
| <p>
 |
| An implementation mechanism&nbsp;specifies the actual implementation for the architectural mechanism (hence the
 |
| name).&nbsp;It can be modeled as a design pattern or presented as&nbsp;example code.
 |
| </p>
 |
| <p>
 |
| The best time to&nbsp;produce the&nbsp;implementation mechanism is usually when the first piece of functionality that
 |
| needs it is scheduled for development. Architects and developers work together to develop this.
 |
| </p>
 |
| <p>
 |
| For examples of the kinds of information that you might capture for a mechanism, see <a class="elementLinkWithType"
 |
| href="./../../../core.tech.common.extend_supp/guidances/examples/architectural_mechanism_attributes_B0ECA2F7.html"
 |
| guid="_eQ_s8Om5Edupia_tZIXEqg">Example: Architectural Mechanism Attributes</a>.
 |
| </p></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |
