Mapping Configuration

To map Polarion work items to EA elements, LemonTree.Connect uses two separate mapping files for import and export:

• %programdata%\LieberLieber\LemonTree.Connect.Polarion\mapping\PolarionImportMapping.xml
• %programdata%\LieberLieber\LemonTree.Connect.Polarion\mapping\PolarionExportMapping.xml

Default Mapping Configuration

The default import mapping has the following element and connector mappings:

The default export mapping has the following element and connector mappings:

Each mapping consists of a set of mapping rules where you define how an element from EA corresponds to an element from Polarion.

Type Mapping

To map the type, a matchingRule is used, for example:

<matchingRule>
    <externalProperty name='_objectType' value='block'/>
    <myumlProperty name='_objectType' value='Class'/>
</matchingRule>

This matching rule maps the Polarion work item type “block” (externalProperty) to the EA element type “Class” (myumlProperty).

Class is a generic element type, which would also include SysML Blocks, since they derive from UML Classes. In order to define a more specific mapping the matching rule has to be extended by a stereotype:

<matchingRule>
    <externalProperty name='_objectType' value='block'/>
    <myumlProperty name='_objectType' value='Class'/>
    <myumlProperty name='_stereotype' value='SysML1.4::block' />
</matchingRule>

This specific mapping only considers SysML Blocks and ignores UML Classes.

Another example of a special type mapping is the EA element type Requirement. Since requirements do not exist in the base UML definition, a special stereotype needs to be used to map requirements:

<matchingRule>
            <externalProperty name='_objectType' value='feature' />
            <myumlProperty name='_objectType' value='Class' />
            <myumlProperty name='_stereotype' value='EA Specifics 1.0::requirement' />
</matchingRule>

Supported EA Element Types

LemonTree Connect uses different terms for element types and attribute names. In the mapping file, you have to use the LemonTree Connect specific names in order to properly map those element types. Please refer to the following table below:

Attribute Mapping

To map an attribute, a “property” is used:

<property external='title' myuml='Name'/>

In this example, the Polarion attribute “title” (external) is mapped to the EA attribute “Name” (myuml).

If you want to use custom EA attributes (=tagged values), you can use the same mechanism of the property mapping, but use a double “:” in front of the attribute name:

<property external="priority" myuml="::Priority"/>

In this example, the Polarion attribute “priority” is mapped to an EA tagged value “Priority”. A tagged value will be created by the import if it does not exist. Tagged values don’t have to be created upfront.

A tagged value can be found in the EA properties on an element:

Alternatively, you can enable the tagged value dialog:

Supported EA Attributes

LemonTree Connect uses different terms for element types and attribute names. In the mapping file, you have to use the LemonTree Connect specific names in order to properly map those attributes. If an attribute can only be used for specific EA Types (f.e. "Fixed Value" is a specific attribute of a Parameter), it is mentioned in the column "Applies only to EA Type". If it can be used with many types, the column is empty.

Please refer to the following table below:

Using the "Status" property of Requirements in EA

In order to save and visualize the status property of requirements in EA properly, the attribute mapping has to be done in a specific way. 

If you want the importer to write the status of the Polarion item into the EA status property, you have to create an attribute mapping that looks like this:

<property external='reqStatus' myuml='EA Specifics 1.0::requirement::Status' />

Here is an example of using the status property with a SysML requirement:

<mappingRule>
    <matchingRule>
        <externalProperty name='_objectType' value='requirement'/>
        <myumlProperty name='_objectType' value='Class'/>
        <myumlProperty name='_stereotype' value='EA Specifics 1.0::requirement' />
    </matchingRule>
    <properties>
        <property external='title' myuml='Name'/>
        <property external='description' myuml='Documentation'/>
        <property external='reqStatus' myuml='EA Specifics 1.0::requirement::Status' />
    </properties>
</mappingRule>

However, we recommend not using the status property from EA or Polarion for attribute mappings. In both tools, the status properties have predefined values, which should be set directly in the tool, with the allowed values and they might be related to specific workflows and / or state transitions.

Mapping EA Connectors to Work Item Link Roles

To map EA connectors to Polarion Work Item Link Roles, the matching rule is also used:

<matchingRule>
    <externalProperty name='_linkField' value='implements' />
    <myumlProperty name='_objectType' value='Realization' />
</matchingRule>

In this example the link role “implements” from Polarion (externalProperty) is mapped to the EA connector type “Realization” (myumlProperty). In order to use Polaron Link Roles, you have to use the ID of the defined linke role in the mapping file.

Supported link types are:

• Association
• Dependency
• Generalization
• Realization

If you want to use extended connectors you have to use stereotypes. For example, a trace connector in EA is a dependency with the stereotype EAUML::trace. For a trace connector, the matching rule would look like this:

<matchingRule>
    <externalProperty name='_linkField' value='implements' />
    <myumlProperty name='_objectType' value='Dependency' />
    <myumlProperty name='_stereotype' value='EAUML::trace' />
</matchingRule>

Another example for a extended connector type is a satisfy connector from SysML:

<matchingRule>
    <externalProperty name='_linkField' value='implements' />
    <myumlProperty name='_objectType' value='Dependency' />
    <myumlProperty name='_stereotype' value='SysML1.4::satisfy' />
</matchingRule>