When using the Eclipse Modeling Framework (EMF), one frequently faces the problem of having to deal with several large heterogeneous and interrelated models. The information relevant for a specific user at a given time is often scattered across those models. Therefore, we often have the need for composing, weaving or simply linking (parts of) these models in order to provide a more unified and usable view of the modeled system(s).
With the currently available technologies, this is not a trivial task. Ideally, we would like to have a kind of virtual EMF resource offering a centralized and transparent access point to a global view on these different interconnected models. It should be implemented in a way such that:
- The virtual EMF resource behaves as a normal model, so interoperability (compatibility with existing EMF-based solutions/tools) is guaranteed;
- There is a perfect synchronization between the composed view (virtual resource) and the original models;
- Performance is not an issue, because neither creating nor accessing the global view results in additional costs (loading time, memory usage, etc.).
As a solution, this talk introduces the brand new Virtual EMF tool which enables users to efficiently access, handle and combine a set of interrelated EMF models in a completely transparent way.
To actually illustrate the interesting capabilities provided by this EMF-based tool, we will demonstrate how this new approach is applicable to the very common problem of traceability between different models. The concrete scenario to be shown is a reverse engineering process in which several consecutive models obtained from the same Eclipse plugins source code have to be considered and treated all together.
Using the MDT MoDisco project, you can directly get a full representation of your Java source code as EMF models. The obtained Java models, covering everything from the package’s structure to the detailed content of the methods, can be practically used for many different purposes. Still using MoDisco and related Eclipse Modeling technologies (e.g. ATL), these models can be transformed into several different views. For instance, three of them would be:
- A KDM model to extract the superstructure of the source code;
- A UML2 class model to show its internal object-oriented architecture;
- The Java model itself.
Most likely, we would like to see the traceability relationships between these different models (e.g. while looking at the UML model, we may be interested in seeing which Java model excerpt corresponds to that specific UML element). This is particularly important when the different models may be updated during the reverse engineering process, and so may have to be synchronized accordingly. We will use Virtual EMF, in this context, to implement the support for dealing transparently with all these models considering their traceability relations.
Learn more about our virtual EMF approach in this short paper!!. Slides of the talk are now also available:
FNR Pearl Chair. Head of the Software Engineering RDI Unit at LIST. Affiliate Professor at University of Luxembourg. More about me.
Hi,
I wonder why we need to compose models, the idea of DSL is silmplfy by having diffrent view point why trying now to compose them. So what is the diffrence beteween the model composed and GPL?
The difference is that the composed model is automatically generated. This allows you to get the best of both worlds. You use DSLs to facilitate the definition of specific views of the system but you’re still able to generate superviews by automatically composing the DSLs to still get the big picture
Hi Jordi,
Thanks for you answer,its better clear know, but i still got two other questions as im intersted with this field of reaserch:
Is it possible to compose several models at once, or we have to do it with pair of models?
I dont think that the composed model is automatically generated as we have to introduce a correspondence model that we have to modify it each time that we change metaelements of metamodels?
What are can be other use this kind of composition other than tracabillity stated in the example of you paper?
thanks again
Hello,
Currently we only support the composition of two models, although conceptually there are no limitations on virtualizing larger sets of models. We plan to extend the tool soon to support this functionality.
For the second question: indeed, we do not cover the whole composition process. We focus on the generation phase of composition (i.e. with inter-model relationships already identified in the form of the correspondence model), and leave the matching phase (i.e. the one that compares models and generate the correspondences) to be carried out with separately. Nevertheless, there are several existing tools/techniques to perform the matching (transformations, composition languages, …), to be chosen according the user needs, and that can be integrated with Virtual EMF.
About the links, we currently support associations (e.g. used in traceability), merging (joining elements), and filtering of elements. We plan to add support for other types of links in the future (e.g. inheritance).
Don’t hesitate to contact if you want more information!