ODX Metamodel Implementation

This Ecore implementation of the ODX metamodel is based on the EMF XSD2Ecore import, followed by a post-processing in order to fix the inconsistencies, and to make the metamodel usable and optimized for further used in an Eclipse/Java/EMF environment and for model transformation rules development.

Schema Inconsistencies

Metamodel Optimizations

Here is another example of multi-valued simplification:

ODXMultiValuedExample

Common Structural Features

In order to ease ODX model handling and to make rule development more efficient, a set of abstract classes have been added, which role is to factorize and host the most common attributes and references. The name of all those classes starts with ODX prefix and ends with Object suffix.

ODXAbstractObjects

ODXIdentifiedObject is also referenced by ODXLink to point to the right identified object.

Group Types

Some classes have a group attribute which multiplicity is * and which type is several possible subtypes. In parallel, the same class has derived references to each of the subtypes. So, when the order is significant, the group attribute is translated to a reference which type is an existing super type, while the other references to subtypes are kept as derived references. If the reference is not ordered (unsignificant order), and if the super type is not existing, then references to subtypes are set to be non-derived.

Model Edition Customizations

Miscellaneous

The value (byte array) of the attributes typed HexBinary are handled in the reader and writer connectors.

The V and Vt classes cannot be optimized and must be preserved, otherwise there is no way to make the distinction between 0 default value (unset) and explicit 0 value (set to default).