This page describes the conventions for the statements used to add precision to core component mappings.

Each UML class, attribute and association in a specific registered model has a UML dependency to an element in the core components model. To specify the transformation precisely, we can label the dependency with a statement constructed of up to 4 clauses.

• from
• where
• to
• with

1. empty statement

In simple cases the translation can be understood from the dependency without further annotation. For example an instance of the registered class AxleSpacing with two values becomes an instance of the Core Component AxleSpacing with identical values (the mapping of datatypes being specified elsewhere).

In all examples in this page the specific model element is shown on the left while the core component is shown on the right.

2. "where" clause

If the specific registered model element is more general than the core component, a "where" clause can select the subset of values for which the given mapping applies.

For example the registered class "Incident_Definition" can represent a number of distinct concepts such as abnormal loads, obstructions, hazards and weather. Without precision, this forces a mapping to the top level traffic event core component.

However, this mapping says very little and fails to convey the meaning of Incident_Definition. Instead the Incident_Definition can map to specific core components with the use of a "where" clause.

The illustration shows just two examples, and there would be more in the same style to completely cover the semantics of Incident_Definition. This is a fairly extreme example - in many cases a simple single where clause is sufficient.

3. "with" clause

A "where" clause deals with a specific registered model element being more general than its corresponding core component. It is also possible that a specific registered model could be more specific than its corresponding core component element. For example a specific registered model could have used a very specific class to represent a concept that is expressed by a particular enumeration value within a more general class in the core component. The transformation can be expressed by a "with" clause.

In this example the attribute "Category1" has two dependencies and therefore produces two attribute values in the core components: the numeric value is mapped directly to Flow.vehicles and there is an accompanying VehicleClass instance with the specified value of vehicleClass attribute, which comes from the definition of "Category1".

A "with" clause can also be used to express value mappings from attribute to attribute where the values do not use the same value domains or the same units. For example when converting an attribute from kilometres to metres, the following clause would be used:

A further example is where units are constant in the specific model but variable in the core components.

4. "to" clause

A translation will often deal with a set of related classes at the same time. The links between the instances must be preserved. In many cases an unlabelled mapping is sufficiently clear. In the example below, it is understood that the RegisteredPart instance belonging to the RegisteredWhole will map to a CoreComponentPart instance belonging to a corresponding CoreComponentWhole. If necessary a systematic rule could be expressed to formalise this understanding.

In other cases these simple mappings could be ambiguous. In the following variant the CoreComponentWhole can now have two different kinds of association to CoreComponentPart, with different semantics.

The plain mapping of classes is now ambiguous. In order to represent semantics, and in order to support a translation, we need to specify which kind of CoreComponentPart is the equivalent to a RegisteredPart when used in the context of a RegisteredWhole.

The principal way to remove ambiguity is to map the associations. By adding a dependency we specify which association is the equivalent to the registered association, and therefore which role the RegisteredPart is taking.

An alternative notation that is convenient on attribute mapping diagrams is to use a "to" clause.

The "to" clause becomes especially convenient when a registered class is used in multiple contexts and when the mapping of its attributes differs between the contexts. A single diagram showing all of this with associations would be very cluttered.

5. "from" clause

In the similar but reversed scenario, a single model element may be used in multiple contexts within an aggregating whole within the specific registered model. For example the registered class Incident uses the class TypeID to describe the type of incident and also the type of data source. The mapping shown below is ambiguous: does it apply to the TypeID of the Incident_TypeID or the TypeID of the Incident's DataSource_TypeID?

Again, the ambiguity could be removed by showing the association mappings on the same diagram, but a convenient alternative is to use a "from" clause.

6. Combining clauses in statements

It is possible to have any, all, or none of the clauses in each statement. The same mapping may also have multiple clauses of the same type.

For example a single dependency could have two sets of four clauses:

• from AClass.assocRole where anAttr == "value 1"
• to AnotherClass.RelatedClass with anotherAttr = "value 2";
• from AClass.assocRole where anAttr == "value 11"
• to YetAnotherClass.RelatedClass with yetAnotherAttr = "value 22"

7. "to" clause with "new"

Another case is where a single object instance maps to multiple core component object instances. For example one model groups pollutant measurements in a single instance while the core components have one instance per pollutant. A readable solution is to add a further keyword "new" into the "to" clause to illustrate that the presence of the attribute results in the creation of a separate core component object. This will typically be combined with a "with" clause as in the following example.

A similar approach may be used to map a single event to a pair of related events.

8. "where" clause with isKindOf()

It may be possible that attributes from an abstract base class could map to different core component elements depending on the concrete subclass. This may suggest that the core component model is not optimal, but if it does occur it may be represented by specifying "where isKindOf(concreteClassName)" in the attribute mappings for the abstract base class.

9. Further cases

• Mapping between numeric values and enumeration literals can be managed with the mechanisms described above, but the statements may be very long. For example consider the mapping between a numeric speed limit and an enumerated speed limit. The statement will take the form of:
  • "where temporarySpeedLimit = 32, with speedLimit = LIMIT_20_MPH;
  • where temporarySpeedLimit = 48, with speedLimit = LIMIT_30_MPH;" etc.
• The statements for enumeration to enumeration mappings are much more concise because there would be set of simple mappings from literal to literal.
• If a long statement would be too cluttered on the diagram, the dependency may simply say "see documentation for details", with the full statement being added to the documentation property of the dependency.
• The absence of an optional attribute may map to a specific value in core components (e.g. "false"). In this case use a where clause with the further keywords "present" or "absent" after the attribute name, i.e. "where [attribute] absent", or "where [attribute] present".
• A particularly difficult case is presented when submitted models take different approaches to state. For example a model may include constructs to support partial updates of a concept. The core components do not support such a notion, and so although the individual attributes will have corresponding core components, the wrapper construct for the partial update will not. Supporting this kind of construct is out of scope for the core component mappings.

Back to Harmonisation...