| <?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" xmi:id="_5WJUUBUEEdqrUt4zetC1gg" name="descriptor,_5V9HEBUEEdqrUt4zetC1gg" guid="_5WJUUBUEEdqrUt4zetC1gg" changeDate="2005-11-15T10:35:38.218-0800"> |
| <mainDescription><p> |
| A Descriptor represent an occurrence of one concrete Content Element (such as Task, Role, Work Product) in an Activity. |
| Descriptors provides a proxy-like representation for these Content Elements within breakdown structures. In addition to |
| just referencing Content Elements it allows overriding the Content Elements' structural relationships by defining its |
| own sets of associations. |
| </p> |
| <p> |
| Descriptors are a key concept for realizing the separation of Processes from Method Content. A Descriptor can be |
| characterized as a reference object for one particular Content Element, which has its own relationships and properties. |
| When a Descriptor is created, it has the same relationships as the referenced Content Element. However, users can |
| modify these relationships for the particular process situation for which the Descriptor has been created. The |
| Descriptor concept allows defining new relationships and specific process related properties. Descriptors are not |
| Content Elements and do not contain their own full descriptions. They refer or trace back to the Content Elements they |
| are based on instead. |
| </p> |
| <h3> |
| Example&nbsp; |
| </h3> |
| <p align="center"> |
| <img alt="Example of Method Content referenced by Descriptor" src="resources/descriptors_uml.gif" /> |
| </p> |
| <p align="center"> |
| Example of Method Content referenced by Descriptors |
| </p> |
| <p> |
| <br /> |
| The above illustration depicts an example using the UML 2.0 profile representation for UMA&nbsp;in which Descriptors |
| have been created for a Task, its performing Roles, as well as its input/output Work Products. The situation implied by |
| this example is that the Task "Prioritize Use Cases" is to be performed differently in a project's Inception phase than |
| in its Elaboration phase. (that is, with different emphasis on different Steps, utilizing different inputs, etc.). In |
| particular, we can observe the following: |
| </p> |
| <ul> |
| <li> |
| The Task in Inception has an additional assisting Role (Customer.Project Manager) and does not provide a |
| relationship to the Risk List Work Product that had been defined as an optional input in the Method Content (that |
| is, Steps of the Task that work with the Risk List will be omitted in this phase). |
| </li> |
| <li> |
| Two different types of Use Case Model Work Products are distinguished here: a Use Case Model as it is normally |
| being used during Inception, which describes use cases only briefly, versus use cases that have been detailed as it |
| is the case during the Elaboration phase. |
| </li> |
| </ul></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |