| <?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="-fr4NS-AIAVE2DWBEN30Zaw" |
| name="new_guideline,_bAjgIIAhEd2RgsZLwhqsAA" guid="-fr4NS-AIAVE2DWBEN30Zaw" changeDate="2008-09-11T09:52:30.953-0700" |
| version="7.5.0"> |
| <mainDescription><p>
 |
| Method packages represent a set of selectable method content elements that provide the user with flexibility in
 |
| choosing what portions of the method he wants to publish. Method elements in one package can reference elements in
 |
| another package.
 |
| </p>
 |
| <p>
 |
| Method packages should be used to represent logical units for useful configurations – sets of elements that should
 |
| either be included together in a configuration or excluded from a configuration. The user can choose which packages to
 |
| include in the published site by making selections in the configuration.
 |
| </p>
 |
| <p>
 |
| Consider packaging very carefully to provide flexibility in what is published. For example, you could put all of the
 |
| tool mentors for a specific tool into a single content package.&nbsp; This makes it very easy for someone to deselect
 |
| the tool mentors from publication.<br />
 |
| <br />
 |
| Packages should be defined so that selecting all packages does not result in overlapping or conflicting content. If
 |
| alternatives are needed, separate plug-ins should be defined, not just separate packages.
 |
| </p>
 |
| <p>
 |
| Method packages can also be used to collect obvious categories of content to make it easy to find things, as opposed to
 |
| just seeing a long list of elements.&nbsp;
 |
| </p>
 |
| <p>
 |
| The following sections provide guidelines on the use of the two types of packages: method content packages and process
 |
| packages.
 |
| </p>
 |
| <p>
 |
| For recommendations on naming content packages, see <a class="elementLinkWithType"
 |
| href="./../../../core.mdev.common.base/guidances/guidelines/method_element_naming_conventions_4A4F743B.html"
 |
| guid="_lAphAF5-EduT-Px7fh0LSg">Guideline: Method Element Naming Conventions</a>.
 |
| </p>
 |
| <p>
 |
| &nbsp;&nbsp; &nbsp;
 |
| </p>
 |
| <h3>
 |
| Method content packages
 |
| </h3>
 |
| <p>
 |
| There are several organizational strategies that can be applied to refine the method content packaging structure.&nbsp;
 |
| </p>
 |
| <h4>
 |
| Option 1: Organizing the content packages along the major areas of concern of the plug-in.
 |
| </h4>
 |
| <p>
 |
| When organizing the method content packages of the plug-in along the plug-in’s major areas of concern, group all method
 |
| content that supports a specific area of concern together in the same (or sub-) content packages.
 |
| </p>
 |
| <p>
 |
| The pros of organizing the content packages along the plug-in’s major areas of concern are as follows:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| It is easy for users configuring the method to select only those areas of concern that they are interested in.
 |
| </li>
 |
| <li>
 |
| The method package structure truly reflects the architecture of the plug-in itself, where each content package is
 |
| cohesive, but loosely coupled with other packages.
 |
| </li>
 |
| <li>
 |
| A plug-in’s content package structure should not be dependent on the base library package structure, which may
 |
| change at any time.
 |
| </li>
 |
| </ul>
 |
| <p>
 |
| The cons of organizing the content packages along the plug-in’s major areas of concern are as follows:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| When the plug-in’s package structure is not aligned the base library’s package structure, it is harder to see what
 |
| plug-in content packages should be selected when specific base content packages are selected. When the packages are
 |
| aligned, it is easy to see where the plug-in content fits into the base content.
 |
| </li>
 |
| </ul>
 |
| <h4>
 |
| Option 2: Echo the packaging used in the base plug-in.
 |
| </h4>
 |
| <p>
 |
| In this approach, align the content package with the base plug-ins content packages. Define a content package structure
 |
| that looks just like the base plug-in’s and place the method content elements in the most appropriate package.
 |
| </p>
 |
| <p>
 |
| If content is contributed to only one or two packages of the base plug-in, rather than to most packages, echo only that
 |
| portion of the base plug-in structure that is needed. For instance, if the base package \Design\Visual Modeling is the
 |
| only package modified, echo only the base plug-in packaging structure of \Visual Modeling and its eventual
 |
| sub-packages.
 |
| </p>
 |
| <p>
 |
| The pros of aligning the plug-in package structure with the base content’s are as follows:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| When the packages are aligned, it is easy to see where the plug-in contents fit into the base plug-in.
 |
| </li>
 |
| <li>
 |
| It also preserves the package selection choices provided by the base plug-in for publication.
 |
| </li>
 |
| </ul>
 |
| <p>
 |
| The cons of aligning the plug-in package structure with the base plug-in’s are as follows:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| The plug-in structure does not reflect its architecture, but instead reflects the base plug-in’s architecture,
 |
| which can change at any time.
 |
| </li>
 |
| </ul>
 |
| <p>
 |
| Method elements that support specific aspects of the plug-in are not packaged together, so it is not easy to select
 |
| relevant subsets of content to be included in a configuration.<br />
 |
| <br />
 |
| &nbsp;&nbsp;
 |
| </p>
 |
| <h3>
 |
| Process packages
 |
| </h3>
 |
| <p>
 |
| Process packages organize processes so they can be managed and located easily. The Configuration View is often used
 |
| when defining new processes because drag and drop is enabled from this view into the process editors. In this view,
 |
| plug-in divisions are not shown, so it can sometimes be helpful to define process packages in plug-ins as the process
 |
| packaging hierarchy for each plug-in is preserved.&nbsp;For example, you may want to put all processes in a plug-in in
 |
| a process package that is named&nbsp;to represent the plug-in.&nbsp; If a plug-in has many processes, you may want to
 |
| define subpackages.&nbsp;
 |
| </p>
 |
| <p>
 |
| In most cases,&nbsp;process packages are used for capability patterns only (the number of delivery processes is usually
 |
| so small,&nbsp;packages are not&nbsp; needed).&nbsp;
 |
| </p>
 |
| <p>
 |
| For recommendations on naming process packages, see see <a class="elementLinkWithType"
 |
| href="./../../../core.mdev.common.base/guidances/guidelines/method_element_naming_conventions_4A4F743B.html"
 |
| guid="_lAphAF5-EduT-Px7fh0LSg">Guideline: Method Element Naming Conventions</a>.
 |
| </p></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |
