{"id":5977,"date":"2017-09-14T02:10:56","date_gmt":"2017-09-14T02:10:56","guid":{"rendered":"https:\/\/modeling-languages.com\/?p=5977"},"modified":"2018-05-19T14:31:40","modified_gmt":"2018-05-19T14:31:40","slug":"gremlin-atl-scalable-model-transformations-over-nosql-databases","status":"publish","type":"post","link":"https:\/\/modeling-languages.com\/gremlin-atl-scalable-model-transformations-over-nosql-databases\/","title":{"rendered":"Gremlin-ATL: Scalable Model Transformations over NoSQL Databases"},"content":{"rendered":"<p>Industrial use of Model Driven Engineering techniques has emphasized the need for efficiently store, access, and transform very large models. While scalable persistence frameworks, typically based on some kind of NoSQL database, have been proposed to solve the model storage issue, the same level of performance improvement has not been achieved for the model transformation problem. Existing model transformation tools (such as the well-known ATL) often require the input models to be loaded in memory prior to the start of the transformation and are not optimized to benefit from lazy-loading mechanisms, mainly due to their dependency on current low-level APIs offered by the most popular modeling frameworks nowadays.<\/p>\n<p>In this post we introduce Gremlin-ATL, a scalable and efficient model-to-model transformation framework that translates ATL transformations into Gremlin, a query language supported by several NoSQL databases. Gremlin-ATL computes transformations within the database itself, bypassing the modeling framework limitations and improving its performance both in terms of execution time and memory consumption. Our approach is an extension of the <a href=\"https:\/\/modeling-languages.com\/mogwai-querying-large-models-ocl-nosql-graphdb\/\">Mogwa\u00ef framework<\/a> that supports transformation constructs and provides an additional abstraction layer to target multiple databases. This post is based on the article <strong>&#8220;Gremlin-ATL: a Scalable Model Transformation Framework&#8221;<\/strong>, accepted at <a href=\"http:\/\/ase2017.org\/\" target=\"_blank\" rel=\"noopener\">ASE 2017<\/a>.<\/p>\n<p>The main contributions of our approach are:<\/p>\n<ul>\n<li>An ATL to Gremlin translation that generates efficient database queries to compute transformations<\/li>\n<li>A <em>Model Mapping<\/em> that allows designers to express their database schema using modeling primitives<\/li>\n<li>A <em>Transformation Helper<\/em> that can be used to tune the transformation execution according to an execution environment (available memory \/ performance requirements)<\/li>\n<\/ul>\n<p>Gremlin-ATL is available as a standalone transformation engine available on <a href=\"https:\/\/github.com\/atlanmod\/Mogwai\" target=\"_blank\" rel=\"noopener\">Github<\/a>, and provides a dedicated implementation tailored to <a href=\"http:\/\/www.neoemf.com\/\" target=\"_blank\" rel=\"noopener\">NeoEMF\/Graph<\/a>. You can find the complete article <a href=\"https:\/\/modeling-languages.com\/wp-content\/uploads\/2017\/09\/document.pdf\">here<\/a>, or continue reading below. The comment section is open for further discussions (what do you think of our approach? do you have use cases involving transformations of large models that could benefit from Gremlin-ATL? are you interested in data migration specification using ATL?). You can also find next the slides we used in the presentation.<\/p>\n<p><iframe loading=\"lazy\" style=\"border: 1px solid #CCC; border-width: 1px; margin-bottom: 5px; max-width: 100%;\" src=\"\/\/www.slideshare.net\/slideshow\/embed_code\/key\/eRcCtNlebUL2ct\" width=\"595\" height=\"485\" frameborder=\"0\" marginwidth=\"0\" marginheight=\"0\" scrolling=\"no\" allowfullscreen=\"allowfullscreen\"> <\/iframe><\/p>\n<div style=\"margin-bottom: 5px;\"><strong> <a title=\"Gremlin-ATL: a Scalable Model Transformation Framework\" href=\"\/\/www.slideshare.net\/g__daniel\/gremlinatl-a-scalable-model-transformation-framework\" target=\"_blank\" rel=\"noopener\">Gremlin-ATL: a Scalable Model Transformation Framework<\/a> <\/strong> from <strong><a href=\"https:\/\/www.slideshare.net\/g__daniel\" target=\"_blank\" rel=\"noopener\">Gwendal Daniel<\/a><\/strong><\/div>\n\n<h2>1. Introduction<\/h2>\n<p>Models are used in various engineering fields as abstract views helping designers and developers understand, manipulate, and transform complex systems.<br \/>\nThey can be manually constructed using high-level modeling tools, such as civil engineering models [1], or automatically generated in model-reverse engineering processes such as software evolution tasks [2] or schema discovery from existing documents [3].<\/p>\n<p>Models are then typically used in Model Driven Engineering (MDE) processes that rely intensively on model transformation engines to implement model manipulation operations like view extraction, formal verification or code-generation [4].<\/p>\n<p>With the growing accessibility of big data (such as national open data programs [5]) as well as the progressive adoption of MDE techniques in the industry [6,7], the volume and diversity of data to model has grown to such an extent that the scalability of existing technical solutions to store, query, and transform these models has become a major issue [8].<\/p>\n<p>For example, reverse engineering tools such as MoDisco [2] rely on MDE technologies to extract a set of high-level models representing an existing code base. These models are then operated by model transformations to create a set of artifacts providing a better understanding of the system, such as UML [9] class diagrams, code documentation, or quality metrics. However, these tools typically face scalability issues when the input code base increases because the underlying modeling frameworks are not designed to store and transform large models efficiently.<\/p>\n<p>Scalable modeling storage systems [10 &#8211; 12] have been proposed to tackle this issue, focusing on providing a solution to store and manipulate large models in a constrained memory environment with minimal performance impact. Relational and NoSQL databases are used to store models, and existing solutions rely on a <em>lazy-loading<\/em> mechanism to optimize memory consumption by loading only the accessed objects from the database.<\/p>\n<p>While these systems have improved the support for managing large models, they are just a partial solution to the scalability problem in current modeling frameworks. In its core, all frameworks are based on the use of low-level model handling APIs. These APIs are then used by most other MDE tools in the framework ecosystem to query, transform, and update models. These APIs are focused on manipulating individual model elements and do not offer support for generic queries and transformations.<\/p>\n<p>This low-level design is clearly inefficient when combined with persistence framework because (i) the API granularity is too fine to benefit from the advanced query capabilities of the backend, and (ii) an important time and memory overhead is necessary to construct navigable intermediate objects needed to interact with the API. As shown in Figure 1, this is particularly true in the context of model transformations, which heavily rely on high-level model navigation queries (such as the <em>allInstances()<\/em> operation returning all instances of a given type) to retrieve input elements to transform and create the corresponding output elements. This mismatch between high-level modeling languages and low-level APIs generates a lot of fragmented queries that cannot be optimized and computed efficiently by the database [13].<\/p>\n<p><a href=\"https:\/\/modeling-languages.com\/wp-content\/uploads\/2017\/09\/ATLtoEMF.png\"><img loading=\"lazy\" decoding=\"async\" class=\"wp-image-5979 size-full\" src=\"https:\/\/modeling-languages.com\/wp-content\/uploads\/2017\/09\/ATLtoEMF.png\" alt=\"ATLtoEMF\" width=\"775\" height=\"341\" srcset=\"https:\/\/modeling-languages.com\/wp-content\/uploads\/2017\/09\/ATLtoEMF.png 775w, https:\/\/modeling-languages.com\/wp-content\/uploads\/2017\/09\/ATLtoEMF-300x132.png 300w, https:\/\/modeling-languages.com\/wp-content\/uploads\/2017\/09\/ATLtoEMF-768x338.png 768w\" sizes=\"(max-width: 775px) 100vw, 775px\" \/><\/a><\/p>\n<p style=\"text-align: center;\"><strong> Figure 1. Model Transformation Engine and Modeling Framework Integration<\/strong><\/p>\n<p>To overcome this situation, we propose Gremlin-ATL, an alternative transformation approach. Instead of translating high-level model transformation specifications into a sequence of inefficient API calls, we translate them into database queries and execute them directly where the model resides, i.e. in the database store. This approach is based on a <em>Model Mapping<\/em> that allows to access an existing database using modeling primitives, and on a <em>Transformation Helper<\/em> that lets modelers tune the transformation execution to fit their performance needs.<\/p>\n<p>The rest of this post is structured as follow: Section 2 introduces the input transformation language and the output database query language of our approach and presents a running example that will be used through the paper. Section 3 presents Gremlin-ATL and its key components, Section 4 present how a transformation is executed from a user point of view. Sections 5 and 6 present our prototype and the benchmarks used to evaluate our solution. Section 7 shows an application example where Gremlin-ATL is used to specify data extraction rules between two data sources. Finally, Section 8 presents the related work and Section 9 summarizes the key points of the paper, draws conclusion, and presents our future work.<\/p>\n<h2>2. Background<\/h2>\n<p>In this section we introduce the key features of ATL [4], the model transformation language we use as the input of our framework, and Gremlin [14], a multi-database graph traversal query language we use as our output language. We also present along the section a running example that is used through this article to illustrate the different steps of our approach.<\/p>\n<h3>2.1. ATL Transformation Language<\/h3>\n<p>In MDE, models are key elements in any software engineering activity. Models are manipulated and refined using model-to-model transformations, and the final software artifacts are (partially) generated with a model-to-text transformation. Each model conforms to a <em>metamodel<\/em> that describes its structure and the possible relationships between model elements and their properties.<\/p>\n<p>As an example, Figure 2(a) shows a simple metamodel representing <em>Types<\/em>, <em>Methods<\/em>, and <em>Blocks<\/em>. <em>Methods<\/em> are defined by a <em>name<\/em>, a <em>visibility<\/em>, and contain a set of <em>Blocks<\/em> representing their <em>body<\/em>. A <em>Method<\/em> is associated with a <em>return Type<\/em>, and can have <em>type parameters<\/em>. A <em>Constructor<\/em> is defined as a subclass of <em>Method<\/em>. An instance of this metamodel is shown in Figure 2(b).<\/p>\n<p>ATL [4] is a declarative rule-based model transformation language that operates at the metamodel level. Transformations written in ATL are organized in modules, that are used to group transformation rules and define libraries. The language defines three types of rules: (i) matched rules that are declarative and automatically executed, (ii) lazy rules that have to be invoked explicitly from another rule, and (iii) called rules which contain imperative code (imperative constructs are not discussed in this post). ATL does not assume any order between matched rules, and keeps a set of <em>trace links<\/em> between the source and target models that are used to resolve elements, and set target values that have not been transformed yet.<\/p>\n<p>The language also defines helpers expressed in OCL [15] that are used to compute information in a specific context, provide global functions, and runtime attributes computed on the fly. OCL helpers can be invoked multiple times in a transformation, and are a good solution to modularize similar navigation chains and condition checking.<\/p>\n<p>Finally, ATL programs are themselves described as models that conform to the ATL metamodel. This feature allows to define high-order transformations, that take an ATL transformation as their input and manipulate it to check invariant properties that should hold in the output model, infer type, or refine the transformation. Our approach relies on this reflective feature to translate ATL transformations into efficient database queries.<\/p>\n<p>Note that in this post we focus on ATL as our input language, but our approach can be adapted to other rule-based transformation languages, notably the QVT standard [16].<\/p>\n<div id=\"attachment_5980\" style=\"width: 263px\" class=\"wp-caption alignleft\"><a href=\"https:\/\/modeling-languages.com\/wp-content\/uploads\/2017\/09\/sample_metamodel.png\"><img loading=\"lazy\" decoding=\"async\" aria-describedby=\"caption-attachment-5980\" class=\" wp-image-5980\" src=\"https:\/\/modeling-languages.com\/wp-content\/uploads\/2017\/09\/sample_metamodel.png\" alt=\"\" width=\"253\" height=\"262\" srcset=\"https:\/\/modeling-languages.com\/wp-content\/uploads\/2017\/09\/sample_metamodel.png 418w, https:\/\/modeling-languages.com\/wp-content\/uploads\/2017\/09\/sample_metamodel-290x300.png 290w\" sizes=\"(max-width: 253px) 100vw, 253px\" \/><\/a><p id=\"caption-attachment-5980\" class=\"wp-caption-text\">(a) Metamodel<\/p><\/div>\n<div id=\"attachment_5981\" style=\"width: 235px\" class=\"wp-caption alignleft\"><a href=\"https:\/\/modeling-languages.com\/wp-content\/uploads\/2017\/09\/sample_instance.png\"><img loading=\"lazy\" decoding=\"async\" aria-describedby=\"caption-attachment-5981\" class=\" wp-image-5981\" src=\"https:\/\/modeling-languages.com\/wp-content\/uploads\/2017\/09\/sample_instance.png\" alt=\"\" width=\"225\" height=\"262\" srcset=\"https:\/\/modeling-languages.com\/wp-content\/uploads\/2017\/09\/sample_instance.png 356w, https:\/\/modeling-languages.com\/wp-content\/uploads\/2017\/09\/sample_instance-257x300.png 257w\" sizes=\"(max-width: 225px) 100vw, 225px\" \/><\/a><p id=\"caption-attachment-5981\" class=\"wp-caption-text\">(b) Instance Model<\/p><\/div>\n<p>&nbsp;<\/p>\n<p>&nbsp;<\/p>\n<p>&nbsp;<\/p>\n<p>&nbsp;<\/p>\n<p>&nbsp;<\/p>\n<p>&nbsp;<\/p>\n<p>&nbsp;<\/p>\n<p>&nbsp;<\/p>\n<p style=\"text-align: center;\"><strong>Figure 2. Example Metamodel and Model<\/strong><\/p>\n<p>Listing 1 shows a simple ATL transformation based on the metamodel shown in Figure 2(a). The rule <em>MethodToMethodUnit<\/em> (line 10) matches all the <em>Method<\/em> elements from the input model that do not contain a <em>typeParameter<\/em> and creates the corresponding <em>MethodUnit<\/em> in the target model. The attributes and references of the created element are set using <em>binding specifications<\/em>: the first one (line 13) checks if the source element is a <em>Method<\/em> or a <em>Constructor<\/em> and sets the <em>kind<\/em> attribute accordingly. The second binding (line 15) sets the value of the <em>export<\/em> attribute by calling the OCL helper <em>getVisibility<\/em> on the source element. Finally, the <em>codeElement<\/em> reference is set with the <em>Block<\/em> elements contained in the <em>body<\/em> reference of the source <em>Method<\/em>. Note that an additional rule has to be specified to map <em>Block<\/em> instances to their corresponding output elements, that will be resolved by the ATL engine using its <em>trace links<\/em> mechanism.<\/p>\n<p style=\"text-align: center;\"><strong>Listing 1. Simplified Java2KDM Rule Example<\/strong><\/p>\n<pre>1  -- returns a String representing the visibility of a Method\r\n2  helper context java!Method def: getVisibility():String=\r\n3    let result : VisibilityKind = self.visibility in\r\n4      if result.oclIsUndefined() then\r\n5        \"unknown\"\r\n6      else\r\n7        result.toString()\r\n8      endif;\r\n9  -- Transforms a Java Method into a KDM Method unit\r\n10 rule MethodToMethodUnit {\r\n11   from src : java!Method(src.typeParameters.isEmpty())\r\n12   to tgt : kdm!MethodUnit(\r\n13     kind &lt;- if (src.oclIsKindOf(java!Constructor))\r\n14       then 'constructor' else 'method' endif,\r\n15     export &lt;- src.getVisibility(),\r\n16     codeElement &lt;- src.body-&gt;asSet() \r\n17 }\r\n<\/pre>\n<h3>2.2. Gremlin Query Language<\/h3>\n<p>NoSQL databases are an efficient option to store large models [17,18]. Nevertheless, their diversity in terms of structure and supported features make them hard to unify under a standard query language to be used as a generic solution for our approach.<\/p>\n<p>Blueprints [19] is an interface designed to unify NoSQL database access under a common API. Initially developed for graph stores, it has been implemented by a large number of databases such as Neo4j, OrientDB, and MongoDB. Blueprints is, to our knowledge, the only interface unifying several NoSQL databases (a list of the vendor&#8217;s implementations is available online at \\url{https:\/\/github.com\/tinkerpop\/blueprints).<\/p>\n<p>Blueprints is the base of the Tinkerpop stack: a set of tools to store, serialize, manipulate, and query graph databases. Gremlin [14] is the query language designed to query Blueprints databases. It relies on a lazy data-flow framework and is able to navigate, transform, or filter a graph.<\/p>\n<p>Gremlin is a Groovy domain-specific language built on top of <em>Pipes<\/em>, a data-flow framework based on process graphs. A process graph is composed of vertices representing computational units and communication edges which can be combined to create a complex processing. In Gremlin terminology, these complex processing vertices are called <em>traversals<\/em>, and are composed of a chain of simple computational units named <em>steps<\/em>. Gremlin defines three types of steps: (i) <em>transform steps<\/em> that compute values from their inputs, (ii) <em>filter steps<\/em> that select or rejects elements w.r.t a given condition, and (iii) <em>side-effect steps<\/em> that compute side-effect operations such as vertex creation or property updates. In addition, the <em>step<\/em> interface provides a set of built-in methods to access meta information, such as the number of objects in a step, output existence, or the first element in a step. These methods can be called inside a traversal to control its execution or check conditions on particular elements in a step.<\/p>\n<p>Gremlin allows the definition of custom steps, functions, and variables to handle query results. For example, it is possible to assign the result of a traversal to a variable and use it in another traversal, or define a custom step to handle a particular processing.<\/p>\n<p style=\"text-align: center;\"><a href=\"https:\/\/modeling-languages.com\/wp-content\/uploads\/2017\/09\/sample_db.png\"><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter size-full wp-image-5982\" src=\"https:\/\/modeling-languages.com\/wp-content\/uploads\/2017\/09\/sample_db.png\" alt=\"\" width=\"663\" height=\"402\" srcset=\"https:\/\/modeling-languages.com\/wp-content\/uploads\/2017\/09\/sample_db.png 663w, https:\/\/modeling-languages.com\/wp-content\/uploads\/2017\/09\/sample_db-300x182.png 300w\" sizes=\"(max-width: 663px) 100vw, 663px\" \/><\/a><\/p>\n<p style=\"text-align: center;\"><strong>Figure 3. Persisted Model<\/strong><\/p>\n<p>&nbsp;<\/p>\n<p>Figure 3 presents a possible graph database representation of the model shown in Figure 2(b): grey vertices represent <em>Method<\/em>, <em>Type<\/em>, and <em>Block<\/em> metaclasses that are linked to their instance through <em>instanceof<\/em> edges. The <em>Method<\/em> <tt>m1<\/tt> is linked to a <em>Block<\/em> instance through the <em>body<\/em> edge, and the <em>Types<\/em> <tt>void<\/tt> and <tt>T<\/tt> using <em>returnType<\/em> and <em>typeParameters<\/em> edges, respectively. Finally, <tt>m1<\/tt> contains a property <tt>visibility<\/tt> that holds a string representation of the <em>VisibilityKind<\/em> enumeration. This graph mapping of metamodel instances is based on the one used in NeoEMF\/Graph [20].<\/p>\n<p>In what follows, we describe some simple Gremlin examples based on this model. A Gremlin traversal begins with a <em>Start<\/em> step, that gives access to graph level information such as indexes, vertex and edge lookups, and property based queries. For example, the traversal below performs a query on the <em>classes<\/em> index that returns the vertices indexed with the name <em>Method<\/em>, representing the <em>Method<\/em> class in the Figure 2(a). In our example, this class matches vertex 1.<\/p>\n<pre>g.idx(\"classes\")[[name:\"Method\"]]; \/\/ -&gt; v(1)\r\n<\/pre>\n<p>The most common steps are <em>transform<\/em> steps, which allow navigation in a graph. The steps <em>outE(rel)<\/em> and <em>inE(rel)<\/em> navigate from input vertices to their outgoing and incoming edges, respectively, using the relationship <em>rel<\/em> as filter. <em>inV<\/em> and <em>outV<\/em> are their opposite: they compute head and tail vertices of an edge. For example, the following traversal returns all the vertices that are related to the vertex 4 by the relationship <em>typeParameters<\/em>. The <em>Start<\/em> step <tt>g.v(4)<\/tt> is a vertex lookup that returns the vertex with the id 4.<\/p>\n<pre>g.v(4).outE(\"typeParameters\").inV; \/\/ -&gt; [v(6)]\r\n<\/pre>\n<p><em>Filter<\/em> steps are used to select or reject a subset of input elements given a condition. They are used to filter vertices given a property value, remove duplicate elements in the traversal, or get the elements of a previous step. For example, the following traversal returns all the vertices related to vertex 4 by the relationship <em>typeParameters<\/em> that have a property <em>name<\/em> containing at least one character.<\/p>\n<pre>g.v(4).outE(\"typeParameters\").inV\r\n  .has(\"name\").filter{it.name.length &gt; 0}; \/\/ -&gt; [v(6)]\r\n<\/pre>\n<p>Finally, <em>side-effect<\/em> steps modify a graph, compute a value, or assign variables in a traversal. They are used to fill collections with traversal results, update properties, or create elements. For example, it is possible to store the result of the previous traversal in a <em>table<\/em> using the <em>Fill<\/em> step.<\/p>\n<pre>def table = [];\r\ng.v(3).outE(\"typeParameters\").inV.has(\"name\")\r\n  .filter{it.name.length &gt; 0}.fill(table); \/\/ -&gt; [v(6)]\r\n<\/pre>\n<h2>3. Gremlin-ATL Framework<\/h2>\n<p>In this section we present Gremlin-ATL, our proposal for handling complex model-to-model transformations by taking advantage of the features of the database backends where the model resides. We first introduce an overview of the framework and its query translation process. We then present the ATLtoGremlin transformation that maps ATL transformations into Gremlin traversals. Finally, we present the auxiliary components used within the Gremlin query to specify the database on which to compute the query on and the specific configuration to use.<\/p>\n<h3>3.1. Overview<\/h3>\n<p>Figure 4 presents an overview of the translation used in Gremlin-ATL to create <em>Gremlin Traversals<\/em> from <em>ATL Transformations<\/em>. An input transformation is parsed into an <em>ATL Transformation Model<\/em> conforming to the <em>ATL metamodel<\/em>. This model constitutes the input of our <em>ATLtoGremlin<\/em> high-order transformation that creates an output <em>Gremlin Traversal<\/em> representing the query to compute.<\/p>\n<p>The <em>ATLtoGremlin<\/em> transformation uses two generic libraries to produce the output query: (i) a <em>Model Mapping Definition<\/em> allowing to access a database as a model by mapping its implicit schema to modeling primitives, and (ii) a <em>Transformation Helper Definition<\/em> used to tune the transformation algorithm according to memory and execution time requirements.<\/p>\n<p>The generated traversal can be returned to the modeler or directly computed in a Gremlin engine that manages the underlying database. Note that our approach also allows to compute directly the generated query in a preset NeoEMF database, as explained in Section 5.<\/p>\n<p>In the following we detail the <em>ATLtoGremlin<\/em> transformation, the <em>Model Mapping<\/em> and <em>Transformation Helper Definition<\/em> used in the generated traversal. A dynamic view of our approach is provided in Section 4.<\/p>\n<p style=\"text-align: center;\"><a href=\"https:\/\/modeling-languages.com\/wp-content\/uploads\/2017\/09\/Overview.png\"><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter size-full wp-image-5983\" src=\"https:\/\/modeling-languages.com\/wp-content\/uploads\/2017\/09\/Overview.png\" alt=\"\" width=\"634\" height=\"420\" srcset=\"https:\/\/modeling-languages.com\/wp-content\/uploads\/2017\/09\/Overview.png 634w, https:\/\/modeling-languages.com\/wp-content\/uploads\/2017\/09\/Overview-300x199.png 300w\" sizes=\"(max-width: 634px) 100vw, 634px\" \/><\/a><\/p>\n<p style=\"text-align: center;\"><strong>Figure 4. Overview of the Gremlin-ATL Framework<\/strong><\/p>\n<p>&nbsp;<\/p>\n<h3>3.2. ATLtoGremlin Transformation<\/h3>\n<h4>3.2.1. Transformation Mapping<\/h4>\n<p>Table 1 shows the mapping used by Gremlin-ATL to translate ATL constructs into Gremlin steps. An ATL <em>Module<\/em> is translated into a Gremlin script, that represents the top-level container storing the entire query to execute.<\/p>\n<p><em>Matched Rule Definitions<\/em> inside the ATL module are mapped to a sequence of steps that access all the elements of the type of the rule. For example, the matched rule definition <em>MethodToMethodUnit<\/em> in Listing 1 is translated into the Gremlin expression <tt>g.allOfKind(\"Method\")<\/tt> that searches in the input graph all the elements representing <em>Method<\/em> instances. <em>Abstract Rule Definitions<\/em> are not translated, because they are called only when a specialized rule is matched. <em>Lazy rule definitions<\/em> are translated into function definitions named with the rule&#8217;s identifier and containing their translated body.<\/p>\n<p><em>Matched rule bodies<\/em> are mapped to a transform step containing the translated expressions representing rule&#8217;s out pattern and bindings. This transform step is followed by an iterate step that tells the Gremlin engine to execute the query. <em>Abstract rule bodies<\/em> are directly mapped without creating a transform step, and generated Gremlin steps are added to the ones of the translated bodies of the corresponding <em>specialized rules<\/em>. This approach flattens the inheritance hierarchy of a transformation by duplicating parent code in each concrete sub-rule.<\/p>\n<p><em>Rule Guards<\/em> defining the set of elements matched by a rule are translated into a Gremlin filter step containing the translated condition to verify. For example, the guard of the rule <em>MethodToMethodUnit<\/em> is translated into the following Gremlin expression that first navigates the reference <em>typeParameters<\/em> and searches if it contains at least one value: <tt>filter{!(src.getRef(\"typeParameters\").hasNext())}<\/tt>.<\/p>\n<p>Rules&#8217; body can contain two types of ATL constructs: <em>out patterns<\/em> representing the target element to create, and <em>attribute\/reference bindings<\/em> describing the attribute and references to set on the created element. <em>Out patterns<\/em> are mapped to a variable definition storing the result of the <em>createElement<\/em> function which creates the new instance and the associated trace links. This instruction is followed by a <em>resolveTraces<\/em> call that tells the engine to resolve the potential trace links associated to the created element. In our example it generates the sequence <tt>tHelper.createElement(\"MethodUnit\", src)<\/tt> that creates a new <em>MethodUnit<\/em> instance in the target model and associates it with the <em>src<\/em> element from the source model. <em>Attribute<\/em> and <em>Reference Bindings<\/em> are respectively translated into the mapping operation <em>setAtt<\/em> and a Transformation Helper&#8217;s <em>link<\/em> call.<\/p>\n<p>Our mapping translates <em>helper definitions<\/em> into global methods, which define a <em>self<\/em> parameter representing the context of the helper and a list of optional parameters. This global function is dynamically added to the <em>Object<\/em> metaclass to allow method-like invocation, improving query readability. <em>Global helper definitions<\/em> are also mapped to global methods, but do not define a <em>self<\/em> parameter. Finally, <em>Global Variables<\/em> are translated into unscoped Gremlin variables.<\/p>\n<p>ATL embeds its own specification of OCL, which is used to navigate the source elements to find the objects to transform, express the guard condition of the transformation rules, and define helpers&#8217; body. We have adapted the mapping defined in the Mogwa\u00ef framework [21] to fit the OCL metamodel embedded in ATL. In addition, we integrated our <em>Model Mapping Definition<\/em> component in the translation in order to provide a generic translation based on an explicit mapping. The current version of Gremlin-ATL supports an important part of the OCL constructs, allowing to express complex navigation queries over models. As an example, the inline <em>if<\/em> construct used in <em>MethodToMethodUnit<\/em> to check whether the source element represents a constructor can be translated into the equivalent Gremlin ternary operator: <tt>src.isKindOf(\"Constructor\") ? \"constructor\" : \"method\"<\/tt>.<\/p>\n<table>\n<caption>Table 1. ATL to Gremlin Mapping<\/caption>\n<tbody>\n<tr>\n<td><strong>ATL Expression<\/strong><\/td>\n<td><strong>Gremlin Step<\/strong><\/td>\n<\/tr>\n<tr>\n<td>module<\/td>\n<td>Gremlin Script<\/td>\n<\/tr>\n<tr>\n<td>matched_rule definition<\/td>\n<td>g.allOfType(type)<\/td>\n<\/tr>\n<tr>\n<td>abstract_rule definition<\/td>\n<td><em>not mapped<\/em><\/td>\n<\/tr>\n<tr>\n<td>lazy_rule definition<\/td>\n<td>def name(type) { body }<\/td>\n<\/tr>\n<tr>\n<td>abstract_rule body<\/td>\n<td>body<sup>1<\/sup><\/td>\n<\/tr>\n<tr>\n<td>specialized_rule body<\/td>\n<td>transform{ body <tt>U<\/tt> parent.body }.iterate()<\/td>\n<\/tr>\n<tr>\n<td>rule_guard(condition)<\/td>\n<td>filter{ condition }<\/td>\n<\/tr>\n<tr>\n<td>out_pattern(srcEl, tgtEl)<\/td>\n<td>var out = tHelper.createElement(tgtEl.type, srcEl);<\/td>\n<\/tr>\n<tr>\n<td><\/td>\n<td>tHelper.resolveTraces(srcEl, tgtEl);<\/td>\n<\/tr>\n<tr>\n<td>attribute_binding<\/td>\n<td>el.setAtt(exp)<\/td>\n<\/tr>\n<tr>\n<td>reference_binding<\/td>\n<td>el.link(exp)<\/td>\n<\/tr>\n<tr>\n<td>helper_definition<\/td>\n<td>def name(var self, params){ expression }<\/td>\n<\/tr>\n<tr>\n<td><\/td>\n<td>Object.metaClass.name = {\u00a0(params) -&gt; name(delegate, params) }<\/td>\n<\/tr>\n<tr>\n<td>obj.helper(params)<\/td>\n<td>obj.helper(params)<\/td>\n<\/tr>\n<tr>\n<td>global_helper defninition<\/td>\n<td>def name(params) { expression }<\/td>\n<\/tr>\n<tr>\n<td>global_helper computation<\/td>\n<td>name(params)<\/td>\n<\/tr>\n<tr>\n<td>global_variable<\/td>\n<td>def name = expression<\/td>\n<\/tr>\n<tr>\n<td>OCL_Expression<\/td>\n<td>Mogwa\u00ef<sup>2<\/sup><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>1. The body of abstract rules is duplicated in the transform step of all its sub-rules.<br \/>\n2. OCL expressions are translated by an improved version of the Mogwa\u00ef framework.<\/p>\n<h4>3.2. Operation Composition<\/h4>\n<p>The above mappings explain how ATL constructs are mapped individually into the corresponding Gremlin steps. In this section we present an overview of the algorithm used to compose these generated steps into a complete query. Listing 2 shows the final Gremlin output for the transformation example shown in Listing 1.<\/p>\n<p>In order to generate a complete Gremlin query, our transformation has to navigate the input ATL model and link the generated elements together. First, the transformation searches all the <em>helper<\/em> definitions (including global ones) and translates them according to the mapping shown in Table 1. The generated functions are added to the Gremlin script container, making them visible for the translated ATL rules. This first step generates the lines 1 to 8 for the helpers <em>getVisibility<\/em>. Note that this initial phase also generates the function that registers contextual helpers to the <em>Object<\/em> metaclass (lines 10-13), allowing method-like invocation in generated expressions.<\/p>\n<p><em>Lazy\\_rule definitions<\/em> are then translated into global functions, and added to the Gremlin script container. <em>Out pattern<\/em> and <em>bindings<\/em> contained in the <em>Lazy\\_rule body<\/em> are translated into their Gremlin equivalent following the mapping presented in the previous section and appended in the generated function body.<\/p>\n<p style=\"text-align: center;\"><strong>Listing 2. Generated Gremlin Traversal<\/strong><\/p>\n<pre>1  \/\/ getVisibility() helper\r\n2  def getVisibility(var vertex) {\r\n3    var result = vertex.getAtt(\"visibility\");\r\n4    if(result == null)\r\n5      return \"unknown\";\r\n6    else\r\n7      return result;\r\n8  }\r\n9\r\n10 \/\/ Add getVisibility to Vertex method list\r\n11 Vertex.metaClass.getVisibility =\r\n12   { -&gt; getVisibility(delegate) }\r\n13\r\n14 \/\/ MethodToMethodUnit\r\n15 g.allOfKind(Method).filter{\r\n16   def src = it;\r\n17   !(src.getRef(\"typeParameters\").hasNext())\r\n18 }.transform{\r\n19   def src = it;\r\n20   var tgt = tHelper.createElement(\"MethodUnit\", src);\r\n21   tHelper.resolveTraces(src, tgt);\r\n22   tgt.setAtt(\"kind\", src.isKindOf(\"Constructor\") ? \"constructor\" : \"method\");\r\n23   tgt.setAtt(\"export\", src.getVisibility());\r\n24   tgt.setRef(\"codeElement\", src.getRef(\"body\").toList() as Set);\r\n25 }.iterate();\r\n<\/pre>\n<p>Once this initial step has been performed the transformation searches all the <em>matched rules definitions<\/em> and creates the associated Gremlin instructions. If the rule defines a guard the generated <em>filter<\/em> step is directly linked after the <em>allOfKind<\/em> operation in order to select the elements that satisfy the guard&#8217;s condition. Then, the <em>transform step<\/em> (and the associated <em>iterate<\/em> call) corresponding to the <em>matched rule body<\/em> is created and added at the end of the traversal. In our example this operation generates lines 15 to 18.<\/p>\n<p><em>Out pattern<\/em> elements contained in the <em>matched rule body<\/em> are retrieved and the corresponding Gremlin instructions (lines 19 to 24) are added to the <em>transform<\/em> step closure. Finally, Rule&#8217;s <em>bindings<\/em> are transformed following the mapping and added in the closure&#8217;s instructions. Note that helper calls inside binding&#8217;s expressions are also translated into the corresponding method calls during this operation.<\/p>\n<h3>3.3. Auxiliary Components<\/h3>\n<h4>3.3.1 Model Mapping<\/h4>\n<p>The <em>Model Mapping<\/em> library defines the basic modeling operations that can be computed by a given database storing a model. It provides a simple API allowing designers to express the implicit schema of their database with modeling primitives. <em>Model Mapping<\/em> can be manually implemented for a given database, or automatically extracted using schema inference techniques such as the NoSQLDataEngineering framework [22]. This mapping is used within the generated Gremlin query to access all the elements of a given type, retrieve element&#8217;s attribute values, or navigate references.<\/p>\n<p>Table 2 summarizes the mapping operations used in Gremlin-ATL and groups them into two categories: <strong>metamodel-level<\/strong> and <strong>model-level operations<\/strong>. The first group provides high-level operations that operate at the metamodel level, such as retrieving the type of an element, type conformance checks, new instances creation, and retrieve all the elements conforming to a type. The second group provides methods that compute element-based navigation, such as retrieving a referenced element, computing the parent\/children of an element, and access its attributes. Finally, these model-level methods allow to update and delete existing references and attributes.<\/p>\n<p>Note that the <em>ATLtoGremlin<\/em> transformation only relies on the definition of these operations to generate a Gremlin query, and is not tailored to a specific <em>Model Mapping<\/em> implementation.<\/p>\n<table>\n<caption>Table 2. Model Mapping API<\/caption>\n<tbody>\n<tr>\n<td><strong>Operation<\/strong><\/td>\n<td><strong>Description<\/strong><\/td>\n<\/tr>\n<tr>\n<td>allOfType(type)<\/td>\n<td>Returns all the strict instances of the given <em>type<\/em><\/td>\n<\/tr>\n<tr>\n<td>allOfKind(type)<\/td>\n<td>Returns all the instances of the given type or one of its sub-types<\/td>\n<\/tr>\n<tr>\n<td>getType(el)<\/td>\n<td>Returns the type of the element <em>el<\/em><\/td>\n<\/tr>\n<tr>\n<td>isTypeOf(el, type)<\/td>\n<td>Computes whether <em>el<\/em> is a strict instance of <em>type<\/em><\/td>\n<\/tr>\n<tr>\n<td>isKindOf(el, type)<\/td>\n<td>Computes whether <em>el<\/em> is an instance of <em>type<\/em> or one of its sub-types<\/td>\n<\/tr>\n<tr>\n<td>newInstance(type)<\/td>\n<td>Creates a new instance of the given <em>type<\/em><\/td>\n<\/tr>\n<tr>\n<td>getParent(el)<\/td>\n<td>Returns the element corresponding to the parent of <em>el<\/em><\/td>\n<\/tr>\n<tr>\n<td>getChildren(el)<\/td>\n<td>Returns the elements corresponding to the children of <em>el<\/em><\/td>\n<\/tr>\n<tr>\n<td>getRef(from, ref)<\/td>\n<td>Returns the elements connected to \\emph{from} with the reference <em>ref<\/em><\/td>\n<\/tr>\n<tr>\n<td>setRef(from, ref, to)<\/td>\n<td>Creates a reference <em>ref<\/em> between <em>from<\/em> and <em>to<\/em><\/td>\n<\/tr>\n<tr>\n<td>delRef(from, ref, to)<\/td>\n<td>Deletes the reference <em>ref<\/em> between <em>from<\/em> and <em>to<\/em><\/td>\n<\/tr>\n<tr>\n<td>getAtt(from, att)<\/td>\n<td>Returns the value of the attribute <em>att<\/em> contained in the element <em>from<\/em><\/td>\n<\/tr>\n<tr>\n<td>setAtt(from, att, v)<\/td>\n<td>Returns the value of the attribute <em>att<\/em> contained in the element <em>from<\/em><\/td>\n<\/tr>\n<tr>\n<td>delAtt(from, att)<\/td>\n<td>Deletes the attribute <em>att<\/em> contained in the element <em>from<\/em><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<h4>3.3.2. Transformation Helper<\/h4>\n<p>The second component used by the <em>ATLtoGremlin<\/em> transformation is a <em>Transformation Helper<\/em> library that provides transformation-related operations that can be called within the generated Gremlin traversal. It is based on the ATL execution engine (presented in Section 2), and provides a set of methods wrapping a <em>Model Mapping<\/em> with transformation specific operations. Note that this library aims to be generic and can be used directly in ad hoc Gremlin scripts to express transformation rules.<\/p>\n<p>Specifically, our <em>TransformationHelper<\/em> provides the following interface:<\/p>\n<ul>\n<li><strong>createElement(type, source)<\/strong>: creates a new instance of the given <em>type<\/em> mapped to the provided <em>source<\/em> element.<\/li>\n<li><strong>link(from, ref, to)<\/strong>: creates a link between <em>from<\/em> and <em>to<\/em>.<\/li>\n<li><strong>resolveTraces(source, target)<\/strong>: resolves the trace links connected to <em>source<\/em> with the <em>target<\/em>.<\/li>\n<li><strong>getTarget(source, bindingName)<\/strong>: retrieves the target element mapped to <em>source<\/em>. If multiple target elements are created from a single source an optional. <em>bindingName<\/em> can be specified to tell the engine which one to choose.<\/li>\n<li><strong>isResolvable(el)<\/strong>: computes whether an element can be resolved.<\/li>\n<li><strong>isTarget(el)<\/strong>: computes whether an element is in the target model.<\/li>\n<li><strong>isSource(el)<\/strong>: computes whether an element is in the source model.<\/li>\n<\/ul>\n<p>The two first operations are wrappers around mapping operations that add model transformation specific behavior to the mapping. The <tt>createElement(type, sourceElement)<\/tt> operation delegates to the mapping operation <tt>newInstance(type)<\/tt>, and adds a trace link between the created element and the source one. <tt>link(from, ref, to)<\/tt> delegates to the mapping operation <em>setRef<\/em> to create a regular reference between from and to or a trace link if <em>to<\/em> is not yet part of the target model.<\/p>\n<p>The five last operations define transformation specific behaviors, such as retrieving the target element from an input one, resolve trace links, or compute whether an element is part of the source of the target model. Note that Gremlin-ATL provides two implementations (one in memory and one in a database) of this library that can be directly plugged to compute a transformation.<\/p>\n<h2>4. Runtime Framework<\/h2>\n<p>The Gremlin script generated by the <em>ATLtoGremlin<\/em> transformation is generic and relies on the <em>Model Mapping<\/em> and <em>Transformation Helper<\/em> interfaces. In order to execute it on an existing database, the framework needs to bind these abstract interfaces to their concrete implementations designed to access a specific database.<\/p>\n<p>Figure 5 shows our framework from a user point of view: the user provides an ATL query to the <em>Query Translation<\/em> component (1), which compiles the query into a Gremlin script and returns it to the user (2). The generated script is then sent to the <em>Query Execution<\/em> API with the concrete implementation of the <em>Model Mapping<\/em> and a <em>Transformation Helper<\/em> (3) the user wants to use during the execution. The internal Gremlin engine finally computes the transformation using these implementations (4) and returns the result (such as execution traces, or transformation errors if any) to the user (5).<\/p>\n<p>This architecture allows to pre-compile transformations into Gremlin scripts and execute them later with specific implementations of the <em>Model Mapping<\/em>. In addition, generated scripts can be executed multiple times on different mappings without recompilation. The framework can also process and compile new input transformations on the fly, generating the corresponding Gremlin scripts dynamically.<\/p>\n<p><a href=\"https:\/\/modeling-languages.com\/wp-content\/uploads\/2017\/09\/user.png\"><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter size-full wp-image-5984\" src=\"https:\/\/modeling-languages.com\/wp-content\/uploads\/2017\/09\/user.png\" alt=\"\" width=\"452\" height=\"281\" srcset=\"https:\/\/modeling-languages.com\/wp-content\/uploads\/2017\/09\/user.png 452w, https:\/\/modeling-languages.com\/wp-content\/uploads\/2017\/09\/user-300x187.png 300w\" sizes=\"(max-width: 452px) 100vw, 452px\" \/><\/a><\/p>\n<p style=\"text-align: center;\"><strong>Figure 5. User Point of View<\/strong><\/p>\n<p>As an example, we can define a possible <em>Model Mapping<\/em> implementation for the persisted model of Figure 3 that would compute the <tt>allOfType(Type)<\/tt> operation with an access to the vertex representing the metaclass <em>Type<\/em> and a backward navigation of its incoming <em>instanceof<\/em> edges. The <tt>getAtt<\/tt> and <tt>getRef<\/tt> operations can be translated into property access and edge navigation, respectively, and the <tt>newInstance<\/tt> operation can be computed by adding a new vertex in the database with an outgoing edge linked to the vertex representing its metaclass. Note that Gremlin-ATL embeds preset <em>Model Mapping<\/em> implementations for accessing NeoEMF, Neo4j, and relational databases.<\/p>\n<p>Once the <em>Model Mapping<\/em> interface is bounded to its implementation, the modeler can choose the <em>Transformation Helper<\/em> he needs to compute the transformation. The choice of a specific implementation is a trade-off between execution time and memory consumption: a <em>Transformation Helper<\/em> storing transformation information (such as trace links) in memory will be efficient when computing transformations on top of relatively small models, but will not scale to larger ones. Conversely, an implementation relying on a dedicated database can scale to larger models but would not be optimal when using small models. Gremlin-ATL defines two default implementations (one in memory and one in database) that can be directly plugged to compute a transformation and extended to provide further performances.<\/p>\n<h2>5. Tool Support<\/h2>\n<p>Gremlin-ATL is released as a set of open source Eclipse plugins publicly available on <a href=\"https:\/\/github.com\/atlanmod\/Mogwai\" target=\"_blank\" rel=\"noopener\">GitHub<\/a>.<br \/>\nInput ATL transformations are parsed using the standard ATL parser, which creates a model representing the abstract syntax of the transformation. The generated model is sent to the <em>ATLtoGremlin<\/em> ATL transformation, which contains around 120 rules and helpers implementing the translation presented in Section 3.<\/p>\n<p>Once the Gremlin model has been generated, it is transformed into a textual Gremlin query using a model-to-text transformation. A final step binds the <em>Model Mapping<\/em> and the <em>Transformation Helper<\/em> definitions to their concrete implementation and the resulting script is then sent to a Gremlin script engine, which is responsible of computing the query on top of the database. The updated database is finally saved with the transformed content.<\/p>\n<p>Additionally, a preconfigured implementation of Gremlin-ATL is bundled with the NeoEMF model persistence framework that extends the standard <em>Resource<\/em> API with transformation operations. ATL transformations are computed using the Gremlin-ATL engine transparently, on top of a preset NeoEMF <em>Model Mapping<\/em> implementation. The resulting model is compatible with NeoEMF and its content can be reified and manipulated using the standard modeling API if needed. This transparent integration allows the use of Gremlin-ATL for critical model transformations, while keeping the rest of the application code unchanged. We believe that this approach can ease the integration of Gremlin-ATL into existing modeling applications that have to compute complex transformations on the top of large models.<\/p>\n<p>The current implementation embeds a set of predefined <em>Model Mappings<\/em> and <em>Transformation Helpers<\/em>. Both can easily be adapted to specify how you want transformation-related operations to be computed. This is done by extending a set of abstract classes with limited implementation effort. As an example, the model mapping used to access Neo4j databases storing NeoEMF models defines 23 methods (around 250 LOC), and the in-database <em>Transformation Helper<\/em> defines 9 methods (around 100 LOC) implementing the transformation operations and storing intermediate results in the database.<\/p>\n<h2>6. Evaluation<\/h2>\n<p>In this section we evaluate the performance of the Gremlin-ATL framework by comparing the execution performance of the same set of ATL transformations using the standard ATL engine and the Gremlin-ATL framework. Note that we do not consider alternative transformation frameworks in this evaluation, because they are either based on the same low-level modeling API as ATL (such as QVT [16]), or are not designed to optimize the same transformation scenario (such as Viatra [23]).<\/p>\n<p>Our evaluation aims to address the following research questions: (i) is Gremlin-ATL faster than standard ATL when applied to large models stored in scalable persistence frameworks? and (ii) does our approach scales better in terms of memory consumption?<\/p>\n<p>In the following we benchmark our approach with two transformations, a toy one created on purpose for this analysis and a more complex one taken from an industrial project involving a reverse engineering scenario. Transformations are evaluated on a set of models of increasing size, stored in Neo4j using the NeoEMF mapping. Transformed models are also stored in NeoEMF using the same mapping. Experiments are executed on a computer running Fedora 20 64 bits. Relevant hardware elements are: an Intel Core I7 processor (2.7 GHz), 16 GB of DDR3 SDRAM (1600 MHz) and a SSD hard-disk. Experiments are executed on Eclipse 4.6.0 (Neon) running Java SE Runtime Environment 1.8.<\/p>\n<h3>6.1 Benchmark Presentation<\/h3>\n<p>Experiments are run over five models (sets 1 to 5) of increasing sizes, automatically constructed by the MoDisco [2] Java Discoverer, a reverse engineering tool that extracts low-level models from Java code. The first two models are generated from internal projects containing few dozens of classes, and the larger ones are computed from the MoDisco framework itself, and the Java Development Tool (JDT) plugins embedded in Eclipse. Table 3 presents the size of the input models in terms of number of elements and XMI file size. These models are migrated to NeoEMF\/Graph before executing the benchmark to enable scalable access to their contents.<\/p>\n<table>\n<caption>Benchmarked Models<\/caption>\n<tbody>\n<tr>\n<td><strong>Model<\/strong><\/td>\n<td><strong># Elements<\/strong><\/td>\n<td><strong>XMI Size (MB)<\/strong><\/td>\n<\/tr>\n<tr>\n<td>set1<\/td>\n<td>659<\/td>\n<td>0.1<\/td>\n<\/tr>\n<tr>\n<td>set2<\/td>\n<td>6756<\/td>\n<td>1.7<\/td>\n<\/tr>\n<tr>\n<td>set3<\/td>\n<td>80665<\/td>\n<td>20.2<\/td>\n<\/tr>\n<tr>\n<td>set4<\/td>\n<td>1557007<\/td>\n<td>420.6<\/td>\n<\/tr>\n<tr>\n<td>set5<\/td>\n<td>3609354<\/td>\n<td>983.7<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>In order to evaluate our approach, we perform two transformations that take as input the Java models conforming to MoDisco&#8217;s Java metamodel, and translate them into models conforming to the Knowledge Discovery Model (KDM) [24] that is a pivot metamodel used to represent software artifact independently of their platform.<\/p>\n<p>The <em>AbstractTypeDeclaration2DataType<\/em> transformation matches all the <em>AbstractTypeDeclaration<\/em> elements (declared classes, interfaces, enumerations, etc.) of the input model and create the corresponding KDM <em>DataType<\/em>. It is composed of a single rule that matches all the subtypes of <em>AbstractTypeDeclaration<\/em>. The second benchmarked transformation is a subset of the <em>Java2KDM<\/em> transformation. It is extracted from an existing industrial transformation that takes a low-level Java model and creates the corresponding abstract KDM model. The transformations are run in a 512 MB JVM with the arguments <tt>-server<\/tt> and <tt>UseConcMarkSweepGC<\/tt> that are recommended by Neo4j.<\/p>\n<h3>6.2. Results<\/h3>\n<p>Tables 4 and 5 present the results of executing the transformations on top of the input model sets. First columns contain the name of the input model of the transformation, second and third columns present the execution time and the memory consumption of ATL engine and Gremlin-ATL, respectively. Execution times are expressed in milliseconds and memory consumption in megabytes.<\/p>\n<p>The correctness of the output models are checked by comparing the results of our approach with the ones generated by running the ATL transformation on the original input XMI file using a large Java virtual machine able to handle it. The comparison is performed using EMF Compare [25].<\/p>\n<table>\n<caption>AbstractTypeDeclaration2DataType Results<\/caption>\n<tbody>\n<tr>\n<td><strong>Model<\/strong><\/td>\n<td><strong>Execution Time(ms)<\/strong><\/td>\n<td><\/td>\n<td><strong>Memory Consumption (MB)<\/strong><\/td>\n<td><\/td>\n<\/tr>\n<tr>\n<td><\/td>\n<td><strong>ATL<\/strong><\/td>\n<td><strong>Gremlin-ATL<\/strong><\/td>\n<td><strong>ATL<\/strong><\/td>\n<td><strong>Gremlin-ATL<\/strong><\/td>\n<\/tr>\n<tr>\n<td><strong>set1<\/strong><\/td>\n<td>1633<\/td>\n<td>710<\/td>\n<td>2.0<\/td>\n<td>8.3<\/td>\n<\/tr>\n<tr>\n<td><strong>set2<\/strong><\/td>\n<td>3505<\/td>\n<td>1139<\/td>\n<td>3.2<\/td>\n<td>10.0<\/td>\n<\/tr>\n<tr>\n<td><strong>set3<\/strong><\/td>\n<td>11480<\/td>\n<td>1649<\/td>\n<td>17.6<\/td>\n<td>11.7<\/td>\n<\/tr>\n<tr>\n<td><strong>set4<\/strong><\/td>\n<td>67204<\/td>\n<td>3427<\/td>\n<td>99.3<\/td>\n<td>23.0<\/td>\n<\/tr>\n<tr>\n<td><strong>set5<\/strong><\/td>\n<td><em>OOM<\/em><sup>1<\/sup><\/td>\n<td>11843<\/td>\n<td><em>OOM<\/em><\/td>\n<td>100.0<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>1. The application threw an OutOfMemory error after two hours.<\/p>\n<table>\n<caption>Java2KDM Results<\/caption>\n<tbody>\n<tr>\n<td><strong>Model<\/strong><\/td>\n<td><strong>Execution Time(ms)<\/strong><\/td>\n<td><\/td>\n<td><strong>Memory Consumption (MB)<\/strong><\/td>\n<td><\/td>\n<\/tr>\n<tr>\n<td><\/td>\n<td><strong>ATL<\/strong><\/td>\n<td><strong>Gremlin-ATL<\/strong><\/td>\n<td><strong>ATL<\/strong><\/td>\n<td><strong>Gremlin-ATL<\/strong><\/td>\n<\/tr>\n<tr>\n<td><strong>set1<\/strong><\/td>\n<td>1735<\/td>\n<td>1341<\/td>\n<td>3.2<\/td>\n<td>11.2<\/td>\n<\/tr>\n<tr>\n<td><strong>set2<\/strong><\/td>\n<td>4874<\/td>\n<td>2469<\/td>\n<td>11.0<\/td>\n<td>12.8<\/td>\n<\/tr>\n<tr>\n<td><strong>set3<\/strong><\/td>\n<td>33407<\/td>\n<td>4321<\/td>\n<td>45.2<\/td>\n<td>23.2<\/td>\n<\/tr>\n<tr>\n<td><strong>set4<\/strong><\/td>\n<td>5156798<\/td>\n<td>38402<\/td>\n<td>504.5<\/td>\n<td>52.0<\/td>\n<\/tr>\n<tr>\n<td><strong>set5<\/strong><\/td>\n<td><em>OOM<\/em><\/td>\n<td>129908<\/td>\n<td>OOM<\/td>\n<td>96.0<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<h3>6.3. Discussion<\/h3>\n<p>The results presented in Tables 4 and 5 show that Gremlin-ATL is a good candidate to compute model transformations on top of large models stored in NeoEMF\/Graph. Our framework is faster than the standard ATL engine for the two benchmarked transformations, outperforming it both in terms of execution time and memory consumption for the larger models.<\/p>\n<p>Results from Tables 4 and 5 show that the complexity of the transformation has a significant impact on ATL&#8217;s performances. This is particularly visible when the transformations are evaluated on the large models: <em>Java2KDM<\/em> is 2.9 times slower than <em>AbstractType2DataType<\/em> on <em>set3<\/em>, and up to 76 times on <em>set4<\/em>. This difference is explained by the large number of low-level modeling API calls that are generated by <em>Java2KDM<\/em> in order to retrieve the matching elements, computes rules&#8217; conditions, and helpers.<\/p>\n<p>Gremlin-ATL&#8217;s execution time is less impacted by the transformation complexity, because the generated Gremlin query is entirely computed by the database, bypassing the modeling API. The database engine optimizes the query to detect access patterns and cache elements efficiently, and allows to benefit from the database indexes to retrieve elements efficiently. Results on <em>set4<\/em> show that Gremlin-ATL&#8217;s approach is faster than ATL by a factor of 19 and 134 for <em>AbstractType2DataType<\/em> and <em>Java2KDM<\/em>, respectively.<\/p>\n<p>The results also show that ATL&#8217;s performance on <em>set4<\/em> and <em>set5<\/em> are tightly coupled to the memory consumption. Indeed, in our experiments we measured that most of the execution time was spent in garbage collection operations. This high memory consumption is caused by the in-memory nature of the engine, that keeps in memory all the matched elements as well as the trace links between source and target models. When the input model grows, this in-memory information grows accordingly, triggering the garbage collector, which blocks the application until enough memory has been freed. In addition, the intensive usage of the low-level model handling API increases the memory overhead, by reifying intermediate modeling elements that also stay in the memory.<\/p>\n<p>Conversely, Gremlin-ATL does not require these complex structures, because trace links are stored within the database itself, and can be removed from the memory if needed.<br \/>\nThis implementation avoids garbage collection pauses, and allows to scale to very large models. Our approach operates on the optimized database structures, and thus does not have to reify modeling elements, improving the memory consumption. Looking at the <em>Java2KDM<\/em> transformation, this strategy reduces the memory consumption by a factor of 10 for <em>set4<\/em>.<\/p>\n<p>ATL requires less memory than Gremlin-ATL to compute the transformations on top of the small models (<em>sets<\/em> <em>1<\/em> and <em>2<\/em>). This difference is caused by the initialization of the Gremlin engine (and its underlying Groovy interpreter) used to evaluate the generated scripts. However, this extra memory-consumption has a fixed size and does not depend on the evaluated transformation nor on the transformed model.<\/p>\n<p>Note that the results only show execution time and memory consumption related to the computation of the transformations, we did not take into account the time and memory required to generate an executable file that can be interpreted by the ATL engine nor the time needed to produce the Gremlin script to compute, because this extra cost is fixed for a given transformation and does not depend on the model size. In addition, Gremlin-ATL allows to pre-compile and to cache existing Gremlin queries in order to limit script generation.<\/p>\n<p>As a summary, our experiments report that using Gremlin-ATL to compute a well-known model transformation outperforms the standard ATL engine when applied on top of large models stored in current model persistence frameworks. Still, additional experiments could reinforce these conclusions. We plan to extend this preliminary evaluation by reusing transformations available in the ATL Zoo.<\/p>\n<h2>7. An Application to Data Migration<\/h2>\n<p>We have seen how Gremlin-ATL can improve performance of transformations for large models. In this section, we show how Gremlin-ATL can also be useful in the context of a data migration process when the schema of the data is unavailable (the common scenario in many NoSQL databases that are schemaless). To do so, we implement a simple migration operation on top of two data sources, and emphasize that using ATL as a migration language shortens the amount of required code to write for the migration with a limited impact on the application performance.<\/p>\n<p>In this example, the input of our process is the open source <a href=\"https:\/\/offshoreleaks.icij.org\/pages\/database\" target=\"_blank\" rel=\"noopener\">ICIJ Offshore Leaks Database<\/a> that contains the results of the Panama papers investigations stored in a Neo4j database. The output of the process is a simple <a href=\"http:\/\/www.h2database.com\" target=\"_blank\" rel=\"noopener\">H2<\/a> relational database containing the migrated data.<\/p>\n<p>The input database contains one million elements divided into four categories represented as node&#8217;s labels: <em>Officers<\/em>, <em>Entities<\/em>, <em>Addresses<\/em>, and <em>Intermediates<\/em>. Connections between elements are represented by labeled edges, for example the shareholder of an entity is represented by an edge with the label <tt>SHAREHOLDER_OF<\/tt> between the corresponding <em>Officer<\/em> and <em>Entity<\/em> nodes. Other edges are used to represent the different roles of an <em>Officer<\/em>, the connections between <em>Entities<\/em> and <em>Intermediates<\/em>, and their <em>Addresses<\/em>. Finally, node&#8217;s properties are used to represent additional information, such as the different fields of an <em>Address<\/em> record.<\/p>\n<p>The operation to perform is a simple data extraction task that retrieves from the input database all the <em>Officer<\/em> elements that are shareholders of a company. Results are stored in a relational table containing the <em>Officer<\/em> names and the name of the corresponding <em>Entity<\/em>.<\/p>\n<p>We define a Neo4j mapping allowing to navigate the input database as a model: <tt>allOfType(type)<\/tt> operations are computed by searching for the nodes labeled by <em>type<\/em>, and <tt>newElement(type)<\/tt> instructions are mapped to a node creation with a label representing the type. We also define <tt>getRef(from, ref)<\/tt> navigation operations as edge navigations, and <tt>getAtt(from, att)<\/tt> property accesses on the node representing <em>from<\/em>. Note that this mapping does not contain any information specific to the ICIJ Offshore Leaks Database, and can be reused on top of any Neo4j database using the same data representation.<\/p>\n<p>To let the framework store the results in the desired relational database we defined an additional mapping that is able to access a relational database and serialize model elements in tables representing their types. Attributes are mapped to table columns, and references to foreign keys. Note that due to the lack of space we do not detail this mapping, but the complete definition is available on the project repository.<\/p>\n<p>Listing 3 shows the ATL transformation rule that expresses our operation: it matches all the <em>Officer<\/em> entities that corresponds to <em>Entity<\/em> shareholders in the input database and creates a corresponding <em>CompanyShareholder<\/em> record in the output model containing the names of the <em>Officer<\/em> and the related <em>Entity<\/em>. Listing 4 presents the corresponding Java code that uses the Neo4j and JDBC APIs to manipulate the databases.<\/p>\n<p>When the transformation is computed, source and target mappings are used to execute modeling operations defined in the ATL transformation. For example, the navigation of the <tt>SHAREHOLDER_OF<\/tt> reference is delegated to the Neo4j mapping, while the creation of the <em>CompanyShareholder<\/em> instance is computed by the relational mapping that creates a new table <em>CompanyShareholder<\/em> if it does not exist and inserts a new record in it containing the provided information.<\/p>\n<p>As illustrated by the provided examples, the ATL program is around two times shorter than the corresponding Java implementation. In addition, the ATL transformation only relies on ATL language constructs, and does not contain any explicit database specific operation. We believe that using ATL as a common language to perform data migration is interesting when modelers have to integrate data from heterogeneous sources, and do not have the expertise to write efficient queries both in the input and output database languages.<\/p>\n<p>The execution of this data migration operation creates 296041 records in the output database. The Java implementation is computed within 10342 ms, and the Gremlin-ATL one in 11006 ms. This execution time increase of 6.4% is caused by the underlying Gremlin engine that adds a small execution overhead, and our modeling layer that wraps the native APIs. Still, we think that the gains in terms of code readability and maintainability can balance this slight overhead increase and constitute an interesting solution to integrate data from multiple sources.<\/p>\n<p style=\"text-align: center;\"><strong>Listing 3. Company Shareholder Migration ATL Rule<\/strong><\/p>\n<pre>1  rule shareholder2relationalOfficer {\r\n2  from s : IN!Officer (not(s.name.oclIsUndefined()\r\n3    and s.SHAREHOLDER_OF-&gt;isEmpty())\r\n4  to t : OUT!CompanyShareholder(\r\n5    name &lt;- s.name,\r\n6    company &lt;- s.SHAREHOLDER_OF.name) \r\n7  }\r\n<\/pre>\n<p style=\"text-align: center;\"><strong>Listing 4. Company Shareholder Migration Java<\/strong><\/p>\n<pre>1  Connection c = ds.getConnection();\r\n2  c.createStatement().execute(\"create table if not exists CompanyShareholder (id integer not null auto_increment, name varchar(200), company varchar(200), primary key (id));\");\r\n3  c.commit();\r\n4  try (Transaction tx = graphdb.beginTx()) {\r\n5    try (ResourceIterator&lt;Node&gt; officers = graphdb.findNodes(Label.label(\"Officer\"))) {\r\n6      while (officers.hasNext()) {\r\n7        Node off = officers.next();\r\n8        Iterable&lt;Relationship&gt; rels = off.getRelationships(Direction.OUTGOING, RelationshipType.withName(\"SHAREHOLDER_OF\"));\r\n9        for (Relationship r : rels) {\r\n10         Node head = r.getEndNode();\r\n11         if(off.hasProperty(\"name\") &amp;&amp; head.hasProperty(\"name\")) {\r\n12           String officerName = (String)off.getProperty(\"name\");\r\n13           String companyName = (String)head.getProperty(\"name\");\r\n14           c.createStatement().execute(\"insert into CompanyShareholder values (NULL, '\" + officerName +\"', '\" + companyName + \"');\");\r\n15         }\r\n16       }\r\n17     }\r\n18     officers.close();\r\n19   }\r\n20 }\r\n<\/pre>\n<h2>8. Related Work<\/h2>\n<p>Several solutions have proposed to parallelize and distribute model transformations to improve the efficiency and scalability of existing transformation engines. ATL-MR [26] is a map-reduce based implementation of the ATL engine that computes transformations on top of models stored in HBase. The tool benefits from the distributed nature of the database to compute ATL rules in parallel, improving the overall execution time. Parallel-ATL [27] is an implementation of the ATL engine able to benefit from a multicore environment by splitting the execution into several workers that access a global shared model asynchronously. The LinTra [28] platform is another solution that relies on the Linda coordination model to enable concurrency and distribution of model transformations.<\/p>\n<p>Compared to these approaches, Gremlin-ATL does not require a parallel infrastructure to optimize the transformation but instead relies on the scalability mechanisms of the database engine, one of the strong points and initial motivations for the apparition of NoSQL databases. For example, the distributed Neo4j database provides a Gremlin endpoint that is able to execute efficiently traversals on graph databases stored in a cluster, by splitting the computation according to the data localization. The Gremlin language itself provides native parallization constructs (e.g., the <em>split-merge<\/em> step) that could be used to further improve transformation execution performance.<\/p>\n<p>The Viatra project [23] is an event-driven and reactive model transformation platform that relies on an incremental pattern matching language to access and transform models. Viatra receives model update notifications and uses its incremental engine to re-compute queries and transformation in an efficient way at the cost of a higher memory consumption. Viatra and Gremlin-ATL work best in different scenarios. Viatra is very efficient when a set of query\/transformations are executed multiple times on a model, while Gremlin-ATL is designed to efficiently perform single transformation computations.<\/p>\n<p>Transforming large models stored in databases is also related to the schema matching and data migration problems targeted in the database community [29]. Several approaches such as COMA [30] or Cupid [31] have been proposed to detect equivalent constructs in data schemas (using schema information or instances analysis), and integrated into data migration frameworks [32] to semi-automate data migration between heterogeneous sources. While Gremlin-ATL could benefit from these approaches (e.g., by automatically constructing <em>Model Mappings<\/em>), they usually focus on the schema matching phase and not on the efficient execution of the data migration processes based on those mappings.<\/p>\n<p>Our approach can also be combined with proposals on efficient graph transformation computation, such as the approach proposed by Krause et al. that parallelizes graph transformations using the Bulk Synchronous Parallel (BSP) framework Apache Giraph [33]. The Gremlin language provides a <a href=\"http:\/\/tinkerpop.apache.org\/providers.html\" target=\"_blank\" rel=\"noopener\">connector<\/a> to enable Giraph computation on top of graph databases, that could be used to link both approaches.<\/p>\n<h2>9. Conclusion<\/h2>\n<p>In this article we presented Gremlin-ATL, a framework that computes rule-based transformations by reexpressing them as database queries written in the Gremlin graph traversal language. Our evaluation shows that using Gremlin-ATL to transform models significantly improves the performance both in terms of execution time and memory consumption.<\/p>\n<p>As future work we plan to extend our approach into a family of mappings adapted to different NoSQL backends in order to provide a set of NoSQL modeling frameworks able to both store and manipulate models &#8220;natively&#8221;. We also plan to complete our mapping with the ATL constructs that are not yet supported and study translations from other transformation languages, which could reuse many of the patterns defined for ATL. Finally, we want to explore how Gremlin-ATL can be used in other scenarios involving the query, evolution and integration of unstructured data. Manipulating such data requires first to discover its implicit schema\/s. This schema can be naturally expressed as an explicit model and therefore be a natural fit for our framework that could then be used to facilitate its manipulation.<\/p>\n<h2>10. Aknowledgement<\/h2>\n<p>This work has been partially funded by the Electronic Component Systems for European Leadership Joint Undertaking under grant agreement No. 737494 (MegaM@Rt2 project) and the Spanish government (TIN2016-75944-R project).<\/p>\n<h2>11. References<\/h2>\n<p>[1] S.Azhar, &#8220;Building information modeling (BIM): Trends, benefits, risks, and challenges for the AEC industry,&#8221; Leadership and Management in Engineering, vol. 11, no. 3, pp. 241-252, 2011.<\/p>\n<p>[2] H.Bruneliere, J.Cabot, G.Dup\u00e9, and F.Madiot, &#8220;MoDisco: A model driven reverse engineering framework,&#8221; Information and Software Technology, vol. 56, no. 8, pp. 1012-1032, 2014.<\/p>\n<p>[3] J.L.C. Izquierdo and J.Cabot, &#8220;JSONDiscoverer: Visualizing the schema lurking behind JSON documents,\u201d Knowledge-Based Systems, vol. 103, pp. 52\u201355, 2016.<\/p>\n<p>[4] F.Jouault, F.Allilaire, J.B\u00e9zivin, and I.Kurtev, &#8220;ATL: A model transformation tool,&#8221; Science of Computer Programming, vol. 72, no. 1, pp. 31-39, 2008.<\/p>\n<p>[5] N.Huijboom and T.Van den Broek, &#8220;Open data: an international comparison of strategies,&#8221; European journal of ePractice, vol. 12, no. 1, pp. 4-16, 2011.<\/p>\n<p>[6] J.Hutchinson, J.Whittle, and M.Rouncefield, &#8220;Model-driven engineering practices in industry: Social, organizational and managerial factors that lead to success or failure,&#8221; Science of Computer Programming, vol. 89, pp. 144-161, 2014.<\/p>\n<p>[7] J. Whittle, J. Hutchinson, and M.Rouncefield, &#8220;The state of practice in model-driven engineering,&#8221; IEEE software, vol. 31, no. 3, pp. 79-85, 2014.<\/p>\n<p>[8] D.S.Kolovos, L.M.Rose, N.Matragkas, R.F.Paige, E.Guerra, J.S.Cuadrado, J.De Lara, I.R\u00e1th, D.Varr\u00f3, M.Tisi et al., &#8220;A research roadmap towards achieving scalability in model driven engineering,&#8221; in Proceedings of BigMDE&#8217;13. ACM, 2013, pp. 1-10.<\/p>\n<p>[9] OMG, &#8220;UML Specification,&#8221; 2017. [Online]. Available: www.omg.org\/spec\/UML<\/p>\n<p>[10] Eclipse Foundation, &#8220;The CDO Model Repository (CDO),&#8221; 2017. [Online]. Available: http:\/\/www.eclipse.org\/cdo\/<\/p>\n<p>[11] G.Daniel, G.Suny\u00e9, A.Benelallam, M.Tisi, Y.Vernageau, A.G\u00f3mez, and J.Cabot, &#8220;Neoemf: a multi-database model persistence framework for very large models,&#8221; in Proceedings of the MoDELS 2016 Demo and Poster Sessions. CEUR, 2016, pp. 1-7.<\/p>\n<p>[12] J.E.Pag\u00e1n, J.S.Cuadrado, and J.G.Molina, &#8220;A repository for scalable model management,&#8221; Software and Systems Modeling, vol. 14, no. 1, pp. 219-239, 2015.<\/p>\n<p>[13] R.Wei and D.S.Kolovos, &#8220;An efficient computation strategy for allinstances(),&#8221; Proceedings of BigMDE&#8217;15, pp. 32-41, 2015.<\/p>\n<p>[14] Tinkerpop, &#8220;The Gremlin Language,&#8221; 2017. [Online]. Available: www.gremlin.tinkerpop.com<\/p>\n<p>[15] OMG, &#8220;OCL Specification,&#8221; 2017. [Online]. Available: www.omg.org\/spec\/OCL<\/p>\n<p>[16] OMG, &#8220;QVT Specification,&#8221; 2017. [Online]. Available: http:\/\/www.omg.org\/spec\/QVT<\/p>\n<p>[17] J.E.Pag\u00e1n, J.S.Cuadrado, and J.G.Molina, &#8220;Morsa: A scalable approach for persisting and accessing large models,&#8221; in Proceedings of the 14th MoDELS Conference. Springer, 2011, pp. 77-92.<\/p>\n<p>[18] A.Benelallam, A.G\u00f3mez, G.Suny\u00e9, M.Tisi, and D.Launay, &#8220;Neo4EMF, a Scalable Persistence Layer for EMF Models,&#8221; in Proceedings of the 10th ECMFA. Springer, 2014, pp. 230-241.<\/p>\n<p>[19] Tinkerpop, &#8220;Blueprints API,&#8221; 2017. [Online]. Available: www.blueprints.tinkerpop.com<\/p>\n<p>[20] A.G\u00f3mez, G.Suny\u00e9, M.Tisi, and J.Cabot, &#8220;Map-based transparent persistence for very large models,&#8221; in Proceedings of the 18th FASE Conference. Springer, 2015, pp. 19-34.<\/p>\n<p>[21] G.Daniel, G.Suny\u00e9, and J.Cabot, &#8220;Mogwa\u00ef: a framework to handle complex queries on large models,&#8221; in Proceedings of the 10th RCIS Conference. IEEE, 2016, pp. 225-237.<\/p>\n<p>[22] D.S.Ruiz, S.F.Morales, and J.G.Molina, &#8220;Inferring versioned schemas from NoSQL databases and its applications,&#8221; in Proceedings of the 34th ER Conference. Springer, 2015, pp. 467-480.<\/p>\n<p>[23] G.Csert\u00e1n, G.Huszerl, I.Majzik, Z.Pap, A.Pataricza, and D.Varr\u00f3, &#8220;Viatra-visual automated transformations for formal verification and validation of UML models,&#8221; in Proceedings of the 17th ASE Conference. IEEE, 2002, pp. 267-270.<\/p>\n<p>[24] OMG, &#8220;Knowledge Discovery Metamodel (KDM),&#8221; 2017. [Online]. Available: http:\/\/www.omg.org\/technology\/kdm\/<\/p>\n<p>[25] C.Brun and A.Pierantonio, &#8220;Model differences in the eclipse modeling framework,&#8221; UPGRADE, The European Journal for the Informatics Professional, vol. 9, no. 2, pp. 29-34, 2008.<\/p>\n<p>[26] A.Benelallam, A.G\u00f3mez, M.Tisi, and J.Cabot, &#8220;Distributed model-to-model transformation with ATL on MapReduce,&#8221; in Proceedings of the 8th SLE Conference. ACM, 2015, pp. 37-48.<\/p>\n<p>[27] M.Tisi, S.Martinez, and H.Choura, &#8220;Parallel execution of ATL transformation rules,&#8221; in Proceedings of the 16th MoDELS Conference. Springer, 2013, pp. 656-672.<\/p>\n<p>[28] L.Burgue\u00f1o, M.Wimmer, and A.Vallecillo, &#8220;A linda-based platform for the parallel execution of out-place model transformations,&#8221; Information and Software Technology, vol. 79, pp. 17-35, 2016.<\/p>\n<p>[29] E.Rahm and P.A.Bernstein, &#8220;A survey of approaches to automatic schema matching,&#8221; The VLDB Journal, vol.10, no.4, pp. 334-350, 2001.<\/p>\n<p>[30] H.-H.Do and E.Rahm, &#8220;Coma: a system for flexible combination of schema matching approaches,&#8221; in Proceedings of the 28th international conference on Very Large Data Bases. VLDB Endowment, 2002, pp. 610-621.<\/p>\n<p>[31] J.Madhavan, P.A.Bernstein, and E.Rahm, &#8220;Generic schema matching with cupid,&#8221; in The VLDB Journal , vol.1, 2001, pp. 49-58.<\/p>\n<p>[32] C.Drumm, M.Schmitt, H.-H.Do, and E.Rahm, &#8220;Quickmig: automatic schema matching for data migration projects,&#8221; in Proceedings of the 16th CIKM conference. ACM, 2007, pp. 107-116.<\/p>\n<p>[33] C.Krause, M.Tichy, and H.Giese, &#8220;Implementing graph transformations in the bulk synchronous parallel model.&#8221; in Proceedings of the 17th FASE Conference, vol. 14, 2014, pp. 325-339.<\/p>\n<span class=\"et_bloom_bottom_trigger\"><\/span>","protected":false},"excerpt":{"rendered":"<p>Gremlin-ATL is a scalable and efficient model-to-model transformation framework that translates ATL transformations into Gremlin, a query language supported by several NoSQL databases<\/p>\n","protected":false},"author":30,"featured_media":5993,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_et_pb_use_builder":"","_et_pb_old_content":"","_et_gb_content_width":"","footnotes":""},"categories":[36,50,23],"tags":[117,435,591,433],"hashtags":[],"_links":{"self":[{"href":"https:\/\/modeling-languages.com\/wp-json\/wp\/v2\/posts\/5977"}],"collection":[{"href":"https:\/\/modeling-languages.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/modeling-languages.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/modeling-languages.com\/wp-json\/wp\/v2\/users\/30"}],"replies":[{"embeddable":true,"href":"https:\/\/modeling-languages.com\/wp-json\/wp\/v2\/comments?post=5977"}],"version-history":[{"count":0,"href":"https:\/\/modeling-languages.com\/wp-json\/wp\/v2\/posts\/5977\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/modeling-languages.com\/wp-json\/wp\/v2\/media\/5993"}],"wp:attachment":[{"href":"https:\/\/modeling-languages.com\/wp-json\/wp\/v2\/media?parent=5977"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/modeling-languages.com\/wp-json\/wp\/v2\/categories?post=5977"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/modeling-languages.com\/wp-json\/wp\/v2\/tags?post=5977"},{"taxonomy":"hashtags","embeddable":true,"href":"https:\/\/modeling-languages.com\/wp-json\/wp\/v2\/hashtags?post=5977"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}