Scalable model persistence frameworks have been proposed to handle large (potentially generated) models involved in current industrial processes. They usually rely on databases to store and access the underlying models, and provide a lazy-loading strategy that aims to reduce the memory footprint of model
navigation and manipulation. Dedicated query and transformation solutions have been proposed to further improve performances by generating native database
queries leveraging the backend’s advanced capabilities. However, existing solutions are not designed to specifically target the validation of a set of constraints over large models. They usually rely on low-level modeling APIs to retrieve
model elements to validate, limiting the benefits of computing native database queries. In this paper we present an extension of the Mogwa¨ı query engine that aims to handle large model validation efficiently. We show how model constraints
are pre-processed and translated into database queries, and how the validation of the model can benefit from the underlying database optimizations. Our approach is released as a set of open source Eclipse plugins and is fully available online.
2. Introduction
Large models are not a research chimera!
Civil engineering
Biology
Reverse engineering
Need to provide solutions to
Store large models
Efficiently query, transform and validate them
3. Model Persistence
Default serialization mechanism: XMI
Scalable model persistence frameworks
Use databases to store models
Relational: CDO
NoSQL: Morsa, NeoEMF
Advanced features (versioning, collaborative editing, transactions)
Low memory footprint
4. Model Queries and Transformations
API Call1
…
API Calln
OCL
Query
OCL
Interpreter
EMF API Database
Package.allInstances().name
get(p1)
get(p1,name)
…
get(pn)
get(pn,name)
Low-level modeling API
→ Not aligned with the
database capabilities
Fragmented queries
→ Not efficient
→ Remote database
Intermediate objects
→ Memory consumption
→ Execution time overhead
5. Model Queries and Transformations
Not efficient to compute model queries and transformations
Why can’t we write database queries manually?
Model persistence frameworks typically rely on NoSQL databases
Multiple query languages, data representation, etc
Low-level queries are hard to understand and maintain
Modeling expertise vs. Database expertise
Solution: generate them!
6. Mogwaï
Translation engine
Support for OCL and ATL
Generates generic Gremlin traversals
Backend-agnostic queries
Model datastore
Abstraction layer on top of the backend
Defines query and transformation primitives
Implementations for NeoEMF, Neo4j3, and experimental Jdbc support
8. Model Validation
Mogwaï efficiently supports model queries and transformations
What about model validation?
Two-step process
Find the elements to check (i.e. involved in at least one constraint)
Typically costly in scalable model persistence frameworks
Check the constraints for each elements
Efficiently computed by Mogwaï query engine
Can we optimize this two step process to benefit from Mogwaï?
9. Model Validation
Mogwaï
Translation Engine
Model
Database
Model Constraints
Gremlin
Script
Model Datastore
Impl.
uses
e1: El
Model Datastore
Definition
uses
implements
Database
results
e1: El
e1: ElModel
Elements
v1
v3
v2Reification
Constraint
Pre-processing
10. Constraint pre-processing
context Client inv validClient:
self.hasPaid implies self.orders.products
->forAll(p | p.price > 0)
Constraint Rewriting
• Based on existing work
1- Find all the Clients
2- Evaluate validClient for each
Client instance
Client.allInstances()->select(c | !(c.hasPaid implies
c.orders.products->forAll(p.price > 0)))
11. Constraint Rewriting
Systematic mapping
Translate context-specific constraints into global queries
Local optimizations
Mogwaï benefits
Efficient allInstances() computation
Execute a single query
Return all the instances violating the constraint
13. Evaluation
0
20
40
60
80
100
120
140
MDT OCL Standard AllInstances + Mogwaï Pre-processing + Mogwaï
Model Validation Memory Consumption (MB)
NotEmptyClassName ValidJavadocTags
Benchmarks
Java Model
~ 80 000 elements
3 configurations / 2 constraints
14. Conclusion
Mogwai
Translation-based approach
Standard language support
No query fragmentation
Support for various datastores
Model validation with Mogwaï
Constraint pre-processing
Single query execution
Positive results
15. Future Work
Advanced rewriting techniques
Adapted to the underlying database ‘’schema’’
Heuristics (number of operations, nested iterators, etc)
Constraint composition
Static analysis
Reuse common parts in constraint navigation paths
Rewrite a set of constraints