Common examples of mappings

Warning

This page is under construction.

To contribute or participate contact support@boost-lab.net

List of reviewed elements

Important

DomainModel mappings should usually follow the CoreModel approach.

“Common” attributes : Id, Name, Description, SameAs, ClassifiedAs

Mapping of the Id attribute as an IdentifierSelect

CoreModel: the target entity has an Id attribute.

CoreModel: the target entity does not have an Id attribute.

Mapping of the Description/Name attribute as a DescriptorSelect

CoreModel: the target entity has a Description/Name attribute.

Another way of doing it:

CoreModel: the target entity does not have a Description/Name attribute.

Mapping of the SameAs attribute as a Proxy

CoreModel: the target entity does not have a SameAs attribute.

Mapping of the Definition attribute as a ProxyItemSelect

Mapping of the ClassifiedAs attribute as a Classification

CoreModel: the target entity does not have a ClassifiedAs attribute.

Mapping of the Class attribute as a ClassSelect

Mapping of the default value /ignore and NULL

“/IGNORE/” to clearly define that this is a dummy data.

CoreModel‘s examples:

We use /IGNORE when a mandatory attribute in the ARM is being replaced by an assignment in the core model. /IGNORE indicates that the expected value will be find in an assignment.

NULL means that an attribute is not set at all . It shall not be a mandatory attribute. When we have a mandatory attribute in the ARM which has no equivalent in the core model, we need to figure out how to give it a default value in the mapping. If we cannot, it means that we are missing something in the model and we shall modify either the core or the ARM . There is a preference for an update of the CoreModel or an agreement on a default mapping value.

Example of the use of dummy instances with Initial_view_definition_context

Location of a constraint block

• A constraint block should be located in the CTC package of the related SELECT.
• If the constraint block is not related to a SELECT, the constraint block specific to a CTC should be in the CTC Package.
• We don’t create a sub-package in the CTC for “Constraint” in the Domain Model layer (unlike the CoreModel).

Use of constraint’s outputs

CoreModel‘s example:

“Rules” :

• the ouput of a constraint represents the entity (see n°1),
• represent entities by a block, when there is a need to access to specific attributes (see n°2),
• if the constraint’s ouput is a “template”, drag and drop it into the view (see n°3).

Fore more information on constraints, see Create a Simple Constraint and Using a Constraint

Questions on specific mappings from their review

In the DomainModel, the mapping of PlannedActivity:

We do not assign a property using its name.

In the DomainModel, the mapping of PropertyDefinitionAssignment:

We do not assign a Unit but a Class with tha same Name.

Inverse relationship

From the example on a BlockDefinitionDiagram that shows InterfaceSpecification and InterfaceSpecificationVersion with the part property versions shown as an association between them do the following:

Todo

1. Right click on the Association and select Specification
2. In the left hand pane click on the + sign beside the Roles
3. Select the unnamed role represented by a circle
4. Enter the name of the inverse attribute as the name of the role
5. Click on the Owned by field (should be association at present) and change that to Block (accept the change to navigability)
6. Specify the multiplicity
7. set the Is Read Only to true
8. click OK

How to represent IDENTICAL MAPPING in parametric diagrams

The proposed mapping will map the ExternalItem to an External_representation_item, then in the mapping of ExternalRepresentationItem we use this mapping (identical!) and add the name property.

How to do a mapping of a single/combined classification

See Mapping a combined Classification and Mapping a single Classification

Circular relationships in parametric diagrams

e.g. Representation and Representation_context representation_in_context attribute is an inverse (not stereotyped, set as read-only) so no need to map it !

How to map an enumeration

For example, a TwistDirection will have a counterpart enumeration in the ARM. In which case we follow a similar pattern to Select types. Create a value property on the Domain Enumeration of type ARM:enumeration (yes enumerations can have properties ;-) call this “value” [1] and public. For each enumeration literal in the domain model set the slot for the value property to be the corresponding enumeration literal from the ARM When using the enumeration in another mapping use the value property (containing the ARM enumeration) to bind in the parametric diagram. If there is no correspondence between domain and ARM then we have to extend this approach.

How to create a select mapping

Two types of SELECT’s mapping:

In both cases, no parametric diagrams

1. one port defined (but no parametric diagram) every member goes out with the same types and we have one output port, knowing that each member of the SELECT should be mapped in its own parametric diagram.

==> when SELECT contains only Block Types

eg.: DateTimeAssignmentSelect

2. No output ports

There are few of them (from the common attributes) but used everywhere.

==> when SELECT is hybrid: contains Block Types and Primitive Types

eg.: ClassSelect

1. create an output port for the SELECT in the DomainModel, typed as the SELECT object in the target ARM;
2. for each of the specializations in the DomainModel’s SELECT type, provide a SELECT mapping as a parametric diagram (inside the concerned Block), that shows how the target ARM specialization is mapped to that port.

Section author: Aminata Mbengue [Boost Conseil]