The Model View Framework provides/relies on the same API as the modeling framework. It is fundamental to be non-intrusive, to be interoperable with other EMF-based solutions (model querying, model transformation, code generation, etc.). The bypass between the view framework and the database persistence framework is useful for scalability reasons (native actions on the resources, e.g. queries).
Towards Scalable Model Views on Heterogeneous Model Resources - MODELS 2018 @Copenhagen, Denmark
Towards Scalable Model Views on
Heterogeneous Model Resources
ACM/IEEE 21st International Conference on
Model Driven Engineering Languages and Systems
October 19, 2018 - Copenhagen, Denmark
Hugo Bruneliere, Florent Marchand de Kerchove,
Gwendal Daniel, Jordi Cabot
● Engineering of complex systems (e.g. CPSs)
○ Models have different nature, number or size
○ Need for views combining these models
● EMF Views for building/handling views over
heterogeneous EMF models
○ Relies on a model virtualization mechanism
○ Works quite well on models of reasonable size
● What about scalability in more realistic scenarios?
○ Industrial applications with larger scale models
coming from different data sources...
Context & Problem
● A conceptual integration approach combining model views
and model persistence solutions
● A practical realization of this approach with
○ EMF Views - model view framework
○ NeoEMF & CDO - model persistence frameworks
● An evaluation of the approach + implementation in a
realistic use case from the MegaM@Rt2 European project
● Building views on heterogenous model sources
○ Platform-specific initialization code for NeoEMF and
CDO (e.g. URL, ResourceFactory, data store config.)
● Persisting the view information in a scalable way
○ Initializing a NeoEMF database backend (instead of
standard XMI model serialization)
● Optimizing the view loading and element access
○ Early exits in collection navigation (e.g. EList), more
lazy loading for virtual references in EMF Views core
● Optimizing the view querying...
Integration Approach - Challenges
● Two versions of the same view
○ Fully file-based - standard EMF-XMI
○ Mix of file and database resources
■ Requirement and Component models → EMF-XMI
■ Runtime model + view-specific data → NeoEMF
■ Java source code model → CDO
● Three complementary benchmarks
○ View creation, view loading and view querying
○ Model size from 10¹ to 10⁶ elements
● Main observations
○ Slower and more memory-consuming to create the
view-specific information than XMI (as expected)
○ 4x faster than XMI for loading a 10⁶ view
○ 3x to 42x slower than XMI for navigating
○ Slower than XMI for querying (as expected)
■ Up to 6x speedup by specializing OCL queries...
● Use of a common modeling API (provided by EMF)
○ Base integration was relatively straightforward
■ EMF Views + NeoEMF + CDO
○ Capabilities/features (from these tools) can be hidden
■ Efficient APIs not available from the generic API
○ Impacts of some actions can be hidden
■ API default behavior may lead to surprising (and
■ More elaborated delegation strategies have to be
envisioned to get more benefits...
● Quite significant number of model view approaches
○ Cf. https://hal.archives-ouvertes.fr/hal-01590674
○ Not so many proofs of their scalability
● Few approaches integrating models from different sources
○ If they do, they have other limitations (e.g. querying)
● Model composition or decoration approaches
○ Limited optimization strategies for different backends
● Interesting work available on the model querying side
○ Incrementality, data warehouse, etc.
○ Possible extensions of our approach...
● Extend the optimized querying support (for OCL but also
using other transformation languages)
■ Cf. the Mogwaï approach for instance
■ Cf. capabilities provided by VIATRA
● Connection with other modeling APIs, environments or
■ KMF, Epsilon, etc.
● In MegaM@Rt2 project… more applications!
■ E.g. on systems having physical parts (CPS)
Fork us: https://github.com/atlanmod/emfviews
Check out the paper: https://hal.archives-ouvertes.fr/hal-01845976
firstname.lastname@example.org , florent.marchand-de-kerchove@imt-
email@example.com , firstname.lastname@example.org
Thanks for your attention!