Automatic generation of UML profile graphical editors for Papyrus

Papyrus offers, among other choices, the mechanism of creating UML profiles using a Profile Diagram editor. Users can use the palette provided in the UML Profile Diagram editor to create all elements required to form a UML profile. The properties of each element (e.g. data types of properties, multiplicity, navigability, etc.) can then be set using the properties view. In a profile, each Stereotype needs to extend a UML concept (hereby referred to as meta-element). The users need to define which meta-elements their Stereotypes extend. This is achieved by importing the meta-elements and by adding appropriate extension links between their Stereotypes and the meta-elements by using the tool provided in the palette. The process of creating a UML profile can be repetitive and labour-intensive, depending on the size of the profile. Having created a profile, users can then apply it to a UML model. To do this, users typically create instances of UML meta-elements (e.g. UML::Class) and apply their Stereotypes defined in their UML profiles. For example, if a Stereotype extends the UML::Class meta-element, users can apply it to selected instances of UML::Class in their models. In this sense, the users are creating instances of the elements they define in their DSLs.

One of the limitations of UML profiles in Papyrus is that links between Stereotypes can be instantiated as edges in a diagram only if they extend a connector meta-element (e.g. UML::Association). For example, if ‘Stereotype A’ refers to ‘Stereotype B’ via an ‘A_to_B’ reference, then in order to be able to draw this connection as an edge on the diagram, ‘A_to_B’ should be created as a separate Stereotype. These connector Stereotypes do not hold any information about the Stereotypes that they can connect, so users need to define such restrictions by manually writing OCL constraints to validate at least two things: (1) if the source and target nodes are of the correct type and (2) if the connector is in the correct direction (e.g. for ‘A_to_B’), the edge should lead from ‘Stereotype A’ to ‘Stereotype B’. These constraints can be rather long and need to be manually written and customised for each edge Stereotype. As illustrated in Sect. 4.3, this can also be a labour-intensive and error-prone process.

With the UML profile created, users can apply it to UML diagrams. Users select a UML element (e.g. an instance of UML::Class) and manually apply a Stereotype in the UML profile they define. A Stereotype can only be applied to instances of the meta-elements they extend. For example, a Stereotype that extends the UML::Package meta-element in the profile cannot be applied to an instance of UML::Class. This task is arguably labour-intensive and repetitive. In addition, users typically need to remember the meta-element that each Stereotype extends in their UML profile.

To address this recurring concern, Papyrus offers at least three possible options for creating a custom palette which allows users to create UML elements and apply selected Stereotypes on them in a single step. For the first option, users can make use of the customisation facility to create their own palettes and then specify what Stereotypes should be instantiated for the creation tools in the palette. Although this is an easy-to-use approach, it must be done manually every time a new diagram is created. In addition, it cannot be shared in case the editor needs to be distributed to collaborators. The second option involves the manual definition of an XML-based Palette Configuration file which is automatically loaded every time the profile is applied to a diagram. This option, however, is discouraged by Papyrus as it does not allow the full use of Papyrus functionality. Furthermore, this option is based on a deprecated framework; hence, its use is discouraged. The third option is to create a Papyrus editor associated with the UML profile, which includes the manual creation of a number of interrelated models and artefacts, including a Palette Configuration model, an ElementTypesConfiguration model, which is used to associate Stereotypes in the UML profile with its UML meta-element and the concrete syntax of the meta-element, etc. Although this option provides a whole solution to create a UML profile editor, in the paper we illustrate that it is a labour-intensive and error-prone process.

The definition of custom shapes for the instantiated Stereotypes is another common requirement. In Papyrus, Scalable Vector Graphics (SVG) shapes can be bound to Stereotypes during the profile creation process. However, to make these shapes visible, users need to set the visibility of the shape of each Stereotype to true. Although this is an acceptable trade-off, the users typically need to hide the default shapes by writing custom style rules in a Cascading Style Sheet (CSS), as by default the SVG shape bound to a Stereotype overlaps with the default shape of the base meta-element. The CSS can be written once but need to be loaded each time manually on every diagram that is created.

To create a distributable (i.e. an Eclipse plug-in) graphical editor that has diagrams tailored for the profile and to avoid all the aforementioned drawbacks, users need to create a number of interrelated models and files and to implement extension points in an Eclipse plug-in project. Figure 1 shows all the artefacts needed to be created for having a distributable Papyrus UML profile editor for Papyrus 3.0+¹. These artefacts include:Through our experiment (see Sect. 5), we found out that it is difficult, if not impossible, to create these models without any working examples, taking also into account that the documentation of Papyrus provides limited useful insight in this matter.

Detailed discussions about the artefacts needed in order to create a UML profile editor are provided in Sect. 4. A few hundred lines of code need to be written, while tedious and repetitive tasks (e.g. model creation) should be done. This is backed by our studies in the evaluation, which is discussed in Sect. 5.

As mentioned in [25], in different phases of the system engineering process, different metamodels created using the same modelling language could be used based on the current phase’s needs. Papyrus opted for the option allows the definition of UML profiles based on the UML specifications defined by the OMG standard. As a result, it may be the case that problems, when using tools that implement UML, arise due to the use of an inappropriate version of the metamodel by the tool vendors. Examples of solutions in tackling such problems that are a result of potential design flaws in OMG specifications are presented in [3] and [26]. However, our personal experience, which is verified by the evaluation results, shows that the problems with the creation of UML profiles and graphical editors in Papyrus arise from the labour-intensive and repetitive tasks related mostly in the definition of all the other artefacts (which are a result of a design decision by the tool vendor) rather than the UML profile itself. We argue that this labour-intensive, repetitive and error-prone tasks could be automated.

In this paper, we present our tool—Jorvik, which uses a single-source input to automatically generate a UML profile and models/files mentioned above for the generation of a distributable Papyrus editor that supports the UML profile.

In this example, we define a DSL—the Simple Development Process Language (SDPL)—in an annotated Ecore metamodel and we generate the corresponding UML profile and Papyrus graphical editor using Jorvik. We start by defining the abstract syntax of the DSL using Emfatic⁴, a textual notation for Ecore, which is shown in Listing 1 (ignore the annotations at this point). A process defined in SDPL consists of Steps, Tools and Persons participating in it. Each ‘Person’ is familiar with certain ‘Tools’ and can have different Roles in steps of a process, while each ‘Step’ refers to the next step that follows using the next reference.

In order to generate the UML profile and the Papyrus graphical editor, we need to add the following concrete syntax-related annotations shown in Listing 1. Due to the relevance of our work with Eugenia [28], a tool that uses the same principles for the generation of GMF editors and inspired our work, and to be as consistent as possible, the syntax of our annotations match those in Eugenia, where possible.

The automated M2M and M2T transformations are then executed on the Ecore file, and the produced SDPL Papyrus editor (with supporting palette and custom shapes for the SDPL profile) is presented in Fig. 3.

The generated editor is fully functional, but it can be further customised to fit the users’ custom needs. For example, by default, our automatic transformations dictate the diagram, through the CSS file to show the Stereotype name applied to each node. However, in this example we want to hide the Stereotype names and display labels in red font. This can be achieved by manually amending the generated CSS file. However, the CSS file will be automatically overridden if the user regenerates the profile and the editor in the future (e.g. because of a change in the metamodel). To avoid this, users can use the *optional* CSS generation polishing transformation (#5b in Fig. 4) shown in Listing 2. Every time the profile and editor generation is executed, the polishing transformation will be executed, which will set the visibility of the Stereotypes to false automatically.

The EGL template in Listing 2 generates a CSS rule in lines 1–3 that sets the visibility property of the Stereotypes’ labels to false. It stores all the elements in the Ecore metamodel that are annotated as @Node (line 6) in a collection and iterates though them in lines 7–10. For each of the node Stereotypes, it generates the static text ‘[appliedStereotypes =’ followed by the name of each Stereotype and a comma. At the end, it prints the curly brackets (lines 10 and 12) and the text ‘fontColor:red;’ in line 11. The resulted output that is amended automatically in the original CSS file (by the polishing transformation) is shown in Listing 4.

To check the correctness of the annotated Ecore metamodel, a model validation program is first executed against the metamodel. The program is written using EVL and consists of several rules that check if the annotated Ecore elements have all the necessary information (e.g. a UML base class) and if the values provided are correct (e.g. font size for labels is a positive integer). Listing 5 presents an example of a rule written in EVL which checks if the value provided for the ‘bold’ details in a @Node annotation is correct (i.e. true or false) ⁷.

Table 1 enumerates all the rules included in the pre-transformation validation step along with their descriptions and the conditions that are checked.

The EMF to UML profile generation executes a model-to-model transformation written in ETL. The source model of this transformation is the annotated Ecore metamodel (e.g. Listing 1), and the target model is a UML profile model. This transformation consists of two main rules, one that creates a Stereotype for each EClass element of the metamodel and a second that creates a Stereotype for each EReference annotated as @Edge:When all Stereotypes are created, a number of post-transformation operations are executed to (1) create the generalisation relationships between the Stereotypes, (2) add the references/containment relationships between the Stereotypes, (3) create the extension with the UML base meta-element and (4) generate and add the needed OCL constraints for each edge:

To illustrate the OCL constraints, we provide a partial view of the SDPL UML profile in Fig. 5⁸.

In Fig. 5, there are three Stereotypes. ‘Person’ and ‘Tool’ extend meta-element UML::Class, and they correspond to classes ‘Person’ and ‘Tool’ in the metamodel shown in Listing 1. Stereotype ‘familiarWith’, which extends meta-element UML::Association, corresponds to the reference‘familiarWith’ in the ‘Person’ class in Listing 1. In Fig. 3, the ‘familiarWith’ association is used to connect ‘Person Alice’ with ‘Tool StarUML’. However, Papyrus, by default, allows the ‘familiarWith’: Stereotype to be applied to any Association, and not strictly to Associations which connect ‘Person’ and ‘Tool’ stereotyped elements. Therefore, constraints are needed to check (at least) two aspects:

Apart from the UML profile, Papyrus graphical editors require an Element Types Configuration model, which associates the Stereotypes defined in the UML profile with their abstract syntax (the meta-elements in UML they extend) and their concrete syntax (the graphical notations of the meta-elements in UML they extend)¹⁰.

This transformation is responsible for creating an Element Types Configuration model (of extension .elementtypesconfiguration) that contains type specialisation information for the Stereotypes in the UML profile. For each element of type Stereotype, two SpecializationTypeConfigurations are created, one links the Stereotype to its UML meta-element, and another links the Stereotype to the concrete syntax of its UML meta-element. For example, a Stereotype that extends UML::Class needs to specialise the UML::Class MetamodelTypeConfiguration defined in the UML Element Types Configuration model, and it needs to specialise the Class Shape SpecializationTypeConfiguration defined in the UML diagram Element Types Configuration model¹¹. In addition to SpecializationTypeConfigurations, for each Stereotype element an ApplyStereotypeAdviceConfiguration needs to be created, which associates the SpecializationTypeConfiguration to the actual Stereotype in the UML profile.

This transformation is responsible for creating a Palette Configuration model (of extension .paletteconfiguration) that configures the contents of the custom palette for the diagram in Papyrus. The model conforms to the PaletteConfiguration metamodel that ships with Papyrus. The transformation creates a new PaletteConfiguration element and adds two new DrawerConfiguration elements that represent two different tool compartments in our palette (i.e. one for the tools that create nodes and one for those creating edges). For each element in the Ecore metamodel annotated as @Node/@Edge, a new ToolConfiguration element is created and added to the nodes/edges drawer, respectively. The kind of ToolConfiguration is decided based on the @Node/@Edge annotation. For nodes, the kind is CreationTool while for edges, the kind is ConnectionTool. An IconDescriptor element is also created and added to the ToolConfiguration pointing to the path of the icon for that tool. (This is the path passed as argument to the icon property of the @Node/@Edge annotation.) Finally, each ToolConfiguration needs to refer to the element types they conform to, which are defined in the Element Types Configuration model transformed in Step #3. In this way, when an element is created in the diagram using the palette, behind the scene, Papyrus is able to locate the Stereotype element and determine the UML syntax it specialises.

As stated above, the look and feel of diagram elements in Papyrus can be customised using CSS. In this transformation, we generate our default CSS style rules that define the appearance of nodes and edges in diagrams. Each node on a diagram has a set of compartments where the attributes, shapes, etc. appear. Initially, for all nodes that will appear on the diagram, we create a CSS rule to hide all their compartments and another rule to enable the compartment that holds the shape. The latter rule also hides the default shape inherited from the meta-element that the Stereotype extends. Then, for each Stereotype that appears as a node, a CSS rule is generated to place the SVG figure in the shape compartment. For elements of type Stereotype, the assignment of the SVG shapes to the Stereotypes is achieved by assigning the path of the SVG file to the svgFile property available in CSS. Finally, we generate the CSS rules for each edge, e.g. if a lineStyle parameter is set, then the lineStyle property for that Stereotype is set to the value of the lineStyle parameter (e.g. ‘solid’, ‘dashed’, etc.).

In order for Papyrus to create a diagram, it requires the initialisation of the diagram. The creation command is a Java class which is responsible for initialising Papyrus diagrams. The creation command class is needed since Papyrus 3.0+. The rationale for the creation command is that it creates a UML model from the UMLFactory as the root element of the diagram. The minimal requirement for diagram initialisations is:In order to apply the user-defined UML profiles, they need to use the pathmap defined in their plug-ins, which is explained in #8. The Java class is generated using a model-to-text transformation written in EGL.

Papyrus adopted the notion of an Architecture model in order to describe the architecture of the graphical editors since Papyrus 3.0+. This transformation synthesises an Architecture model using a model creation program written in the Epsilon Object Language (EOL) [30]. The program needs 1) the annotated Ecore metamodel for the DSL, 2) the Element Types Configuration model and 3) the Palette Configuration model; thus, it should be executed after the transformations that generate the latter 2 artefacts (i.e. Steps #3 and #4). In particular, in the Architecture model, the generation program creates:The Architecture model then needs to be registered and acts as the entry point to all the models/files for a Papyrus editor, which is done in Step #9.

Jorvik supports the generation of the UML profile and its supporting editor in either a new Eclipse plug-in project or in the same Eclipse plug-in project where the annotated Ecore metamodel resides. In both scenarios, the ‘MANIFEST.MF’, the ‘build.properties’ and the ‘plugin.xml’ files are created (or overridden respectively). The ‘plugin.xml’ file includes all the necessary extensions for Papyrus to be able to register the UML profile and create the diagrams (e.g. extensions that point to the Architecture model). For the creation of a Papyrus editor, in the ‘plugin.xml’, three extension points need to be implemented:For the scenario where the Papyrus plug-in is created as a new project, the shapes (SVG files) and the icons (PNG files) are copied to the newly created plug-in project.

Finally, two files that only consist of the XML and the XMI header (namely ‘*.profile.di’ and ‘*.profile.notation’) are generated. These files are necessary for Papyrus to construct the UML profile model¹².

This M2T transformation generates the ETL file that can be used to transform the UML models created in Papyrus and conform to the UML profile generated by our approach, back to EMF models that conform to the source Ecore metamodel given as input to the approach. The reason behind this is to allow the users to propagate any changes they make in their transformed UML profiles back to their EMF models. One rule is generated for each of the Stereotypes that transforms them back to the appropriate type of the Ecore metamodel. Each Stereotype has the same attributes and references as the original EClass; therefore, this EGL script also generates the statements in each rule that populate the attributes and the references of the newly created instance of each EClass with the equivalent values of the UML model. An example of an auto-generated rule is shown in Listing 8. This rule transforms elements stereotyped as ‘Person’ in the UML model to elements of type ‘Person’ in an EMF model which conforms to the Ecore metamodel presented in Listing 1.

ETL provides the \({:}{:}=\) operator for rule resolution. When \(::=\) is used, the ETL execution engine inspects the established transformation traces and invokes the applicable rules (if necessary) to calculate the counterparts of the source elements contained in the collection.

In our example (line 6 in Listing 8), the expression ‘s.familiarWith’ returns a collection of UMLProcess!Tools (denoted by ct). By using ‘::=’, the ETL engine will look for the rules that transform UMLProcess!Tool to EMFProcess!Tool and invoke the rules if necessary (if the source elements have not been transformed, as shown in the transformation trace) and put the transformed elements into sub-collections (denoted by sc). After the ETL engine goes through all the elements in ct, the sub-collections scs are returned (flattened to a single collection if more than one) and are added to ‘t.familiarWith’.

For transformations #2–#5, users are able to define polishing transformations (#2b–#5b, whereas #2b–#4b are model-to-model transformations and #5b is a model-to-text transformation) that complement those included in our implementation. After each built-in transformation is executed, the workflow looks to find a transformation with the same file name next to the Ecore metamodel. If a file with the same name exists, it is executed against the Ecore metamodel and targets the already created output model of the original transformation. The execution of the polishing transformation is set not to overwrite the target model but to refine it instead. Table 2 shows the names that each polishing transformation is expected to have.

In EMF, a reference between two classes can be flagged as a containment relation, which is consistent with the containment definition of UML associations (with exception of the deletion cascade mechanism). These types of relations, when presented visually, can benefit from showing the contained elements shapes inside the shape of the container, as opposed to the line/arrow presentation. For example, if a package is represented with an empty rectangle, classes contained in the package would appear inside this rectangle.

However, our generated editors do not offer some special features that the Archimate for Papyrus tool offers. For example, Archimate for Papyrus offers a third drawer in the palette for some diagrams that is called ‘Common’ and includes two tools (named ‘Grouping’ and ‘Comment’). Another feature that is not supported by our default transformations is the fact that in Archimate for Papyrus, users are able to have the elements represented either by their shapes or by a coloured rectangle depending on the CSS class applied to them. Finally, Archimate for Papyrus also organises the creation of the Junction (which is a node that acts as a junction for edges) node in the relations’ drawer in the palette. In order to be able to implement such missing features, we need to write the extra polishing transformations. We do not go into details of the polishing transformations for this specific example¹⁴.

In our previous work [49], we compared our approach with Archimate for Papyrus. However, as we mentioned in Sect. 2, Papyrus changed its underlying metamodels and the mechanism for creating UML-specific editors. To ensure that our results are still valid for Papyrus 3.0+, we regenerated all the Archimate editors using Jorvik. We add the lines of code needed for Jorvik to our findings in the previous work.

Table 3 summarises the efficiency of Jorvik, both for Jorvik pre-Papyrus 3.0 version and for Jorvik post-Papyrus 3.0 version¹⁵. To make a fair comparison, we count both the lines of code and the number of model elements in each artefact that constitutes to a working editor. Hence, the numbers in Table 3 are shown in the format of Lines of Code/Number of Model Elements. For artefacts which are not models (e.g. the CSS file), we only provide the lines of code metric as well for artefacts created by polishing transformations in Jorvik, as these were generated by the polishing transformation scripts.

For Jorvik pre-Papyrus 3.0 (columns under Jorvik (pre-Papyrus 3.0)), we need to manually create five annotated Ecore metamodels, which involve writing 436 lines of code in Emfatic, which is equivalent to 668 model elements. For polishing transformations, we need to write 11 lines of code in the transformation script for Element Types Configuration, 50 lines for Palette Configuration, 195 lines for CSS and 10 lines for types configuration. For Jorvik post-Papyrus 3.0 (columns under Jorvik (post-Papyrus 3.0)), we need the same Ecore metamodels (i.e. five); thus, the numbers do not change. For polishing transformations, we need to write 50 lines for the Palette Configuration and 195 lines for CSS.

It can be observed from the numbers, for Jorvik, we create 63.5% less objects, and we write 63.7% code in CSS in order to produce editors that matches the original Archimate for Papyrus editors. In addition to the working editors (which offer the same functionalities and features as the original Archimat for Papyrus tool), Jorvik also produces the OCL constraints for the profiles, as well as the ETL transformations which allows the interoperability from UML profiles to annotated EMF metamodels.

In addition to the generation of the Archimate profile/editors, we test Jorvik with nine more Ecore metamodels from different domains. The names of the metamodels (including Archimate) and their size (in terms of types) are provided in Table 4. Next to the size, in parenthesis, the number of types that should be transformed so they can be instantiated as nodes/edges is also provided.

As illustrated in Table 4, the metamodels vary in size, from small profiles (with five Stereotypes) to large profiles (with up to 57 Stereotypes). The approach is able to produce the profiles and the editors for all metamodels, demonstrating that it can be used to generate the desired artefacts for a wide spectrum of domains. The time needed for the generation varies from milliseconds up to a few seconds. In the future, we plan to assess further the scalability of our approach using larger metamodels.

We have argued that Jorvik provides significant gains in productivity when building custom UML Profile editors for Papyrus. We design a user experiment to substantiate our claim and quantify the productivity improvement. As discussed in Sect. 4, there are eight major steps to be taken in order to create a UML profile as well as its supporting editor. In this experiment, we compare the time needed to develop an editor using Papyrus infrastructure (hereby referred to as the Papyrus approach) with the time needed to develop the same editor using Jorvik. For the Papyrus approach, we design eight tasks, each with its own deadline (see Table 5) for the participants to complete towards manually creating a UML profile and a working UML editor for the profile. For Jorvik, we design one task for the participants to complete to automatically generate a UML profile and a working UML editor for that profile. We ask two participants to take part in the experiment and work on two profiles we choose. We record the time taken for the participants to complete the experiment using both approaches and we compare the times.

Building on the powerful concepts and semantics of UML, and its wide adoption in modelling artefacts of object oriented software and systems, UML profiles enable the development of DSLs by extending (and constraining) elements from the UML metamodel [13]. More specifically, UML profiles make use of extension mechanisms (e.g. Stereotypes, tagged definitions and constraints) through which engineers can specialise generic UML elements and define DSLs that conform to the concepts and nature of specific application domains [40]. Compared to creating a tailor-made DSL by defining its metamodel and developing supporting tools from scratch, the use of UML profiles introduces several benefits including lightweight language extension, dynamic model extension, model-based representation, preservation of metamodel state and employment of already available UML-based tools [33]. Driven by these benefits, several UML profiles have been standardised by the OMG including MARTE [17] and SySML [12]) which are now included in most widely used UML tools (e.g. Papyrus [34]).

In safety-critical application domains such as railway, avionics and network infrastructures, developed UML profiles support the specification and examination of security patterns [6, 38], analysis of intrusion detection scenarios [22] and modelling and verification of safety-critical software [5, 45, 50].

Other researchers have designed UML profiles for the specification [9, 35] and visualisation of design patterns [10]. Also, [42] proposes a methodology for formalising the semantics of UML profiles based on fUML [20], a subset of UML limited to composite structures, classes and activities with a precise execution semantics. For an analysis of qualitative characteristics of several UML profiles and a discussion of adopted practices for UML profiling definition, see [37]. Likewise, interested readers can find a comprehensive review on execution of UML and UML profiles in [7].

Irrespective of the way these UML profiles were developed, either following ad hoc processes or based on guidelines for designing well-structured UML profiles [13, 40], they required substantial designer effort. Also, the learning curve for new designers interested in exploring whether UML profiles suit their business needs is steep [15]. In contrast, Jorvik automates the process of generating UML profiles using a single annotated Ecore metamodel and reduces significantly the developer’s effort for specifying, designing and validating UML Papyrus profiles (cf. Sect. 5).

Relevant to Jorvik is research introducing methodologies for the automatic generation of UML profiles from an Ecore-based metamodel [31]. The work in [32] proposes a partially automated approach for generating UML profiles using a set of specific design patterns. However, this approach requires the manual definition of an initial UML profile skeleton, which is typically a tedious and error-prone task [47]. The methodology introduced in [15, 16] facilitates the derivation of a UML profile using a simpler DSL as input. The methodology requires the manual definition of an intermediate metamodel that captures the abstract syntax to be integrated into a UML profile. The intermediate metamodel is then compared against the UML metamodel to identify a set of required UML extensions, as well as the transformation of the intermediate metamodel into a corresponding functioning UML profile. Similarly, [31] introduces an approach for the automatic derivation of a UML profile and a corresponding set of OCL expressions for Stereotype attributes using annotated MOF-based metamodels. Another relevant research work is JUMP [4] that supports the automatic generation of profiles from annotated Java libraries [4]. Despite the potential of these approaches, they usually involve non-trivial human-driven tasks, e.g. a UML profile skeleton [32] or an intermediate metamodel [15, 16], or have limited capabilities (e.g. support of UML profile derivation with generation of OCL constraints [31]). In contrast, Jorvik builds on top of standard Ecore metamodels that form the building blocks of MDE [18]. Furthermore, Jorvik facilitates the development of a full-fledged UML profile and a distributable Papyrus graphical editor including the generation of OCL constraints and the definition of optional polishing transformations (cf. Sect. 4.11).

Jorvik also subsumes research that focuses on bridging the gap between MOF-based metamodels (e.g. Ecore) and UML profiles. In [2], the authors propose a methodology that consumes a UML profile and its corresponding Ecore metamodel and uses M2M transformation and model weaving to transform UML models to Ecore models, and vice versa. The methodology proposed in [47] simplifies the specification of mappings between a profile and its corresponding Ecore metamodel using a dedicated bridging language. Through an automatic generation process that consumes these mappings, the technique produces UML profiles and suitable model transformations. Along the same path, the approach in [14] employs an integration metamodel to facilitate the interchange of modelling information between Ecore-based models and UML models. Compared to this research, Jorvik automatically generates UML profiles (like [47] and [14]), but requires only a single annotated Ecore metamodel and does not need any mediator languages [47] or integration metamodels [14]. Also, the transformation of models from UML profiles to Ecore is only a small part of our generic approach (Sect. 4.10) that generates not only a full-fledged UML profile but also a distributable custom graphical editor as an Eclipse plug-in.

There are a number of works that use MDE techniques to generate modelling facilities for models. The most widely used tool for graphical modelling is the Graphical Modelling Framework [1] (GMF) provides editor generation facilities for EMF models. GMF provides the foundation for a number of tools. However, as stated in [28], creating graphical editors in GMF typically involves non-trivial, repetitive and error-prone tasks. Hence, a number of tools emerged, such as Sirius [43], Eugenia [28] and Papyrus. While other tools focus on creating editing facilities for EMF models, Papyrus provides an open-source solution for UML modelling and UML Profiling.

It is to be noted that editors are only one particular aspect of an MDE environment supporting UML profiles. There are a number of tools which focus on transformations, validations, code generations and comparison tools for UML models. For example, a work which addresses the generation of basic change operations over UML profile models has been presented in [3, 26].