0. Model Differences

Model Differences

The Ecore meta-metamodel and the model that the language Java implicitly contains are very similar but not identical. That means Ecore meta-metamodels cannot be used to represent Java code perfectly. That means some features from the language Java cannot be extracted at all. Other features can only be extracted under certain conditions.

The differences between the two models are:

• Lack of constructors: While constructors play an essential role in the object-oriented language Java, there is no counterpart in the Ecore meta-metamodel. When generating code from Ecore metamodels, objects are created with factories, and fields get their values with setters. Therefore Ecore metamodels do not need constructors. As a result, constructors cannot be extracted from Java code.
• Lack of access level modifiers: The Ecore meta-metamodel does not have access level modifiers. It also does not have any similar counterpart. When generating code from Ecore metamodels, methods and types are created public. EAttributes and EReferences are generated as private fields. For these fields, accessor methods are generated. This leaves two options: Either the extraction of all methods as EOperations, even if their access level modifiers will not match their generated counterparts, or restricting the extraction of elements depending on their access level modifiers (e.g., be buildthat only extracting public methods and attributes).
• Lack of abstract methods: While Ecore metamodel certainly does have abstract EClasses, there are no abstract EOperations as a counterpart to abstract methods in the language Java. This means abstract methods can only be extracted as normal EOperations or cannot be extracted at all.
• Lack of a static concept: The language Java differs between static elements and object-oriented elements. That means one can create static attributes and methods, which do not need object instantiation. Those attributes and methods can be accessed through the class directly. The Ecore meta-metamodel has not such a static concept. As a result, attributes and methods can only be extracted as normal (object-oriented) EAttributes, EReferences, and EOperations or cannot be extracted at all.
• Different understanding of enumerations In the Ecore meta-metamodel EEnums are EDataTypes. That means their functionality is very limited. In the language Java, Enumerations have many features, which classes or interfaces have. An Enumeration is more like a class or an interface. This causes the following differences:
  • Lack of interfaces for enumerations
  • Lack of methods for enumerations
  • Lack of attributes for enumerations
• Lack of external super types: In an Ecore metamodel, EClasses can only inherit from EClasses within the metamodel. Also, EClasses can only realize EClasses from within the metamodel. That means so called external super types are not possible. In the language Java this feature is available. For example, it is possible to create a class that inherits from the project external class LinkedList. That means for every extracted type whose super type is not a type in the project, there will be a loss of semantic information.
• Lack of direct array support: There is no direct support for arrays in the Ecore meta-metamodel. The most collections are modeled through ELists. That means there is no direct counterpart for Arrays when extracting Ecore metamodels from Java code.
• Containment of external data types: Attributes whose types are external types and references to external types need EDataTypes to depict that relation in an Ecore metamodel. That means for every external type there is an EDataType in the metamodel. These EDataTypes have to be contained in EPackages of the metamodel. Because EDataTypes whose names are similar cannot be contained in the same EPackage, a package hierarchybe built for EDataTypes. This hierarchy is not part of the original package hierarchy of the Java project.
• Lack of nested types: While the language Java gives the possibility to nest types (Classes, interfaces, and enumerations) into other types, this feature is not available in the Ecore meta-metamodel. This means inner types have no direct counterpart for the extraction. Nested types can either be extracted as normal types with a special naming scheme (which can lead to class name collisions), or they can be extracted in an additional subpackage named after their outer types (which can lead to package name collisions), or cannot be extracted at all.

For more information about how the model differences affect the extraction of Ecore metamodels see the thesis, as a part of which this project was developed for.