This document summarizes the TemporalEMF approach for managing temporal aspects of models.
The key points are:
1. TemporalEMF provides a lightweight extension to modeling standards that treats models and their elements as temporal, allowing automatic management of model history without requiring changes to modeling tools or processes.
2. It implements a new infrastructure built on Eclipse Modeling Framework and a NoSQL database to store the temporal evolution of models.
3. The approach defines a temporal query language to retrieve historical information from models at different points in time, addressing current limitations of modeling tools around temporal aspects.
4. Right now, Simulated
by using VCS
1. Doesn’t scale (every time
we save the whole model)
2. Must be triggered on-
demand
3. No fine-grained
management of individual
elements (e.g. Queries)
9. TemporalEMF contributions
• Light-weight extension of current metamodeling standards:
– Models are automatically and transparently treated as temporal
(“normal” access performed as usual)
• Implemented in a new Infrastructure to manage temporal models:
– TemporalEMF is built on top the Eclipse Modeling Framework.
– Models history is stored in a NoSQL database.
• We outline a temporal OCL-like query language to retrieve historical
information from models at any point in time.
9
10. Applications
• Collaborative modeling where you want to
revise past design decisions and/or constraint
how the model can be evolved
• Model-based Simulation where you want to
model different scenarios, run them and study
which ones performed the best
10
12. A Profile for Temporal Metamodeling
12
Combines our previous Temporal UML work with
the concept of EMF Profiles
13. A Transportation Line Metamodel
Simulator – Smart Production Systems
13
CDL-MINT is a multi-year research effort towards liquid models of cyber-physical production
systems. https://cdl-mint.big.tuwien.ac.at/
14. …enables a temporal analysis
Now, we can compute execution states of
interest (e.g. for provenance) and KPIs:
Q1 — Find all items which have been
processed by machine m.
Q2 — Find the components which
had an item assigned at a particular
point in time.
Q3 —Find the components which
had an item assigned within a
particular time frame.
Q4 — Compute the utilization of
machine e for the whole system
execution lifecycle.
14
15. …that can be expressed with Temporal OCL
15
Component.allInstances()->select(c | not
c.hostsAt(instant).oclIsUndefined())
Q2 - Find the components which had an item
assigned at a particular point in time.
17. Based on Bigtable
• Map-based (i.e. key-value) stores are especially
well-suited to persist models (for direct accesses).
• Data is stored in tables, which are sparse,
distributed, and multi-dimensional sorted maps.
• These maps are indexed by the tuple row key,
column key, and a timestamp.
17
Alternative mappings best suited for other scenarios: NeoEMF: A multi-
database model persistence framework for very large models. Sci. Comput.
Program. 149: 9-14 (2017)
18. Models in Bigtable
• Our proposed data model flattens the typical graph structure
expressed by models into a set of key-value mappings that fit
Bigtable map-based data model
• Our proposed data model uses a single table with three column
families to store models’ information:
– a property column family, that keeps all objects’ data stored together;
– a type column family, that tracks how objects interact with the meta-
level (such as the instance of relationships); and
– a containment column family, that defines the models’ structure in
terms of containment
18
26. On top of Apache HBase
26
TemporalEMF, available as OSS, can be directly plugged into
any EMF-based tool to immediately provide enhanced temporal
support
28. Questions (TemporalEMF vs Saving Historical
Data Explicitly)
• RQ1: Manipulation Cost — Is there a significant
difference of the time required for producing and
manipulating temporal model elements?
• RQ2: Storage Cost — Is there a significant time
difference when saving the temporal models?
• RQ3: Reproduction Cost — Is there a significant
difference of restoring/querying previous versions
of temporal elements?
28
29. RQ1 – Manipulation Cost
29
Initial small overhead.
Irrelevant in most cases
30. RQ2 – Storage Cost
30
Out of
memory
Very low memory
footprint
31. RQ2 – Storage Cost
31
Performance does
not deteriorates
35. Summary
• Domain (meta)models are automatically and
transparently treated as temporal models.
• Allowing temporal queries to retrieve and compare the
model contents at different points in time.
• An extension to the standard EMF APIs allows
modelers to easily express such temporal queries.
• TemporalEMF relies on HBase to provide an scalable
persistence layer to store all past versions.
35
36. Further work
• Definition of temporal patterns that cover most
common types of temporal queries
• Add prediction capabilities based on the analysis of the
temporal data
– E.g. to adapt the tool interface based on the modeling
profile of a user
• Towards a full temporal modeling tool, e.g. adding
default temporal support to any model manipulation
operation
36
Notas do Editor
.e. the data is what drives the models we have to use and not the models the ones that define what data we can have in the system
Big data apps require a continuous improvement cycle that depends on the changes of the data
Models evolve with the data
The same project cannot reappear
We can hire and fire the same employee several times and we need to keep tract of each period
Of course at the implementation level this requires either using a temporal database or the addition of
Timestampt attributes to store all the time-sensitive information
EMF Profiles = UML Profiles for EMF
We see a model of a production plant composed of áreas where ítems are processed by a number of machines, conveyors,
Storage units,…
By defining our transportation line metamodel as temporal, we can “for free” ask several intersting análisis questions
We look for all components that didn’t have an undefined value at that point
We get the timestamp part for free!!!!
Property keeps track of all atributtes and associations. Containment is the pointer back to the container object
Storage cost in memory
TEMF before and after is exactly the same because we are always saving the data in HBased
XMI Before: after running the simulation, how much memory we used
XMI After: same but also taking into account the time to sabe the model (this requires additional computation for storing links)
In TEMF the performance of the simulation is constnat
With XMI since we need to explicitly manage the traces, the number of iterations we can do per time unit decreases.
Q1 Works better while it fits in memory, then it quickly crashes