Mapping Configuration
Configuration Tag
Starting with 3.0.0 each mapped Package now gets as it's own configuration
tagged Value. This always saves the current used iteration of your mapping and also changes how you update your mapping!
Old Configurations
If you used LemonTree.Connect for Polarion before 3.0.0, your packages will miss the configuration tag. This might lead problems so please try to update your mapping before your export or import!
To map Polarion work items to EA elements, LemonTree.Connect uses a XML style mapping configuration. There are default mappings available to get started. In order to create your own mapping we suggest you copy one of our default mappings and edit it according to your needs. Each mapping consists of a set of mapping rules where you define how an element from EA corresponds to an element from Polarion. Further details below.
Set Mapping
On the first import or export for each package you can select your chosen mapping file. Our standard mappings are preselected by default.
Update Mapping
It is not enough to just edit your chosen XML file, you also have to update the mapping of your package via Configure Mapping for Package
. This updates the configuration
tag of your package.
Please ensure that you have select the correct file before clicking Update
Configuration Tag
Each package now has a `configuration
tag that contains the whole mapping XML.
To see and directly edit your mapping you can click the three dots next to this tag.
While you can edit and copy / paste here, please note this is not directly synced with your XML file. For future application it would be prudent to persist any changes here outside the model as well.
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>
Empty Stereotype Mapping
For the export empty stereotype mapping can be added in the mapping file, for example like:
<matchingRule>
<externalProperty name='_linkField' value='depends_on' />
<myumlProperty name='_objectType' value='Dependency' />
<myumlProperty name='_stereotype' value='' />
</matchingRule>
This mapping excludes all elements with a stereotype that is not specifically mapped as well.
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:
Type Meaning | Value to use in the mapping xml |
---|---|
Attribute, Part or Required / Provided Interface | Property |
Accept Event Action | AcceptEventAction |
Action Pin | ActionInputPin |
Activity | Activity |
Activity Parameter | ActivityParameterNode |
Actor | Actor |
Artifact | Artifact |
Call Behavior Action | CallBehaviorAction |
Call Operation Action | CallOperationAction |
Component | Component |
Class | Class |
DataType | DataType |
Enumeration | Enumeration |
Object | InstanceSpecification |
Interaction | Interaction |
Interface | Interface |
Atomic Action | OpaqueAction |
Operation | Operation |
Package | Package |
Port | Port |
Requirement1 | Class (+Stereotype EA Specifics 1.0::requirement) |
Send Signal Action | SendSignalAction |
Signal | Signal |
State | State |
StateMachine | StateMachine |
Trigger | Trigger |
UseCase | UseCase |
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:
Attribute Meaning | Applies only to EA Type | Value to use in the mapping xml |
---|---|---|
Alias | MyUmlExt:Alias | |
Author | EA Specifics 1.0::Author | |
Classifier2 | #Type | |
Complexity | EA Specifics 1.0::Complexity | |
Const | Attribute | IsReadOnly |
Containment | Attribute | AggregationKind |
CreatedDate | Element Metadata 1.0::CreatedDate | |
Default Value | Parameter | DefaultValue |
Direction | Parameter | Direction |
Fixed Value | Parameter | EA Specifics 1.0::IsConst |
Initial Value | Attribute | DefaultValue |
IsCollection | Attribute | EA Specifics 1.0::Attribute::IsCollection |
Lower Bound | Attribute, Parameter | LowerBound |
ModifiedDate | Element Metadata 1.0::ModifiedDate | |
Multiplicity | All Elements like Class, Activity, Interface, etc. |
EA Specifics 1.0::Multiplicity |
Name | Name | |
Notes | Documentation | |
Phase | EA Specifics 1.0::Phase | |
Return Type | Operation | #Type2 |
Simple Type (f.e. int, boolean, etc.) | Operation, Attribute | EA Specifics 1.0::TypeString |
Status3 | EA Specifics 1.0::Status | |
Static | Attribute | IsStatic |
Stereotype | EA Specifics 1.0::StereotypeString | |
Upper Bound | Attribute, Parameter | UpperBound |
Version | EA Specifics 1.0::Version | |
Visible On4 | #VisibleOn |
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
- Aggregation
- Composition
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>
Usage of Aggregation and Composition as virtual connector types
To use Aggregation
or Composition
connector types, objectType
has to be set to #Aggregation
or #Composition
.
<mappingRule>
<matchingRule>
<externalProperty name='_linkField' value='implements'/>
<myumlProperty name='_objectType' value='#Aggregation'/>
</matchingRule>
</mappingRule>
<mappingRule>
<matchingRule>
<externalProperty name='_linkField' value='depends_on'/>
<myumlProperty name='_objectType' value='#Composition'/>
</matchingRule>
</mappingRule>
Note
Associations with "shared or composite" Target Aggregation Property now also need the virtual Type mapped. Aggregations with "shared or composite" Source Aggregation Property still need Association Type mapped.
Default Mapping
The default mapping files can be found to be found under
%programdata%\LieberLieber\LemonTree.Connect.Polarion\mapping\
Reset mapping files
If you want to reset the default mappings just delete the files from the mapping folder above and restart Enterprise Architect. This will restore them from the install folder.
Default Import Mapping
The default mapping for Import is in PolarionImportMapping.xml
.
It has the following element and connector mappings:
EA Type | EA Stereotype | Polarion Type |
---|---|---|
Class | EA Specifics 1.0::requirement | requirement |
Class | EA Specifics 1.0::requirement | systemrequirement |
Class | EA Specifics 1.0::requirement | softwarerequirement |
Class | EA Specifics 1.0::requirement | customerrequirement |
Usecase | testcase | testcase |
Link role mappings | ||
Association | relates_to | |
Dependency | depends_on | |
Realization | implements |
Default Export Mapping
The default mapping for Export is in PolarionExportMapping.xml
It has the following element and connector mappings:
EA Type | EA Stereotype | Polarion Type |
---|---|---|
Package | package | |
Class | class | |
Property | property | |
Operation | operation | |
Parameter | parameter | |
Interface | interface | |
Component | component | |
Port | port | |
Actor | actor | |
UseCase | usecase | |
Link role mappings | ||
Association | relates_to | |
Dependency | depends_on | |
Realization | implements |
-
Requirements are no valid UML types. Therefore EA uses a specific profile to define requirements. EA Requirements have to be mapped using the UML type Class and a stereotype EA Specifics 1.0::requirement. Example mapping:
↩<matchingRule> <externalProperty name='_objectType' value='requirement' /> <myumlProperty name='_objectType' value='Class' /> <myumlProperty name='_stereotype' value='EA Specifics 1.0::requirement' /> </matchingRule>
-
Classifier stands for all different kind of Elements, which are referenced by type. This includes: Type of Objects, Return Type of Operations, Type of Attributes, Type of Parameters, Type of Ports, Type of Activity Parameters, Type of Action Pins. ↩↩
-
If you use an element of type Requirement in the mapping (a Class with the Stereotype EA Specifics 1.0::requirement), you have to use the attribute name EA Specifics 1.0::requirement::Status. See Using the "Status" property of Requirements in EA for more details. ↩
-
Visible On is a special attribute provided by LemonTree.Connect to create references to diagrams, which use the exported elements. For more details, check out Export Links to Diagrams Visualizing Elements ↩