More Related Content

Slideshows for you(20)


Similar to V for visualization: VIATRA finally goes graphical thanks to Sirius!(20)


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

  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:
  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. 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. 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. 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. 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. 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. Tel: +36 70 633 3973 Email: @IncQueryLabs

Editor's Notes

  1. Viewpoints Different view of the underlying model Abstraction  Hides complexity
  2. Incremental query engine for EMF Declarative language Incremental, live queries Highly scalable Advanced support for On-the-fly validation Custom views Traceability Derived features
  3. * Saving XText TypeResource instances * * * Transaction issue with Resource loading and reloading (in case a reload there is only a read-only transaction) * * Possible patch available in
  4. Xtext Stable URI: Default XMI like relative URI fragments (based on order like patterns/@.0 etc) Customize Xtext FragementProvider provider might be required (based on reference naming) Serilization: Custom serializer might be required to handle graphical editing Sirius: embedded Embedded Xtext editors * Virtual EMF resource * Xtext loads virtual resource -> text representation is displayed , editing as normal * On save changes are needed to be written back to the original model
  5. References between representation * syntax updates have to consider both syntaxes (not future proof) JVM inferred model elements support is problematic for Sirius
  6. Tool integration issues Graphical refer to textual representation (is this required) Qualified/Unqualified names vs URIs Custom code to Sirius based editors is required