This document discusses three approaches for integrating textual and graphical editing of VIATRA queries: 1) using a shared EMF serialization, 2) using EMF-based view models, and 3) using separated DSLs. The current approach uses a shared EMF model from Xtext for synchronization between the textual and graphical editors. Lessons learned include the need for language co-evolution and bidirectional/incremental synchronization to reduce semantic gaps and enable editing in both domains. A beta graphical editor for VIATRA queries will be available in the next release.

1. V for visualization:
VIATRA finally goes graphical
thanks to Sirius!
(and Clarity)
Ákos Horváth, Ádám Lengyel, István Ráth and Zoltán Ujhelyi,
IncQuery Labs Ltd.
Eric Lepicier and Stéphane Bonnet
Thales

2. Outline
Textual and graphical editor
editor integration
• Introduction
• Motivation
Background
• VIATRA, Xtext, Capella,
Sirius-Xtext integration
• Approaches
• Lessons learned
Conclusion
• Conclusion
Main Contributors
 From IncQuery Labs
o Zoltán Ujhelyi
o Ádám Lengyel
o István Ráth
o Ákos Horváth
o Ábel Hegedüs
 From Thales
o Eric Lepicier
o Stéphane Bonnet
o Matthieu Helleboid
o and many others

3. pattern availableGreaterThanTotalCpu(host : HostInstance) {
HostInstance.availableCpu(host, aCpu);
HostInstance.totalCpu(host, tCpu);
check(aCpu > tCpu);}
pattern sendTransitionAppSignal(transition, app, signal) {
Transition.action(transition, action);
app == eval(SignalUtil.getAppId(action));
signal == eval(SignalUtil.getSignalId(action));}
pattern notAllocatedButRunning(app : ApplicationInstance) {
ApplicationInstance.state(app, AppState::Running);
neg find allocatedApplication(app);}
private pattern allocatedApplication(app:ApplicationInstance)
{ApplicationInstance.allocatedTo(app, _);}
Introduction ??
Huh that looks
complicated
Can I define my
queries graphically?
Wow thanks but it
would be nice if I
could work on both
representations

4. Motivating scenario: Clarity
French national and Industrial collaboration
project (started in 2014)
• Grow the Capella ecosystem
• 20+ partners
Extract information
from these models!
Copyright: polarsys.org

5. Motivating scenario:
Heavy use of EMF-IncQuery ( VIATRA
queries)
• Part of core services in Capella
• User defined queries  custom high-level graphical editor
Copyright: polarsys.org
Capella end-user
graphical queries

6. Background: VIATRA query
VIATRA query
• Incremental model query engine
• Own query language = VQL
o declarative
o graph pattern based
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 VIATRA : http://www.eclipse.org/viatra/

7. Background: Viatra Query Language
More details on VIATRA : http://www.eclipse.org/viatra/
package org.eclipse.viatra.examples.cps.generator.queries
import “http://org.eclipse.viatra/model/cps"
pattern States(t : HostType) {
HostType(t);
}
pattern test (ht, hi) {
HostInstance(hi);
HostType(ht);
HostType.instances(ht, hi);
}
Query definition Query parameter
Type constraint (syntactic sugar)
Type constraint
Package declaration
Import statement
Reference constraint

8. Background:
Xtext
• Textual editor generator framework
o LL(*) parser based on ANTLR
o Incremental compiler
 EMF serialization
• High-level support for
o Validation
o Referencing
o Context aware operations
• Support for JVM based languages
o Xbase
More details on Xtext: https://eclipse.org/xtext/

9. Background:
Sirius
• Custom concrete syntax for visualization
o Tree, table, graph, etc.
• Provides viewpoint definition over EMF models
• Abstraction can be defined using interpreted
expressions
• Supports several viewpoints over
the same abstract syntax
• Highly scalable and customizable
• EMF based
More details on Sirius: https://eclipse.org/sirius/

10. Xtext-Sirius integrated language editor
for VQL

11. Our three approaches
Shared EMF
serialization
• 2016
(VIATRA)
EMF-based
view models
• 2015
(@SiriusCon) *
Separated
DSLs for
design
• ~2015
(Clarity)
Query
definition
[Xtext]
Query
definition
[Sirius]
Text Xtext serialization [EMF] Graph
(*) More details on the EMF-based view models approach : link
Query
definition
[Xtext]
Query
definition View
[Sirius]
Text EMF GraphEMF
sync
h
Query
definition
[Xtext]
Query
definition
[Sirius]
Text EMF GraphEMF
Common Representation
sync
h

12. Overview: Current VQL editor support (attempt 3
 )
Based on common EMF model from Xtext
• Allows reuse of available tooling
o Validation
o Translation
• Synchronization is done on EMF instance level
Query
definition
[Xtext]
Query
definition
[Sirius]
Text Xtext serialization [EMF] Graph
pattern test (ht, hi) {
HostInstance(hi);
HostType(ht);
HostType.instances(ht, hi);}

13. DEMO
Simple query definitions
• Basic manipulation
Visualization example with Sirius
Visual and textual editors

14. Lessons learned from our three attempts

15. Technological differences
Topic Sirius Xtext
Editing -Direct model
manipulation
-Add/Remove characters
Cross-references -Model URI
-Direct Java references in
AST
-Qualified and short
names
Validation support -Manual
-Live  requires change
tracking (use VIATRA)
-Live
-Manual (rarely)
Imperative control
structures
- Problematic -Well supported
(e.g., Xbase support)
Challenges - Embedded Xtext editors - Stable URIs
- Serialization

16. Shared EMF serialization
Shared tooling
• Code generation
• Validation
Complex model manipulation operations
• Structural updates
• Serializability
Gap between textual and graphical
representation
• Unstable UI fragments (e.g., URI changes with add/del)
• Xtext specific artefacts (e.g., import declarations)
Implementation differences
• Textual editing + reparsing vs. Transactional editing
References between representation
• Grammar AST will become an “API”
Query
definition
[Xtext]
Query
definition
[Sirius]
Text Xtext serialization [EMF] Graph

17. EMF-based view models
Dedicated
editors/views
for both syntaxes
Shared tooling
• Based on the selected language
Complex synchronization transformation
• Unidirectional, incremental transformation
o Can be handled by Viatra (if changes are supported)
• Semantic Gap mapping
Unidirectional synchronization
• Bidirectionality?
o Subject to R&D  unambiguity
Query
definition
[Xtext]
Query
definition View
[Sirius]
Text EMF GraphEMF
sync
h

18. Separated DSLs for design
Dedicated editors
for both syntaxes
Tooling duplication
• Validation
• Code-generation  defined only on common
representation
Synchronization
• Can be uni~ and also bidirectional
Change management
• Requires work
o on both frontends
o on both synchronization transformations
Tool integration issues
• E.g., Can graphical models refer to textual
Query
definition
[Xtext]
Query
definition
[Sirius]
Text EMF GraphEMF
Common Representation
sync
h

19. Conclusions

20. Conclusions
No silver bullet
Language co-evolution is required in the long-run
21
Semantic gap is small
Cross-references can
be mapped
Heavy tool reusability
required
Languages often
change
One dedicated editor
and multiple views
Incrementality is
required to some degree
Languages change only
sometimes
Bidirectional /
Incremental synchronization
is required
Editing in both domains is
required
• Separated tooling provides
enhanced UX
Languages rarely change
Works well
when

21. Final points
A beta graphical editor will be available in
Viatra 1.5
• Contributors:
o IncQuery Labs, Thales
Clarity project provided dedicated graphical
tooling for (VIATRA) query specification
• Within eClarity we plan to further this tooling 
Your contributions (feedback, forum posts,
ideas, patches) are very welcome!
• To what direction should we enhance this approach?
22

22. http://www.incquerylabs.com/
info@incquerylabs.com
Tel: +36 70 633 3973
Email: akos.horvath@incquerylabs.com
@IncQueryLabs
https://www.facebook.com/incquerylabs/
https://www.linkedin.com/company/incquery-labs-ltd-