blob: ff10d5ea93dc08b01c5fe3ba7b699a3926c359f6 [file] [log] [blame]
<?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>&lt;p&gt;
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.
&lt;/p&gt;
&lt;p&gt;
Review these points when you are considering Implementation Mechanisms:
&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;
&lt;p&gt;
&lt;b&gt;Determine the ranges of characteristics.&lt;/b&gt; 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.
&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;
&lt;b&gt;Consider the cost of purchased components&lt;/b&gt;. 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.
&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;
&lt;b&gt;Conduct a search for the right components, or build the components.&lt;/b&gt; 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.&lt;br /&gt;
&lt;br /&gt;
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.
&lt;/p&gt;
&lt;/li&gt;
&lt;/ul&gt;</mainDescription>
</org.eclipse.epf.uma:ContentDescription>