EMF-IncQuery: Blazing-fast reaction time even for very large diagrams (Sirius integration)
-
Upload
akos-horvath -
Category
Software
-
view
576 -
download
0
Transcript of EMF-IncQuery: Blazing-fast reaction time even for very large diagrams (Sirius integration)
EMF-IncQuery: Blazing-fast reaction time
even for very large diagrams
Ákos Horváth, Ábel Hegedüs, Zoltán Ujhelyi, István RáthIncQuery Labs Ltd.
Gábor Bergmann, Csaba Debreceni, Dániel VarróBudapest University of Technology and Economics
Outline
Query-based view models• Overview• Evaluation
Motivation and backgroundSirius and queries
Sirius integration• Overview• Evaluation
Conclusion• Conclusion
Main Contributorso Ádám Lengyelo Ábel Hegedüso Zoltán Ujhelyio István Rátho Ákos Horváth
Introduction
3
??I don’t need all that information
Can I define a simplified model?
Can I define a viewpoint
to visualize it?
Maintanence• Incrementally• Immediately
Maintenance:• Incrementally• Immediately
Viewpoint:• Different view of
underlying model• Abstraction hides
complexity
4
Motivating scenario: CONCERTOEU-ECSEL project (started in 2013)• General MDD toolchain for safety-critical systems
o Analysis and code generation for component based systemso UML based modelingo Non-modifiable PSM
Simplified Example
FAM_PilotControl : Function
FAM_Navigation : Function
FAM_FMS : Function
FAM_EMS : Function
nav2ems:InformationLink
provider
consumer
subFunctions
provider
consumer
PilotControl
SubS1
Navigation
FMS
SubS2
EMS
tag: func
tag: func
tag: func
tag: func
EMS: Engine Management System FMS: Flight Management SystemInPort/OutPort
nav2fms:InformationLink
SimulinkConcerto Component models
(UML + profiles)
Id
Id Other SubSystem without tagFunction SubSystem with "func" tag)
Port Blocks
id:Function id:InformationLink
View
More details on Matlab Simulink and Eclipse integration: https://github.com/FTSRG/massif
5
Background: SiriusSirius• Custom concrete syntax for visualization
o Tree, table, graph, etc.• Provides viewpoint definition over EMF models• Abstraction can be defined using interpreted
expressionso MTL – Acceleo Model-to-Text languageo OCL- Object Constraint languageo AQL (recommended as of 3.1) – Acceleo Query
Language• Supports several viewpoints over
the same abstract syntaxMore details on Sirius: https://eclipse.org/sirius/
Background: EMF-IncQueryEMF-IncQuery• Incremental model query engine• Own query language = IQPL
o declarativeo graph pattern based
6
Query Model
Updated results Result deltas
Evaluator
Model change
Efficient change propagation
Always up-to-date results without model re-traversal
Track changes of your model in terms of queries
More details on EMF-IncQuery integration: http://www.eclipse.org/incquery/
IncQuery as a query language in Sirius
8
VSM Render
Overview: IQPL as query language for Sirius
Sirius provides API to provide custom expression interpreter• org.eclipse.sirius.common.expressionInterpreter• org.eclipse.sirius.common.proposalProvider
4. UI updates
EMF Model
B. ChangeNotificationsA. Model
Modification
Live QueriesLive
Queries
2. Get queries
3. Query results
1. UI refresh
DEMOSame model query written in • MTL• AQL• IncQuery
Using IncQuery in Sirius
9
Master:AppTypeSM1: State Machine
S1: State
S2: State
sendSignal()
:HostInstance
:Master
Slave:AppTypeSM1: State Machine
SA: State
SB: State
receiveSignal()
:HostInstance
:Slave
communicates
allocatedTo allocatedTo
instanceOf
instanceOf
10
Evaluation: Interpreted expression
MTL AQL EIQ MTL AQL EIQ MTL AQL EIQSmall Medium Large
0
5000
10000
15000
20000
25000
30000
35000First Execution
Recalculation
Model SizeExec
utio
n Ti
me
[Ms]
Models EObjects EReferences EAttributes Diagram nodes Diagram edgesSmall 3550 34222 9471 12 17Medium 6994 124708 22129 17 13Large 63580 1233581 457230 167 6154
Profiler was used to isolate query execution timeAQL • provides good
performance• Low memory
profileIncQuery• Recalculations
< 50 ms• Requires up to
2x memoryo Large ~1.2 Gb
Query-Based Resources
EVM
VIEW MODELS AND SIRIUS
DerivedModel
EMF Model
A. Model Modification
B. ChangeNotifications
Live QueriesLive
Transformation
Live QueriesLive
TransformationDerivedModel
C. Delta updates
C. Delta updates
D. UI refresh
D. UI refreshB. ChangeNotifications
More details on EVM: http://wiki.eclipse.org/EMFIncQuery/DeveloperDocumentation/EventDrivenVM
VSM + Render
More matches can appear at the same time• Ordered execution schema (priority for rules)Internal traceability for created objects• Explicit definitionConfiguration model hides underlying EVM rule definitions• Predefined set of manipulation rules availableIn summary: One way incremental synchronization arbitrary transformation
Execution of motivating example
11
FAM_PilotControl : Function
FAM_Navigation : Function
FAM_FMS : Function
subFunctions
consumer
PilotControl
SubS1
Navigation
FMS
tag: func
tag: func
tag: func
Simulink CCM
subFunctions
Query results Traceability
functionf_1
f_2
f_3
Trace
Trace
Trace
a 2 3appear create add
Query results
functionIdentifierf_1 i_1
f_2 i_2
f_3 i_3
subFunctionf_1 i_1
f_2 i_2
b appear 4 set
Updating derived modelsInitial setup of derivation rules• EClassifiers, EStructuralFeatures
Query result deltas• Delta = (Found, Lost, Updated)
Based on EMF-IncQuery Event-Driven Virtual machineIntegration architecture
14
Source model
Live transformatio
nrules
Query engine
IncQuery- EVM
Derived model
Change notifications
Match set delta
ApplicationModel
manipulationConfiguratio
n Model manipulation
1
23
4
SiriusUI
update5
DEMO
15
Standard Sirius domain• Family representation• Incremental synchronization
o On-the-fly(Concerto EMF-UML2)• Viewpoint for simplified representation
Using IncQuery in Sirius
16
First timeexecution
9+16 81+160 201+400 401+800 601+1200 801+1600 1201+24000
5000
10000
15000
20000
25000
30000
35000
Transformation
Size of target (view) model (elements + references)Runt
ime
[Ms]
Models EObjects EReferences Diagram nodes Diagram edges9+16 38 89 9 1681+160 371 890 81 160201+400 926 2225 201 400401+800 1851 4450 401 800601+1200 2776 6675 601 1200801+1600 3701 8900 801 16001201+2400 5551 13350 1201 2400 10+
derivation rules
Transformation ~33% of overall runtime
Memory consumption ~3.5x of original model
Evaluation - Concerto
17
Evaluation - ConcertoIncrementalrecalculation
0
200
400
600
800
1000
1200
Deletion Deletion + Sirius
Size of target (view) model (elements + references)
Runt
ime
[ms]
Models EObjects EReferences Diagram nodes Diagram edges9+16 38 89 9 1681+160 371 890 81 160201+400 926 2225 201 400401+800 1851 4450 401 800601+1200 2776 6675 601 1200801+1600 3701 8900 801 16001201+2400 5551 13350 1201 2400 Transformation
re-execution < 50 ms
Refreshing < 1 s
Refreshing is also faster
Conclusions
19
ConclusionsProof-of-concept version is available• IncQuery does well as expected in incremental recalculations• Incremental refreshing is not (yet) available
o Started working on the issues with Obeo • Usage requires deep knowledge of both Sirius and IncQuery• Common base with new EMF-IncQuery Viewers
Experience• Concerto EU-ECSEL project
o Works with Papyrus and EMF-UML2!• Aimed application scenario
o Viewpoint definition directly for EMF models (one-to-one mapping)
o Online synchronization
20
Final pointsThe examples and more details are available form• https://github.com/FTSRG/iq-sirius-integration• Contributors:
o Main: BME-FTSRG, IncQuery Labs Ltd.o Supporting projects: Concerto (EU-Artemis)o (Hopefully) future partner: Obeo
• Presentation will be available on slideshare
Your contributions (feedback, forum posts, ideas, patches) are very welcome!• To what direction should we enhance this approach?