Automated migration of EuGENia graphical editors to the web

Domain-specific languages (DSLs) are languages tailored for particular domains. Many frameworks and tools have been proposed to develop editors for DSLs, especially for desktop IDEs, like Eclipse. We are witnessing the advent of low-code development platforms, which are cloud-based environments supporting rapid application development by using graphical languages and forms. While this approach is very promising, the creation of new low-code platforms may require the migration of existing desktop-based editors to the web. However, this is a technically challenging task. To fill this gap, we present ROCCO, a tool that migrates Eclipse-based graphical modelling editors to the web, to facilitate their integration with low-code platforms. The tool reads a meta-model annotated with EuGENia annotations, and generates a web editor using the DPG web framework used by the UGROUND company. In this paper, we present the approach, including tool support and an evaluation based on migrating nine editors created by third parties, which shows the usefulness of the tool.


INTRODUCTION
Model-Driven Engineering (MDE) [29] is a software paradigm that prescribes an active use of models during the construction process. Thus, models are used to describe, validate, simulate, generate code and maintain the software, among many other activities. These models can be built using general-purpose modelling languages, such as the Unified Modelling Language (UML), but the use of Domain-Specific Languages (DSLs) is also common [16].
DSLs are languages tailored to a specific problem, containing customized concepts representing the abstractions within the domain [10,21,22]. This way, the definition of (graphical) DSLs, and their modelling environments is recurrent when building MDE solutions [15]. The benefit of using a DSL is that it can lead to more effective solutions within a domain, while allowing end-users with little technical background to perform programming tasks [17]. In the last years, many tools have been developed to automate the construction of DSL editors [5, 8, 11-14, 19, 25, 30, 34], especially since the popularization of extensible IDEs like Eclipse. Still, the development of DSL editors, in particular for graphical DSLs is a challenging task.
We have recently witnessed the advent of low-code development platforms, which are cloud-based environments supporting the rapid development of applications by using graphical languages and forms. While this approach is very promising, the creation of new low-code platforms may profit from the reuse of existing MDE solutions in a cloud environment. This implies the migration of existing desktop-based editors to the web. However, without automation, this is a technically challenging task.
In order to fill this gap, we propose a tool to automate the migration of Eclipse-based graphical DSL editors to the web. In particular, the tool supports editors built using EuGENia [8] and creates an editor for DPG-PsiEngine [2,3]. This is a web-based framework used within UGROUND as a basis for its ROSE low-code development platform [7]. This way, our solution enables the automated reuse of DSL editors within low-code environments, eliminating the need for re-developing such editors. We have evaluated our tool by migrating nine editors built by third parties, obtaining good results, and demonstrating the applicability of this tool in practice.
The rest of this paper is organized as follows. Section 2 provides background on technologies used in our work, and introduces a running example. Section 3 describes our approach to migration, and Section 4 tool support. Section 5 presents an evaluation. Section 6 compares with related work and Section 7 presents conclusions and future work.

BACKGROUND AND MOTIVATION
In this section we introduce the different technologies involved in our approach, on the basis of a running example.

Eclipse Modeling Framework and EuGENia
The Eclipse Modeling Framework (EMF) [9,31] is a widely used (partial) implementation of the meta-object facility (MOF) standard of the OMG [23]. EMF is a meta-modelling framework integrated within Eclipse. It supports a notation (Ecore) for creating metamodels, and a code generation facility that produces Java code (enabling the construction of models and model transformations programmatically) and tree editors to create models interactively. EMF supports model serialization using the XML Metadata Interchange (XMI), an OMG standard for meta-data exchange [35].  Figure 1: Ecore meta-model for Petri nets with EuGENia annotations As a running example, assume we would like to create a modelling editor for Petri nets [24] using EMF. Petri nets are a popular formalism to model concurrent system, made of places, which may hold zero or more tokens, and that can be connected to transitions via input and output arcs. Figure 1 shows the ecore meta-model of Petri nets with EuGENia annotations. The meta-model supports Petri nets with weighted arcs (attribute tokenNo in ArcPT and ArcTP) and time in transitions to model delays. By convention, most Ecore meta-models have a root class, which contains directly or indirectly all other classes via composition relations. This way, each classexcept the root class -is contained into another one. This is especially useful to edit models using the generated tree editors, since the instances of the contained classes appear as children of the container ones.
While EMF generates a tree editor by default, more user-friendly editors are typically required. They are normally either textual or graphical. In this paper we focus on graphical DSLs. There are several technologies to help in the construction of graphical editors within Eclipse, like Graphiti [12], Sirius [30], GMF [11] or EuGENia  [8] (which we analyse in Section 6). We decided to support the latter technology due to its popularity, since it is extensively used by both researchers and practitioners.
EuGENia [18] simplifies the development of GMF-based graphical model editors by automatically generating the required models needed by the GMF editor construction framework from a single annotated Ecore meta-model.
As an example, Figure 2 shows some annotations indicating that Places, Transitions and Tokens are to be displayed as nodes (annotation gmf.node), while arcs are to be represented as links (annotation gmf.link), and all elements are to be placed in the diagram represented by the PetriNet (annotation gmf.diagram). Figure 5 shows the resulting editor. It contains a canvas to graphically edit the model, and a palette to create the objects. The object attributes can be changed from an Eclipse properties view (not shown in the Figure).

DPG (Diagram Programming Generator)
The web technology that we target in this work is based on the Programmable Solutions Interpreter Engine, (PsiEngine) [2,3]. PsiEngine implements, evaluates, interprets and executes DSLs described in XML within the web client. It uses HTML5, CSS3, JavaScript and DOM together with technologies, services and tools from Web 2.0 and the specification of XML-DSL grammars in order to build web components, widgets, and dynamic web sites to give the solution to specific web application problems or parts of them.
PsiEngine is a generic lightweight JavaScript framework (it a cross browser platform) that processes and evaluates programs written in Psi Language [2]. On top of PsiEngine, a set of Psi languages (Graph Library Psi GLPsi, Diagram Psi DPsi, Visual Tool Psi TPsi and Data Form Psi DFPsi) were created to develop the functionality of a programmable diagram.
Formally, a programmable diagram is a set of graphical elements that define an SVG-based diagram, and each graphical element can have associated visual tools (like dialogue boxes, toolbars, pop-ups, floating menus, menus, and drag and drop), programming utilities (classes, scripts, functions, and variables) and heterogeneous information data sources (XML/JSON) that determine their appearance and content.
The Diagram Programming Generator (DPG) is a layer on top of the PsiEngine that encodes DSLs as a JSON-based grammar, which specifies the elements necessary to create a programmable diagram "Url":"... " , "Doc": "... " filledrhomb -> circlecross {stroke-dasharray:2,2;}", java class name -> "Shape":"Image" square -> circle "Field":"IMG_URL" filledsquare -> circle "Symbol":"name_symbol" java class -> java class in PsiEngine. The execution engine that interprets a DPG specification, is called DPG-PsiEngine. Its objective is to generate the code in the different Psi languages and to start the programmable diagram. Additionally, in DPG-PsiEngine a template engine was incorporated for the administration and generation of graphical elements and forms. It also includes components for connection via REST API, to obtain JSON information. These frameworks are used within UGROUND as a basis for the low-code solutions, and some examples are available at http://devrho.com/.

AUTOMATING EDITOR MIGRATION
This section presents our migration approach, we first describe how the abstract syntax is migrated (Section 3.1), and then the graphical concrete syntax (Section 3.2).

Migrating the abstract syntax
Our approach starts reading the domain meta-model and transforming the classes into the DSL-JSON format of DPG. All the (non-abstract) classes in the EMF meta-model are placed inside a DPG table called "Elements": {...}. Then, inside such table, they are placed into a key "Type": {...}. Later, classes need to be classified as nodes or connectors, as we will explain in next section. All the attributes and references of the classes are stored into a key "Fields": {...}, and then attributes are associated with different types of DPG controls depending on their eType, as shown in Table 2. The source and target of references are specified using the JSON key "Start": and "End":. In EMF meta-models, we may have abstract classes, and inheritance hierarchies. However, neither abstract classes or inheritance are supported by DPG. To overcome this limitation, our mapping flattens the inheritance hierarchy, collecting the attributes and references of upper classes in the hierarchy, and replicating them in lower classes where they are required.

Migrating the concrete syntax
Our approach also translates EuGENia annotations to the DPG format, which distinguishes nodes and connectors. Hence, we have to decide on the basis of EuGENia annotations which classes or references of EMF meta-model are going to become nodes, and which ones connectors. In addition, we need to consider the different graphical styles configured in these annotations.
In DPG the graphical information is stored in JSON, where we need to define libraries of nodes and connectors, as Listing 2 shows. Please note that DPG uses CSS styles, e.g., for colour values. The details of the mapping of different styles of nodes and links between EuGENia and DPG are described in Tables 1 and 3. The  former table details the mappings between figures and decorations for links, and the latter describes the mapping between the other annotation options.
In DPG, when attributes of nodes or links are to be edited, a dialog box is presented. As explained in the previous section (cf., Table 2), each attribute can be associated with a different control, depending on its eType, to properly edit its value. Finally, the information about the palette, and the corresponding icons are also translated.
Regarding limitations of our translation, we do not currently support the EuGENia annotation @gmf.affixed to attach nodes to the border of another one. In addition, the @gmf.compartment annotation, which allows node nesting, is not natively supported either. However, we provide a workaround that allows inserting elements in the container objects (we will see an example in Section 5).

TOOL SUPPORT
We have created a tool called ROCCO (MigRatiOn towards Cloudbased GraphiCal EditOr) that implements the previous mapping. ROCCO is an Eclipse plugin that reads Ecore meta-models with EuGENia annotations and synthesises the necessary DPG files. For this purpose, it uses the Acceleo code generation language. The architecture of the tool is shown in Figure 3, which also shows the generation process.
A screenshot of the ROCCO IDE is shown in Figure 4 in which labels (1,3) indicate the main generic templates and the different modules and files templates. Label 2 shows the meta-model of the running example with EuGENia annotations. It is shown using the emfatic editor for Ecore models. Label 4 are the files required  to support the graphical editor of the DPG-PsiEngine Platform. Label 5 signals the specification file generated for DPG-PsiEngine. Label 6 is the generated Acceleo project. Finally Label 7 contains the meta-models with EuGENia annotations to be migrated. Figure 5 shows the resulting DPG editor for the running example. It can be seen how the synthesized editor mimics well the original one defined with EuGENia (cf. Figure 2).

EVALUATION
In this section, our goal is to answer the following research question: Can ROCCO migrate Eclipse-based graphical modelling editors (EuGENia) to the web, to facilitate their integration with low-code platforms?
For this purpose, we have evaluated our tool by migrating existing EuGENia editors into DPG-PsiEngine. We have taken nine EuGENia editors from the Epsilon online repository 1 (taking all meta-models with EuGENia annotations), and checked whether a complete DPG editor is obtained, required manual changes or had lacking functionality.
The evaluation results are shown in Table 4. The table shows the meta-model size in classes, and the lines of code of the generated DPG specifications. Then it shows the number of node, link (applied to nodes and references), compartment and affixed annotations. We marked with Yes/No whether the different annotations were correctly translated between these two platforms. For containment, we used Yes*, since we emulate compartments as graphical areas with  less functionalities than in EuGENia. Overall, we could fully migrate eight out of the nine editors. For the other one (components), we obtained a working editor, but with lacking functionality regarding affixed features. In the EuGENia editor ports can be affixed to components, to appear in their borders. Instead they are connected via links in DPG editor.
As an example, Figure 6 shows the BPMN editor in EuGENia and the resulting one in DPG. We could emulate lanes (containment compartments in EuGENia) as rectangles. However, these have less functionality than the ones in EuGENia for handling the children elements.
Overall, we can answer our research question in a positive way, since in all cases we obtained a working editor, albeit with lacking functionality for affixed, and less sophistication for compartments. These limitations will be addressed in future work.

RELATED WORK
Next, we review some of the main frameworks to define graphical DSLs both for desktop environments (especially Eclipse) and on the web.
The most widely used MDE environment nowadays is the Eclipse Modelling Project of the Eclipse Modeling Framework [9], which can integrate with different tools for specifying DSLs. First, we review some tools in the Eclipse ecosystem, whether they are desktop applications or cloud-based IDE/tool, then we talk about some other tools outside the Eclipse ecosystem in the same manner.
Graphiti [12] is a framework that allows building graphical editors programmatically in Java. The Graphical Modeling Framework (GMF) [11] is a model-based solution for developing graphical editors, which requires specifying three types of models: GMF-map (describing the structure), GMF-graph (describing the apperance) and GMF-tool (with the editor behaviour). GMF and Graphiti are large and powerful frameworks, and consequently their use requires considerable technical expertise.
EuGENia [8] seeks to reduce the amount of technical experience required to specify a DSL with GMF, by providing higher level annotations that are mapped into a subset of the underlying framework.
Sirius [30], is a more recent framework for building graphical editors within Eclipse. It is also model-based, but it is interpreted, instead of compiled (like GMF). While there are plans to enable the deployment of Sirius editors on the web, this is still not supported.
Obeo Designer [6] is a commercial framework which allows user to create own graphical workbenches for specific domains like  software applications, industrial systems and organization of major companies. It also integrates with Sirius and other MDE tools. It facilitates the collaborative work, allows user to store models and representations (diagrams, tables, matrices, trees) in a shared repository. Multiple users can work on the same data simultaneously without any conflict and technical skills. Users can also import/export the project from the standard data access point i.e CDO, the Eclipse open-source solution to store EMF models into a database. Outside the Eclipse ecosystem, MetaEdit+ [1] is a graphical language workbench, which allows specifying domain-specific modelling languages by defining their abstract syntax, concrete visual syntax and semantics (via code generators). It supports graphical notations as well as textual, symbolic or tabular notations. MetaEdit+ uses a proprietary persistence format, therefore models and languages created with MetaEdit+ cannot be directly used with other modelling tools or language workbenches.
The previous tools do not provide a framework which can run on cloud for their integration with low-code development platform. However, some solutions exist to build web-based editors for graphical DSLs. For example, WebGME [20] is a tool to create graphical DSLs directly in the browser 2 . It uses a UML class diagram-based meta-model to specify the modelling concepts, relationships and attributes. It also supports model versioning and collaboration on the cloud.
AToMPM [32] is a web version of AToM 3 [5]. It allows defining graphical DSL editors that run on the web 3 , and to specify DSL semantics using graph transformations. It supports two types of collaboration mechanisms distributed in real time. Screenshare allows two or more clients to share exactly the same drawing area: any modification made to a model (abstract or concrete syntax) is replicated on all observing clients. Modelshare only shares the abstract syntax of a model between clients.
EMF.cloud 4 is a project -still under development -aiming at making EMF-based technologies accessible via the cloud, including graphical editors. These are based on the Graphical Language Server Platform (GLSP) [26,27] 5 . GLSP transfers the advantages of the language server protocol (LSP) to graphical modelling languages.
These editors, then can be deployed on web-based IDE such as Eclipse Theia.
Finally, EuGENia Live [28] is a web-based tool for designing graphical DSLs. It encourages the construction and collaboration of models and meta-models in iterative and incremental development.
Altogether, we have analysed several tools to create graphical editors either for desktop applications or for the web. However, we are not aware of solutions supporting editor migration to the web, to enable their integration with low-code development platforms.

CONCLUSIONS AND FUTURE WORK
In this paper, we have presented an approach for the automated migration of EuGENia editors to the web. The target framework is DPG, a web framework developed and used in the UGROUND company as a basis for its ROSE low-code platform. We have evaluated the approach on editors created by third parties, showing whether a complete DPG editor is obtained, required manual changes or had lacking functionality.
In the future, we plan to improve the mapping with support for affixed nodes, and better support for compartments. We are working on creating a default web editor for meta-models with no EuGENia annotations. Moreover, we would like to profit from other Psi languages to map editing actions, like refactorings or model abstraction operations [4] to enable more scalable modelling and connect models of heterogeneous languages.
We would also like to improve our migration to consider not only editors, but also existing instance models. Technically, we would like to improve the tool to automate deployment, and to offer a better GUI. We also plan to support the migration of editors built with other frameworks, like Sirius.