| <?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="-Rex8oOBv985RruZNrCW0rg" name="implementation_mechanisms,_3ANskOK5EdqHEo0wLIc5jg" guid="-Rex8oOBv985RruZNrCW0rg" changeDate="2006-09-25T21:09:13.255+0100" version="1.0.0"> |
| <mainDescription><p> |
| An Implementation Mechanism is a refinement of a corresponding Design Mechanism that uses, for example, a particular |
| programming language and other implementation technology (such as a particular vendor's middleware product). An |
| Implementation Mechanism may instantiate one or more idioms or implementation patterns. |
| </p> |
| <p> |
| Review these points when you are considering Implementation Mechanisms: |
| </p> |
| <ul> |
| <li> |
| <p> |
| <b>Determine the ranges of characteristics.</b> Take the characteristics that you identified for the Design |
| Mechanisms into consideration to determine reasonable, economical, or feasible ranges of values to use in the |
| Implementation Mechanism candidate. |
| </p> |
| </li> |
| <li> |
| <p> |
| <b>Consider the cost of purchased components</b>. For Implementation Mechanism candidates, consider the cost of |
| licensing, the maturity of the product, your history or relationship with the vendor, support, and so forth in |
| addition to purely technical criteria. |
| </p> |
| </li> |
| <li> |
| <p> |
| <b>Conduct a search for the right components, or build the components.</b> You will often find that there is no |
| apparently suitable Implementation Mechanism for a particular Design Mechanism. This will either trigger a |
| search for the right product or make the need for in-house development apparent. You may also find that some |
| Implementation Mechanisms are not used at all.<br /> |
| <br /> |
| The choice of Implementation Mechanisms is based not only on a good match for the technical characteristics, |
| but also on the non-technical characteristics, such as cost. Some of the choices may be provisional. Almost all |
| have some risks attached to them. Performance, robustness, and scalability are nearly always concerns and must |
| be validated by evaluation, exploratory prototyping, or inclusion in the architectural prototype. |
| </p> |
| </li> |
| </ul></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |