Interdependent mapping declarations for transformations that generate multiple objects from a single input object

You can author a transformation that creates multiple related objects from a single input object by using interdependent mapping declarations.

In model-to-model transformations, you can specify only one output type per mapping declaration. As a result, when you generate a transformation from the mapping declaration and run it, all the output objects are of the specified type.

You can use submap mappings within the mapping declaration to generate extractors that populate features of an output object. However, before you can create a submap mapping, the feature that you want the extractor to populate must be visible in the output type of the mapping declaration.

Note: By default, many features are filtered. You might be able to display a feature by changing the level of filtering. For more information, read the topic named "Showing and hiding features of input and output objects in mapping declarations."

If the feature that you need is not visible, the solution is to use an entire element, instead of a feature of an element, as the input object for submap mapping.

When a feature of an element is the input object for submap mapping, as is typically the case, the contents of the feature are extracted and passed to the transform of the submap. However, when an element is the input object for submap mapping, the transform passes an instance of the complete element, including all its features. As a result, in the generated transformation source code, all the features are available for subsequent transforms.

This approach is useful when the available mapping schema cannot provide submaps within the context of a single mapping declaration for all the objects that you want to generate from an input element of the mapping declaration. You can use this technique to define more than one mapping declaration, so that more than one transform is available to process the same input object.

Why all features might not be visible as submap targets

The types of the outputs, like the types of the inputs, are organized in type hierarchies. Descendants of a type extend the ancestor's type definition by adding new features to the ancestor's type. To support polymorphism, features are often of types that are not included in the type hierarchy.

For example, a feature might be of type "Classifier" rather than "Class" or "Interface." In the mapping editor you could expand the feature of type "Classifier" and see the features that a "Classifier" has. But you cannot see the features that a "Class" or "Interface" has that a "Classifier" does not have. This lack of visibility means that you cannot directly create a mapping to those added features.

Alternate solutions

The solution presented earlier has the advantage that it does not require you to write Java™ code. Two alternate solutions, both requiring custom Java code, are available, and might offer a simpler, more maintainable, or more flexible solution under certain circumstances:

  • Instead of using a submap, use a custom map and write the Java code that populates the feature at runtime.
  • Use a custom submap and write the Java code that supplies an output object and designate a feature of that object for the extractor to target. Note that this alternative typically requires much less code than the preceding alternative.

Feedback