How to modify an existing method type
Modifications to an existing method type can be specified using an xml file, “user_defined_types.xml”. Any type, including both IBM Rational Method Composer (RMC) standard types and user-defined types, can be modified.
1.0 Create User-Defined Type Definition File
- In Rational Method Composer, click File > Create UDT definition to either open the wizard for a new definition file or open the existing definition file.
- If no definition file exists
- You will be prompted to select the parent folder where the new user-defined type file should be placed.
- Select either the configuration directory (for a standard library), or a configuration project folder (for a workspace-based library).
Note: The definition file will always be named “user_defined_types.xml”.
- Click Finish to open the definition file.
- You will be prompted to select the parent folder where the new user-defined type file should be placed.
- RMC will open the definition file in its built-in text editor.
Note: You may also open it from any other text editor, including XML editors.
- The definition file is ready for modifying existing types, or creating/modifying user-defined types.
Once you finish modifying the types:
- Save the work
- Click on File > Update UDT Elements
- Click OK to continue.
The changes you specified will now take effect.
2.0 Modifying Existing Type Definitions
To modify existing types, create <modifiedType></modifiedType> tags and insert them between the <types></types> tags.
The following sections describes each of the additional tags and attributes within the modifiedType tag.
Note the type modification is an library-wide modification to types. If you want to only modify a certain subset of the type elements, you may have to create separate user-defined types for that subset in order to keep similar elements unaffected.
When modifying process element types, such as "org.eclipse.epf.uma.Activity", the modifications will be available in a new relationships tab added to the Properties view.
Smart tables are not yet supported for process elements.
The id attribute is mandatory. Set to an existing type, either a preset RMC type or a user-defined type. See the section on “List of user-defined types”. The id can be any text string, although convention is to use a string that identifies the company doing the modification, followed by the id of the type being modified, and then a name for the modification.
For example: “com.abc.Task.accountable” above.
In this example, the modifiedType's id is the preset “task” type in RMC, therefore the changes will apply to all “task” type element.
A section is a named grouping of attributes and relationships. Relationships and attributes must be grouped into sections. This example adds a section called “Additional Roles” to all “task” elements; the name of the section is defined using the <name></name> tag immediately inside the section tag. In the next three chapters, we will illustrate the different uses of the section.
This attribute determines whether an RMC type can be used to create Jazz Work Item Types (see topics “Generating a Jazz Process Template” and “Updating a Jazz Project Area using Rational Method Composer” for guidance on how to create Jazz Work Item Types).
Here is an example of modifying the Work Products type in RMC so that it can be used to create Jazz Work Item Types:
<modifiedType id="org.eclipse.epf.uma.WorkProduct" isJazzWorkItemType="true"> </modifiedType>
3.0 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” described previously.
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 RMC 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:
- 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”).
- 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”).
- 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.
Inside each <reference>, you can define a <valueType> tag which restricts the type that can be set for this <reference>. In the example above, the <valueType> is set to the preset “role” element, which means only “role” elements can be added to this relationship.
<oppositeReference> is set to request RMC 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.
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>.
To view the results of the modifiedType, create a task element called “example_task”, as shown below. 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. The screenshot below shows the list of qualifiers available to be assigned.
If you create an example capability patterns that include the “example_task”, you can see the following as reflection of setting the contributeTo attribute for the reference “Informed”:
Note the Model Info column now says “Informed” for the System Architect role, since it has an “Informed” relationship to the “example_task”.
Click on the preview tab to see the results of this example:
Notice the new section “Additional Roles” is added in the middle with its two references.
Click on “System Architect”, you can see the opposite reference appears on the role page given the label “Informed by” and a link to the example_task.
The following screen shot shows the effect of “contributeTo” attribute that the given “Informed” label appears in the model info column for the System Architect.
4.0 Reference sections – tables
When you need to display some more complicated relationships in the reference section, you can add tables. The following example adds a state transition table to work products. The table defines the states that the work product can transition to, and the tasks that cause each transition.
To build a table, the section type must be “reference”. You must define the references for the table row, column, and cell. These references are defined before the table tag. In this example, there are two references, namely States and Action.
The table tag requires four attributes: id, rowReference, columnReference, and cellReference. The values of the rowReference, columnReference, and cell Reference must be the ids of references defined earlier. You will also need to give the table a name using the <name></name>tag.
You can see the table in the RMC editor by clicking on the Relationship tab.
The first part is where you can add elements in each of the references that has been defined. For instance, in the example above, States and Actions has been added.
While you are adding the reference elements, the row and column headers in the table at the bottom of the page are updated. You can then assign elements to each cell by selecting from a drop-down menu.
Once you are done with selecting table elements, you can preview the results:
Note that the table elements are all hyperlinks to the referenced element.
5.0 Rich text editor sections:
Sections can also be assigned a type “RTE”, which stands for “Rich Text Editor.” This type of section can include attributes containing rich text.
This example adds a section called “Enactment Guidance” with a text attribute “Assigning” which describes how to assign the task to an individual, and “Estimating” which provides guidance on how to estimate the effort for this task. You will need to define the name of the rte field using the <name></name> tag.
Using the same “example_task” element, you can click on the “attribute” tab to see the rich text section added and the two rich text fields that were defined for the new section.
Again, the results can be seen by clicking on the Preview tab:
Standard Types of RMC:
|RMC Element Type Name||Type ID String|
|Work Product Type||org.eclipse.epf.uma.WorkProductType|
|Work Product Descriptor||org.eclipse.epf.uma.WorkProductDescriptor|
|Role Set Grouping||org.eclipse.epf.uma.RoleSetGrouping|
Translate this page: