Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

V for visualization: VIATRA finally goes graphical thanks to Sirius!

SiriusCon2016, Paris

  • Login to see the comments

V for visualization: VIATRA finally goes graphical thanks to Sirius!

  1. 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. 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. 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. 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:
  5. 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: Capella end-user graphical queries
  6. 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 :
  7. 7. Background: Viatra Query Language More details on 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. 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:
  9. 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:
  10. 10. Xtext-Sirius integrated language editor for VQL
  11. 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. 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. 13. DEMO Simple query definitions • Basic manipulation Visualization example with Sirius Visual and textual editors
  14. 14. Lessons learned from our three attempts
  15. 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. 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. 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. 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. 19. Conclusions
  20. 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. 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. 22. Tel: +36 70 633 3973 Email: @IncQueryLabs