| <?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="-5CLdH3UFH1QyioMJKjggvg" |
| name="practice_fw_plugin_parts,_vgjh4PG1EdyO9sYxKNWf8A" guid="-5CLdH3UFH1QyioMJKjggvg" |
| changeDate="2008-11-05T04:50:07.296-0800" version="7.2.0"> |
| <mainDescription><p>
 |
| In order to improve the configurability and navigability of a <a class="elementLink"
 |
| href="./../../../core.mdev.common.base/guidances/concepts/practice_fw_6DA4D54D.html"
 |
| guid="__LjaEFQsEd2uvIuuFjd1Fg">Practice Framework</a>&nbsp;library, the concept of plug-in parts was introduced.
 |
| “Plug-in parts” basically says that each of the&nbsp;<a class="elementLink"
 |
| href="./../../../core.mdev.common.base/guidances/concepts/practice_lib_plugin_types_3EA8002F.html"
 |
| guid="__428YO6cEdygKbJMUVNEtg">Practice Library Plug-In Types</a>&nbsp;is actually implemented as more than one
 |
| physical plug-in.&nbsp;Specifically, any plug-in that is intended to be extended, or has method elements that are
 |
| delayed assigned (e.g., contains work products and/or tasks) can be considered a “logical” plug-in that has one or more
 |
| “physical” plug-in "parts":
 |
| </p>
 |
| <p>
 |
| Figure 1 shows the plug-in parts and their relationships. In this diagam, [Plug-In X], [Plug-In Y] and [Plug-In
 |
| Z]&nbsp;represent logical plug-ins.
 |
| </p>
 |
| <p>
 |
| Figure 1. Plug-In Parts and&nbsp;their Relationships
 |
| </p>
 |
| <p>
 |
| <img alt="plugin_parts" src="resources/plugin_parts.jpg" />
 |
| </p>
 |
| <p>
 |
| The relationships shown in&nbsp;Figure 1 can be described as follows:&nbsp;
 |
| </p>
 |
| <p>
 |
| <strong>Base</strong> plug-ins contain the <u>base</u> definitions of the method elements of the logical plug-in.&nbsp;
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| A logical plug-in only has one Base plug-in&nbsp;(this makes it easy to see where the base element definitions
 |
| "live").&nbsp;
 |
| </li>
 |
| <li>
 |
| Base plug-ins may depend on other Base plug-ins (dependencies between Base plug-ins represent dependencies between
 |
| the logical plug-ins).
 |
| </li>
 |
| </ul>
 |
| <p>
 |
| <strong>Extend</strong> plug-ins contain elements that <u>extend</u> (i.e., customize) elements in the Base
 |
| plug-in.&nbsp;
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| A logical plug-in can have zero or more Extend plug-ins (a plug-in does not have to be customized and it may be
 |
| customized in different ways).&nbsp;
 |
| </li>
 |
| <li>
 |
| Extend plug-ins depend on the Base plug-in that contain the elements being extended.&nbsp;
 |
| </li>
 |
| <li>
 |
| Since there may be more than one Extend plug-in, the plug-in names should be qualified.
 |
| </li>
 |
| </ul>
 |
| <p>
 |
| <strong>Assign</strong> plug-ins contain the <u>assignment</u> of method elements in a Base or an Extend plug-in to
 |
| those things for which delayed assignment is supported (it does NOT contain all assignments).&nbsp;For more information
 |
| on delayed assignment, see <a class="elementLinkWithType"
 |
| href="./../../../core.mdev.common.base/guidances/concepts/delayed_assignment_24142865.html"
 |
| guid="_rlrykJcbEd2sTqxclDgvog">Concept: Delayed Assignment</a>.&nbsp;
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| A logical plug-in can have zero or more Assign plug-ins. If&nbsp;a&nbsp;Base (or an Extend)&nbsp;plug-in does not
 |
| contain any elements that need to be delayed assigned, then there is not an Assign plug-in.
 |
| </li>
 |
| <li>
 |
| <strong>Assignment extensions</strong>. If the logical plug-in is extended (there's an Extend plug-in) and those
 |
| extensions include things that are delayed assigned, then there needs to be an Assign plug-in for those extensions
 |
| (and the Assign plug-in is dependent on the Extend plug-in).
 |
| </li>
 |
| <li>
 |
| <strong>Alternate assignments</strong>.&nbsp; If there are alternate assignment approaches that apply to Base or
 |
| Extend plug-in&nbsp;elements, then there will be separate Assign plug-ins for the alternate assignment
 |
| schemes.<br />
 |
| Note: In actuality, only one assignment scheme should be included in a method library (or workspace) at a time and
 |
| those that are there, should always be selected (that's why these assignments are "under" the logical plug-in).
 |
| </li>
 |
| <li>
 |
| Assign plug-ins depend on the Base or Extend plug-ins&nbsp;that contain the definitions of the elements being
 |
| assigned.&nbsp;For example, an Assign plug-in may depend on the Base plug-in that contains a task, the Category
 |
| Definition Base plug-in that contains the discipline the task is being assigned to, and the Role Definition Base
 |
| plug-in that contains the definition of the role that is being assigned to the task.&nbsp;
 |
| </li>
 |
| <li>
 |
| Since there may be more than one Assign plug-in, the plug-in names should be qualified.&nbsp;Specifically, if the
 |
| assignments are for an extension, the same name qualifier should be used as was used on the Extend plug-in, so it
 |
| is easy to see why the Assign plug-in is extended.&nbsp;If the assignments are for a particular assignment scheme,
 |
| use a qualifier that indicates that scheme (e.g., maybe a specific <a class="elementLink"
 |
| href="./../../../core.mdev.common.base/guidances/termdefinitions/context_AF8B381C.html"
 |
| guid="_Kemu0PHZEdyO9sYxKNWf8A">context</a>&nbsp;and/or <a class="elementLink"
 |
| href="./../../../core.mdev.common.base/guidances/concepts/practice_config_CC7754F2.html"
 |
| guid="_0H9aAO7EEdy9EOwDlaw7Kw">Practice Configuration</a>).
 |
| </li>
 |
| </ul>
 |
| <p>
 |
| The benefits of the plug-in parts concept are:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| The <strong>separation of concerns</strong> between the: (1)&nbsp;base method element definitions, (2) extensions
 |
| to those base definitions, and (3) delayed assignment of the elements
 |
| </li>
 |
| <li>
 |
| <strong>Alternative assignment approaches are easy to define</strong>.&nbsp; Assign plug-ins are easily replaced
 |
| with alternate assignment plug-ins. That way authors can define their own role assignments to implement specific
 |
| governance processes and/or may define their own categorization schemes.
 |
| </li>
 |
| <li>
 |
| <strong>Logical plug-in extensions and assignments appear together in the library and are easy to select when
 |
| defining a configuration</strong>.&nbsp;The definition of these plug-in parts and the implementation of an
 |
| appropriate naming convention means that all parts of a plug-in are listed together in the library and can be
 |
| selected together&nbsp;when defining a&nbsp;configuration.&nbsp;
 |
| </li>
 |
| </ul></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |
