There are many situations in which you would like to extend or annotate a model with additional information but most times the last thing you’d like to do is to change its metamodel to be able to include this new information. Changing the metamodel is a very costly process (e.g. you’ll need to recreate the modeling environment and, possibly, to migrate other existing models). Even when you have to do it, e.g. to adapt your domain-specific (modeling) language (DSML) to the new needs of the domain it was created for, you’d prefer a less traumatic evolution alternative.
As a solution, In this paper (to be presented at TOOLS Europe 2011 and co-authored by Philip Langer , Konrad Wieland , Manuel Wimmer and myself ) we propose to reuse the idea of UML Profiles for general EMF Models. Love them or hate them but UML profiles have been a key enabler for the success of UML by providing a lightweight language-inherent extension mechanism which is expressive enough to cover an important subset of adaptation scenarios. We believe a similar concept for DSMLs would provide an easier extension mechanism for EMF. As an example, the next figure shows an Ecore model in the process of being annotated with an EJB Profile
With EMF Profiles we aim at realizing the following five design principles:
- Annotating a model should be as light-weight as possible, hence, no adaption of existing metamodels should be required
- Aiming at avoiding to pollute existing metamodels with concern-specific metaclasses.
- Aiming at separating annotations from the original model to allow importing only those annotations which are of current interest for a particular modeler in a particular situation.
- Avoiding proprietary formats. Annotations shall be conforming to a formal and well-known specification such as it is known from metamodel/model conformance.
- Enabling an intuitive way of annotating models. Users should be able to use the environments and editors they are familiar with.
To embed the profile mechanism into EMF, a language for specifying profiles is needed as a first ingredient. For this, we have created an Ecore-based Profile MM
Specific profiles can now be modeled by creating instances of this profile meta-model. Given that EMF does not directly support multi-level modeling, to be able to apply these profiles on arbitrary models, we have studied two different architectural solutions (again details in the paper)
To top it off, we have also addressed the issue of reusing existing profiles to apply them to several DSMLs with the concept of generic profiles (profiles defined for generic types, independent of a concrete metamodel) and meta-profiles (where stereotypes extend meta-metaclasses and thus they become available for all models conforming to an Ecore-based metamodel).
Our EMF Profile mechanism has been implemented as Eclipse plug-in (as seen in the image above). To define a profile, modelers may apply either the tree editor generated from the Profile Metamodel or the graphical EMF Profiles Editor which is realized with GMF. The graphical notation used in this editor resembles the UML Profiles syntax. With these editors, modelers may define new profiles. Metaclasses to be extended with the profile may be imported by custom popup menu entries when right-clicking the canvas of the editor and are visualized using the graphical notation from Ecore. Application of the defined profiles can be done with any EMF-generated tree-based editor or any GMF-based diagram editor (EMF Profiles just use the standard extension points of both to integrate seamlessly with them). To apply profiles, our plug-in contributes a popup menu entry which appears whenever a model element is right-clicked. By this menu, users may apply defined profile and annotate elements with the stereotypes. When a stereotype is applied, the defined stereotype icon is attached to the model element. Furthermore, we created a Profile Applications view, which shows all applied stereotypes of the currently selected model element. For assigning the tagged values of an applied stereotype, we leverage the PropertyView which generically derives all defined tagged values from the loaded profile`s metamodel.
Our goal is somehow similar to that of the EMFFacet project so we hope to start contributing our work to that project soon!.
FNR Pearl Chair. Head of the Software Engineering RDI Unit at LIST. Affiliate Professor at University of Luxembourg. More about me.
Recent Comments