Composite EMF Models
Composite EMF Models is a component-oriented extension for the Eclipse Modeling Framework. Its purpose is to facilitate the development of interconnected models.
Although EMF supports distributed modeling by splitting model files in several resources, this is no real "logical" separation in terms of components. All model elements are usable by referencing models and if the referenced model changes, inconsistencies may arise.
Composite EMF Models is a research project intended to overcome these issues by introducing Export and Import interfaces. Export interfaces specify which model elements of the main model, called Body, should be exposed to other models, i.e. are part of the public API. Import interfaces specify which elements of a Body model are to be required from some Export interface. Instances of Export/Import interfaces are delegate objects that forward feature-requests towards the "original" object: Export objects delegate to their Body, Import objects redirect requests made on their Body to their Export.
Extended Ecore meta-model
Export and Import interfaces are defined as an EExport/EImport model.
They are both a specialization of the Ecore meta-model. EPackage, EClass, EAttribute and EReference are subclassed and equipped with
one (EExport) resp. two (EImport) references: For example,
ExportedClass has a reference bodyClass : EClass,
ImportedAttribute has references exportedAttribute : ExportedAttribute and bodyAttribute : EAttribute,
and so on. Any Ecore model can be used as Body model.
The interface models can have a "simpler" structure than those they refer to, i.e. an Export interface may consist of only a subset of the classes and features of the Body model. The tool provides support for deriving an interface model from a Body model.
Composite "network" structure
So we have several models referencing each other, but how do we know what component a specific model belongs to? Body, Export and Import models can be encapsulated in a Component and such a component can be registered in a dedicated Component Registry. A Component is a simple wrapper object that references the parts that make up the component. Composite EMF Models also includes a graphical (GMF-based) diagram-editor that provides a "network" view on a set of components.
Concrete import/export objects serve one purpose: they delegate between the instances that import from each other. An export object has a reference to the Body object it represents. Whenever you ask an export object for the current value of an attribute, the export object delegates this request to the Body object. Import objects point to an Export object and to a Body object. The Body object does not "know" it is imported, so it can't delegate to the import on its own. For this reason we use AspectJ Load Time Weaving to plant the body-to-import delegation code. Delegation from import to export is done by the export itself.
Composite EMF Models can be used with the CDO (Connected Data Objects) framework. The editors supplied with CompoEMF come in an extended version with CDO support and an Eclipse view for managing CDO repositories and creating composite model instances in them. This allows distributing composite models in a real-world scenario in a client-server like fashion.
CompoHenshin model transformation language
CompoHenshin is a transformation language that facilitates the systematic transformation of Composite EMF models. By using CompoHenshin, developers can define and execute transformation rules that specify queries and manipulations of export and import objects, a feature not provided by conventional transformation languages. CompoHenshin is an extension to the meta-model, graphical editor, and interpreter kernel of the Henshin model transformation language