v for visualization: viatra finally goes graphical thanks to sirius!
TRANSCRIPT
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
Outline
Textual and graphical editor integration• Introduction• Motivation
Background• VIATRA, Xtext, Capella,
Sirius-Xtext integration• Approaches• Lessons learned
Conclusion• Conclusion
Main Contributors From IncQuery Labs
o Zoltán Ujhelyio Ádám Lengyelo István Rátho Ákos Horvátho Ábel Hegedüs
From Thaleso Eric Lepiciero Stéphane Bonneto Matthieu Helleboid o and many others
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
Motivating scenario: ClarityFrench national and Industrial collaborationproject (started in 2014)• Grow the Capella ecosystem• 20+ partners
Extract information from these models!
Copyright: polarsys.org
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
Background: VIATRA queryVIATRA query• Incremental model query engine• Own query language = VQL
o declarativeo 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/
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
Background:Xtext• Textual editor generator framework
o LL(*) parser based on ANTLRo Incremental compiler
EMF serialization• High-level support for
o Validationo Referencingo Context aware operations
• Support for JVM based languageso Xbase
More details on Xtext: https://eclipse.org/xtext/
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/
Xtext-Sirius integrated language editor for VQL
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
synch
Query definition[Xtext]
Query definition [Sirius]
Text EMF GraphEMF
Common Representation
synch
Overview: Current VQL editor support (attempt 3 )
Based on common EMF model from Xtext• Allows reuse of available tooling
o Validationo Translation
• Synchronization is done on EMF instance levelQuery
definition[Xtext]
Query definition[Sirius]
Text Xtext serialization [EMF] Graph
pattern test (ht, hi) { HostInstance(hi); HostType(ht); HostType.instances(ht, hi);}
DEMOSimple query definitions• Basic manipulationVisualization example with Sirius
Visual and textual editors
Lessons learned from our three attempts
Technological differences
Topic Sirius XtextEditing -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
Shared EMF serializationShared tooling• Code generation• ValidationComplex model manipulation operations• Structural updates• SerializabilityGap 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 editingReferences between representation• Grammar AST will become an “API”
Query definition[Xtext]
Query definition[Sirius]
Text Xtext serialization [EMF] Graph
EMF-based view models
Dedicated editors/viewsfor both syntaxesShared tooling• Based on the selected languageComplex synchronization transformation• Unidirectional, incremental transformation
o Can be handled by Viatra (if changes are supported)• Semantic Gap mappingUnidirectional synchronization• Bidirectionality?
o Subject to R&D unambiguity
Query definition[Xtext]
Query definition View
[Sirius]Text EMF GraphEMF
synch
Separated DSLs for design
Dedicated editors for both syntaxesTooling duplication• Validation• Code-generation defined only on common
representationSynchronization• Can be uni~ and also bidirectionalChange management• Requires work
o on both frontendso on both synchronization transformations
Tool integration issues• E.g., Can graphical models refer to textual
representation?
Query definition[Xtext]
Query definition [Sirius]
Text EMF GraphEMF
Common Representation
synch
Conclusions
21
ConclusionsNo silver bulletLanguage co-evolution is required in the long-run
Semantic gap is smallCross-references can be mappedHeavy tool reusability requiredLanguages often change
One dedicated editor and multiple viewsIncrementality is required to some degreeLanguages change only sometimes
Bidirectional /Incremental synchronization is requiredEditing in both domains is required• Separated tooling provides
enhanced UX
Languages rarely change
Works well when
22
Final pointsA beta graphical editor will be available inViatra 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?
http://www.incquerylabs.com/[email protected] Tel: +36 70 633 3973Email: [email protected]
@IncQueryLabs
https://www.facebook.com/incquerylabs/https://www.linkedin.com/company/incquery-labs-ltd-