| <?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="-rsHCan4NDJUYJeoK5s-DBA" |
| name="new_guideline,__428YO6cEdygKbJMUVNEtg" guid="-rsHCan4NDJUYJeoK5s-DBA" changeDate="2008-11-05T09:48:31.125-0800" |
| version="7.2.0"> |
| <mainDescription><p>
 |
| In order to ensure that the plug-ins within the <a class="elementLink"
 |
| href="./../../../core.mdev.common.base/guidances/concepts/practice_fw_6DA4D54D.html"
 |
| guid="__LjaEFQsEd2uvIuuFjd1Fg">Practice Framework</a>&nbsp;library&nbsp;fit together nicely and to maximize reuse
 |
| across elements, specific plug-in types are defined. Such a consistent approach for how plug-ins are structured allows
 |
| true plug-and-play between content authored by different groups and ensures that remotely authored content integrates
 |
| seamlessly into the overall library. To support this, individual plug-in types can be defined to define each the
 |
| important separate areas of concern.&nbsp;Plug-ins&nbsp;can then follow a consistent packaging structure for the actual
 |
| content based on the plug-in's type.
 |
| </p>
 |
| <p>
 |
| Figure 1 summarizes the types of plug-ins that should be defined when defining a practice framework&nbsp;library, as
 |
| well as the allowable dependencies between these plug-in types.
 |
| </p>
 |
| <p>
 |
| Figure 1. Practice Framework Library Plug-In Types and their Relationships
 |
| </p><br />
 |
| <br />
 |
| <p>
 |
| <img height="443" alt="plugin_types_and_their_relationships" src="./resources/plugin_types.jpg" width="338" />
 |
| </p>
 |
| <p>
 |
| The plug-ins shown in&nbsp;Figure 1 and&nbsp; described below are "logical" plug-ins. As described in the "Plug-in
 |
| parts" section below, each logical plug-in may be represented by a number of individual "plug-in parts". In other
 |
| works, for every logical plug-in, there may be more than one physical plug-in.
 |
| </p>
 |
| <p>
 |
| <strong>Core</strong> plug-ins contain the elements intended to be shared between other plug-ins in the
 |
| framework.&nbsp; They provide the foundation of the framework and enable reuse across the elements in the framework
 |
| (e.g., <a class="elementLink" href="./../../../core.default.uma_concept.base/guidances/concepts/practice_F5C8EAAB.html"
 |
| guid="_qhCTAFRREd2CWscN8Mx6rg">Practice</a>s and <a class="elementLink"
 |
| href="./../../../core.default.uma_concept.base/guidances/termdefinitions/process_68E308B4.html"
 |
| guid="_yQ5m2NnmEdmO6L4XMImrsA">process</a>es). The core elements serve used as a foundation for defining how the
 |
| various different types of content will fit together.&nbsp;Specifically, include elements that serve as the interface
 |
| between practices (<a class="elementLink"
 |
| href="./../../../core.mdev.common.base/guidances/concepts/work_product_slot_D5B44CE7.html"
 |
| guid="_Er1OcJIfEdybeduord13cg">Work Product Slot</a>s), as well as key reusable elements such as work products or
 |
| guidance that are intended to be used in a variety of different practices (i.e., shared across practice plug-ins).
 |
| </p>
 |
| <p>
 |
| <strong>Practice</strong> plug-ins contain the&nbsp;practice&nbsp;elements.&nbsp;There is&nbsp;a Practice plug-in per
 |
| practice.&nbsp;Practice plug-ins only depend on Core plug-ins (thus enabling them to be plugged and played).<br />
 |
| Exception: Some practices are defined by reusing content from other practices (e.g., booster practices). For example, a
 |
| practice may be defined to pre-configure a set of practices into one and then provide some value-added extensions to
 |
| the whole.
 |
| </p>
 |
| <p>
 |
| <strong>Process</strong> plug-ins contain the elements that define <a class="elementLink"
 |
| href="./../../../core.mdev.common.base/guidances/termdefinitions/cross_practice_process_5F83B112.html"
 |
| guid="_9NcfoFJgEd2SzrMjC_svdw">cross-practice process</a>es that are intended to be shared across configurations
 |
| (practice-specific processes are contained in Practice plug-ins and configuration-specific processes are contained in
 |
| Publish plug-ins). Cross-practice processes are assembled from elements (<a class="elementLink"
 |
| href="./../../../core.default.uma_concept.base/guidances/termdefinitions/task_6C1FF051.html"
 |
| guid="_x459ktnmEdmO6L4XMImrsA">task</a>s and/or processes) contained in Practice plug-ins and possibly other Process
 |
| plug-ins.&nbsp;Process plug-ins include the processes themselves, as well as any process-specific extensions to
 |
| existing elements that are needed to make the various parts of the process work and fit together. There can by any
 |
| number of process plug-ins; however, an attempt should be made to group similar processes that always appear together
 |
| in the same process plug-in.&nbsp;For example, you may define a Process plug-in for a particular process family, for a
 |
| set of processes that share a common lifecycle approach/style and/or for all of the processes included in a specific
 |
| method asset.Process plug-ins can depend on Core plug-ins (for shared elements), Practice plug-ins (for
 |
| practice-specific elements to included in the process) and Process plug-ins (for shared processes).
 |
| </p>
 |
| <p>
 |
| <strong>Publish</strong> plug-ins contain method elements that are unique to a specific configuration that is being
 |
| published. For example, a Publish plug-in might contain some configuration-specific navigation views, roadmaps, a
 |
| welcome page, an so on. A Publish plug-in may even include process, if that process is configuration-specific.
 |
| </p>
 |
| <p>
 |
| In summary, the practice framework plug-in types represent how the key concepts are implemented physically (i.e., how
 |
| the practice framework library is organized around practices):
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| The practices themselves (<strong>Practice</strong> plug-ins)
 |
| </li>
 |
| <li>
 |
| The elements that are shared across practices (<strong>Core</strong> plug-ins)
 |
| </li>
 |
| <li>
 |
| The processes that are assembled from the practices and that are shared across
 |
| configurations&nbsp;(<strong>Process</strong> plug-ins)
 |
| </li>
 |
| <li>
 |
| The elements that support a specific Publishable configuration (<strong>Publish</strong> plug-ins). For more
 |
| information on Publishable configurations, see <a class="elementLinkWithType"
 |
| href="./../../../core.mdev.common.base/guidances/concepts/practice_lib_config_types_B96A959A.html"
 |
| guid="_1gchoO6dEdygKbJMUVNEtg">Concept: Practice Library Configuration Types</a>.
 |
| </li>
 |
| </ul>
 |
| <p>
 |
| The separation of shared elements (Core plug-ins), practice-specific elements (Practice plug-ins) and cross-practice
 |
| elements (Process and Publish plug-ins) maximizes reuse between the elements in the framework (practices share core
 |
| elements and&nbsp;cross-practice processes share practice and&nbsp;core elements)
 |
| </p>
 |
| <h3>
 |
| Plug-in parts
 |
| </h3>
 |
| <p>
 |
| In order to improve the configurability and navigability of the practice framework library (as well as to implement <a
 |
| class="elementLink" href="./../../../core.mdev.common.base/guidances/concepts/delayed_assignment_24142865.html"
 |
| guid="_rlrykJcbEd2sTqxclDgvog">Delayed Assignment</a>), the concept of plug-in parts was introduced.&nbsp; For more
 |
| information on this, see <a class="elementLinkWithType"
 |
| href="./../../../core.mdev.common.base/guidances/concepts/practice_lib_plugin_parts_538A81D.html"
 |
| guid="_vgjh4PG1EdyO9sYxKNWf8A">Concept: Practice Library Plug-In Parts</a>.
 |
| </p></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |
