Reference sections

A reference section is a section with type “reference”. This kind of section is used to define additional relationships for the element. The following example adds two new relationships to every task – one called “accountable”, and one called “informed”. These will be added to the section “Additional Roles”.

XML:

<?xml version="1.0" encoding="UTF-8"?>
<types xmlns="http://www.ibm.com.rmc/library/usertype">
	<modifiedType id="org.eclipse.epf.uma.Task">
		<section id="com.abc.Task.addRoles" type="reference">
			<name>Additional Roles</name>
			<reference name="Accountable" id="com.abc.Task.accountable" publish="true"
				<valueType>org.eclipse.epf.uma.Role</valueType>
				<oppositeReference publish="true">
					<name>Accountable for</name>
				</oppositeReference>
				<reference_qualifiers>
					<qualifier id="com.abc.Task.accountable.reviews">Reviews</qualifier>
					<qualifier id="com.abc.Task.accountable.signs">Signs</qualifier>
				</reference_qualifiers>
			</reference>
			<reference name="Informed" id="com.abc.Task.informed" publish="true" contributeTo="roles">
				<valueType>org.eclipse.epf.uma.Role</valueType>
				<oppositeReference publish="true">
					<name>Informed by</name>
				</oppositeReference>
			</reference>
		</section>
	</modifiedType>
</types>

<reference>:

For each section of type reference, you can add any number of <reference></reference> tags to add relationships to other elements. Each <reference> must be given a name and an id. You can suppress the <reference> from publishing by setting the “publish” attribute to false.

Another useful attribute for the <reference> tag is “contributeTo”. This attribute tells MEC that the new relationship should be treated as an extension of an existing relationship, and publish it accordingly. Currently there are three scenarios where the contributeTo attribute has an effect:

1. In a modified “Task” type, contributeTo set to “roles”: this means the reference is a role relationship. When this task has been added to a process work breakdown structure, the role relationship name will appear in the the model info column, along with the standard role relationships (“performing” and “additional”).
2. In a modified “Task” type, contributeTo set to “workProduct”: this means the reference is a workProduct relationship. When this task has been added to a process work breakdown structure, the relationship name will appear in the model info column, along with standard work product relationships (“mandatory input”, “optional input”, “output”).
3. In a modified “Role” Type, contributeTo set to “workProduct”: this means the reference is a workProduct relationship. When this role has been explicitly added (as opposed to implicitly added because of a task) to a process' team allocation, the relationship name will appear in the model info column in the team allocation tab, along with any standard work product relationships (the “responsible for” relationship).

In the XML example above, the reference “Informed” will contribute to “roles” and thus “informed” will appear in the model info in the work breakdown structure that includes the task and an “informed” role.

<oppositeReference>:

<oppositeReference> is set to request Engineering Method Composer to publish a link from the assigned element to the referencing element.

For example: Using the example above, if you add an engineer role to the “accountable” reference, you get a link to the task on the “engineer” role page that is labeled “accountable for”. The “accountable for” is defined by the <name> tag inside <oppositeReference> and can be any text string. You can suppress <oppositeReference> from being published by setting the publish attribute to false, although you would probably never do this.

<reference_qualifiers>:

The reference_qualifiers tag is optional It is used to further qualify a referenced element. In the example above, “reviews” and a “signs” qualifier were added to the “Accountable” relationship using the qualifier tag nested inside <reference_qualifiers></reference_qualifiers>.

MEC Editor:

To view the results of the modifiedType, create a task element called “example_task”. Note that a new tab, called “Relationships”, is now available to input relationship references according to the modifiedType definitions.

Right underneath the task name, an expandable section is created, named “Additional Roles”. This corresponds to the <section> tag. Two reference fields are displayed, named “Accountable” and “Informed” respectively, and they correspond to the <reference> tags. For each reference field, an add button on its right allows the user to select the appropriate roles that can be linked through this reference.

Notice that when you select the referenced role in the example above, you can assign or unassign qualifiers as defined by the <reference_qualifiers> tag. If you create example capability patterns that include the “example_task”, you will see that the System Architect role is labeled "Informed" in the Model Info column. The contributeTo attribute must be set for this information to be carried across from the task to the Capability Pattern.

Browsing:

If you click the preview tab, you can view the results of this example. Notice that the new section “Additional Roles” is added in the middle with its two references.

Click on System Architect to see the opposite reference appears on the role page given the label “Informed by” and a link to the example_task.