Mapping Configuration
General
The Mapping Configuration is used to define which attributes from Jama Connect items are mapped to attributes from Enterprise Architect elements (and also vice versa).
A standard mapping for importing and exporting is provided with the LemonTree.Connect for Jama Connect version and can be found in
C:\ProgramData\LieberLieber\LemonTree.Connect.Jama\mapping
Tip
Relations in the mapping configuration are case sensitive, so be sure to use the correct Jama Connect Keys as described. The link names have to match the exact casing from the admin page of the relationships.
New mapping templates
Example mapping templates introducing an improved schema are placed in the mapping folder on EA startup when the old files are removed or renamed.
Import
If you start an import for the first time, the default mapping file is already chosen. You can use a different one. Or if you have changed the path, reset it to the default mapping.
Here is an explanation of the different section in the import mapping user interface:
| UI Section | Description |
|---|---|
 |
The package in the EA model, where the requirements will be imported to |
 |
The set, which should be located in a component of a project, from where the requirements will be imported in Jama Connect |
 |
The mapping file which is used for the import. A default mapping is used or can be changed if needed. There is also the possibility to validate your current mapping |
Update Mapping
It is not enough to just edit your chosen XML file, to apply the changes you also have to update the mapping of your package via Update Mapping.
On this screen you can load and view mapping configurations.
While you can edit the content here, please note this is not directly synced with your XML file.
To update or generate a mapping file outside the model use the option Export to file
Clicking Save to package updates the configuration tag of your package. Please doublecheck your setup before confirming.
Configuration Tag
Each package has a configuration tag that contains the whole mapping XML.
For an alternative way, to see and directly edit your mapping you can click the three dots next to this tag.
Default Type Mapping
Mandatory Mapping
It is necessary to map SET to Package, otherwise the import will not work!
The default mapping for an import includes following items:
| Jama Connect Item | Jama Connect Key | EA Type | EA Stereotype |
|---|---|---|---|
| set | SET | Package | |
| folder | FLD | Package | |
| stakeholder requirement | SHRQ | Class | EA Specifics 1.0::requirement |
| system requirement | SYSRQ | Class | EA Specifics 1.0::requirement |
| text | TXT | Artifact | |
| Derived from | Derived from | Dependency |
Original Key Mapping
Only the ORIGINAL set key is used. For example if you change the key of your set from SYSRQ to SYSREQ you would still have to map SYSRQ. The types original key can always be found in the administration under "Item types"
Default Attribute Mapping
The default mapping for importing form Jama Connect (external) to EA contains following attributes:
| Jama Connect Property | EA Property |
|---|---|
| id | ::Id |
| key | ::Key |
| uri | ::Uri |
| type | ::Type |
| name | Name |
| description | Documentation |
Example rule matching Jama Folders to EA Packages:
elementRule>
<matchingRule>
<externalProperty name="_objectType" value="FLD" />
<myumlProperty name="_objectType" value="Package" />
</matchingRule>
<properties>
<property external="id" myuml="::Id" />
<property external="key" myuml="::Key" />
<property external="uri" myuml="::Uri" />
<property external="type" myuml="::Type" />
<property external="name" myuml="Name" />
<property external="description" myuml="Documentation" />
</properties>
</elementRule>
Export
If you start an export for the first time, the default mapping file is already chosen. You can use a different one. Or if you have changed the path, reset it to the default mapping.
Closing Diagrams
Before you start the export all diagrams need to be saved and closed. Otherwise the export cannot start!
Here is an explanation of the different section in the export mapping user interface:
| UI Section | Description |
|---|---|
 |
The package in the EA model, which contains the architecture and will be exported |
 |
The project in Jama Connect in which the architecture elements and the links will be exported |
|
The mapping file which is used for the export. A default mapping is used or can be changed if needed. There is also the possibility to validate your current mapping |
Default Type Mapping
Mandatory Mapping
It is necessary to map SET to Package, otherwise the export will not work!
The default mapping for an export includes following items:
| Jama Connect Item | Jama Connect Key | EA Type |
|---|---|---|
| set | SET | Package |
| folder | FLD | Package |
| system architecture | SYSARCH | Class |
| Satisfied By | Satisfied By | Dependency |
| text | TXT | ea_Diagram |
Original Key Mapping
Only the ORIGINAL set key is used. For example if you change the key of your set from SYSRQ to SYSREQ you would still have to map SYSRQ. The types original key can always be found in the administration under "Item types".
Default Attribute Mapping
The default mapping for exporting from EA to Jama Connect contains following attributes:
| Jama Connect Property | EA Property |
|---|---|
| name | Name |
| description | Documentation |
Example rule matching Jama Folders to EA Packages:
<elementRule>
<matchingRule>
<externalProperty name="_objectType" value="FLD" />
<myumlProperty name="_objectType" value="Package" />
</matchingRule>
<properties>
<property external="name" myuml="Name" />
<property external="description" myuml="Documentation" />
</properties>
</elementRule>
Type Mapping
To map the type, a matchingRule is used, for example:
<matchingRule>
<externalProperty name='_objectType' value='SYSARCH'/>
<myumlProperty name='_objectType' value='Class'/>
</matchingRule>
This matching rule maps the Jama Connect item type “SYSARCH” - key for System Architecture - (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='SYSARCH'/>
<myumlProperty name='_objectType' value='Class'/>
<myumlProperty name='_stereotype' value='SysML1.4::block' />
</matchingRule>
This specific mapping only considers SysML Blocks and ignores basic 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='SYSRQ' />
<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:
<elementRule>
<matchingRule>
<externalProperty name='_linkField' value='depends_on' />
<myumlProperty name='_objectType' value='Dependency' />
<myumlProperty name='_stereotype' value='' />
</matchingRule>
</elementRule>
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:
| EA Type | XML Type | XML Stereotype |
|---|---|---|
| Attribute, Part or Required / Provided Interface | Property | |
| AcceptEventAction | AcceptEventAction | |
| ActionInputPin | ActionInputPin | |
| Activity | Activity | |
| ActivityParameterNode | ActivityParameterNode | |
| Actor | Actor | |
| Artifact | Artifact | |
| Atomic Action | OpaqueAction | |
| CallBehaviorAction | CallBehaviorAction | |
| CallOperationAction | CallOperationAction | |
| Component | Component | |
| Class | Class | |
| DataType | DataType | |
| Device | Device | |
| DeploymentSpecification | DeploymentSpecification | |
| ExecutionEnvironment | ExecutionEnvironment | |
| Enumeration | Enumeration | |
| InstanceSpecification | InstanceSpecification | |
| Interaction | Interaction | |
| Interface | Interface | |
| Node | Node | |
| OpaqueAction | OpaqueAction | |
| Operation | Operation | |
| Package | Package | |
| Property | Property | |
| Port | Port | |
| Requirement1 | Class | EA Specifics 1.0::requirement |
| Requirement (nonfunctional) | Class | EA Specifics 1.0::requirement,EAREQ::NonfunctionalRequirement |
| Requirement (functional) | Class | EA Specifics 1.0::requirement,EAREQ::FunctionalRequirement |
| Requirement (regulatory) | Class | EA Specifics 1.0::requirement,EAREQ::RegulatoryRequirement |
| Requirement (security) | Class | EA Specifics 1.0::requirement,EAREQ::SecurityRequirement |
| SendSignalAction | SendSignalAction | |
| Signal | Signal | |
| State | State | |
| StateMachine | StateMachine | |
| SysML Block | Class | SysML1.4::block |
| SysML Constraint Block | Class | SysML1.4::constraintBlock |
| SysML Full Port | Port | SysML1.4::FullPort |
| SysML Interface Block | Class | SysML1.4::InterfaceBlock |
| SysML Proxy Port | Port | SysML1.4::ProxyPort |
| SysML Requirement | Class | EA Specifics 1.0::requirement,SysML1.4::requirement |
| SysML Test Case | Activity | SysML1.4::testCase |
| Trigger | Trigger | |
| UseCase | UseCase |
Attribute Mapping in general
To map an attribute, a “property” is used:
<property external='name' myuml='Name'/>
In this example, the Jama Connect attribute “name” (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="uri" myuml="::Uri"/>
In this example, the Jama Connect attribute “uri” is mapped to an EA tagged value “Uri”. Tagged values don't have to be created upfront, as they are created on import.
Tagged values can be found in the Tags tab as part of EA properties section.
Alternatively, you can enable the Properties element tool:
Custom Profile Properties
To map properties of a custom profile their full qualified name (FQN) has to be used.
Warning
If you previously mapped via Tagged Value Map you have to remove it and adapt your mapping to use the profiles FQN.
The proper syntax is PROFILE::PROFILE_TYPE::TYPE_PROPERTY
An example using LieberLieber AUTOSAR Profile:
<elementRule>
<matchingRule>
<externalProperty name='_objectType' value='SYSARCH' />
<myumlProperty name='_objectType' value='Class' />
<myumlProperty name='_stereotype' value='AUTOSAR Behavior::AUTOSAR Software Component Implementation' />
</matchingRule>
<properties>
<property external='name' myuml='Name'/>
<property external='description' myuml='Documentation'/>
<property external='software_version' myuml='AUTOSAR Behavior::AUTOSAR Software Component Implementation::Software Version' />
</properties>
</elementRule>
Properties and stereotypes from profiles can usually be found in the element properties dialog:
For a full qualified mapping rule append the property name to the stereotype with an ::
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 |
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 Jama Connect 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='SYSRQ'/>
<myumlProperty name='_objectType' value='Class'/>
<myumlProperty name='_stereotype' value='EA Specifics 1.0::requirement' />
</matchingRule>
<properties>
<property external='name' myuml='Name'/>
<property external='description' myuml='Documentation'/>
<property external='status' myuml='EA Specifics 1.0::requirement::Status' />
</properties>
</mappingRule>
However, we recommend not using the status property from EA or Jama Connect 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.
Workflow Configuration
It is not possible to write to the Jama status field on export if configured for Workflow
Exporting "RunStates" of Objects / Instance Specifications to a custom field in Jama Connect
If you want to export the RunStates of a Object to a single field in Jama Connect, you have to create an attribute mapping with #RunStates as shown in the example below:
<elementRule>
<matchingRule>
<externalProperty name='_objectType' value='SYSARCH'/>
<myumlProperty name='_objectType' value='InstanceSpecification'/>
</matchingRule>
<properties>
<property external='title' myuml='Name'/>
<property external='description' myuml='Documentation'/>
<property external='runstates' myuml='#RunStates' />
</properties>
</elementRule>
Mapping Type "OccurrenceSpecification" or "TimeObservation
Using mapping Rules for Type "OccurrenceSpecification" or "TimeObservation" and the attribute mapping #RunStates for Instance Specifications simultaneously, is not supported and will result in a "Malformed Model Exception".
Mapping EA Connectors to Relationships
The matching rule is also used to map EA connectors to Jama Connect relationships:
<linkRule>
<matchingRule>
<externalProperty name="_linkField" value="Derived from" />
<myumlProperty name="_objectType" value="Dependency" />
</matchingRule>
<properties />
</linkRule>
In this example the relationship "Derived from" from Jama Connect (externalProperty) is mapped to the EA connector type “Dependency” (myumlProperty).
Supported link types are:
| EA Type | Mapping Type | Default Stereotype |
|---|---|---|
| Abstraction | Abstraction | |
| Aggregation | #Aggregation | |
| Association | Association | |
| CommunicationPath | CommunicationPath | |
| Composition | #Composition | |
| Connector | Connector | |
| ControlFlow | ControlFlow | |
| Dependency | Dependency | |
| Deployment | Deployment | |
| EA Trace (Abstraction) | Abstraction | EAUML::trace |
| EA Trace (Dependency) | Dependency | EAUML::trace |
| Extend | Extend | |
| Extension | Extension | |
| Generalization | Generalization | |
| Include | Include | |
| InformationFlow | InformationFlow | |
| Instantiation | Usage | StandardProfileL2::Instantiate |
| Manifest | Manifestation | |
| Nesting | Dependency | EA Specifics 1.0::nesting |
| ObjectFlow | ObjectFlow | |
| PackageImport | PackageImport | |
| Realization | Realization | |
| Transition | Transition | |
| Substitution | Substitution | |
| SysML Allocate | Abstraction | SysML1.4::allocate |
| SysML Copy | Dependency | SysML1.4::copy |
| SysML Derive | Dependency | SysML1.4::deriveReqt |
| SysML Refine | Dependency | SysML1.4::refine |
| SysML Satisfy | Dependency | SysML1.4::satisfy |
| SysML Trace | Dependency | SysML1.4::trace |
| SysML Verify | Dependency | SysML1.4::verify |
| Template Binding | TemplateBinding | |
| Usage | Usage |
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='Derived from' />
<myumlProperty name='_objectType' value='Dependency' />
<myumlProperty name='_stereotype' value='EAUML::trace' />
</matchingRule>
Another example for for an extended connector type is a satisfy connector from SysML:
<matchingRule>
<externalProperty name='_linkField' value='Derived from' />
<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
The link type EA displays can be misleading as Association\Aggregation\Composition are differntiatet by their "Aggregation" property in the target tab of the link.
- If the property is set to none, it should be mapped as Association
- If set to composite, it should be Composition
- If set to shared, it should be Aggregation
Enable reverseDirection mapping option
Jama project configuration may have a defined rule set which restricts the allowed direction of relationships.
If a rule set requires relationships to be in the reverse direction compared to EA, a mapping addition must be used.
To align the directions add reverseDirection="true" to the external matching rule as shown below.
<linkRules>
<linkRule>
<matchingRule>
<externalProperty name="_linkField" value="Satisfied By" reverseDirection="true"/>
<myumlProperty name="_objectType" value="Dependency" />
</matchingRule>
<properties />
</linkRule>
</linkRules>
-
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='SYSRQ' /> <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. ↩