blob: 380efab0bd6359f31f73ecc9b1e061e9ea84b92a [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" xmi:id="_5WJUUBUEEdqrUt4zetC1gg" name="descriptor,_5V9HEBUEEdqrUt4zetC1gg" guid="_5WJUUBUEEdqrUt4zetC1gg" changeDate="2005-11-15T10:35:38.218-0800">
<mainDescription>&lt;p&gt;
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.
&lt;/p&gt;
&lt;p&gt;
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.
&lt;/p&gt;
&lt;h3&gt;
Example&amp;nbsp;
&lt;/h3&gt;
&lt;p align=&quot;center&quot;&gt;
&lt;img alt=&quot;Example of Method Content referenced by Descriptor&quot; src=&quot;resources/descriptors_uml.gif&quot; /&gt;
&lt;/p&gt;
&lt;p align=&quot;center&quot;&gt;
Example of Method Content referenced by Descriptors
&lt;/p&gt;
&lt;p&gt;
&lt;br /&gt;
The above illustration depicts an example using the UML 2.0 profile representation for UMA&amp;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 &quot;Prioritize Use Cases&quot; 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:
&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;
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).
&lt;/li&gt;
&lt;li&gt;
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.
&lt;/li&gt;
&lt;/ul&gt;</mainDescription>
</org.eclipse.epf.uma:ContentDescription>