Supporting CRUD Model Operations from EOL to SQL

Xabier De Carlos

, Goiuria Sagardui

and Salvador Trujillo

IK4-Ikerlan Research Center, P

◦

J. M. Arizmendiarrieta 2, 20500 Arrasate-Mondragon, Spain

Mondragon Unibertsitatea, Goiru 2, 20500 Arrasate-Mondragon, Spain

Keywords:

Model Driven Development, Persistence, Model Queries, Model Operations, Database.

Abstract:

Model-based software development promises improvements in terms of quality and cost by raising the abstrac-

tion level of the development from code to models, but also requires mature techniques and tools. Although

Eclipse Modelling Framework (EMF) introduces a default persistence mechanism for models, namely XMI,

its usage is often limited as model size increases. To overcome this limitation, during the last years alterna-

tive persistence mechanisms have been proposed in order to store models in RDBMS and NoSQL databases.

Under this new paradigm, model operations can be performed at model-level and persistence-level, e.g., map-

ping EOL model operations into SQL statements. In this paper, we extend our framework (called MQT) to

support CRUD (Create, Read, Update and Delete) operations from model- (EOL) to persistence-level (SQL),

using a streaming execution of queries at run-time. Through comparable evaluation metrics, we evaluate the

performance and memory footprint of the framework using the GraBaTs scenario.

1 INTRODUCTION

Model Driven Development (MDD) intended to raise

the abstraction level from code to models, using mod-

els as ﬁrst-class citizens of the development process

(Atkinson and Kuhne, 2003). The MDD adoption en-

compasses additional tasks such as model validation,

constraint checking or model analysis, often requir-

ing model querying and modiﬁcation. As in the tra-

ditional software development process, models may

become very large (up to millions elements), so scal-

able model persistence and operation mechanisms are

highly demanded (G

omez et al., 2015).

Eclipse Modelling Framework (EMF)

is a ma-

ture and a widely used modelling framework pro-

vided within the Eclipse IDE, which adopts XML

Meta-data Interchange (XMI)

as the default mech-

anism to persist models. However, as the size of the

model increases, XMI potentially may entail memory

and computation problems (Benelallam et al., 2014;

Espinazo Pag

an and Garc

ıa Molina, 2014). Conse-

quently, over the last decade, additional persistence

mechanisms have been proposed to effectively sup-

port large-scale models containing a bunch of ele-

ments such us in reverse engineering, construction

or wind-power (Bagnato et al., 2014)). These recent

https://eclipse.org/modeling/emf/

http://www.omg.org/spec/XMI/

approaches opt for the use of databases as a persis-

tence mechanism (e.g. Morsa (Pag

an et al., 2013), or

Neo4Emf (Benelallam et al., 2014)).

When models are persisted in a database, en-

gineers may operate with models in two different

ways: at model-level and persistence-level (also re-

ferred to as database-level). Model-level operations

are closer to modelling engineers due to the model-

ing language nature. Hence, if a persistence mecha-

nism is changed or evolved, model operations still re-

main valid. Some examples of model-level languages

are: Epsilon Object Language (EOL) (Kolovos et al.,

2010), Object Constraint Language (OCL)

, EMF

Query (Hunter, 2015), and IncQuery (Ujhelyi et al.,

2015). Persistence-level operations are database de-

pendant. This type of operations are typically ex-

ecuted directly over the database, with an inherent

straightforward performance optimization. Examples

here include: SQL for relational databases or Mor-

saQL (Espinazo Pag

an and Garc

ıa Molina, 2014), and

Morsa for models (Pag

an et al., 2013).

In a previous work, we presented the ﬁrst bits of

MQT (Model Query Translator), in a preliminary at-

tempt to translate a model-level imperative language

(EOL) into a persistence-level declarative language

(SQL) at run time. In this paper, we present a

proof-of-concept prototype that supports translation

http://www.omg.org/spec/OCL/

Carlos, X., Sagardui, G. and Trujillo, S.

Supporting CRUD Model Operations from EOL to SQL.

DOI: 10.5220/0005644401530160

In Proceedings of the 4th International Conference on Model-Driven Engineering and Software Development (MODELSWARD 2016), pages 153-160

ISBN: 978-989-758-168-7

153

1 EClass . all . pr i n tA bs tra c t Na me s () ;

2 for (c in EClass . all ){

3 c. e S up e rT y pe s .

pr i n tA bstr a ct Na me s () ;

4 }

5 operation Collection< E C lassifier >

pr i n tA bstr a ct Na me s () {

6 se l f . select ( c | c . abstrac t ) . n a me

. println () ; }

Listing 1: Sample model-level operation speciﬁed using

in EOL.

of CRUD (Create, Read, Update, Delete) operations

from EOL to SQL using streaming execution at run-

time. To the best of our knowledge, there is not any

other framework that supports CRUD operations from

EOL model operations to SQL.

2 TOWARDS RUN-TIME

QUERIES IN MODELS

Epsilon Object Language (EOL) (Kolovos et al.,

2006) is an imperative programming language for cre-

ating, querying and modifying EMF models. It is a

mixture of Javascript and OCL, and facilitates speci-

ﬁcation of queries and model modiﬁcations. For in-

stance, Listing 1 illustrates a model-level query spec-

iﬁed using EOL. In this example, the query prints the

names of all abstract EClass instances (line 1) and

uses the printAbstractNames (lines 5 to 7) oper-

ation for this purpose. All EClass instances are it-

erated (lines 2 to 4), and the names of each abstract

super-type are printed (line 3). Such query statement

also employs the printAbstractNames operation for

printing the names of the abstract candidates only.

SQL is a structured and mature language to

query or modify information from RDBMS (and

also from some NoSQL databases such as Mon-

goDB

or Neo4J

). While EOL is an imperative lan-

guage, SQL

is declarative. If we translate an

EOL query into a declarative language (e.g. SQL),

the printAbstractNames operation from Listing 1

should be translated differently for the statement in

line 1 and for the one in line 3.

For Listing 1, if translation is performed at

compilation-time, it will be necessary to decide query

mapping beforehand. Such static query-analysis is

avoided in case of run-time translation, since it will

allow the system to adapt the target SQL query for

http://www.unityjdbc.com/mongojdbc

https://goo.gl/l22XZO

http://www.w3schools.com/sql/default.asp

each particular scenario at execution time.

Moreover, there also exist some constructs that

have not direct mapping between EOL (imperative)

and SQL (declarative). For example, EOL supports

loop statements (line 5 in Listing 1) that are not sup-

ported, at least natively, in SQL. This means that

in compilation-time translation, such construct mis-

match increases the inherent translation complexity,

so run-time translation is more appropriate for ﬂexi-

ble mapping (Carlos et al., 2015).

3 CRUD OPERATIONS IN MQT

In a ﬁrst version, the MQT framework was able to

partially translate EOL operations into SQL and op-

erate with SELECT operations against a H2 embedded

database (Carlos et al., 2015). In this paper, we extend

the MQT framework which supports: the streaming

execution of queries, and the translation process for

all CRUD operations.

Figure 1a illustrates an overview of our frame-

work. As depicted in the ﬁgure, the EOL Module

is the responsible for parsing and executing model

operations. The EMC (Epsilon Model Connectivity

Layer) provides different interfaces to connect and

communicate with the EOL Module. In this sense,

MQT implements such interfaces for EOL integra-

tion.

The domain metamodel provides valuable infor-

mation during the translation process. MQT uses this

information to optimize SQL queries, as well as to

perform correctness checking for query results:

• Feature Cardinality is used to optimize query per-

formance by adding a limit clause (e.g. SELECT

* FROM ... LIMIT N) into the translated SQL.

Feature cardinality also checks if a query returns

the expected numbers of results.

• Feature Type for checking if a query returns in-

stances of the expected type.

• Subtypes. Know which classes extend a speciﬁc

EClass instance. This is useful when all instances

of a speciﬁc type are queried.

MQT uses a metamodel agnostic data-schema to

persist models (see Figure 1(b). For more informa-

tion about the persistence approach please refer to our

previous work (Carlos et al., 2015).

3.1 Streaming Execution of Queries

MQT provides streaming execution of translated SQL

statements. This means that queries are only executed

MODELSWARD 2016 - 4th International Conference on Model-Driven Engineering and Software Development

154

a) b)

Figure 1: (a) Overview of the framework and (b) database-schema used in MQT.

on-demand, with two major beneﬁts: (i) a lower mem-

ory usage since the information is queried and main-

tained in memory only when needed, and (ii) avoids

partial results which increase memory usage and ex-

ecution speed.

This is achieved through lazy-objects, with two

different implementations:

1. EDBObject. Each instance of this class repre-

sents a model-object. Each EDBObject instance

contains the ID of the model element within the

database and the type of the object. This lazy-

object is able to construct SQL statements in order

to obtain database attributes and reference values

of the represented model element. Values are only

obtained from the database when needed.

2. EDBCollection. This class is employed to in-

stantiate collections of model elements or feature

values. Each instance is a lazy-collection that is

able to construct a SQL statement based on trans-

lation information. The statement is only con-

structed and executed when the information of the

list is required by another operation. Additionally,

EDBCollection instances are able to customize

the constructed SQL statement to obtain the in-

formation from the database more efﬁciently (e.g.

the SQL statement would not be the same when

querying the size of a list or all elements within a

list).

During the translation process, both implementa-

tions, i.e. EDBObject or EDBCollection, are instan-

tiated by the EDBModel. This latter class is the respon-

sible for constructing and executing SQL statements

with the aim of creating new model element instances.

Additionally, the EDBModel class is the starting point

for the streaming translation and execution of the SQL

statements.

Figure 2 illustrates the streaming construction and

execution of a SQL query from a EOL operation. The

operation prints the name of the ﬁrst abstract EClass

instance speciﬁed within the queried model. Steps of

the translation are detailed below:

1. The EDBModel creates a new instance of a lazy-

collection containing model elements (L1). This

collection obtains information from the translated

query (at this point that objects should be of type

EClass). However, the SQL statement is not con-

structed nor executed since the information is not

required at this point.

2. The EDBModel creates another lazy-collection

(L2). This instance inherits information of L1

and also obtains new information related with the

condition. At this point the L2 collection is able

to construct a SQL statement which obtains all

EClass instances that are abstract. However, it is

not constructed at this point since the results are

not required.

3. MQT parses and translates the first() EOL op-

eration in the third step. This step requires to ob-

tain the ﬁrst element of the collection. With this

purpose, L2 collection constructs an SQL state-

ment with the information provided in the previ-

ous steps. Then executes the SQL query against

the database. The SQL statement returns all ab-

stract EClass instances to the L2 collection. Next,

L2 gets the ﬁrst result returned by the database and

instantiates an EDBObject specifying it(OBJ1). L2

returns OBJ1 to the EOL Module.

4. The name of the previously returned element is re-

quired, since it has to be printed in the screen. Be-

ing so, the OBJ1 instance constructs and executes

an SQL statement which obtains the value of the

name attribute in the database. Finally, the value

is returned and printed.

Supporting CRUD Model Operations from EOL to SQL

155

Figure 2: Run-time translation process and streaming execution.

3.2 Support for Model-Level CRUD

Operations

Table 1 illustrates the process followed by MQT for

translating and executing CRUD model operations

from EOL to SQL. Is important to note that with MQT

all the translated and executed SQL statements within

a same operation are committed only when the opera-

tion is executed completely. If commits are performed

after executing each translated SQL statement, and

the operation is not executed completely, result can

be a corrupted model.

4 EMPIRICAL STUDY

In this section, we aim to provide memory and per-

formance metrics for the run-time query translation

for different model CRUD operations and compare it

with XMI. The EOL operations have been executed

using MQT and XMI. Results correctness has been

automatically validated by comparing query results of

both approaches, i.e. MQT and XMI. In order to get

reliable numbers, each query was processed 10 times

for each case and discussed the results against the fol-

lowing quantitative metrics:

• Execution Time Average: Execution time average

of each case expressed in milliseconds (ms).

• Memory Usage: Maximum memory usage dur-

ing query execution for each case expressed in

megabytes (in MB).

In MQT, execution time includes both time for

query translation and time for query execution. In

XMI, execution time includes time for loading the

model in memory, time for executing the query and

time for persisting modiﬁcations. In the case of the

Read type operation, we also provide the query execu-

tion time required by XMI when the model has been

previously loaded in memory (not possible in CRE-

ATE, Update and Delete operations).

The experiment was executed as a standalone ap-

plication on a Intel Core I7-3520M @ 2.90 GHz,

8GB, Windows 7 SP1 (64-Bit) operative system and

Java SE v1.8.0. We have repeated 10 times the exe-

cution of each model operation and in each execution

the virtual machine was restarted. We provide met-

rics for models of the GraBaTs 2009 scenario (Sottet

et al., 2009), since it is widely used to evaluate model

persistence and querying approaches. These models

specify source code of different Java packages and

conform to the JDTAST metamodel which contains

abstractions of the Java source code. Table 2 sum-

marizes different properties of the GraBaTs’ models

(Set0-4). We have obtained evaluation metrics for the

following model CRUD operations:

• OP1: Create Operation. Creates one Class per

each existing TypeDeclaration (see Listing 2).

The name of the Class instance will correspond

with the name of the TypeDeclaration instance.

• OP2: Read Operation. Query from the Gra-

BaTs case study (Sottet et al., 2009) that prints

the names of all the singleton classes (Listing 3).

MODELSWARD 2016 - 4th International Conference on Model-Driven Engineering and Software Development

156

Table 1: Translation process of different CRUD operations.

Operation EOL Operation MQT Translation Generated SQL queries

Operations with model elements

Create model element new EClass EDBModel.createInstance() con-

structs and executes a SQL insert that

adds a new element within the database.

INSERT INTO Object

Delete model element — EDBModel.deleteElement() constructs DELETE FROM Object

and executes SQL statements that delete: DELETE FROM AttributeValue

the element itself, the attributes and SELECT refElements FROM ReferenceValue

references of the element, and childrens foreach(elem in refElements)

of the element. EDBModel.deleteElement(object)

Operations with single-value features

Update attribute or c.name=”E1” EDBObject.setValue() constructs UPDATE AttributeValue / ReferenceValue

non-containment reference a SQL update that replaces old value with

the new one.

Update containment reference c.children = elem EDBModel.setValue() method ﬁrst SELECT oldValue FROM ReferenceValue

checks if the reference contains a value if(oldValue != null)

(SQL select) and if contains it is deleted EDBModel.deleteElement(oldValue)

with a SQL delete. Then, another SELECT parent FROM ReferenceValue

SQL select checks if the new reference if(parent != null)

is contained by other element. If is UPDATE ReferenceValue

contained, a SQL update is generated and else

executed, else an insert SQL is generated

and executed.

INSERT INTO ReferenceValue

Operations with multi-value features

Create value c.eSuperFeatures.add(newElem) EDBCollection.add(), featureNumber = SELECT COUNT(features)

c.eSuperFeatures.addAll(elemList) EDBCollection.addAll() all call FROM AttributeValues/ReferenceValues

... to EDBCollection.addValue() that EDBModel.deleteElement(oldValue)

ﬁrst checks with a SQL select if the new EDBModel.deleteElement(oldValue)

value can be added. If it can be added, if featureNumber < maxValues

an SQL insert is constructed and executed INSERT INTO AttributeValues/ReferenceValues

for adding the new value. else

showErrorAndTerminate()

Update value c.eSuperFeatures = refList EDBCollection.setValue() checks if SELECT oldVal FROM AttributeValues/ReferenceValue

the feature contains values. If contains, it EDBCollection.removeAll(oldVal)

calls EDBCollection.deleteElement() to

delete them. Finally it calls EDBCollec-

tion.addValue() to set the new values.

EDBCollection.addAll(newVal)

Delete value c.eSuperFeatures.remove(elem) EDBCollection.remove() if feature.isContainmentReference()

c.eSuperFeatures.clear() EDBCollection.removeAll() all EDBModel.deleteElement(elem)

... call to EDBCollection.remove(). else

This method removes feature value from

the model element. If the reference is of

containment type, contained elements are

recursively deleted.

DELETE FROM AttributeValue/ReferenceValue

Table 2: Characteristics of the GraBaTs models.

Set0 Set1 Set2 Set3 Set4

Size (MB) 8,8 27 271 598 646

Classes 14 40 1.6K 5.7K 5.9K

Elem. 70K 198K 2M 4.8M 4.9M

• OP3: Update Operation. Renames all the exist-

ing TypeDeclaration instances (Listing 4).

• OP4: Delete Operation. Selects the ﬁrst

CompilationUnit instance and then deletes all

the elements that are contained in the reference

called types and all the elements contained by

them (Listing 5).

for( ty pe in T yp eD ec la ra ti on . all ){

var c l ass = new E C l a s s ;

cla s s . name = t ype . na me .

fu l l yQ uali f ie dN am e ;}

Listing 2: Create type operation.

var t= T y p eD ec la ra ti on . all . se l e c t (

td |

td . bo d y De clar a t ions . e x i s t s ( md :

Me t h od De clar a ti on |

md . modi f i e r s . ex i s t s ( mod : M o d i f i er |

mod . public == true ) and md .

modi f i e rs . e x i s t s ( mod : M o d i f i er |

mod . static == true ) and md .

ret u r n Ty p e . is T yp e O f ( Si mp l eT y pe

) and md . retur n T y pe . n ame .

fu l l yQ uali f ie dN am e == td . name .

fu l l yQ uali f ie dN am e )) ;

for ( it er a t o r in t)

itera t o r . name . fu l ly Qu al if ied N a me

. println () ;

Listing 3: Read type operation.

4.1 Discussion

Table 3 illustrates the memory and performance

results for each operation (OP1-4) for Set0-4. We

have further analyzed the evaluation results below:

Supporting CRUD Model Operations from EOL to SQL

157

Table 3: Obtained results: execution time average (in milliseconds) and maximum memory usage (in Megabytes).

SET 0 SET 1 SET 2 SET 3 SET 4

Time Mem Time Mem Time Mem Time Mem Time Mem

CREATE

XMI 2626 169 6173 304 24104 1078 60551 2159 73084 2309

MQT 98 125 171 122 1665 175 3830 355 4085 366

READ

XMI 2663 163 3980 310 26541 1127 76407 2284 81538 2437

MQT 164 130 216 118 1646 187 3075 317 3288 316

UPDATE

XMI 4880 165 8700 328 38313 1505 100415 3069 145246 3305

MQT 101 116 200 124 2351 181 8406 374 9532 399

DELETE

XMI 3394 155 4607 330 29446 1539 86707 3069 87736 3241

MQT 5705 699 14278 755 80137 667 224272 449 245803 474

for( ty pe in T yp eD ec la ra ti on . all )

ty p e . nam e . f ul ly Qual i fi ed Na me = "

NewName ";

Listing 4: Update type operation.

var c o mp U n i t = C ompi l a ti on Un it . a ll

. fi r s t () ;

compU n i t . t y p es . clear () ;

Listing 5: Delete type operation.

Create Operation. With this operation we have in-

serted 0,02% of the model elements in Set0 and Set1,

0,08% in Set2 and 0,10% in Set3 and Set4. Execu-

tion Time: Differences in time consumption are very

relevant as MQT is between 14 and 36 times faster

than XMI. Analysing the execution time for insertion

with respect to the total number of elements of the

models, in Set0 and Set1 while MQT takes 0,001 ms

for each element in XMI it takes 0,03 ms. In big-

ger models, while the execution time per each ele-

ment is lower in both approaches, in XMI is around

0,013 ms, MQT takes 0,0008 ms for each model ele-

ment. Looking at the execution time with respect to

the number of inserted model elements, MQT ranges

from 7 ms for each inserted element in Set0 to 0,7 ms

in Set4. In XMI it takes 187 ms for each inserted ele-

ment in Set 0 and 12 ms in Set4. In both approaches,

the time to insert an element decreases as the number

of inserted elements grows, which indicates an over-

head independent of the number of elements inserted.

Memory Usage. XMI consumes more memory than

MQT. Differences in memory consumption are big-

ger as the size of the models grows. In Set0, MQT

consumes 26% less memory than XMI, in Set1 60%

and in Set2, Set3 and Set4 consumes around 84% less

than XMI. By using the advantages of operating at

persistence level, memory consumption is very low in

MQT (366,2 MB in the biggest model) which indi-

cates that is more appropriate for bigger models than

XMI.

Read Operation. Execution Time. Size of the

model has a great impact over the time required to

execute the read operation with XMI as the model has

to be loaded in memory before operating it. Conse-

quently, XMI requires more time than MQT to exe-

cute the query. From Set0 to Set2 XMI is between 16

and 18 times slower than MQT. But this difference is

increased on the two largest models (Set3 and Set4)

where MQT is 24 times faster than XMI. Addition-

ally, if we compare the results of MQT with the time

required by XMI when the model has been already

loaded in memory, these are similar in both cases.

Memory Usage. The memory usage with XMI and

MQT is similar in the case of Set0 (around 150MB).

In Set1, while the memory usage is duplicated re-

spect to Set0 if XMI is used, memory usage is sim-

ilar in MQT. The model size has higher impact over

memory usage in Set2 with XMI and it is increased

to around 1.1GB. By contrast, memory usage impact

is lower if MQT is used and it only increases 69MB.

In Set3, while memory usage is duplicated respect to

Set2 if XMI is used (using around 2.2GB), MQT only

requires 317MB. The trend is similar in Set4 where

XMI requires more than 2.4GB and MQT only uses

316MB. These memory usage results show how the

streaming execution of SQL statements provided by

MQT minimizes the memory usage when models are

queried, since it only loads the required information.

Update Operation. With this query we have up-

dated 0,02% of the model elements in Set0 and Set1,

0,08% in Set2 and 0,10% in Set3 and Set4. Execu-

tion Time. XMI requires to serialize again the mod-

iﬁed model (from memory) and MQT only requires

persisting changes. Being so, MQT is 48 times faster

than XMI for Set0, 43 times faster for Set1, 16 times

faster for Set2, around 12 times faster for Set3 and

15 times faster for Set4. Looking at the execution

time with respect to the number of updated model el-

ements, MQT ranges from 7.2 ms for each inserted

MODELSWARD 2016 - 4th International Conference on Model-Driven Engineering and Software Development

158

element in Set0 to 1.5 ms in Set4. XMI takes 348 ms

for each inserted element in Set 0 and 24 ms in Set4.

In both approaches, the time to update an element is

around double time to insert an element. Update re-

quires ﬁrst to ﬁnd the element and then perform the

update. Memory Usage. XMI consumes more mem-

ory than MQT. Differences in memory consumption

are bigger as the size of the models grows. In Set0,

MQT consumes 30% less memory than MQT, in Set2

62% and in Set2, Set3 and Set4 consumes 88% less

than XMI. While in XMI memory consumption for

Set4 is 20 times bigger than Set0, for MQT is only

3.44 times bigger.

Delete Operation. Execution Time. In the case of

MQT, performance values are not assumable for large

models. The design of the delete operation translation

is recursive: deleting an element also requires per-

forming additional operations to delete children con-

tained by the deleted element. This design derives in a

translation that contains many SQL statements. There

is need of re-factoring the translation for the delete

operations. In the case of XMI, entire model is previ-

ously loaded in-memory and the operation for obtain-

ing elements to be deleted, and then delete them, is

resolved faster. However, XMI requires more than 86

seconds for performing delete operation on the largest

models (Set3-4). Memory Usage. While memory us-

age values are higher than XMI in Set0-1 (4.5 times

for Set0 and 2.3 times for Set1), memory usage is

lower than XMI in the other models (2.3 times for

Set2 and 6.8 for Set3-4).

4.2 Threats to Validity

We have used metamodels and models from the Gra-

BaTs 2009 case study, a widely used case study to

evaluate model persistence and querying approaches.

However, a more intensive evaluation should be per-

formed analysing the impact of the nature of the

model and the metamodel over the execution time and

memory footprint.

5 RELATED WORK

There are other proposals to generate persistence level

queries from model-level queries: In (Egea et al.,

2010), the authors describe an approach focused on

generating MySQL code from a given OCL expres-

sions. An approach to generate SQL queries from

OCL invariants is presented in (Heidenreich et al.,

2007). In (Demuth et al., 2001), the authors de-

scribe an approach that generates views using OCL

constraints, and then uses them to check the integrity

of the persisted data. The approach has been imple-

mented using a tool that generates SQL queries from

OCL constraints (OCL2SQL

). A similar approach

for integrity checking is proposed in (Marder et al.,

1999). DresdenOCL (Demuth and Wilke, 2009) pro-

vides a tool set that supports parsing and evaluating

OCL constraints on various models (e.g. EMF, Java,

or UML). Additionally, the approach also provdes

Java/AspectJ and SQL code generation. All these pre-

viously described approaches translate OCL queries

(Read type operations) into SQL. The approaches

provide a compilation-time translation since both lan-

guages are declarative and they have direct mapping.

By contrast, our approach translates EOL, a impera-

tive language, to a declarative language (SQL). For

this reason, our framework performs the translation

at run time. Moreover, as an imperative language is

translated, MQT supports translation of CRUD oper-

ations.

Another work (Parreiras, 2012) describes an ap-

proach that, ﬁrst executes queries in persistence-level

(SPARQL). And then uses obtained results as the

input of model-level queries (OCL). While this ap-

proach translates queries from persistence-level to

model-level, our approach provides translation from

model- to persistence-level.

6 CONCLUSIONS

In this paper, we have presented an extension of the

MQT framework to support run-time translation and

streaming execution of model CRUD operations from

EOL to SQL. The framework provides the model en-

gineers the usability of operating at model-level but

at the same time taking advantages of database per-

formance. We have tested the framework for differ-

ent CRUD operations (OP1-4) for models of different

sizes (Set0-4). Overall, MQT seems to perform prop-

erly in terms of memory and time for create, read and

update operations but not for delete. MQT requires

less memory than XMI and at the same time, execu-

tion times are also better than XMI.

For future work, we will perform an evaluation

taking into account more operations and larger mod-

els. We also plan to improve the translation and exe-

cution mechanism for delete type operations.

“http://dresden-ocl.source”

Supporting CRUD Model Operations from EOL to SQL

159

ACKNOWLEDGEMENTS

This work is partially supported by the EC, through

the Scalable Modelling and Model Management on

the Cloud (MONDO) FP7 STREP project (#611125).

The authors wish to thank Aitor Murguzur, Xabier

Mendialdua and Dimitris Kolovos for his participa-

tion on this work.

REFERENCES

Atkinson, C. and Kuhne, T. (2003). Model-driven develop-

ment: a metamodeling foundation. Software, IEEE,

20(5):36–41.

Bagnato, A., Brosse, E., Sadovykh, A., Mal

o, P., Trujillo,

S., Mendialdua, X., and Carlos, X. D. (2014). Flexible

and scalable modelling in the MONDO project: In-

dustrial case studies. In Proceedings of the 3rd Work-

shop on Extreme Modeling, Valencia, Spain, Septem-

ber 29, 2014., pages 42–51.

Benelallam, A., G

omez, A., Suny

e, G., Tisi, M., and Lau-

nay, D. (2014). Neo4EMF, a Scalable Persistence

Layer for EMF Models. In Cabot, J. and Rubin,

J., editors, Modelling Foundations and Applications,

volume 8569 of Lecture Notes in Computer Science,

pages 230–241. Springer International Publishing.

Carlos, X. D., Sagardui, G., Murguzur, A., Trujillo, S., and

Mendialdua, X. (2015). Model Query Translator - A

Model-Level Query Approach For Large-Scale Mod-

els. In Proceedings of the 3rd International Confer-

ence on Model-Driven Engineering and Software De-

velopment, Angers, France.

Demuth, B., Hussmann, H., and Loecher, S. (2001). OCL

as a Speciﬁcation Language for Business Rules in

Database Applications. In Gogolla, M. and Kobryn,

C., editors, UML 2001 The Uniﬁed Modeling Lan-

guage. Modeling Languages, Concepts, and Tools,

volume 2185 of Lecture Notes in Computer Science,

pages 104–117. Springer Berlin Heidelberg.

Demuth, B. and Wilke, C. (2009). Model and object ver-

iﬁcation by using dresden ocl. In Proceedings of

the Russian-German Workshop Innovation Informa-

tion Technologies: Theory and Practice, Ufa, Russia,

pages 687–690.

Egea, M., Dania, C., and Clavel, M. (2010). MySQL4OCL:

A Stored Procedure-Based MySQL Code Generator

for OCL. Electronic Communications of the EASST,

36.

Espinazo Pag

an, J. and Garc

ıa Molina, J. (2014). Query-

ing Large Models Efﬁciently. Inf. Softw. Technol.,

56(6):586–622.

omez, A., Tisi, M., Suny

e, G., and Cabot, J. (2015). Map-

based transparent persistence for very large models.

In Egyed, A. and Schaefer, I., editors, Fundamen-

tal Approaches to Software Engineering, volume 9033

of Lecture Notes in Computer Science, pages 19–34.

Springer Berlin Heidelberg.

Heidenreich, F., Wende, C., and Demuth, B. (2007). A

Framework For Generating Query Language Code

From OCL Invariants. Electronic Communications of

the EASST, 9.

Hunter, A. (2015). EMF Query. https://projects.eclipse.

org/projects/modeling.emf.query. [Online; accessed

02-February-2015].

Kolovos, D., Paige, R., and Polack, F. (2006). The epsilon

object language (eol). In Rensink, A. and Warmer, J.,

editors, Model Driven Architecture Foundations and

Applications, volume 4066 of Lecture Notes in Com-

puter Science, pages 128–142. Springer Berlin Hei-

delberg.

Kolovos, D. S., Rose, L. M., and Paige, R. F. (2010). The

epsilon book (2010).

Marder, U., Ritter, N., and Steiert, H. (1999). A DBMS-

Based Approach for Automatic Checking of OCL

Constraints. In Proceedings of OOPSLA, volume 99,

pages 1–5.

Pag

an, J. E., Cuadrado, J. S., and Molina, J. G. (2013).

A Repository for Scalable Model Management. Soft-

ware & Systems Modeling, pages 1–21.

Parreiras, F. S. (2012). Semantic Web and Model-driven

Engineering. John Wiley & Sons.

Sottet, J.-S., Jouault, F., et al. (2009). Program compre-

hension. In Proc. 5th Int. Workshop on Graph-Based

Tools.

Ujhelyi, Z., Bergmann, G., Heged

us,

A., Horv

ath,

A., Izs

B., R

ath, I., Szatm

ari, Z., and Varr

o, D. (2015). EMF-

IncQuery: an Integrated Development Environment

for Live Model Queries. Sci. Comput. Program.,

98:80–99.

MODELSWARD 2016 - 4th International Conference on Model-Driven Engineering and Software Development

160