Supporting CRUD Model Operations from EOL to SQL
Xabier De Carlos
1
, Goiuria Sagardui
2
and Salvador Trujillo
1
1
IK4-Ikerlan Research Center, P
J. M. Arizmendiarrieta 2, 20500 Arrasate-Mondragon, Spain
2
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 first-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 modification. 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)
1
is a ma-
ture and a widely used modelling framework pro-
vided within the Eclipse IDE, which adopts XML
Meta-data Interchange (XMI)
2
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
1
https://eclipse.org/modeling/emf/
2
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)
3
, 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 first 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
3
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
Copyright
c
2016 by SCITEPRESS Science and Technology Publications, Lda. All rights reserved
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 specified 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-
fication of queries and model modifications. For in-
stance, Listing 1 illustrates a model-level query spec-
ified 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
4
or Neo4J
5
). While EOL is an imperative lan-
guage, SQL
6
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
4
http://www.unityjdbc.com/mongojdbc
5
https://goo.gl/l22XZO
6
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 flexi-
ble mapping (Carlos et al., 2015).
3 CRUD OPERATIONS IN MQT
In a first 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 figure, 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 specific
EClass instance. This is useful when all instances
of a specific 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 benefits: (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 efficiently (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 first abstract EClass
instance specified 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 first 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 first 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 modifications. 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 first 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)
first 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 first
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-
ified 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 first to find 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
7
). 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, first 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.
7
“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 Specification Language for Business Rules in
Database Applications. In Gogolla, M. and Kobryn,
C., editors, UML 2001 The Unified 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-
ification 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 Efficiently. Inf. Softw. Technol.,
56(6):586–622.
G
´
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
´
o,
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