| <?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:rmc="http://www.ibm.com/rmc" rmc:version="7.5.0" xmlns:epf="http://www.eclipse.org/epf" |
| epf:version="1.5.0" xmi:id="_S8KCcMP2EdmWKcx6ixEiwg" |
| name="analysis_mechanism,_0gvqoMlgEdmt3adZL5Dmdw" guid="_S8KCcMP2EdmWKcx6ixEiwg" |
| changeDate="2008-02-09T13:19:23.718-0800" version="1.0.0"> |
| <mainDescription><p>
 |
| An Analysis Mechanism is a conceptual representation of an <a class="elementLink" href="./../../../core.tech.common.extend_supp/guidances/concepts/arch_mechanism_2932DFB6.html" guid="_mzxI0A4LEduibvKwrGxWxA">Architectural Mechanisms</a>. Over time, Analysis Mechanisms are refined into <a class="elementLink" href="./../../../core.tech.common.extend_supp/guidances/concepts/design_mechanism_CE197B4E.html" guid="_w2ACwA4LEduibvKwrGxWxA">Design Mechanism</a>s&nbsp;and, later, into <a class="elementLink" href="./../../../core.tech.common.extend_supp/guidances/concepts/implementation_mechanism_C92E670B.html" guid="_0LcUkA4LEduibvKwrGxWxA">Implementation Mechanism</a>s.
 |
| </p>
 |
| <p>
 |
| Analysis Mechanisms&nbsp;allow the developer to focus on understanding the requirements without getting distracted by
 |
| the specifics of a complex implementation. They are a way of abstracting away the complexity of the solution, so people
 |
| can better comprehend the problem.
 |
| </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.
 |
| </li>
 |
| </ul>
 |
| <p>
 |
| You can identify Analysis Mechanisms top-down, from previous knowledge, or bottom-up, meaning that you discover them as
 |
| you proceed.
 |
| </p>
 |
| <p>
 |
| In the top-down mode, you are guided by experience -- you know that certain problems are present in the domain and will
 |
| require certain kinds of solutions. Examples of common architectural problems that might be expressed as mechanisms
 |
| during analysis are: persistence, transaction management, fault management, messaging, and inference engines. The
 |
| common aspect of all of these is that each is a general capability of a broad class of systems, and each provides
 |
| functionality that interacts with or supports the basic application functionality. The Analysis Mechanisms support
 |
| capabilities required in the basic functional requirements of the system, regardless of the platform that it is
 |
| deployed upon or the implementation language. Analysis Mechanisms also can be designed and implemented in different
 |
| ways. Generally, there will be more than one design mechanism that corresponds with each Analysis Mechanism. There may
 |
| also be more than one way of implementing each design mechanism.
 |
| </p>
 |
| <p>
 |
| The bottom-up approach is where Analysis Mechanisms ultimately originate. They are created as the you see, perhaps
 |
| faintly at first, a common theme emerging from a set of solutions to various problems. For example: There is a need to
 |
| provide a way for elements in different threads to synchronize their clocks, and there is a need for a common way of
 |
| allocating resources. <a class="elementLink" href="./../../../core.tech.common.extend_supp/guidances/concepts/analysis_mechanism_8369C159.html" guid="_0gvqoMlgEdmt3adZL5Dmdw">Analysis Mechanism</a>s, which simplify the language of analysis, emerge from these
 |
| patterns.
 |
| </p>
 |
| <p>
 |
| Identifying an Analysis Mechanism means that you identify a common, perhaps implicit&nbsp;subproblem, and you give it a
 |
| name. Initially, the name might be all that exists. For example, the system will require a persistence
 |
| mechanism.&nbsp;Ultimately, this mechanism will be implemented through the collaboration of various classes, some of
 |
| which do not deliver application functionality directly, but exist only to support it. Very often these support classes
 |
| are located in the middle or lower layers of a layered architecture, thereby providing a common support service to all
 |
| application-level classes.
 |
| </p>
 |
| <p>
 |
| If the subproblem that you identify is common enough, perhaps a pattern exists from which the mechanism can be
 |
| instantiated, probably by binding existing classes and implementing new ones, as required by the pattern. An Analysis
 |
| Mechanism produced this way will be abstract, and it will require further refinement throughout design and
 |
| implementation work.
 |
| </p>
 |
| <p>
 |
| You can see examples of how Architectural Mechanisms can be represented in <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> |
