Persisting and managing models larger than a few tens of megabytes using XMI introduces a signi cant time and memory footprint overhead to MDE work ows. Several approaches provide alternative persistence mechanisms based on databases that can be integrated with EMF. However, to the best of our knowledge there is less coverage of approaches on models persistence which include model querying, versioning and edition capabilities leveraging persistence capabilities. In this poster we present an approach that provides model persistence based on embedded databases. This approach aims to provide scalability through model edition, querying and versioning mechanisms that leverage database capabilities.
XML Metadata Interchange (XMI) is an XML-based model interchange format standardised by the OMG, and the default model persistence format in the widely-used Eclipse Modelling Framework (EMF). Being an XML-based format, models stored in XMI need to be fully loaded in memory before they can be queried or modi ed. As models grow in size, this can have a signi cant impact both on the overall time needed to execute a query on a stored model, and on the memory footprint of the host application. As such, there is a need for alternative model persistence mechanisms that scale better in terms of speed and memory footprint.
Approaches like Morsa[
Additionally, models are used within collaborative modelling environments
where di erent versions of models are managed and shared between developers.
Version Control Systems (VCSs) provide support for version management, and
di erent approaches have been proposed for version control of models. Some
approaches such as ModelCVS [
Other approaches like EMF Compare [
Contribution While some approaches focus on providing persistence for large-scale models (i.e. Morsa, Neo4EMF, etc.), other approaches focus on model-speci c VCSs (i.e. EMFStore, ModelCVS, etc.). However, to the best of our knowledge, a database persistence mechanism to be integrated with a distributed VCS (i.e. GIT) has not been explored yet, and we believe that this mechanism can be a good alternative for large-scale model versioning. Providing a persistence mechanism also implies to implement model query and edition mechanisms. Consequently, as we are looking for a scalable solution to be used for large-scale model persistence, version control, edition and querying mechanisms should be scalable.
We propose a persistence mechanism to be integrated within VCSs. Scalability on version control, and model-level edition and querying is supported through mechanisms that leverage capabilities of the database (i.e. partial load and modi cations). The approach is divided in four parts: persistence (core of the approach) and edition, query and version control layers that are created around the persistence and leveraging its capabilities. 2.1
While most of the existing approaches perform model versioning through centralised repositories, we propose database based persistence of models to be integrated within distributed VCSs. Persistence is based on single- le embedded databases and it provides di erent bene ts: (i) drop-in replacement for XMI les facilitating integration in a VCS and in modelling tools; (ii) partially load and modify models; and (iii) model comparison at di erent levels ( le, database or model levels).
Work done and open issues. We have implemented a mechanism that persists models in embedded and single- le relational databases. We have used H2 as the database back-end. The designed data schema is metamodel-agnostic and it supports persistence of models that conform to arbitrary metamodels. We have validated the solution with positive results after performing preliminary evaluation. Open issues related to this task are: (i) to perform a more complete evaluation comparing performance with other database con gurations (indexes, table views, cache, etc.) and also with other existing solutions; (ii) to improve the database schema; (iii) to analyse alternative embedded database back-ends; and (iv) to analyse how to persist more complex models (mega-models, models with decorator models, etc.) 2.2
While model-level query languages such as OCL or EOL are commonly used by engineers, persistence-level query languages leverage capabilities of the used persistence mechanism. To solve this issue, Model-Level Query Layer translates at run-time model-level EOL queries to persistence-level (SQL). Performing the translation at run-time provides transparency to the modelling engineers that can specify and execute model-level queries without worrying on the used persistence mechanism. In this way, the model-level queries are automatically translated to a persistence-speci c query language, leveraging persistence mechanism's capabilities.
As Figure 1 illustrates, the run-time translation process parses query expressions within the query program. Each query expression is translated at run-time. Translated query is executed over the database (the model) only when the information is required (by other queries or by the user).
Work done and open issues. We have implemented a rst prototype that translates EOL queries to SQL queries and also executes over the persistence mechanism. Additionally, we have analysed the time required by the approach for performing the query translation, concluding that the translation does not imply a signi cant time overload. The prototype supports all the EOL sentences that obtain information from models. Model modi cation sentences are not supported, but we plan to support them in a future prototype. Moreover, the prototype supports only EOL at model-level and SQL at persistence level. For future work we plan to add extensibility, providing more query languages at both sides. 2.3
The approach provides a database persistence mechanism to be used in distributed mainstream VCSs. While source code di erencing/merging is natively supported by VCSs (i.e. GIT or Subversion), they only support versioning models at le-level. Thus, the VCS Integration Layer provides support for model-speci c and scalable di erencing and merging.
In this way, we propose a di erencing and merging mechanism that perform the di erence and merge at di erent-levels. Figure 2 illustrates the proposed strategy. As it is shown on the gure, a con ict appears when User2 pushes a new model version to User1. Consequently, a di erence or merge should be performed. Both versions (model.db) are a large-scale model persisted within an embedded single- le database. Being so, versions are compared rst at le or database level (step 1 ) and then the di erences are extracted (step 2 ). Finally, di erences are used to load models partially on the di erencing/merging (step 3 ). These partial models only contain the information required to resolve the con ict.
Work done and open issues. We have described directions that we will follow to provide a scalable model di erencing/merging solution which leverage capabilities of the proposed persistence mechanism. However, the approach is not yet implemented. Moreover we have to analyse feasibility to extend existing di erencing/merging tools (i.e. EMF Compare) with this strategy. 2.4
Providing an alternative persistence mechanism requires the support of integration with modelling tools, to be able to edit persisted models. The Tool Integration Layer aims to provide integration of the persistence mechanism with EMF. This layer will implement the Resource interface of EMF to integrate the persistence mechanism with EMF. Moreover, scalable solutions for model edition such as partial load or load on demand will be provided.
Work done and open issues. We have described directions to be followed to integrate persistence within EMF-based modelling tools and they will be implemented in the future.