| <div class="post"> | |
| <h2 class="title">VIATRA 2.3.0 is released</h2> | |
| <div class="date">Dec 18, 2019</div> | |
| <div class="body"><p>The <a target="_blank" href="http://eclipse.org/viatra">VIATRA project</a> is happy to report that release 2.3.1 is now available with a few performance enhancements.</p><p>All downloads are available now from the <a target="_blank" href="/viatra/downloads.php">downloads area</a> or the <a target="_blank" href="http://marketplace.eclipse.org/content/viatra">Marketplace</a>.</p></div> | |
| </div> | |
| <div class="post"> | |
| <h2 class="title">VIATRA 2.2.1 is released</h2> | |
| <div class="date">Sep 4, 2019</div> | |
| <div class="body"><p>The <a target="_blank" href="http://eclipse.org/viatra">VIATRA project</a> is happy to report that release 2.2.1 is now available with a few performance enhancements.</p><p>All downloads are available now from the <a target="_blank" href="/viatra/downloads.php">downloads area</a> or the <a target="_blank" href="http://marketplace.eclipse.org/content/viatra">Marketplace</a>.</p></div> | |
| </div> | |
| <div class="post"> | |
| <h2 class="title">VIATRA 2.2.0 is released</h2> | |
| <div class="date">Jun 19, 2019</div> | |
| <div class="body"><p>The <a target="_blank" href="http://eclipse.org/viatra">VIATRA project</a> is happy to report that release 2.2.0 is now available with SimRel 2019-06, including a few new features, bugfixes and performance enhancement.</p><p>All downloads are available now from the <a target="_blank" href="/viatra/downloads.php">downloads area</a> or the <a target="_blank" href="http://marketplace.eclipse.org/content/viatra">Marketplace</a>.</p></div> | |
| </div> | |
| <div class="post"> | |
| <h2 class="title">VIATRA 2.1.0 is released</h2> | |
| <div class="date">Dec 19, 2018</div> | |
| <div class="body"><p>The <a target="_blank" href="http://eclipse.org/viatra">VIATRA project</a> is happy to report that release 2.1.0 is now available together with SimRel 2018-12, including new features, bugfixes and performance enhancements as well.</p><p>All downloads are available now from the <a target="_blank" href="/viatra/downloads.php">downloads area</a> or the <a target="_blank" href="http://marketplace.eclipse.org/content/viatra">marketplace</a>.</p></div> | |
| </div> | |
| <div class="post"> | |
| <h2 class="title">VIATRA 2.0.1 is released</h2> | |
| <div class="date">July 13, 2018</div> | |
| <div class="body"><p>The <a target="_blank" href="http://eclipse.org/viatra">VIATRA project</a> is happy to report that release 2.0.1 is now available with a few fixed bugs and performance enhancements.</p><p>All downloads are available now from the <a target="_blank" href="/viatra/downloads.php">downloads area</a> or the <a target="_blank" href="http://marketplace.eclipse.org/content/viatra">marketplace</a>.</p><p>Feel free to reach out on the Eclipse Forums of VIATRA if you have questions, we will not leave any unanswered. You can also request <a target="_blank" href="http://incquerylabs.com/">industrial support</a> for more advanced issues.</p></div> | |
| </div> | |
| <div class="post"> | |
| <h2 class="title">VIATRA 2.0 is released</h2> | |
| <div class="date">June 27, 2018</div> | |
| <div class="body"><p>The <a target="_blank" href="http://eclipse.org/viatra">VIATRA project</a> is happy to report that release 2.0.0 is now available together with <a href="https://www.eclipse.org/photon/">Eclipse Photon</a>.</p><p>This release mostly focused on Java compatibility, including Stream support for the pattern matcher API and performance enhancements. Additionally, the query language was enhanced with a few features to reduce the amount of patterns necessary for certain constructs.</ul><p>As part of the <a href="https://www.youtube.com/watch?v=gDAb_iyO5Fc&list=PLy7t4z5SYNaQjVGIS9YUfZzFQpNFYpCny">Photon Webinar series in vECM</a> we had a presentation about the new features of VIATRA 2.0: | |
| <div style="width: 560px; height: 315px; overflow: hidden; margin: 0 auto;"> | |
| <div class="videowrapper youtube" id="SkCrPbtxrsg" style="width: 560px; height: 315px; text-align: center; position:relative;"> | |
| <a href="https://www.youtube.com/watch?v=SkCrPbtxrsg"><img src="/viatra/images/viatra_photon_webinar.png" /><div class="fa fa-5x fa-play" style="position:absolute;"></div></a> | |
| </div> | |
| <script src="js/yt-embed.min.js" ></script> | |
| </div> | |
| </p><p>For a more complete list of changes, see the dedicated <a target="_blank" href="/viatra/documentation/releases.html#viatra-20">New and noteworthy</a> page, or have a look at the list of <a target="_blank" href="https://projects.eclipse.org/projects/modeling.viatra/releases/2.0.0/bugs">fixed issues</a>.</p><p>All downloads are available now from the <a target="_blank" href="/viatra/downloads.php">downloads area</a> or the <a target="_blank" href="http://marketplace.eclipse.org/content/viatra">marketplace</a>.</p><p>Feel free to reach out on the Eclipse Forums of VIATRA if you have questions, we will not leave any unanswered. You can also request <a target="_blank" href="http://incquerylabs.com/">industrial support</a> for more advanced issues.</p></div> | |
| </div> | |
| <div class="post"> | |
| <h2 class="title">Talk at EclipseCon France 2018</h2> | |
| <div class="date">June 14, 2018</div> | |
| <div class="body"><p>At EclipseCon France 2018 we held a presentation about using VIATRA and other EMF-specific technologies inside MagicDraw, one of the leading systems engineering tools based on UML/SysML titled <a href="https://www.eclipsecon.org/france2018/session/lessons-learned-building-eclipse-based-add-ons-commercial-modeling-tools">Lessons learned from building Eclipse-based addons for commercial modeling tools</a>. For more details, look at the slides linked at the talk page, or look at the recorded session at Youtube: https://www.youtube.com/watch?v=tZ7zaGnu4w8.</p></div> | |
| </div> | |
| <div class="post"> | |
| <h2 class="title">VIATRA 1.7 is released</h2> | |
| <div class="date">December 13, 2017</div> | |
| <div class="body"><p>The <a target="_blank" href="http://eclipse.org/viatra">VIATRA project</a> is happy to report that release 1.7.0 is now available with multiple new features and fixed bugs.</p><p>This release mostly focused on bugfixes and performance enhancements, resulting in decreased memory consumption.</ul><p>For a more complete list of changes, see the dedicated <a target="_blank" href="/viatra/documentation/releases.html#viatra-17">New and noteworthy</a> page, or have a look at the list of <a target="_blank" href="https://projects.eclipse.org/projects/modeling.viatra/releases/1.7.0/bugs">fixed issues</a>.</p><p>All downloads are available now from the <a target="_blank" href="/viatra/downloads.php">downloads area</a> or the <a target="_blank" href="http://marketplace.eclipse.org/content/viatra">marketplace</a>.</p><p>Feel free to reach out on the Eclipse Forums of VIATRA if you have questions, we will not leave any unanswered. You can also request <a target="_blank" href="http://incquerylabs.com/">industrial support</a> for more advanced issues.</p></div> | |
| </div> | |
| <div class="post"> | |
| <h2 class="title">VIATRA 1.6 is out with Eclipse Oxygen</h2> | |
| <div class="date">June 30, 2017</div> | |
| <div class="body"><p>The <a target="_blank" href="http://eclipse.org/viatra">VIATRA project</a> is happy to report that release 1.6.0, included in the <a href="https://www.eclipse.org/oxygen/">Eclipse Oxygen Release Train</a>, is now available with multiple new features and fixed bugs.</p><p>The most notable highlights of this VIATRA release include:</p><ul><li><strong>Query runtime enhancements</strong> for special cases, like dangling edges and recursive patterns result in less surprises for users of the query engine.</li><li><strong>The Getting started tutorial</strong> was updated and extended from its previos version, and now is available both from <a href="https://www.eclipse.org/viatra/documentation/tutorial.php">the project website</a> and <a href="http://help.eclipse.org/oxygen/topic/org.eclipse.viatra.documentation.help/html/tutorial/intro.html?cp=102_1">the Eclipse Help</a> as well. The tutorial features both query and transformation development features.</li><li><strong>The Query Test facilities</strong> of VIATRA that were originally used for internal tests are now extended to use for the testing of queries as well: it is possible to evaluate the results of model queries, and calculate coverage report for them.</li></ul><p>For a more complete list of changes, see the dedicated <a target="_blank" href="https://wiki.eclipse.org/VIATRA/Releases/NewAndNoteworthy1.6">New and noteworthy</a> page, or have a look at the list of <a target="_blank" href="https://projects.eclipse.org/projects/modeling.viatra/releases/1.6.0/bugs">fixed issues</a>.</p><p>All downloads are available now from the <a target="_blank" href="https://www.eclipse.org/viatra/downloads.php">downloads area</a> or the <a target="_blank" href="http://marketplace.eclipse.org/content/viatra">marketplace</a> and the main Oxygen update site as well.</p><p>Feel free to reach out on the Eclipse Forums of VIATRA or the developer mailing list if you have questions, we will not leave any unanswered. You can also request <a target="_blank" href="http://incquerylabs.com/">industrial support</a> for more advanced issues.</p></div> | |
| <!-- <div class="author">Zoltán Ujhelyi</div></div> --> | |
| </div> | |
| <div class="post"> | |
| <h2 class="title">VIATRA 1.5 released</h2> | |
| <div class="date">December 22, 2016</div> | |
| <div class="body"><p>The <a target="_blank" href="http://eclipse.org/viatra">VIATRA project</a> is happy to report that release 1.5.0 is now available with multiple new features and fixed bugs.</p><p>The most notable highlights of this VIATRA release include:</p><ul><li><a target="_blank" href="https://wiki.eclipse.org/VIATRA/Releases/NewAndNoteworthy1.5#Remote_debugging_support_added_to_the_VIATRA_model_transformation_debugger"><strong>Model transformation debugger</strong></a>: This version greatly improved the model transformation debugger of VIATRA: now it is possible to debug transformations from other JVM instances.</li><li><a target="_blank" href="https://wiki.eclipse.org/VIATRA/Releases/NewAndNoteworthy1.5#Performance_improvements"><strong>Performance enhancements</strong></a>: Version 1.5 focused on query evaluation performance: various fixes aimed at reducing the memory requirements for Rete networks and improve the planning and execution time for the local search-based pattern matcher. In a complex proprietrary code base we measured a memory reduction of about 15-30%.</li><li><a target="_blank" href="https://wiki.eclipse.org/VIATRA/Releases/NewAndNoteworthy1.5#Support_for_more_number_literals_in_query_language"><strong>Query Language Updates</strong></a>: In version 1.5 the query language was extended with support for various number literals, e.g. long or float values.</li></ul><p>For a more complete list of changes, see the dedicated <a target="_blank" href="https://wiki.eclipse.org/VIATRA/Releases/NewAndNoteworthy1.5">New and noteworthy</a> page, or have a look at the list of <a target="_blank" href="https://projects.eclipse.org/projects/modeling.viatra/releases/1.5.0/bugs">fixed issues</a>.</p><p>All downloads are available now from the <a target="_blank" href="https://www.eclipse.org/viatra/downloads.php">downloads area</a> or the <a target="_blank" href="http://marketplace.eclipse.org/content/viatra">marketplace</a>.</p><p>Feel free to reach out on the Eclipse Forums of VIATRA or the developer mailing list if you have questions, we will not leave any unanswered. You can also request <a target="_blank" href="http://incquerylabs.com/">industrial support</a> for more advanced issues.</p></div> | |
| <!-- <div class="author">Zoltán Ujhelyi</div></div> --> | |
| </div> | |
| <div class="post"> | |
| <h2 class="title">VIATRA 1.4.1 released</h2> | |
| <div class="date">November 3, 2016</div> | |
| <div class="body"><p>The <a target="_blank" href="http://eclipse.org/viatra">VIATRA project</a> is happy to report that the service release 1.4.1 is now available, with some <a target="_blank" href="https://projects.eclipse.org/projects/modeling.viatra/releases/1.4.1/bugs">hotfixes</a> for our 1.4.0 version. These fixes handles regressions with regards to tooling and runtime components as well. Furthermore, this release widens the compatibility with Xtext versions, making this version available in Eclipse releases from Mars to Oxygen.</p><p>All downloads are available now from the <a target="_blank" href="https://www.eclipse.org/viatra/downloads.php">downloads area</a> or the <a target="_blank" href="http://marketplace.eclipse.org/content/viatra">marketplace</a>. All existing users are recommended to upgrade.</p><p>Feel free to reach out on the Eclipse Forums of VIATRA or the developer mailing list if you have questions or request <a target="_blank" href="http://incquerylabs.com/">industrial support</a> for more advanced issues.</p></div> | |
| <!-- <div class="author">Zoltán Ujhelyi</div></div> --> | |
| </div> | |
| <div class="post"> | |
| <h2 class="title">VIATRA 1.4 released</h2> | |
| <div class="date">October 1, 2016</div> | |
| <div class="body"><p>The <a target="_blank" href="http://eclipse.org/viatra">VIATRA project</a> is happy to report that release 1.4.0 is now available with multiple new features and fixed bugs.</p><p>The most notable highlights of this VIATRA release include:</p><ul><li><strong><a target="_blank" href="https://wiki.eclipse.org/VIATRA/Releases/NewAndNoteworthy1.4#Local_search_support_during_query_evaluation">Local Search</a>-based model query evaluation</strong>: In order to execute model queries with a smaller memory footprint, an alternative query backend was enabled. For backwards compatibility, this search-based backend is not turned on by default, but has to be requested manually.</li><li><a target="_blank" href="https://wiki.eclipse.org/VIATRA/Releases/NewAndNoteworthy1.4#Query_development_environment_improvements"><strong>Development environment</strong><strong> updates</strong></a>: The update of the query and transformation development environment has continued during this release, and the new views are now the recommended way to use for debugging model queries.</li><li><a target="_blank" href="https://wiki.eclipse.org/VIATRA/Releases/NewAndNoteworthy1.3#Model_transformation_debugger_prototype"><strong>Query Language Updates</strong></a>: In version 1.4 the query language was extended with a set of new features, most notable the support for aggregators, such as <em>sum</em> or <em>min</em>, or the explicit specification of the required query backend.</li></ul><p>For a more complete list of changes, see the dedicated <a target="_blank" href="https://wiki.eclipse.org/VIATRA/Releases/NewAndNoteworthy1.4">New and noteworthy</a> page, or have a look at the list of <a target="_blank" href="https://projects.eclipse.org/projects/modeling.viatra/releases/1.4.0/bugs">fixed issues</a>.</p><p>All downloads are available now from the <a target="_blank" href="https://www.eclipse.org/viatra/downloads.php">downloads area</a> or the <a target="_blank" href="http://marketplace.eclipse.org/content/viatra">marketplace</a>.</p><p>Feel free to reach out on the Eclipse Forums of VIATRA or the developer mailing list if you have questions, we will not leave any unanswered. You can also request <a target="_blank" href="http://incquerylabs.com/">industrial support</a> for more advanced issues.</p></div> | |
| <!-- <div class="author">Zoltán Ujhelyi</div></div> --> | |
| </div> | |
| <div class="post"> | |
| <h2 class="title">An overview on the evolution of VIATRA</h2> | |
| <div class="date">July 18, 2016</div> | |
| <div class="body"><p>An open-access <a target="_blank" href="http://link.springer.com/article/10.1007/s10270-016-0530-4">article</a>, entitled <em>'Road to a reactive and incremental model transformation platform: three generations of the VIATRA framework'</em> has been published in the <a target="_blank" href="http://link.springer.com/journal/10270/15/3">latest issue</a> of <a target="_blank" href="http://link.springer.com/journal/10270">Software and Systems Modeling</a> written by Dániel Varró, Gábor Bergmann, Ábel Hegedüs, Ákos Horváth, István Ráth and Zoltán Ujhelyi, major contributors and co-leads of <a target="_blank" href="https://www.eclipse.org/viatra/">VIATRA</a>.</p><p>The paper summarizes the <a target="_blank" href="https://wiki.eclipse.org/VIATRA/History">history </a>of the VIATRA model transformation framework by highlighting key features and illustrating main transformation concepts along an open case study influenced by an industrial project.</p><p>The same issue includes another VIATRA related <a target="_blank" href="http://link.springer.com/article/10.1007/s10270-014-0436-y">paper</a>, entitled <em>'Query-driven soft traceability links for models'</em>, that discusses the application of model queries for robust traceability between fragmented model artifacts.</p></div> | |
| <!-- <div class="author">Ábel Hegedüs</div></div> --> | |
| </div> | |
| <div class="post"> | |
| <h2 class="title">Introducing the Query by Example addon of VIATRA</h2> | |
| <div class="date">July 15, 2016</div> | |
| <div class="body"><p>We present an illustrated introduction to Query By Example (QBE), an exciting new addon of VIATRA. QBE is a tool that helps you write queries simply by selecting model elements in your favorite editor. This automatic feature is intended to help users who are learning the VIATRA Query Language and/or are unfamiliar with the internal structure of the modeling language (metamodel) they are working with.</p><h2>The problem: querying what you do not know</h2><p>Model queries are used for a multitude of reasons. Often, they are developed by modeling tool authors to accomplish built-in functionalities of the language or tool, such as <a href="https://wiki.eclipse.org/VIATRA/Addon/Validation">well-formedness checking</a>, <a href="https://wiki.eclipse.org/VIATRA/Addon/Query_Based_Features">derived features</a> or <a href="https://wiki.eclipse.org/VIATRA/Addon/VIATRA_Viewers">declarative views</a>. But sometimes it is not the developer of the modeling language who specifies the query: e.g. users may define queries themselves to enforce a company-specific design rules, or 3rd parties may provide transformation plugins that map a model into a different representation.</p><p>There is a hidden obstacle here: usually only the language developer has intimate knowledge of the metamodel (the <strong>abstract syntax</strong>), while others are familiar with the language merely through views presented to users (the <strong>concrete syntax</strong>). It is, however, the abstract syntax which is necessary for defining queries in the traditional way.</p><h2>Motivating case study: defining UML design rules</h2><p>Imagine, for instance, that you are an engineer at a company that creates <a target="_blank" href="http://www.uml.org/">UML</a> models using <a target="_blank" href="https://eclipse.org/papyrus/">Papyrus</a>, and you wish to define model queries in order to implement validation for an in-house design rule that all your UML Sequence Diagrams should adhere to: "Engine objects can invoke UI methods only in a non-blocking way".</p><p>The first challenge would be formulating a query that identifies blocking calls between objects on Sequence Diagrams - such a situation would look like this in the Papyrus editor:</p> <img src="http://static1.squarespace.com/static/5614faafe4b03f677dc3822b/56153118e4b022593e35e24b/577f9fd56b8f5b3cacc6a5ae/1467981801246//img.png" alt="what a synchronous call looks like in the concrete syntax"/> what a synchronous call looks like in the concrete syntax <p>Expressing this query in the <strong>.vql</strong> syntax would require you to know the names of the relevant <em>EClasses</em> of the UML metamodel and their features.</p><p>There are some easier hurdles to jump - the editor palette tells you that the vertical lines are not actually called "objects" but rather <em>Lifelines</em>. You might also understand from the default name offered by Papyrus that the contents of the diagram are actually represented by a model object of type <em>Interaction</em>.</p><p>Sometimes, you will find a bit more difficulty in formulating the query. Although the Papyrus editor palette tells you that the "arrow" thingy representing a blocking method invocation is a "Message Sync", but the actual model object is of the class <em>Message</em>, and the synchronous nature is expressed by its <em>messageSort </em>attribute being set to <em>MessageSort::synchCall</em>.</p><p>However, some aspects turn out to be much more difficult to guess. The UML graphical syntax offers no clues that would let you realize that the message does not directly refer to the lifelines, or vica versa. Instead, there are two invisible objects (of type <em>MessageOccurrenceSpecification</em>) at play, that represent the sending or receiving of the message by a lifeline:</p> <img src="http://static1.squarespace.com/static/5614faafe4b03f677dc3822b/56153118e4b022593e35e24b/578512b7b8a79b20f43ac4e2/1468338913694//img.png" alt="A schematic representation of a UML model fragment in abstract syntax"/> A schematic representation of a UML model fragment in abstract syntax <p>Really, this whole thing is a mess. It is quite difficult to understand the abstract structure and come up with the right type names when writing a query, unless you are an expert of the relevant modeling language (the UML standard, in this case).</p><h2>The solution: Query by Example at a glance</h2><p>Wouldn't it be much easier if you could just create an <strong>example </strong>in concrete syntax using a regular model editor, and then instruct the model query framework to <strong>"fetch me stuff that looks like this</strong><strong>"</strong>? You are in luck - this is pretty much what the new <strong>Query By Example (QBE) </strong>tool lets you do! (Available from the <a href="https://www.eclipse.org/viatra/downloads.php">update sites</a> as a VIATRA Addon since v1.3.)</p><p>To get started, the you have to select a few elements in the model, and initiate the QBE process. The QBE tool will perform a model exploration on the given EMF model to find how the selected <strong>anchor </strong>elements relate to each other. The <em>Query by Example</em> view will present the results of the model discovery, where you can follow up on the status of the pattern being generated, and perform some fine-tuning on it (via the <em>Properties </em>view). The pattern code can be exported either to the clipboard, or to a .vql file. After subsequent fine tuning, the Update button can be used to propagate any changes made to the previously saved .vql file.</p><h2>Screencast</h2> <div class="videowrapper"><iframe src="//www.youtube.com/embed/FjOE444DPrE?wmode=opaque&enablejsapi=1" scrolling="no" allowfullscreen="" frameborder="0" height="480" width="640"> </iframe></div> <p>(View video with subtitles/CC turned on.)</p><h2>Case study walk-through: creating your first query by example</h2><p>Select the two lifelines and the message in the Papyrus editor:</p> <img src="http://static1.squarespace.com/static/5614faafe4b03f677dc3822b/56153118e4b022593e35e24b/577fa843d482e970d7437a0c/1467984005707//img.png" alt="Sequence Diagram, with message and its source and target lifelines selected"/> Sequence Diagram, with message and its source and target lifelines selected <p>Now it is time to press the "<em>Start</em>" button on the <em>Query By Example </em>tool:</p> <img src="http://static1.squarespace.com/static/5614faafe4b03f677dc3822b/56153118e4b022593e35e24b/577fa90cc534a505061aec94/1467984141196//img.png" alt="Pressing start on the QBE View"/> Pressing start on the QBE View <p>A quick glance on the contents of the QBE view (which will be explained in greater detail soon) immediately tells you that the tool has discovered that the three selected model elements are connected via three additional objects - an <em>Interaction </em>and two <em>MessageOccurrenceSpecification</em>s<em>: </em></p> <img src="http://static1.squarespace.com/static/5614faafe4b03f677dc3822b/56153118e4b022593e35e24b/577fac412994caa79310e696/1467984964179//img.png" alt="QBE View after selecting an example"/> QBE View after selecting an example <p>The QBE tool has also explored all the attribute values of these six objects, but has no way to know which of them are actually relevant to the query. Most attribute values in the example are incidental, such as the name of the lifeline. So you need to manually go through the list, find the one that has <em>MessageSort::synchCall </em>as the value of the <em>messageSort </em>of the <em>Message </em>(it is quite apparent from the list that none of the other attributes have anything to do with the synchronous nature of the invocation). Then you can simply indicate that it should be added as a condition to the query, by selecting it from the list, and marking it in the <em>Properties</em> view as <em>included</em>.</p><p>Finally, another button on the QBE UI lets you export the pattern to the clipboard, or a .vql file in a Viatra Query project.</p> <img src="http://static1.squarespace.com/static/5614faafe4b03f677dc3822b/56153118e4b022593e35e24b/577fadc22e69cfdc8fbd21c3/1467985374649//img.png" alt="Saving the finished query to the clipboard"/> Saving the finished query to the clipboard <p>If you save the generated query to a .vql file, you will notice that it does not compile at first.</p><p>A compiler error comes from the fact that the QBE tool can not (yet) guess the name of the Java package where you save the file. You can fix this by manually specifying your package: select the "<em>package</em>" entry in the QBE view, and use the <em>Properties</em> view to change the name. While you are at it, you may even change the name of the pattern to something meaningful. If you have previously opted to save the generated query to a file in the workspace, you can now overwrite that file with the new content by a single click on the <em>Update</em> button:</p> <img src="http://static1.squarespace.com/static/5614faafe4b03f677dc3822b/56153118e4b022593e35e24b/57836e6a9de4bb11478986e7/1468231279158//img.png" alt="PAckage and pattern names, and the Update button"/> PAckage and pattern names, and the Update button <p>There is one more likely reason for your query not compile: the query project might not have the UML types on its classpath; you can fix this easily by adding the metamodel bundle <em>org.eclipse.uml2.uml </em>to your dependencies.</p><p>The generated query should look something like this (small variations possible), with pattern variables created for anchors and intermediate objects (the former appearing as pattern parameters); reference constraints created for the paths connecting them; and the additional attribute constraint that was manually requested:</p><pre class="source-code"><span class="cm-variable">package</span> <span class="cm-variable">org</span>.<span class="cm-property">example</span>.<span class="cm-property">uml</span>.<span class="cm-property">designrules</span> <span class="cm-keyword">import</span> <span class="cm-string">"http://www.eclipse.org/uml2/5.0.0/UML"</span> <span class="cm-variable">pattern</span> <span class="cm-variable">blockingCall</span>( <span class="cm-variable">lifeline0</span> : <span class="cm-variable">Lifeline</span>, <span class="cm-variable">lifeline1</span> : <span class="cm-variable">Lifeline</span>, <span class="cm-variable">message0</span> : <span class="cm-variable">Message</span> ) { <span class="cm-variable">MessageOccurrenceSpecification</span>(<span class="cm-variable">messageoccurrencespecification0</span>); <span class="cm-variable">Interaction</span>(<span class="cm-variable">interaction0</span>); <span class="cm-variable">MessageOccurrenceSpecification</span>(<span class="cm-variable">messageoccurrencespecification1</span>); <span class="cm-variable">Lifeline</span>.<span class="cm-property">coveredBy</span>(<span class="cm-variable">lifeline0</span>, <span class="cm-variable">messageoccurrencespecification0</span>); <span class="cm-variable">Lifeline</span>.<span class="cm-property">coveredBy</span>(<span class="cm-variable">lifeline1</span>, <span class="cm-variable">messageoccurrencespecification1</span>); <span class="cm-variable">Interaction</span>.<span class="cm-property">lifeline</span>(<span class="cm-variable">interaction0</span>, <span class="cm-variable">lifeline1</span>); <span class="cm-variable">Lifeline</span>.<span class="cm-property">interaction</span>(<span class="cm-variable">lifeline0</span>, <span class="cm-variable">interaction0</span>); <span class="cm-variable">Message</span>.<span class="cm-property">sendEvent</span>(<span class="cm-variable">message0</span>, <span class="cm-variable">messageoccurrencespecification0</span>); <span class="cm-variable">MessageOccurrenceSpecification</span>.<span class="cm-property">message</span>(<span class="cm-variable">messageoccurrencespecification1</span>, <span class="cm-variable">message0</span>); <span class="cm-variable">Interaction</span>.<span class="cm-property">message</span>(<span class="cm-variable">interaction0</span>, <span class="cm-variable">message0</span>); <span class="cm-variable">Message</span>.<span class="cm-property">receiveEvent</span>(<span class="cm-variable">message0</span>, <span class="cm-variable">messageoccurrencespecification1</span>); <span class="cm-variable">MessageOccurrenceSpecification</span>.<span class="cm-property">message</span>(<span class="cm-variable">messageoccurrencespecification0</span>, <span class="cm-variable">message0</span>); <span class="cm-variable">Message</span>.<span class="cm-property">messageSort</span>(<span class="cm-variable">message0</span>, <span class="cm-variable">MessageSort</span>::<span class="cm-variable">synchCall</span>); } </pre><p>You can now load the query into Query Explorer (or the new <a href="https://wiki.eclipse.org/VIATRA/Releases/NewAndNoteworthy1.3#Query_development_environment_update">Query Results</a> view) to verify that it does the right thing - i.e. it matches exactly those elements that you want it to match. If it does not, you can use the QBE UI to make adjustments, and fine-tune the query (e.g. adding or removing additional constraints, see below) to meet your goals.</p><h2>How it works under the hood</h2><p>When you select some elements in an editor or viewer, and press the "Start" button of QBE, the tool needs to recognize the selection as a set of <em>EObject</em>s. VIATRA ships with integration components for several popular editor frameworks (in particular, it works out of the box with Papyrus, which is <a target="_blank" href="https://www.eclipse.org/modeling/gmp/">GMF</a>-based), but you might need to contribute a <a href="https://wiki.eclipse.org/VIATRA/Query/DeveloperDocumentation/Model_connectors">model connector</a> plug-in in order to be able to use QBE with a custom editor.</p><p>The model discovery will start separately from each selected <em>EObject </em>(anchor element), and will traverse EMF reference links up to a given exploration depth limit, in order to collect all paths (not longer than the given depth) connecting two anchors.</p><p>Initially, the tool automatically selects the smallest exploration depth that makes all anchors connected by the paths discovered. You can use the <em>Exploration depth</em> slider in the QBE view to manually increase this depth limit, so that the tool notices additional, less direct connections between the selected anchors. Changing the exploration depth will re-trigger model discovery, so that the tool can gather new paths.</p><p>After model discovery, a first attempt at a pattern will be formed by all paths that were found to connect the anchors. Pattern variables will consist of anchor points (given by the user as part of the selection) as well as the additional objects discovered as intermediate points along the paths. By default, only variables corresponding to anchors will be used as pattern parameters, while the rest will be local variables. References traversed along paths will contribute edge constraints to the pattern body. </p><h2>Fine tuning</h2><p>Sometimes, the QBE tool will not immediately stumble upon the query that you are interested in. You can identify problems with the proposed pattern by directly inspecting the generated query code, or by examining query results on a test model. In these cases, there are still ways you can fine-tune the pattern through the QBE (and <em>Properties</em>) view, to make sure the generated query is useful.</p><p>For instance, recall how we originally designated the two <em>Lifeline</em>s and the <em>Message </em>as part of the example. Had you selected the two <em>Lifeline</em>s only, QBE would have found them connected by a path of length 2 - as they are both lifelines in the same <em>Interaction</em>. The fact that they exchange a <em>Message </em>turns out to be a less direct relationship between the two anchors. In order to arrive at the correct query, you have to manually increase the exploration depth to 4, thereby forcing QBE to search for connections between anchors in a wider context.</p><p>Depending on other particularities of the model you use as example, this wider context may have included connections between the Lifelines that are incidental in the example model, and not essential parts of the query. In this case, it is still the responsibility of the query developer to determine which details are relevant; the QBE view allows you to mark connecting paths as well as intermediate objects as excluded from the result. In the previous case study, having a common <em>Interaction </em>was not actually necessary as part of the query - but it is not important to remove it now, as it will not influence the results.</p><p>Additional fine-tuning options include:</p><ul><li>Promoting intermediate objects found during the discovery to act as pattern parameters (along with the anchors).</li><li>Renaming pattern variables.</li><li>Adding attribute constraints based on the attribute values of the discovered objects (as demonstrated before).</li><li>Similarly, adding negative application conditions. By pressing the 'Find negative constraints' button, the tool will search for references between pairs of variables (anchors or intermediate objects) that are permitted in the metamodel, but not present in the example instance model. The absence of such references will be offered as additional, opt-in 'neg find' constraints that can be individually selected to be included in the query.</li></ul><h2>The rest of the case study and conclusion</h2><p>You might have noticed that the above case study is far from complete. We have only managed to identify the relationship between the sender and receiver <em>Lifeline</em>s of a blocking call; we still need to</p><ol><li>express using QBE that a given <em>Lifeline</em> represents an instance of a certain <em>Class</em></li><li>express using QBE that a<em> </em>certain <em>Class</em> resides in a <em>Package </em>with the name "<em>Engine</em>" or "<em>GUI</em>"</li><li>write a final query that uses pattern composition to combine the previously created QBE queries in order to match a violation of the constraint in question (i.e. "an Engine object invoking a method on a UI class in a blocking way").</li></ol><p>Here is what the Class diagram looks like:</p> <img src="http://static1.squarespace.com/static/5614faafe4b03f677dc3822b/56153118e4b022593e35e24b/5783b699cd0f681aa0382929/1468249755710//img.png" alt="Snippet of Class diagram in the concrete syntax"/> Snippet of Class diagram in the concrete syntax <p>For the first task, one only needs to select a <em>Lifeline </em>and its associated <em>Class</em>. Whoops - the Papyrus UI becomes an obstacle here, as there seems to be no way to simultaneously display these two elements. Fortunately, we can just select one of the two elements as a single anchor, switch over the view to the other element, and then tell the QBE tool to <strong>expand the previous selection</strong> with the new element by selecting the "<em>Expand</em>" alternative action available from the little drop-down arrow at the "<em>Start</em>" button.</p><p>The second task requires familiar steps only: selecting a <em>Class </em>and its <em>Package </em>as the two anchors, and then adding the name of the UML package as an attribute constraint. Note that in a more complex real-word example, the query would probably include a more complex condition (such as a regular expression) on the name of the package. As of now, QBE can only generate constraints for exact attribute value filtering; if you need anything more advanced than that, then you will have to consider the query generated by QBE merely as a starting point that you have to modify manually.</p><p>The third task is best solved by simply manually writing a query that composes the previously obtained patterns, and not by applying QBE, so it is left as an exercise to the reader :) The main purpose of QBE is to help the user discover connections in a model with an unfamiliar abstract syntax; it will not replace regular query engineering in the generic case.</p><p>To put it simply, you should think of Query By Example as a <strong>tool for abstracting away the ugly, unknown details of a modeling language </strong>before<strong> </strong>developing more complex queries for that language as usual.</p></div> | |
| <!-- <div class="author">Gábor Bergmann</div></div> --> | |
| </div> | |
| <div class="post"> | |
| <h2 class="title">VIATRA wins the offline contest at TTC 2016</h2> | |
| <div class="date">July 11, 2016</div> | |
| <div class="body"><p>This year the <a href="http://www.transformation-tool-contest.eu/">9th Transformation Tool Contest</a> has been organized in Vienna, at the <a href="http://staf2016.conf.tuwien.ac.at/">STAF 2016</a> conference, where each submission must solve a complex task related to model transformation.</p><p>This year's task was a simplified version of the <a target="_blank" href="https://github.com/martin-fleck/cra-ttc2016">Class Responsibility Assignment problem</a>, where methods and attributes have to be assigned to classes in a way that the assignment is optimal with respect to certain software metrics. Our team has solved this problem using VIATRA's rule-based design space exploration framework (<a href="https://wiki.eclipse.org/VIATRA/DSE">VIATRA-DSE</a>), and our solution <a href="http://www.transformation-tool-contest.eu/solutions_cra.html">was awarded the first prize</a> from the nine submitted solutions. The solution was authored by Gábor Szárnyas and András Szabolcs Nagy. The source is <a href="https://github.com/FTSRG/ttc16-cra-viatra-dse">available on Github</a>.</p><p>The corresponding research was supported by the MTA-BME Lendület 2015 Research Group on Cyber Physical Systems (<a target="_blank" href="https://inf.mit.bme.hu/en/news/2016/07/viatra-wins-offline-contest-ttc-2016">original article</a>).</p></div> | |
| <!-- <div class="author">IncqueryLabs</div></div> --> | |
| </div> | |
| <div class="post"> | |
| <h2 class="title">VIATRA 1.3 Released</h2> | |
| <div class="date">July 7, 2016</div> | |
| <div class="body"><p>The <a target="_blank" href="http://eclipse.org/viatra">VIATRA project</a> is happy to report that release 1.3.0 is now available with multiple new features and fixed bugs.</p><p>The most important highlights of this VIATRA release include (<a target="_blank" href="https://wiki.eclipse.org/VIATRA/Releases/NewAndNoteworthy1.3">details</a>):</p><ul><li>Compatibility with <strong>Eclipse Neon</strong> and <strong>Xtext 2.10</strong></li><li><a target="_blank" href="https://wiki.eclipse.org/VIATRA/Releases/NewAndNoteworthy1.3#Query-by-Example:_Create_queries_based_on_selected_model_elements"><strong>Query by Example</strong></a>: A component to derive queries based on selected model elements. This feature should help to understand the basics of the VIATRA pattern language and/or the structure of the metamodels you work with.</li><li><strong>Updated query and transformation development environment</strong>: The query development environment was updated to accommodate the various features developed over the years and provides a set of views to help query and transformation development.</li><li><a target="_blank" href="https://wiki.eclipse.org/VIATRA/Releases/NewAndNoteworthy1.3#Model_transformation_debugger_prototype"><strong>Incremental Transformation Debugger</strong></a>: You can now monitor the execution of a VIATRA transformations using our new debugger.</li><li>lots of various bug fixes (<a target="_blank" href="https://projects.eclipse.org/projects/modeling.viatra/releases/1.3.0/bugs">details</a>).</li></ul><p>The following video compares the new user interface with the previous version:</p> <div class="videowrapper"><iframe src="//www.youtube.com/embed/4aKDRSiCXXQ?wmode=opaque&enablejsapi=1" height="480" width="854" scrolling="no" frameborder="0" allowfullscreen=""> </iframe></div> <p>All downloads are available now from the <a target="_blank" href="https://www.eclipse.org/viatra/downloads.php">downloads area</a> or the <a target="_blank" href="http://marketplace.eclipse.org/content/viatra">marketplace</a>.</p><p>Feel free to reach out on the Eclipse Forums of VIATRA or the developer mailing list if you have questions, we will not leave any unanswered. You can also request <a target="_blank" href="http://incquerylabs.com/">industrial support</a> for more advanced issues.</p></div> | |
| <!-- <div class="author">Ábel Hegedüs</div></div> --> | |
| </div> | |
| <div class="post"> | |
| <h2 class="title">VIATRA 1.2.1 Released</h2> | |
| <div class="date">June 3, 2016</div> | |
| <div class="body"><p>The <a target="_blank" href="http://eclipse.org/viatra">VIATRA project</a> is happy to report that the service release 1.2.1 is now available, with some <a target="_blank" href="https://projects.eclipse.org/projects/modeling.viatra/releases/1.2.1/bugs">hotfixes</a> for our 1.2.0 version. The most important of these are fixing an exception in the local search based query evaluation algorithm and correcting our Maven artifacts. Read our <a target="_blank" href="http://viatra.net/news/2016/5/viatra-1-2-0-released">previous post</a> for the most important highlights of the 1.2.x VIATRA release cycle.</p><p>All downloads are available now from the <a target="_blank" href="https://www.eclipse.org/viatra/downloads.php">downloads area</a> or the <a target="_blank" href="http://marketplace.eclipse.org/content/viatra">marketplace</a>.</p><p>Feel free to reach out on the Eclipse Forums of VIATRA or the developer mailing list if you have questions or request <a target="_blank" href="http://incquerylabs.com/">industrial support</a> for more advanced issues.</p></div> | |
| <!-- <div class="author">IncqueryLabs</div></div> --> | |
| </div> | |
| <div class="post"> | |
| <h2 class="title">Eclipse Neon DemoCamp in Budapest</h2> | |
| <div class="date">June 2, 2016</div> | |
| <div class="body"><img src="http://static1.squarespace.com/static/5614faafe4b03f677dc3822b/56153118e4b022593e35e24b/574ff414c2ea513538c2a857/1464857626267//img.png" alt=""/> <p>IncQuery Labs' mission is to revive and engage the <a target="_blank" href="http://www.incquerylabs.com/news/2016/5/12/the-eclipse-enthusiast-budapest-group-has-been-just-launched">Hungarian Eclipse community </a>therefore, we are launching the <a href="http://www.meetup.com/Eclipse-Enthusiasts-Budapest/">Eclipse Enthusiast Budapest Group</a> and organizing an <a href="https://wiki.eclipse.org/Eclipse_DemoCamp_Neon_2016/Budapest">Eclipse DemoCamp</a>. </p><p>During the summer DemoCamp season, several events are dedicated to the current release of Eclipse Platform and related projects. Thus, Eclipse DemoCamp Budapest will focus on the release of Neon and will present recent developments in various platform components and projects such as VIATRA 1.3 release. </p><p>Join us and learn about Eclipse Neon!</p> <p><strong>Agenda</strong></p><p>6.50 pm -- Registration<br />7.00 pm -- Opening, István Ráth and Ákos Horváth, <a target="_blank" href="http://www.incquerylabs.com/">IncQuery Labs</a>, <br />7.05 pm -- VIATRA 1.3 release, Ábel Hegedüs, IncQuery Labs<br />7.30 pm -- Diagrams in Neon Light - Brief introduction of GEF4, Krisztian Koncz, ClickAndLike<br />7.55 pm -- Break<br />8.05 pm -- Eclipse technologies in the automotive industry, <a target="_blank" href="http://www.thyssenkrupp.hu/en">Thyssenkrupp Presta Hungary Ltd</a>. <br />8.30 pm -- Discussion on the Hungarian Eclipse Community, Networking </p><p>Language of the presentations: HU<br />Date and venue: <strong>06 July, 2016</strong>, Bartók Béla út 10-12. 1111 Budapest (<a href="http://kek.org.hu/helyszin/">KÉK</a>)<br />Registration: <a href="https://wiki.eclipse.org/Eclipse_DemoCamp_Neon_2016/Budapest">Eclipse wiki page</a> (EN) or <a href="http://www.meetup.com/Eclipse-Enthusiasts-Budapest/events/231040401/">meetup.com</a> (HU)</p><p>The DemoCamp is organized by IncQuery Labs and sponsored by Eclipse Foundation and IncQuery Labs. </p></div> | |
| <!-- <div class="author">Katalin Bokor</div></div> --> | |
| </div> | |
| <div class="post"> | |
| <h2 class="title">VIATRA 1.2 Released</h2> | |
| <div class="date">May 11, 2016</div> | |
| <div class="body"><p>The <a target="_blank" href="http://eclipse.org/viatra">VIATRA project</a> is happy to report that release 1.2.0 is now available with several new features and fixed bugs. As you might remember from our <a target="_blank" href="http://viatra.net/news/2016/2/say-goodbye-to-emf-incquery-say-hello-to-viatra-query">announcement</a> earlier this year, VIATRA and EMF-IncQuery have been merged, in order to form (a now graduated) joint VIATRA project that includes both query and transformation-related functionality, in an integrated package. This 1.2.0 release marks the first stable release for the joint project, providing the following libraries:</p><ul style="margin-left:40px"><li><strong>Query</strong>: the pattern language, query editor, code generator and query evaluation runtime (previously known as EMF-IncQuery)</li><li><strong>Transformation</strong>: the event-driven virtual machine, the internal transformation DSL and related development tools</li><li><strong>CEP</strong>: the Complex Event Processing framework</li><li><strong>DSE</strong>: the Design Space Exploration framework</li><li><strong>Integration</strong>: GMF, Graphiti, MWE2, UML, MoDisco and Xcore integration features</li><li><strong>Addon</strong>: frameworks that extend the core functionality, such as data binding support, validation, query-based derived features and the Viewers framework for on-the-fly model visualization</li><li><strong>Model obfuscator</strong>: standalone tool for obfuscating EMF models</li></ul><p>The most important highlights of this VIATRA release include (<a target="_blank" href="http://wiki.eclipse.org/VIATRA/Releases/NewAndNoteworthy1.2">details</a>):</p><ul><li>a <a target="_blank" href="http://wiki.eclipse.org/VIATRA/Releases/MigrationTo1.2">migration guide and an automated migration tool</a> that should make upgrading straightforward, for both EMF-IncQuery and VIATRA users</li><li>a brand new, up-to-date, fully featured and comprehensive <a target="_blank" href="http://static.incquerylabs.com/projects/viatra/viatra-docs/ViatraDocs.html">tutorial</a>! Also, be sure to check out the <a target="_blank" href="https://github.com/IncQueryLabs/incquery-examples-cps">CPS demonstrator</a> that showcases many features of the entire VIATRA platform. </li><li>lots of various bug fixes (<a target="_blank" href="https://projects.eclipse.org/projects/modeling.viatra/releases/1.2.0/bugs">details</a>)</li></ul><p>All downloads are available now from the <a target="_blank" href="https://www.eclipse.org/viatra/downloads.php">downloads area</a> or the <a target="_blank" href="http://marketplace.eclipse.org/content/viatra">marketplace</a>.</p><p>The <a target="_blank" href="http://incquerylabs.com/">industrial support</a> behind the new VIATRA platform, as well as our dedication to answer any and all questions regarding our projects is stronger than ever, so feel free to reach out on the Eclipse Forums of VIATRA or the developer mailing list.</p></div> | |
| <!-- <div class="author">István Ráth</div></div> --> | |
| </div> | |
| <div class="post"> | |
| <h2 class="title">Say goodbye to EMF-IncQuery… say hello to VIATRA Query!</h2> | |
| <div class="date">March 1, 2016</div> | |
| <div class="body"><p>We have some very interesting news to share with you today! Six years after the <a target="_blank" href="http://dx.doi.org/10.1007/978-3-642-16145-2_6">introduction of EMF-IncQuery</a> (originally based on the incremental query evaluation technology of the old VIATRA2 framework), we are now <a target="_blank" href="https://projects.eclipse.org/projects/modeling.viatra/reviews/merge-emf-incquery-and-viatra">merging</a> EMF-IncQuery with the new <a target="_blank" href="https://www.eclipse.org/viatra/">VIATRA</a>. </p><p>There are two key reasons behind this move:</p><ul style="margin-left:40px"><li>The new VIATRA has matured significantly since its inception two years ago, and it is now a state-of-the-art reactive model transformation platform. We felt that it is time to graduate the VIATRA project, with the first release of the merged project planned for April 2016.</li><li>VIATRA and EMF-IncQuery have been developed in close co-operation for the last two years, and there is a big overlap between the committer teams. We are confident that this move will make everyone’s lives easier, and be especially beneficial to our users.</li></ul><p>As part of this process, we are introducing a new component structure for VIATRA that makes it easy to categorize the different parts of the project and understand the relations between them. The main components are the following (origins in brackets):</p><ul style="margin-left:40px"><li><strong>Query</strong>: the pattern language, query editor, code generator and query evaluation runtime (EMF-IncQuery)</li><li><strong>Transformation</strong>: the event-driven virtual machine (EMF-IncQuery), the internal transformation DSL and related development tools (VIATRA)</li><li><strong>CEP</strong>: the Complex Event Processing framework (VIATRA)</li><li><strong>DSE</strong>: the Design Space Exploration framework (VIATRA)</li><li><strong>Integration</strong>: GMF, Graphiti, MWE2, UML, MoDisco and Xcore integration features (EMF-IncQuery)</li><li><strong>Addon</strong>: frameworks that extend the core functionality, such as data binding support, validation, query-based derived features and the Viewers framework for on-the-fly model visualization (EMF-IncQuery)</li><li><strong>Model obfuscator</strong>: standalone tool for obfuscating EMF models (VIATRA)</li></ul><p>This plan has already been approved by the Eclipse review process, and now we are in the middle of the technical migration process. Right now, we have finished the process of moving EMF-IncQuery code and examples to the main VIATRA repository, and have renamed and reorganised the code to reflect the new component structure. </p><p>As part of this process, the version number of all plugins were updated as needed, mature plugins and features are 1.2.0, while incubation functionality is at 0.12.0 to make it clear that these are newer than the released 1.1.0 version of EMF-IncQuery. While we are gearing up for our first release after the merge, we will also update the VIATRA update site to the new component structure.</p><p>To make this big change easier for our users, we have prepared a <a target="_blank" href="https://wiki.eclipse.org/VIATRA/Releases/MigrationTo1.2">migration guide and tool</a> that will be able to update your existing EMF-IncQuery projects and code that uses it to the new naming scheme. This tool will be available as part of the SDK feature.</p><p>Since the EMF-IncQuery project has been archived, the main website and the update site URLs are now redirected. You can find the new update site addresses for previous EMF-IncQuery versions on this dedicated <a target="_blank" href="https://www.eclipse.org/viatra/query.php">page</a>. The new address of the release update sites are the following:</p><pre style="margin-left:40px"><a target="_blank" href="http://download.eclipse.org/viatra/incquery/updates/release">http://download.eclipse.org/viatra/incquery/updates/release</a> <a target="_blank" href="http://download.eclipse.org/viatra/incquery/updates-extra/release">http://download.eclipse.org/viatra/incquery/updates-extra/release</a></pre><p>Courtesy of IncQuery Labs Ltd. there is also a mirror of the EMF-IncQuery release update sites:</p><pre style="margin-left:40px"><a target="_blank" href="http://static.incquerylabs.com/projects/incquery/updates/release/">http://static.incquerylabs.com/projects/incquery/updates/release/ </a><a target="_blank" href="http://static.incquerylabs.com/projects/incquery/updates-extra/release/">http://static.incquerylabs.com/projects/incquery/updates-extra/release/</a></pre><p>The <a target="_blank" href="http://incquerylabs.com/">industrial support</a> behind the new VIATRA platform, as well as our dedication to answer any and all questions regarding our projects is stronger than ever, so feel free to reach out on the Eclipse Forums of VIATRA or the developer mailing list.</p><p>Thanks for reading!</p><p>On behalf of the EMF-IncQuery and VIATRA teams:<br />Ábel Hegedüs, Zoltán Ujhelyi, István Ráth (co-leads)</p><p> </p></div> | |
| <!-- <div class="author">Ábel Hegedüs</div></div> --> | |
| </div> | |
| <div class="post"> | |
| <h2 class="title">EMF-IncQuery 1.1.0 and VIATRA 0.8.0 released</h2> | |
| <div class="date">December 7, 2015</div> | |
| <div class="body"><p>The <a target="_blank" href="http://eclipse.org/incquery">EMF-IncQuery</a> project is happy to report that release 1.1.0 is now available with several new features, fixed bugs and support for the brand new Xtext 2.9. All downloads are available now from the <a target="_blank" href="http://eclipse.org/incquery/download.php">Eclipse.org download servers</a> or the <a target="_blank" href="http://marketplace.eclipse.org/content/emf-incquery">Eclipse Marketplace</a>. In addition, the <a target="_blank" href="http://eclipse.org/viatra">VIATRA</a> project has also published release 0.8.0 (<a target="_blank" href="https://www.eclipse.org/viatra/downloads.php">downloads</a>, <a target="_blank" href="http://marketplace.eclipse.org/content/viatra">Marketplace</a>).</p><p>The most important highlights of this EMF-IncQuery release include (<a target="_blank" href="https://wiki.eclipse.org/EMFIncQuery/Releases/NewAndNoteWorthy1.1">details</a>):</p><ul style="margin-left:40px"><li>compatibility with Xtext 2.9</li><li>improvements in the local search-based query evaluation engine</li><li>moved surrogate query support to the runtime</li><li>enhancements to the Maven builder</li><li>cleaned up exported dependencies related to Guava and Xtext</li><li>lots of various bug fixes (<a target="_blank" href="https://projects.eclipse.org/projects/modeling.incquery/releases/1.1.0/bugs">details</a>)</li></ul><p>The most important highlights of the VIATRA release include (<a target="_blank" href="https://wiki.eclipse.org/VIATRA/Releases/NewAndNoteWorthy0.8">details</a>):</p><ul style="margin-left:40px"><li>completely new MWE integration for defining heterogeneous model transformation chains</li><li>new default state encoder for VIATRA-DSE</li><li>redesigned compiler, check expression and traits support for VIATRA-CEP</li><li>lots of various bug fixes (<a target="_blank" href="https://projects.eclipse.org/projects/modeling.viatra/releases/0.8.0/bugs">details</a>)</li></ul><p>We encourage everyone to ask questions in the Eclipse Forums (<a target="_blank" href="http://www.eclipse.org/forums/index.php/f/255/">EMF-IncQuery</a>, <a target="_blank" href="https://www.eclipse.org/forums/index.php/f/147/">VIATRA</a>) - none will be left unanswered. Also, be sure to check out the <a target="_blank" href="https://github.com/IncQueryLabs/incquery-examples-cps">CPS demonstrator</a> that showcases many features of both tools.</p></div> | |
| <!-- <div class="author">Ábel Hegedüs</div></div> --> | |
| </div> | |
| <div class="post"> | |
| <h2 class="title">EMF-IncQuery is introduced in Eclipse newsletter</h2> | |
| <div class="date">December 2, 2015</div> | |
| <div class="body"><p><span style="font-size:14px">This month, the Eclipse newsletter is focusing on Eclipse Modeling, therefore, IncQuery Labs was invited to contribute to this issue. Finally, we decided to provide an overview of EMF-IncQuery. Here you can read the <a target="_blank" href="http://www.eclipse.org/community/eclipse_newsletter/2015/november/article4.php">article</a> and <a target="_blank" href="http://www.eclipse.org/community/eclipse_newsletter/2015/november/">more about Eclipse Modeling</a>.</span></p></div> | |
| <!-- <div class="author">Katalin Bokor</div></div> --> | |
| </div> | |
| <div class="post"> | |
| <h2 class="title">IncQuery and VIATRA at EclipseCon Europe 2015</h2> | |
| <div class="date">November 21, 2015</div> | |
| <div class="body"><p style="text-align:start">This year, István Ráth and Ákos Horváth have attended <a target="_blank" href="https://www.eclipsecon.org/europe2015/">EclipseCon Europe</a> and represented our team. <a target="_blank" href="http://eclipse.org/incquery">IncQuery</a> and <a target="_blank" href="http://eclipse.org/viatra">VIATRA</a> have been featured in two talks:</p><ul><li>"<strong>IoT Supercharged: Complex Event Processing for MQTT with Eclipse Technologies</strong>" (<a target="_blank" href="https://www.eclipsecon.org/europe2015/session/iot-supercharged-complex-event-processing-mqtt-eclipse-technologies">session</a>, <a target="_blank" href="http://www.slideshare.net/IstvanRath/iot-supercharged-complex-event-processing-for-mqtt-with-eclipse-technologies">slides</a>) - featuring a live demo squeezed into a 10 minute lightning talk - luckily everything worked like a charm :-) This talk is about <a target="_blank" href="https://wiki.eclipse.org/VIATRA/CEP">VIATRA-CEP</a>, a new, high-level framework for complex event processing over runtime models. CEP is a hot topic in IoT for obvious reasons: it is one of the key technologies you want to use to process data/event streams - preferably as close to the data source as possible. In an IoT context, this would typically mean your gateway - which is now possible via new technologies such as <a target="_blank" href="https://eclipse.org/kura/">Eclipse Kura</a>. VIATRA-CEP is part of our Eclipse.org model transformation framework <a target="_blank" href="https://eclipse.org/viatra/">VIATRA</a>, completely open source and licensed under the EPL.</li><li>"<strong>IncQuery gets Sirius: Faster and Better Diagrams</strong>" (<a target="_blank" href="https://www.eclipsecon.org/europe2015/session/incquery-gets-sirius-faster-and-better-diagrams">session</a>, <a target="_blank" href="https://www.eclipsecon.org/europe2015/sites/default/files/slides/iqgetsSirius_eclipsecon_15_ha_final_0.pdf">slides</a>, <a target="_blank" href="https://www.youtube.com/watch?v=_78rRHgiNSo">video</a>). This talk is about a new innovation coming from the IncQuery team, namely the integration between EMF-IncQuery and Sirius. Once this is publicly released, you will be able to use IncQuery patterns in Odesign diagram definitions (next to the traditional options and the new AQL), and enjoy the performance benefits. Additionally, we also provide an integration with IncQuery Viewers, which allows you to define "live diagrams" that are synchronized to the semantic model automatically by incremental transformations.</li></ul><p style="text-align:start">Both talks were well received, we were asked quite a few interesting questions and even suggestions on future development ideas. The entire conference schedule was very strong this year, with hot topics such as the "IoT Day", "Project Quality Day", and the "LocationTech Day" that all provided high quality talks on interesting topics. Here are my favorite picks:</p><ul><li>The <a target="_blank" href="https://www.eclipsecon.org/europe2015/session/teaching-old-dogs-new-tricks-lessons-learned-after-one-year-open-source-activities-internet">first day keynote</a> by Stefan Ferber of Bosch Software Innovations was one of the best keynotes I have seen at EclipseCons. It is good to see such a powerful entity joining the Eclipse ecosystem.</li><li>I really liked two Xtext talks: <a target="_blank" href="https://www.eclipsecon.org/europe2015/session/business-dsls-web-applications">Business DSLs in Web Applications</a> and <a target="_blank" href="https://www.eclipsecon.org/europe2015/session/future-xtext">The Future of Xtext</a>. As both IncQuery and VIATRA rely on Xtext, it is good to see this framework moving ahead at such a high pace and quality.</li><li><a target="_blank" href="https://www.eclipsecon.org/europe2015/session/gef4-sightseeing-mars">GEF4 - Sightseeing Mars</a> was one of the highlights of the Conference to me. I was very pleased to see such an important piece of technology gaining new momentum and fresh ideas. The demos were impressive too!</li><li><a target="_blank" href="https://www.eclipsecon.org/europe2015/session/locationtech-processing-geospatial-data-scale">Processing GeoSpatial Data at Scale</a> was very useful to anyone interested in this topic, as it provided a thorough overview of the domain, including challenges and technologies. Stay tuned for some new innovation coming from the IncQuery team in this area in the near future.</li><li>Finally, I'm very happy to see GS Collections joining the Eclipse family under the name Eclipse Collections framework. The <a target="_blank" href="https://www.eclipsecon.org/europe2015/session/eclipse-collections-example">talk</a> was one of the best at the conference. In fact, we are planning to evaluate this technology for use in IncQuery, to optimize the memory footprint.</li></ul><p style="text-align:start">We would like to thank the Budapest University of Technology and Economics, the MONDO and CONCERTO EU FP7 Projects, and IncQuery Labs Ltd. for supporting our talks at the EclipseCon Europe 2015 conference.</p></div> | |
| <!-- <div class="author">István Ráth</div></div> --> | |
| </div> | |
| <div class="post"> | |
| <h2 class="title">EMF-IncQuery moves out of incubation with Release 1.0.0, with VIATRA 0.7.0 also released</h2> | |
| <div class="date">July 14, 2015</div> | |
| <div class="body"><p>The <a target="_blank" href="http://eclipse.org/incquery">EMF-IncQuery</a> project is happy to report that with our new release 1.0.0 the project is graduating out of incubation and reaches a new level of maturity. All downloads are available now from the <a target="_blank" href="http://download.eclipse.org/incquery/updates/release">Eclipse.org download servers</a> or the <a target="_blank" href="http://marketplace.eclipse.org/content/emf-incquery">Eclipse Marketplace</a>. Coinciding with this event is the first public release of the new generation of the<a target="_blank" href="http://eclipse.org/viatra"> VIATRA</a> model transformation framework, which is a complete re-write (<a target="_blank" href="https://www.eclipse.org/viatra/downloads.php">downloads</a>,<a target="_blank" href="http://marketplace.eclipse.org/content/viatra"> Marketplace</a>).</p><p>VIATRA is a high performance model transformation engine powered by IncQuery technology and an Xtend-friendly API based on the "internal DSL" design. Along with traditional, batch-style transformations, VIATRA includes support for source and target incremental live transformations, as well as advanced transformation execution semantics including design space exploration and complex event processing, all integrated over a reactive execution platform.</p><p>The most important highlights of this EMF-IncQuery release include:</p><ul dir="ltr"><li>compatibility with Eclipse Mars (Xtext 2.8), improved UI and builder stability and performance</li><li>support for instance models with "non-wellbehaving" models through<a target="_blank" href="https://wiki.eclipse.org/EMFIncQuery/UserDocumentation/Surrogate_Queries"> surrogate queries</a></li><li><a target="_blank" href="https://wiki.eclipse.org/EMFIncQuery/UserDocumentation/Surrogate_Queries">enhanced</a><a target="_blank" href="https://wiki.eclipse.org/EMFIncQuery/UMLSupport"> support for UML models</a>, including UML-specific derived features</li><li>improvements to the query language, in particular<a target="_blank" href="https://wiki.eclipse.org/EMFIncQuery/UserDocumentation/PureWhitelist"> whitelists for pure functions</a> that are useful for check expressions</li><li>improvements to <a target="_blank" href="http://wiki.eclipse.org/EMFIncQuery/UserDocumentation/IncQuery_Viewers">IncQuery Viewers</a>, our live query result visualization technology</li><li>improvements to our Maven-compatible builder to allow for building IncQuery projects on build servers</li><li>improvements to the<a target="_blank" href="https://wiki.eclipse.org/EMFIncQuery/DeveloperDocumentation/DebuggerTooling"> IncQuery Debugger Tooling</a>, a tool to aid in debugging queries across JVM boundaries</li><li>lots of various bug fixes (<a target="_blank" href="https://bugs.eclipse.org/bugs/buglist.cgi?list_id=6116573&query_format=advanced&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&version=1.0.0&product=Incquery">details</a>)</li></ul><p>The most important highlights of the VIATRA release include:</p><ul dir="ltr"><li>An internal DSL over the<a target="_blank" href="http://eclipse.org/xtend"> Xtend</a> language to specify both<a target="_blank" href="https://wiki.eclipse.org/VIATRA/Transformation_API"> batch and event-driven, reactive transformations</a>.</li><li><a target="_blank" href="https://wiki.eclipse.org/VIATRA/CEP">A complex event-processing engine</a> over EMF models to specify reactions upon detecting complex sequences of events.</li><li>A rule-based<a href="https://wiki.eclipse.org/VIATRA/DSE"> design space exploration</a> framework to explore design candidates as models satisfying multiple criteria.</li><li>A<a target="_blank" href="http://modeling-languages.com/model-obfuscator/"> model obfuscator</a> to remove sensitive information from a confidential model (e.g. to create bug reports).</li><li>lots of various bug fixes (<a target="_blank" href="https://bugs.eclipse.org/bugs/buglist.cgi?bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&list_id=12210277&product=viatra&query_format=advanced&version=0.7.0">details</a>)</li></ul><p>We encourage everyone to ask questions in the Eclipse Forums (<a target="_blank" href="http://www.eclipse.org/forums/index.php/f/255/">IncQuery</a>,<a target="_blank" href="https://www.eclipse.org/forums/index.php/f/147/"> VIATRA</a>) - none will be left unanswered. Also, be sure to check out the new<a target="_blank" href="https://github.com/IncQueryLabs/incquery-examples-cps"> CPS Example</a> that showcases the most complete feature set of both tools.</p><p>Make sure to follow our blog at <a target="_blank" href="http://incquery.net/">http://incquery.net</a>!</p></div> | |
| <!-- <div class="author">István Ráth</div></div> --> | |
| </div> | |
| <div class="post"> | |
| <h2 class="title">EMF-IncQuery: Query Explorer support for EMF Facet Model Browser</h2> | |
| <div class="date">May 26, 2015</div> | |
| <div class="body"><p>The <a target="_blank" href="https://www.eclipse.org/facet/">EMF Facet</a> project provides a convenient editor for EMF models called the <em>EMF Facet Model Browser</em> which is a great replacement for the <em>Sample Reflective Ecore Model Editor</em>.</p><p>To use it, install the EMF Facet SDK as described <a target="_blank" href="https://wiki.eclipse.org/EMF_Facet/#Install">here</a>, and open your model with the <em>EMF Facet Model Browser</em>. It provides grouping model elements by type, grouping attribute and reference values by relation, text search and so on. The only downside is that it only works for models which have their metamodel registered, therefore if you are developing a metamodel, you have to launch a runtime Eclipse instance to be able to edit instance models of your metamodel with the Model Browser.</p> <img src="http://static1.squarespace.com/static/5614faafe4b03f677dc3822b/56153118e4b022593e35e24b/5624c01de4b0fd5726ae29aa/1445249055935//img.png" alt=""/> <p id="yui_3_17_2_1_1445243169412_549407">Starting from EMF-IncQuery 1.0M3, you can also load models from this advanced editor to EMF-IncQuery's <em>Query Explorer</em> view for your convenience! The <em>Show location</em> context menu command also works, but only partially: because the EMF Facet Model Browser can only select one element, it selects only the first element of the match.</p></div> | |
| <!-- <div class="author">Dénes Harmath</div></div> --> | |
| </div> | |
| <div class="post"> | |
| <h2 class="title">Live querying over UML models with EMF-IncQuery</h2> | |
| <div class="date">April 21, 2015</div> | |
| <div class="body"><p>Starting with EMF-IncQuery version 1.0.0.201503271636, it is possible to formulate patterns which query non-trivial structural features of UML models such as qualified name, which didn't work before. Let's see this feature in action through a small example that validates UML models!</p><p>Install the UML support feature and add the UML support plugin to the dependencies of your plugin as described <a target="_blank" href="https://wiki.eclipse.org/EMFIncQuery/UMLSupport">here</a>.</p><p>Write a constraint pattern that matches when a class has multiple superclasses. For more details about writing validation constraints, refer to the documentation of the <a target="_blank" href="https://wiki.eclipse.org/EMFIncQuery/UserDocumentation/Validation">Validation Framework</a>.</p><pre>package org.incquery.uml.demo import "http://www.eclipse.org/uml2/5.0.0/UML" @Constraint( key = {"class"}, severity = "warning", message = "$class.name$ has multiple superclasses" ) pattern multipleSuperclasses(class: Class) { N == count find superclass(class, _); check (N > 1); } private pattern superclass(class, superclass) { Class.superClass(class, superclass); }</pre><p>Notice that the Class.superClass path expression has an information marker saying:</p><p><em>The derived/volatile feature superClass of class Class used in the path expression has a surrogate query org.eclipse.incquery.uml.derivedfeatures.classSuperClass which will be used by EMF-IncQuery.</em></p><p>This means that this otherwise ill-behaving feature will be substituted with an IncQuery pattern which has the same semantics. This technique is called <a target="_blank" href="https://wiki.eclipse.org/EMFIncQuery/UserDocumentation/Surrogate_Queries">surrogate patterns</a>.</p><p>Let's try out our newly created validator! Launch a runtime Eclipse, create an UML model, open it with the <em>Sample Reflective Ecore Model Editor</em>, right-click the editor contents and select <em>EMF-IncQuery Validation > Initialize EMF-IncQuery Validators on Editor</em>.</p> <img src="http://static1.squarespace.com/static/5614faafe4b03f677dc3822b/56153118e4b022593e35e24b/5624be41e4b01226f1195279/1445248579328//img.png" alt=""/> <p>That's great, but clearly not too convenient for the end user. We can do much better if we write some glue code that initializes the validators automatically whenever a <a target="_blank" href="https://www.eclipse.org/papyrus/">Papyrus</a> diagram editor is opened! This Papyrus-specific mechanism is out of the scope of this blog post, but if you are intereseted, you can check it out <a target="_blank" href="http://git.eclipse.org/c/incquery/org.eclipse.incquery.examples.git/tree/papyrus-uml-derived-features/uml-demo.papyrus">here</a>. To test this feature in the runtime Eclipse, create a Papyrus Model and create a new Class Diagram under it in the <em>Model Explorer</em> view.</p> <img src="http://static1.squarespace.com/static/5614faafe4b03f677dc3822b/56153118e4b022593e35e24b/5624be4ee4b01226f11952bc/1445248591979//img.png" alt=""/> <p>Now you have live validation in your graphical UML editor! You can find the whole source code <a target="_blank" href="http://git.eclipse.org/c/incquery/org.eclipse.incquery.examples.git/tree/papyrus-uml-derived-features">among the IncQuery examples</a>.<br />This opens up many possibilities if your domain is UML - for example, you can also perform incremental transformation of your models. The <a target="_blank" href="https://github.com/IncQueryLabs/incquery-examples-cps">CPS example</a> demonstrates multiple methods of achieving this.</p></div> | |
| <!-- <div class="author">Dénes Harmath</div></div> --> | |
| </div> | |
| <div class="post"> | |
| <h2 class="title">New service release for EMF-IncQuery 0.9.1</h2> | |
| <div class="date">February 24, 2015</div> | |
| <div class="body"><p>We have made public a new service release EMF-IncQuery 0.9.1, that fixes <a target="_blank" href="http://projects.eclipse.org/projects/modeling.incquery/releases/0.9.1/bugs">a few issues</a> that were found after the last release. It is recommended for every user of EMF-IncQuery 0.9.0 to update.</p></div> | |
| <!-- <div class="author">Zoltán Ujhelyi</div></div> --> | |
| </div> | |
| <div class="post"> | |
| <h2 class="title">EMF-IncQuery 0.9.0 Released</h2> | |
| <div class="date">February 10, 2015</div> | |
| <div class="body"><p>We have released version 0.9.0 of <a target="_blank" href="http://eclipse.org/incquery">EMF-IncQuery</a>, a release involving a major refactor of our query backend to support non-EMF query scopes, some minor user facing features and <a target="_blank" href="https://projects.eclipse.org/projects/modeling.incquery/releases/0.9.0/bugs">fixing a selection of bugs</a>. In addition, the tooling has been updated to use Xtext 2.7. It is recommended for all users of EMF-IncQuery to update to this latest version, which is available both from <a target="_blank" href="https://marketplace.eclipse.org/node/450505">Eclipse Marketplace</a> and the <a target="_blank" href="https://www.eclipse.org/incquery/download.php">project download page</a>.</p></div> | |
| <!-- <div class="author">Ábel Hegedüs</div></div> --> | |
| </div> | |
| <div class="post"> | |
| <h2 class="title">mbeddr meets IncQuery - Combining the Best Features of Two Modeling Worlds - EclipseCon Europe 2014</h2> | |
| <div class="date">November 3, 2014</div> | |
| <div class="body"><p>We are proud to announce that this year’s EclipseCon again had a talk about EMF-IncQuery, this time in the context of an integration project with a different modeling world. During the summer, we have started to work on the MPS-IncQuery project, which aims to bring IncQuery’s powerful features to the world of the <a target="_blank" href="https://www.jetbrains.com/mps/">Meta Programming System</a> (MPS) from JetBrains. MPS is a powerful language workbench which is designed to ease the development of domain specific and general purpose languages, plus their IDEs. </p><p>The need for this integration project has risen in the context of the <a target="_blank" href="http://mbeddr.com/">mbeddr</a> project (which is developed by itemis). The mbeddr platform is designed for embedded software development as an intelligent IDE (mainly for C) with many higher level abstractions to ease and help all parts of the development process. mbeddr is built on the MPS workbench as a collection of integrated and extensible languages. This makes it easy to customize, reuse and compose the languages to match you own needs and to have the right abstractions at hand when they are needed.</p><p>The talk was rather technical, due to the complexity of many projects involved and because we tried to give details on as many of the following challenges as we could:</p><ul><li><p>Mapping the Xtext language of the EMF-IncQuery project to the MPS’ world to be able to express the queries right in the workbench.</p></li><li><p>Implementing the code generators for the queries in MPS (MPS is written in Java so we need the resulting Java code to actually use the queries).</p></li><li><p>Providing a type-safe API with an extension to the Java base language of MPS. Here, new statements have been introduced in MPS’ Java language (yes, you can do this too) to access the queries that you have written previously.</p></li><li><p>IncQuery's developer UI, the Query Explorer was also ported to MPS so that debugging of queries is made easier.</p></li><li><p>Implementing the backend which is responsible for handling the notifications coming from the observed MPS models. Here, we tried to reuse as much as possible from the already existing EMF-IncQuery backend. By the way EMF-IncQuery is moving towards the refactoring that all kinds of model representations could be plugged in by simply rewriting the modeling-paradigm-specific parts of the backend (to handle the notifications, for example).</p></li><li><p>We have many use cases in the mbeddr project where we could benefit from the efficient graph queries of IncQuery. This includes assessments on requirements documents (the demo was about this use case), computing scoping information in the IDE to figure out what variables/functions are visible at a given point in the C code or to specify constraints. Additionally, projectional editing brings a whole lot of other usages where live maintenance of graphical viewers is important and response time is crucial for larger diagrams.</p></li></ul><p>We also gave a short live demo during the presentation which was centered around the requirements engineering language of mbeddr. This extension is used by many end users of mbeddr to write requirements documents and create various assessments on them. An assessment is simply a small query which reports certain program elements and constructs which satisfy given conditions. The following screenshots briefly describe the scenario:</p><ul><li><p>The requirements document in mbeddr, where you can also see the workpackages with additional properties like responsible company, priority and scope. </p></li></ul> <img src="http://static1.squarespace.com/static/5614faafe4b03f677dc3822b/56153118e4b022593e35e24b/5624bae8e4b0bca6fa6427b3/1445247724474//img.png" alt=""/> <ul><li>The assessment container and the report inside it. The report has the same properties as the workpackages so that the user can specify the conditions and only those workpackages are listed in the result which meet these conditions. </li></ul> <img src="http://static1.squarespace.com/static/5614faafe4b03f677dc3822b/56153118e4b022593e35e24b/5624bb3be4b08f404f196a11/1445247808549//img.png" alt=""/> <p>Additionally here is the query that we have used for the assessment. This establishes a connection between the WorkPackagesAssessmentReport and the WorkPackages. We access the interesting properties (company, priority, scope) of these concepts and use check expressions to specify the conditions when a tuple should appear in the match set of the query.</p> <img src="http://static1.squarespace.com/static/5614faafe4b03f677dc3822b/56153118e4b022593e35e24b/5624bb7ee4b04bb42a1fe63f/1445247874983/pattern.png" alt=""/> <p>Finally here you can see parts of the Java code that is used in the language for the assessment. In MPS you can write constraints and behavior methods (basically derived features) for you language in the Java language of MPS. This language has been extended with additional constructs and types (in runtime) to access the matchers for the queries:</p> <img src="http://static1.squarespace.com/static/5614faafe4b03f677dc3822b/56153118e4b022593e35e24b/5624bba6e4b021dd852bf3dc/1445247913876//img.png" alt=""/> <p>Here, we create a matcher for our query and the scope of the query is specified as this.model which will evaluate to the model of the given assessment during “runtime”. Runtime is quite interesting here, because everything happens in the same JVM; query development, code generation and reloading of their classes and using the queries for your own instance model. After this we create a partial match where we set the first parameter to be the assessment and then we retrieve all the values for the second parameter which will be the workpackages found in the model.</p><hr /><h3 id="yui_3_17_2_1_1445243169412_420259">Licensing</h3><p>This integration project supports a dual licensing setup, where MPS is licensed under Apache 2.0, while all the other tools (EMF-IncQuery, MPS-IncQuery) are licensed under Eclipse EPL.</p><h3>Resources:</h3><ul><li><p>EclipseCon talk: <a target="_blank" data-cke-saved-href="https://www.eclipsecon.org/europe2014/session/mbeddr-meets-incquery-combining-best-features-two-modeling-worlds" href="https://www.eclipsecon.org/europe2014/session/mbeddr-meets-incquery-combining-best-features-two-modeling-worlds">https://www.eclipsecon.org/europe2014/session/mbeddr-meets-incquery-combining-best-features-two-modeling-worlds</a></p></li><li><p>Slides: <a target="_blank" data-cke-saved-href="http://www.slideshare.net/IstvanRath/mbeddr-meets-incquer-combining-the-best-features-of-two-modeling-worlds" href="http://www.slideshare.net/IstvanRath/mbeddr-meets-incquer-combining-the-best-features-of-two-modeling-worlds">http://www.slideshare.net/IstvanRath/mbeddr-meets-incquer-combining-the-best-features-of-two-modeling-worlds</a></p></li><li><p>mbeddr: <a target="_blank" data-cke-saved-href="http://mbeddr.com/" href="http://mbeddr.com/">mbeddr.com</a> (go to the Learn page to see all the papers on mbeddr)</p></li><li><p>MPS-IncQuery (also includes a simple demo which resembles the school example from the EMF tutorials):<a target="_blank" data-cke-saved-href="https://github.com/szabta89/MPS-IncQuery" href="https://github.com/szabta89/MPS-IncQuery">https://github.com/szabta89/MPS-IncQuery</a></p></li><li><p>Meta Programming System: <a target="_blank" data-cke-saved-href="https://www.jetbrains.com/mps/" href="https://www.jetbrains.com/mps/">https://www.jetbrains.com/mps/</a></p></li></ul></div> | |
| <!-- <div class="author">Tamás Szabó</div></div> --> | |
| </div> | |
| <div class="post"> | |
| <h2 class="title">EMF-IncQuery 0.8.1 released and EclipseCon plans</h2> | |
| <div class="date">October 7, 2014</div> | |
| <div class="body"><p>We have released version 0.8.1 of <a target="_blank" href="http://eclipse.org/incquery">EMF-IncQuery</a>, a release <a target="_blank" href="https://projects.eclipse.org/projects/modeling.incquery/releases/0.8.1/bugs">fixing a selection of bugs</a>. It is recommended for all users of EMF-IncQuery to update to this latest version. The update is available both from <a target="_blank" href="https://marketplace.eclipse.org/node/450505">Eclipse Marketplace</a> and the <a target="_blank" href="https://www.eclipse.org/incquery/download.php">project download page</a>.</p><p>Furthermore, István Ráth from the project will be present at EclipseCon Europe 2014, and will be glad to answer any questions in person. If interested, he will be presenting about a new approach to use <a target="_blank" href="http://eclipsesource.com/blogs/2014/09/29/modeling-symposium-eclipsecon-europe-2014/">IncQuery in the MPS-based mbedder tool</a> at the Modeling Symposium.</p></div> | |
| <!-- <div class="author">Zoltán Ujhelyi</div></div> --> | |
| </div> | |
| <div class="post"> | |
| <h2 class="title">EMF-IncQuery 0.8.0 Released</h2> | |
| <div class="date">July 3, 2014</div> | |
| <div class="body"><p>The <a target="_blank" href="http://eclipse.org/incquery">EMF-IncQuery</a> project is happy to report that our new release with the version 0.8.0 is available now from the <a target="_blank" href="http://download.eclipse.org/incquery/updates/release">Eclipse.org download servers</a> or the <a target="_blank" href="http://marketplace.eclipse.org/content/emf-incquery">Eclipse Marketplace</a>.</p><p>The most important highlights of this release include:</p><ul><li>compatibility with Xtext 2.6, improved UI and builder stability and performance</li><li>completely rewritten builder and internal runtime refactorings to improve performance and reusability/adaptability of the IncQuery technology</li><li>a small but significant addition to the query language: <a target="_blank" href="https://wiki.eclipse.org/EMFIncQuery/UserDocumentation/QueryLanguage#Advanced_Pattern_Constraints">the eval() construct</a></li><li>full support for query libraries, i.e. query reuse across multiple IncQuery projects and bundles</li><li><a target="_blank" href="http://incquery.net/blog/2013/10/xcore-meets-incquery-how-new-generation-dsls-are-made-talk-eclipsecon-europe-2013">Xcore integration</a> (query-based derived features)</li><li>improvements to <a target="_blank" href="http://wiki.eclipse.org/EMFIncQuery/UserDocumentation/IncQuery_Viewers">IncQuery Viewers</a>, our live query result visualization technology</li><li>lots of various bug fixes</li><li>a Maven-compatible builder to allow for building IncQuery projects on build servers</li><li><a target="_blank" href="https://wiki.eclipse.org/EMFIncQuery/DeveloperDocumentation/DebuggerTooling">IncQuery Debugger Tooling</a>, a new tool to aid in debugging queries across JVM boundaries</li></ul><p>For a complete list of fixed issues see <a target="_blank" href="https://bugs.eclipse.org/bugs/buglist.cgi?list_id=6116573&query_format=advanced&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&version=0.8.x&product=Incquery">Bugzilla</a>. We encourage everyone to ask questions in the <a target="_blank" href="http://www.eclipse.org/forums/index.php/f/255/">Eclipse Forums</a> (none will be left unanswered) and make sure to follow our blog at <a target="_blank" href="http://incquery.net/">http://incquery.net</a>! Also, be sure to check out the new <a target="_blank" href="http://incquery.net/incquery/examples/emfxcel">EMFxcel example</a> that showcases some new features and supports live queries on Excel spreadsheets.</p></div> | |
| <!-- <div class="author">István Ráth</div></div> --> | |
| </div> | |
| <div class="post"> | |
| <h2 class="title">Three papers accepted at MODELS 2014</h2> | |
| <div class="date">June 10, 2014</div> | |
| <div class="body"><p><strong>Aggregated From: </strong><br /><a target="_blank" href="https://inf.mit.bme.hu/en/news/2014/06/three-papers-accepted-models-2014">https://inf.mit.bme.hu/en/news/2014/06/three-papers-accepted-models-2014</a></p> <img src="http://static1.squarespace.com/static/5614faafe4b03f677dc3822b/56153118e4b022593e35e24b/5624b5e5e4b0530dc6cbee57/1445246444023//img.png" alt=""/> <p id="yui_3_17_2_23_1445243169412_5092">Three papers by our research group have been accepted at the MODELS 2014 (<a target="_blank" data-cke-saved-href="http://modelsconference.org/" href="http://modelsconference.org/" id="yui_3_17_2_23_1445243169412_5347">ACM/IEEE Model Driven Engineering Languages and Systems</a>) scientific conference, the top international forum for model-driven software engineering.</p><p id="yui_3_17_2_23_1445243169412_5093">We would like to thank our student collaborators and the reviewers for their helpful feedback.</p><p id="yui_3_17_2_23_1445243169412_5094">Pointers to the papers:</p> <ul id="yui_3_17_2_23_1445243169412_4328"><li><a target="_blank" data-cke-saved-href="https://inf.mit.bme.hu/research/publications/streaming-model-transformations-complex-event-processing" href="https://inf.mit.bme.hu/research/publications/streaming-model-transformations-complex-event-processing">Dávid István, Ráth István, Varró Dániel: "Streaming Model Transformations by Complex Event Processing"</a></li><li><a target="_blank" data-cke-saved-href="https://inf.mit.bme.hu/research/publications/incquery-d-distributed-incremental-model-query-framework-cloud" href="https://inf.mit.bme.hu/research/publications/incquery-d-distributed-incremental-model-query-framework-cloud">Szárnyas Gábor, Izsó Benedek, Ráth István, Harmath Dénes, Bergmann Gábor, Varró Dániel: "IncQuery-D: A Distributed Incremental Model Query Framework in the Cloud"</a></li><li><a target="_blank" data-cke-saved-href="https://inf.mit.bme.hu/research/publications/translating-ocl-graph-patterns" href="https://inf.mit.bme.hu/research/publications/translating-ocl-graph-patterns">Bergmann Gábor: "Translating OCL To Graph Patterns" </a></li></ul></div> | |
| <!-- <div class="author">István Ráth</div></div> --> | |
| </div> | |
| <div class="post"> | |
| <h2 class="title">A year's worth of research in retrospect</h2> | |
| <div class="date">December 29, 2013</div> | |
| <div class="body"><p>It's the end of the year according to both the calendar, as well as my research grant. I have spent some of this past year doing research on the connection of OCL and graph queries. I have also tried to explain and illustrate my research topic in <a target="_blank" href="http://incquery.net/blog?tag=Jedlik">previous posts of this very blog</a>, and let the readers keep tabs on what I was up to all this time. Let's do a quick recap.</p><h3><strong>Dramatis personæ</strong></h3><p>Before I could start explaining my specific area and the focus of my investigations, I gave a very brief introduction to the paradigm of model-driven engineering in <a target="_blank" href="http://incquery.net/blog/2013/01/modeling-why-bother">this first blog post</a>, trying to present an overview of what "model-driven" means, and why people are using this approach.</p><p>The focus of a model-driven engineering process is on creating and analyzing abstract models, and deriving them from other models. This workflow can benefit from the help of automated tools for editing, storing, and processing models. Automated model processing in particular is very welcome in a wide rande of modeling environments. As discussed by <a target="_blank" href="http://incquery.net/Prim">my second blog post</a>, developing such modeling tools is easier with the availability of declarative model queries, where the tool developer (or the modeler) can formulate a question in a query language, and a query evaluator mechanism delivers the answer automatically.</p><p>Query languages may differ in syntax and expressive power as well, not to mention tool support. Example query languages include the OCL standard, as well as the graph pattern-based language of the EMF-IncQuery tool. <a target="_blank" href="http://incquery.net/blog/2013/07/illogical-captain">One of the posts compared</a>these two languages against various notable logics, which are the fundamental mathematical constructs underlying model queries.</p><p>In realistic application scenarios, it is very common for models to have frequent updates during the design process. As discussed in <a target="_blank" href="http://incquery.net/blog/2013/04/change-or-die-model-queries-evolving-models">a blog post</a>, repeatedly processing a (large scale) model after each small change can lead to significant performance issues. It can be more advantageous to apply <em>incremental</em> evaluation techniques, taking into account the evolving nature of the model. In certain use cases (e.g. well-formedness checks) incremental queries have great performance advantage. The <a target="_blank" href="http://incquery.net/blog/2013/08/providing-incremental-updates-queries-part-i">blog featured a very cursory outline</a> of the procedure of incremental query evaluation in case of EMF-IncQuery, and <a target="_blank" href="http://incquery.net/blog/2013/09/providing-incremental-updates-queries-part-ii-expression-evaluation">gave a glimpse</a> of how I extended the query language and the corresponding evaluation mechanism to support a new construct that was required for my research.</p><h3><strong>The story so far</strong></h3><p>The goal of my current research grant is translating OCL expressions to graph patterns, so that incremental evaluation techniques (see EMF-IncQuery) developed for graph patterns can be applied to queries formulated in OCL. Following an <a target="_blank" href="http://incquery.net/blog/2013/04/relation-between-ocl-and-graph-patterns-pun-intended">intuitive description</a>of the connection between the two languages, two consecutive blog posts demonstated my proposed method for <a target="_blank" href="http://incquery.net/blog/2013/05/patterns-translating-patterns">translating simple OCL</a> language elements and <a target="_blank" href="http://incquery.net/Patterns">more advanced constructs</a> to graph patterns. A further <a href="http://incquery.net/blog/2013/10/it-alive">post reports</a> on <strong>OCL2IQ</strong>, a partial experimental implementation of this translation that was realized as an Eclipse plug-in.</p><p>The final validation of the research is finding out whether there are any benefits that can be reaped in realistic application scenarios. I have <a target="_blank" href="http://incquery.net/blog/2013/11/measuring">published performance measurements</a> to investigate whether my research fulfills its original promise: delivering efficient, incremental query evaluation for a subset of OCL expressions by transforming them to graph patterns of equivalent semantics, and applying EMF-IncQuery on them. While the graph queries automatically generated using the proposed OCL2IQ transformation did not perform quite as well as manually written EMF-IncQuery code, they do come close, and they definitely outperform pure Java as well as stateless or incremental OCL-based approaches.</p><p>All in all, I have reached the main goal of my research by providing a way to evaluate (a restricted set of) OCL expressions more efficiently than previously possible.</p><h3><strong>Related work</strong></h3><p>Research never stands in a vacuum, but rather forms part of a steady stream of scientific and technical investigations in various forms and topics. Therefore one must always try to find out whether others have previously tackled the same or similar problems. This is the case with my research: the 2008 ENTCS paper (original talk at GT-VMT 2006) by Jessica Winkelmann, Gabriele Taentzer, Karsten Ehrig, and Jochen M. Küster, titled <em>Translation of Restricted OCL Constraints into Graph Constraints for Generating Meta Model Instances by Graph Grammars</em><a target="_blank" href="http://dx.doi.org/10.1016/j.entcs.2008.04.038">[Winkelmann et al]</a> describes a similar translation procedure from OCL to graph patterns.</p><p>Despite the close similarity in contributions, the existence of this related work does not make my research unnecessary for a number of reasons: the earlier paper handles a smaller subset of OCL, translates it into a slightly different graph query language, and does not investigate query performance. All of these are largely due to the fact that the paper had different goals: instead of improving query performance, the focus was on providing a method that automatically generates large instance models of a modeling language (e.g. for testing), conforming to well-formedness constraints expressed by OCL invariants.</p><p>Particularly focusing on differences between the supported subsets of OCL, the cited paper has the following shortcomings compared to my proposed translation method:</p><ul><li>support is focused on Boolean-valued OCL expressions only (though non-Boolean navigations can be used in certain ways);</li><li>set operations such as select(), collect(), union(), etc. are not supported;</li><li>aggregations such as sum() are not supported;</li><li>size() can only be compared against constants;</li><li>the result of two paths of navigation, can only be compared for equality.</li></ul><p>During 2014, I plan to submit a paper to a research conference that publishes a formal treatment of my translation method, as well as performance measurements.</p><p><strong>This research was supported by the European Union and the State of Hungary, co-financed by the European Social Fund in the framework of TÁMOP 4.2.4. A/1-11-1-2012-0001 'National Excellence Program'.</strong></p></div> | |
| <!-- <div class="author">Gábor Bergmann</div></div> --> | |
| </div> | |
| <div class="post"> | |
| <h2 class="title">Measuring up</h2> | |
| <div class="date">November 29, 2013</div> | |
| <div class="body"><p>My <a target="_blank" href="http://incquery.net/blog/2013/10/it-alive">previous blog post</a> demonstrated my OCL to EMF-IncQuery transformation <strong>OCL2IQ</strong> in action. Here I am presenting my first performance measurements to investigate whether this solution fulfills the original promise of my research: delivering efficient, incremental query evaluation for a subset of OCL expressions by transforming them to graph patterns of equivalent semantics, and applying EMF-IncQuery on them.</p><p>For this purpose, I compare the performance of:</p><ul><li>a naive Java implementation of the constraint check, as a hypothetical programmer would quickly implement it, without any special effort to improve performance,</li><li>the OCL interpreter of Eclipse, as it evaluates the OCL representation of the constraint check,</li><li>the OCL Impact Analyzer toolkit, as it incrementally evaluates the same OCL expressions,</li><li>hand-written graph patterns interpreted incrementally by EMF-IncQuery,</li><li>graph patterns automatically derived by my tool OCL2IQ from the OCL expression above, likewise interpreted incrementally by EMF-IncQuery.</li></ul><h3>Benchmark setup</h3><p>The performance measurements were carried out in context of the <a target="_blank" href="http://incquery.net/publications/trainbenchmark-scp">Train Benchmark</a>. This benchmark defines a number of well-formedness constraints in a custom metamodel, and measures the constraint checking performance of various model query tools as they process automatically generated instance models of various sizes conforming to the metamodel. The workload and measured performance indicators involve:</p><ul><li><strong>phase 1: </strong>reading the model,</li><li><strong>phase 2: </strong>checking it for any inconsistencies as defined by the well-formedness constraints,</li><li><strong>phase 3: </strong>simulating a transformation / manual editing of the model that performs a predefined sequence of modifications, and</li><li><strong>phase 4: </strong>checking the updated model as well for inconsistencies</li></ul><p>Contrary to traditional stateless query evaluators, incremental query evaluation strategies will complete phase 4 very quickly (instantly, save for the time it takes to return the results), since the set of inconsistencies has already been computed. However, this comes at the cost of maintaining the incremental caches, which imposes an overhead on phase 3 compared to stateless approaches. Similarly, these incremental caches may be initialized as early as during model reading, thereby shifting work from phase 2 to phase 1. Thus when comparing stateless tools against incremental ones, the most relevant performance indicators are<strong>phase1+2 ("Batch Validation")</strong> execution time and <strong>phase 3+4 ("Continuous Validation")</strong> execution time.</p><p>I have reproduced a subset of the Train Benchmark experiments on four of the original instance models using my Dell Latitude E5420 Laptop with an Intel Core i5-2430M @ 2.4Ghz CPU, 16GB of DDR3-1066/1333 RAM, a Samsung SSD 830 as storage, with software stack Eclipse Kepler on Java SE 1.7.0_05-b06on Windows 7 x64. The measured tool versions were the following:</p><ul><li>Eclipse OCL 3.3.0.v20130520-1222</li><li>Eclipse OCL Impact Analyzer 3.2.100.v20130520-1527</li><li>EMF-IncQuery 0.8.0 (nightly at 2013-11-29)</li></ul><h3>Query task</h3><p>The selected benchmark case was the <strong>SignalNeighbor</strong> constraint check (Req 4). I reproduce here the OCL definition of this constraint check:</p><pre>context Route: oclIsKindOf(Route) and self.Route_exit->exists(signal | self.Route_routeDefinition.Sensor_trackElement.TrackElement_connectsTo.TrackElement_sensor->exists(sen2 | Route.allInstances()->exists(route2X | (route2X <> self) and route2X.Route_routeDefinition->includes(sen2) ) and not ( Route.allInstances()->exists(route2 | route2.Route_routeDefinition->includes(sen2) and route2.Route_entry = signal ) ) ) )</pre><p>My tool OCL2IQ outputs the following graph patterns as translation:</p><pre>pattern SignalNeighbor( self : Route ) { Route(route); self == route; Route.Route_exit(self, signal); signal_1 == signal; Route.Route_routeDefinition(self, sensor); temp1 == sensor; Sensor.Sensor_trackElement(temp1, trackelement); temp2 == trackelement; Trackelement.TrackElement_connectsTo(temp2, trackelement_0); temp3 == trackelement_0; Trackelement.TrackElement_sensor(temp3, sensor_0); sen2 == sensor_0; Route(route_0); route2X == route_0; route2X != self; Route.Route_routeDefinition(route2X, sensor_1); sensor_1 == sen2; neg find SignalNeighbor_4(sen2, signal_1); } pattern SignalNeighbor_4( sen2 : Sensor, signal_1 : Signal ) { Route(route_1); route2 == route_1; Route.Route_routeDefinition(route2, sensor_2); sensor_2 == sen2; Route.Route_entry(route2, signal_0); signal_0 == signal_1; }</pre><p>Whilst the original, hand-written EMF-IncQuery query definition looks like this:</p><pre>pattern signalNeighbor(R1) = { find exitSignalSensor(SigA, R1, Sen1A); find connectingSensors(Sen1A, Sen2A); find rDefinition(R3A, Sen2A); R3A != R1; neg find entrySignalSensor(SigA, _R2A, Sen2A); } pattern exitSignalSensor(Sig, R1, Sen1) = { find exitSignal(R1, Sig); find rDefinition(R1, Sen1); } pattern entrySignalSensor(Sig, R2, Sen2) = { find entrySignal(R2, Sig); find rDefinition(R2, Sen2); } pattern entrySignal(R, Sig) = { Route(R); Signal(Sig); Route.Route_entry(R, Sig); } pattern exitSignal(R, Sig) = { Route(R); Signal(Sig); Route.Route_exit(R, Sig); } pattern rDefinition(R, Sen) = { Route(R); Sensor(Sen); Route.Route_routeDefinition(R, Sen); } pattern connectingSensors(Sen1, Sen2) = { find sensorTrackelement(Sen1, Te1); find sensorTrackelement(Sen2, Te2); find trackelementConnected(Te1, Te2); } pattern trackelementConnected(Te1, Te2) = { Trackelement(Te1); Trackelement(Te2); Trackelement.TrackElement_connectsTo(Te1, Te2); } pattern sensorTrackelement(Sen, Te) = { Sensor(Sen); Trackelement(Te); Sensor.Sensor_trackElement(Sen, Te); }</pre><h3>Benchmark results</h3><p>For now, I only measured execution times. Memory consumption - where incremental tools will show their most important disadvantage - will be investigated later. Also note that the Java implementation was already close to timing out for the smaller instance models, so it was never run for the larger ones.</p><p><table border="1" cellpadding="1" cellspacing="1" style="height:313px; width:640px"> <thead> <tr> <th colspan="2" rowspan="1" scope="row"> </th> <th colspan="4" rowspan="1" scope="col">Performance on instance models</th> </tr> </thead> <tbody> <tr> <th colspan="2" rowspan="1" scope="row">Model size (#of nodes+edges)</th> <td class="rteright">113K</td> <td class="rteright">213K</td> <td class="rteright">435K</td> <td class="rteright">867K</td> </tr> <tr> <th colspan="1" rowspan="2" scope="row">Java</th> <td>Batch Validation Time</td> <td class="rteright">37 744 ms</td> <td class="rteright">140 630 ms</td> <td class="rteright"> </td> <td class="rteright"> </td> </tr> <tr> <td>Continuous Validation Time</td> <td class="rteright">35 421 ms</td> <td class="rteright">130 851 ms</td> <td class="rteright"> </td> <td class="rteright"> </td> </tr> <tr> <th colspan="1" rowspan="2" scope="row">OCL</th> <td>Batch Validation Time</td> <td class="rteright">12 019 ms</td> <td class="rteright">42 261 ms</td> <td class="rteright">134 436 ms</td> <td class="rteright">664 327 ms</td> </tr> <tr> <td>Continuous Validation Time</td> <td class="rteright">6 849 ms</td> <td class="rteright">29 813 ms</td> <td class="rteright">124 486 ms</td> <td class="rteright">659 803 ms</td> </tr> <tr> <th colspan="1" rowspan="2" scope="row">OCL-IA</th> <td>Batch Validation Time</td> <td class="rteright">11 309 ms</td> <td class="rteright">31 314 ms</td> <td class="rteright">132 929 ms</td> <td class="rteright">641 865 ms</td> </tr> <tr> <td>Continuous Validation Time</td> <td class="rteright">58 ms</td> <td class="rteright">55 ms</td> <td class="rteright">45 ms</td> <td class="rteright">54 ms</td> </tr> <tr> <th colspan="1" rowspan="2" scope="row">EMF-IncQuery</th> <td>Batch Validation Time</td> <td class="rteright">3 903 ms</td> <td class="rteright">4 822 ms</td> <td class="rteright">6 670 ms</td> <td class="rteright">14 450 ms</td> </tr> <tr> <td>Continuous Validation Time</td> <td class="rteright">7 ms</td> <td class="rteright">5 ms</td> <td class="rteright">8 ms</td> <td class="rteright">7 ms</td> </tr> <tr> <th rowspan="2" scope="row">OCL2IQ</th> <td>Batch Validation Time</td> <td class="rteright">4 376 ms</td> <td class="rteright">4 734 ms</td> <td class="rteright">9 083 ms</td> <td class="rteright">16 441 ms</td> </tr> <tr> <td>Continuous Validation Time</td> <td class="rteright">24 ms</td> <td class="rteright">10 ms</td> <td class="rteright">16 ms</td> <td class="rteright">7 ms</td> </tr> </tbody> </table></p><p>The measurement data testifies that incremental strategies perform extremely well in the "Continuous Validation" workload, delivering execution times that are essentially independent from the size of the unchanging parts of the model. Furthermore it is apparent that EMF-IncQuery provides consistently higher performance as the other approaches. Finally and most importantly, I would like to point out that while the graph queries automatically generated using the proposed OCL2IQ transformation do not perform quite as well as manually written EMF-IncQuery code, they do come close, and they definitely outperform pure Java as well as stateless or incremental OCL-based approaches.</p><p>All in all, I have reached the main goal of my research by providing a way to evaluate (a restricted set of) OCL expressions more efficiently than previously possible.</p><p><strong>This research was supported by the European Union and the State of Hungary, co-financed by the European Social Fund in the framework of TÁMOP 4.2.4. A/1-11-1-2012-0001 'National Excellence Program'.</strong></p></div> | |
| <!-- <div class="author">Gábor Bergmann</div></div> --> | |
| </div> | |
| <div class="post"> | |
| <h2 class="title">It is alive!</h2> | |
| <div class="date">October 31, 2013</div> | |
| <div class="body"><p>In one of my <a target="_blank" href="http://incquery.net/blog/2013/05/patterns-translating-patterns">earlier blog posts</a>, I have outlined the basic ideas and transformation patterns that accomplish a translation of (a subset of) OCL expressions into graph patterns. The theory was illustrated by running examples from the <a target="_blank" href="http://incquery.net/blog/2013/02/primer-model-queries">school case study</a>, where the purpose of querying was to find classmates with the same name. The good news is that I have managed creating an experimental implementation of this translation that maps OCL expressions to equivalent graph patterns.</p><p>If you recall, the original OCL expression detecting such name conflicts was expressed in context of a SchoolClass as follows:</p><pre>self.students->collect(s1 | self.students->select(s2 | s2.name = s1.name and s1 <> s2)-> collect(s2 | Tuple{student1 = s1, student2 = s2, name = s1.name}))</pre><p>The following graph patterns was given originally as its translation:</p><pre>pattern nameConflicts(clazz: SchoolClass, student1: Student, student2: Student, name: EString) = { SchoolClass.students(clazz, student1); SchoolClass.students(clazz, student2); student1 != student2; Student.name(student1, name); Student.name(student2, name); }</pre><p>My tool can currently generate this from the OCL expression as input:</p><pre>pattern translated( self : SchoolClass, student2 : Student, student1 : Student, name : EString ) { SchoolClass.students(self, student); s1 == student; eInt == count find translated_0(s2,s1); eBoolean == eval(eInt > 0); eInt_0 == count find translated_1(s2,s1); eBoolean_0 == eval(eInt_0 > 0); boolean_0 == eval((eBoolean as boolean) && (eBoolean_0 as boolean)); true == boolean_0; SchoolClass.students(self, student_0); s2 == student_0; s2_0 == s2; Student.name(s1, eString_1); student1 == s1; student2 == s2_0; name == eString_1; } pattern translated_0( s2 : Student, s1 : Student ) { Student.name(s2, eString); Student.name(s1, eString_0); eString == eString_0; } pattern translated_1( s2 : Student, s1 : Student ) { s1 != s2; }</pre><p>Admittedly, it is not nearly as nice as the original solution, as some of the solutions I have implemented are quite simple and stupid right now, not as elegant and clever as they could eventually be. In some cases - such as the many EMF-IncQuery variables unnecessarily equated to each other - this is purely a matter of aesthetics. In others, such as pattern translated_1, it actually hurts query evaluation efficiency. However, these generated patterns do the job and deliver correct results.</p><p>Furthermore, the tool does not handle yet all OCL language elements for which the translation was shown to be possible, including some things seen in this <a target="_blank" href="http://incquery.net/blog/2013/06/patterns-translating-patterns-part-ii">former blog post</a>.</p><p>The experimental implementation was realized as an Eclipse plug-in. The source code project is available at <a target="_blank" href="https://github.com/istvanrath/EMF-IncQuery-Addons/tree/master/ocl2iq">github</a>. Use it in the following way:</p><pre>EClass context= MyMetaModelPackage.eINSTANCE; /* reference your Ecore package here*/ String oclCode = "self.whatever"; /* insert OCL code here */ OCLExpression exp = new OCLParseControl().parse(context, oclCode); String patternCode = new OCL2IQ(context, exp, "translated").gen().toString();</pre><p> </p><p><strong>This research was supported by the European Union and the State of Hungary, co-financed by the European Social Fund in the framework of TÁMOP 4.2.4. A/1-11-1-2012-0001 'National Excellence Program'.</strong></p></div> | |
| <!-- <div class="author">Gábor Bergmann</div></div> --> | |
| </div> | |
| <div class="post"> | |
| <h2 class="title">Xcore meets IncQuery: How the new generation of DSLs are made - talk at EclipseCon Europe 2013</h2> | |
| <div class="date">October 29, 2013</div> | |
| <div class="body"><p>The EMF-IncQuery Project is proud to announce our talk at this year's EclipseCon Europe conference titled <a target="_blank" href="http://www.eclipsecon.org/europe2013/xcore-meets-incquery-how-new-generation-dsls-are-made">"Xcore meets IncQuery: How the New Generation of DSLs Are Made"</a>.</p><p>Have you ever got lost in a complex domain-specific model? Are you familiar with Facebook's Graph Search? Ever wished something like this would be available for your favorite EMF-based tool? It is, it's called <a target="_blank" href="http://eclipse.org/incquery">EMF-IncQuery</a>. In fact, it can do more than Graph Search, because you can create <strong>live queries</strong>, meaning you get live updates for your search results as the model is being edited. In the talk, we'll show you some of the most powerful features that this technology can be used for in practice.</p><p>See you on 31 October between 14:15 - 14:50 in Seminarräume 1-3!</p><p>The technology presented in this talk is the result of a collaboration between Ed Merks, Tamas Szabo (itemis AG) and the EMF-IncQuery team. Read the rest of the blog post below for more information regarding the presentation and the live demos.</p><p>In this talk, we present a new technology that takes language engineering to the next level by integrating live graph search (as supported by EMF-IncQuery) right into the heart of DSLs. As a result, the new generation of Xcore DSLs can leverage query-based derived values and relationships (that support notifications) that open up a wide range of new possibilities in interlinking various DSLs (traceability), live validation, and model visualization through live abstractions.</p><p>In the talk, we use concrete examples to show how:</p><ul><li>even beginners can create expressive DSLs from scratch, without having to learn complex and difficult languages such as OCL;</li><li>Xbase, the familiar (Java-like) language can be used in incremental graph queries over EMF models;</li><li>such metamodel-integrated graph queries can significantly enhance the expressive power and usefulness of a DSL;</li><li>yet, the model management and query performance of such a new generation DSL scales exceptionally well even as model sizes grow to the millions.</li></ul><p>Get the slides here:</p><p><strong><a target="_blank" href="https://www.slideshare.net/IstvanRath/xcoreinc-query-ece2013revised">Xcore meets IncQuery: How the New Generation of DSLs are Made</a> </strong>from <strong><a target="_blank" href="http://www.slideshare.net/IstvanRath">Istvan Rath</a></strong></p><p><strong>Live abstractions powered by incremental graph search</strong></p><p>IncQuery Viewers can be used to create live abstractions for your models with a few lines of code. Live abstractions allow your users to manage complex modeling scenarios by providing live updating views that focus on interesting parts of the model.</p><p>IncQuery Viewers supports the JFace Viewer Framework as well as the <a target="_blank" href="http://wiki.eclipse.org/Zest">Zest Graph Visualization Framework</a> (available as open source), as well as the powerful <a target="_blank" href="http://www.yworks.com/yfiles">yFiles Graph Visualization Toolkit</a> from yWorks (available as a commercial add-on from IncQueryLabs Ltd.).</p> <img src="http://static1.squarespace.com/static/5614faafe4b03f677dc3822b/56153118e4b022593e35e24b/5624b1b5e4b083b724bb9127/1445245366815//img.png" alt=""/> <p><strong>Query-based derived features with automatic notification support</strong></p><p>In co-operation with Ed Merks, the EMF-IncQuery team have developed a deep integration between live graph search and <a target="_blank" href="http://wiki.eclipse.org/Xcore">Xcore</a>, the Xtext-based textual syntax for Ecore metamodeling. With this feature, you can write live graph queries with EMF-IncQuery and integrate them transparently into your DSL in the form of <em>derived features that support automatic notifications</em>. As we will show, these query-based derived features can significantly boost the expressive power of your metamodels, help you get rid of a lot of cruft and improve the scalability of your modeling tool.</p> <img src="http://static1.squarespace.com/static/5614faafe4b03f677dc3822b/56153118e4b022593e35e24b/5624b1dbe4b0007a0010fffa/1445245406735/Plug-in_Development_-_library.domain_src_library_LibraryQueries.eiq_-_Eclipse_Platform-14_0.png_src_library_LibraryQueries.eiq_-_Eclipse_Platform-14_0.png?format=original" alt=""/> <p><strong>Try the live demos yourself</strong></p><p>If you want to try the examples used in the demos yourself, install a recent Eclipse Kepler with bleeding edge components from the following <strong>update sites</strong>:</p><ul><li>Eclipse Kepler SR1 Classic</li><li><a target="_blank" href="http://download.eclipse.org/modeling/emf/emf/updates/milestones">EMF all in one SDK 2.10 milestone M2</a></li><li><a target="_blank" href="http://download.eclipse.org/modeling/tmf/xtext/updates/composite/milestones">Xtext 2.5 milestone M2 SDK</a></li><li>Xcore from same EMF milestone update site</li><li><a target="_blank" href="http://download.eclipse.org/modeling/emf/transaction/updates/milestones">EMF Transaction 2.10 milestone M2</a></li><li><a target="_blank" href="http://download.eclipse.org/tools/gef/gef4/updates/integration">GEF4 Zest Visualization Toolkit SDK integration</a></li></ul><p>The EMF-IncQuery demo build can be downloaded from the following <strong>update site</strong>: <a target="_blank" href="http://incquery.net/download.eclipse.org/incquery/updates-xcoreiq">http://download.eclipse.org/incquery/updates-xcoreiq</a></p><p>Alternatively, you can download everything into Eclipse Kepler from the following <strong>all-in-one update site:</strong> <a target="_blank" href="http://download.eclipse.org/incquery/updates-xcoreiq-all">http://download.eclipse.org/incquery/updates-xcoreiq-all</a> </p><p><strong>Example projects</strong></p><p>You can get the demo projects from Git <a href="http://git.eclipse.org/c/incquery/org.eclipse.incquery.examples.git/tree/library">here</a>.</p><ul><li>IncQuery Viewers<ul><li><a target="_blank" href="http://git.eclipse.org/c/incquery/org.eclipse.incquery.examples.git/tree/library/library.ecore">library.ecore</a>: simple Library Ecore project</li><li><a target="_blank" href="http://git.eclipse.org/c/incquery/org.eclipse.incquery.examples.git/tree/library/library.ecore.viewers">library.ecore.viewers</a>: Viewers queries featured in the live demo</li></ul></li><li>IncQuery+Xcore<ul><li><a target="_blank" href="http://git.eclipse.org/c/incquery/org.eclipse.incquery.examples.git/tree/library/library.domain.base">library.domain.base</a>: simple Library Xcore+IncQuery project</li></ul></li><li>Viewers with Xcore projects<ul><li><a target="_blank" href="http://git.eclipse.org/c/incquery/org.eclipse.incquery.examples.git/tree/library/library.domain">library.domain</a>: complete Library Xcore+IncQuery project with advanced examples</li><li><a target="_blank" href="http://git.eclipse.org/c/incquery/org.eclipse.incquery.examples.git/tree/library/library.viewers">library.viewers</a>: more complex Viewers visualization queries, Viewers Extensions UI component samples</li><li><a target="_blank" href="http://git.eclipse.org/c/incquery/org.eclipse.incquery.examples.git/tree/library/library.instances">library.instances</a>: sample instance models featured in the live demos</li></ul></li></ul><p><strong>Notes on dynamic instances</strong></p><p>If you'd like to work with the dynamic instance models as we do in the demos, please apply the following (Workspace-specific) settings for the EMF-IncQuery Query Explorer (through the Property settings page):</p><ul><li>disable wildcard mode for Query Explorer</li><li>enable dynamic mode for Query Explorer</li></ul> <img src="http://static1.squarespace.com/static/5614faafe4b03f677dc3822b/56153118e4b022593e35e24b/5624b257e4b02346887159ff/1445245530880/Preferences.png" alt=""/> <p id="yui_3_17_2_1_1445243169412_128728">A small FAQ regarding dynamic instances:</p><ul><li><strong>Q:</strong> Can queries be changed while the instance model is loaded? <strong>A:</strong> Yes, but the derived features will only be updated after the dynamic instance model is reloaded (editor close-open)</li><li><strong>Q:</strong> Can the .xcoreiq be changed while the instance model is loaded? <strong>A:</strong> Not recommended.</li></ul><p><strong>Related reading</strong></p><p><strong>Technology documentation</strong></p><ul><li><a target="_blank" data-cke-saved-href="http://wiki.eclipse.org/EMFIncQuery/UserDocumentation/IncQuery_Viewers" href="http://wiki.eclipse.org/EMFIncQuery/UserDocumentation/IncQuery_Viewers">IncQuery Viewers Documentation</a></li><li><a target="_blank" data-cke-saved-href="http://wiki.eclipse.org/EMFIncQuery/DeveloperDocumentation/IncQueryXcore" href="http://wiki.eclipse.org/EMFIncQuery/DeveloperDocumentation/IncQueryXcore">IncQuery-Xcore Integration Documentation</a></li><li><a target="_blank" data-cke-saved-href="http://wiki.eclipse.org/EMFIncQuery/UserDocumentation/Query_Based_Features" href="http://wiki.eclipse.org/EMFIncQuery/UserDocumentation/Query_Based_Features">IncQuery Query-based Derived Features Documentation</a></li></ul><p><strong>Research Papers</strong></p><ul><li>Hegedüs, Horváth, Ráth, Varró: <em>Query-driven soft interconnection of EMF Models.</em> (MODELS'12) <a target="_blank" data-cke-saved-href="http://www.inf.mit.bme.hu/en/research/publications/query-driven-soft-interconnection-emf-models" href="http://www.inf.mit.bme.hu/en/research/publications/query-driven-soft-interconnection-emf-models">Paper</a> <a target="_blank" data-cke-saved-href="http://incquery.net/incquery/new/examples/query-driven-soft-links" href="http://incquery.net/incquery/new/examples/query-driven-soft-links">Minipage with examples</a></li><li>Ráth, Hegedüs, Varró: <em>Derived Features for EMF by Integrating Advanced Model Queries.</em> (ECMFA'12) <a target="_blank" data-cke-saved-href="http://www.inf.mit.bme.hu/en/research/publications/derived-features-emf-integrating-advanced-model-queries" href="http://www.inf.mit.bme.hu/en/research/publications/derived-features-emf-integrating-advanced-model-queries">Paper</a> <a target="_blank" data-cke-saved-href="http://incquery.net/incquery/new/examples/derivedfeatures" href="http://incquery.net/incquery/new/examples/derivedfeatures">Minipage with examples</a></li></ul><p><strong>More information</strong></p><ul><li>Dr. István Ráth, EMF-IncQuery Project Lead rath AT mit.bme.hu</li><li>Ákos Horváth, CEO <a target="_blank" data-cke-saved-href="http://incquerylabs.com/" href="http://incquerylabs.com/">IncQueryLabs Ltd.</a> akos.horvath AT incquerylabs.com</li></ul></div> | |
| <!-- <div class="author">István Ráth</div></div> --> | |
| </div> | |
| <div class="post"> | |
| <h2 class="title">Providing incremental updates for queries, part II: expression evaluation</h2> | |
| <div class="date">September 30, 2013</div> | |
| <div class="body"><p>After the overview presented in <a target="_blank" href="http://incquery.net/blog/2013/08/providing-incremental-updates-queries-part-i">my previous blog post</a>, I am now going to discuss incremental expression evaluation, a.k.a. the<strong>eval()</strong> language element, which is my most recent contribution to EMF-IncQuery. The examples continue to rely upon the School metamodel introduced <a target="_blank" href="http://incquery.net/blog/2013/02/primer-model-queries">here</a>.</p><h3><strong>Computed values</strong></h3><p>Queries very often refer to attribute values stored at objects. Sometimes this is not enough, and additional values must be computed based on the attributes in order to express queries. This computation is defined by a deterministic function expressed by an appropriate sublanguage of the query formalism.</p><p>Let us see, for example, an OCL expression that computes a tuition fee for each course based on the course weight:</p><pre>context Course def: tuitionFee() = (100.0 + self.weight * 40.0)->max(450.0)</pre><p>The previous blog post contained an equivalent EMF-InQuery graph pattern:</p><pre>pattern courseTuitionFee(c: Course, fee) = { Course.weight(c, weight); fee == eval(Math.max(450.0, 100.0 + weight * 40.0)); }</pre><h3><strong>Computed values vs. simple checks</strong></h3><p>Very often, the computed value is merely a true/false logical distinction whether the given elements should be included in the query results. For example, the following EMF-IncQuery graph pattern selects only those courses that have a weight exceeding 8 points:</p><pre>pattern importantCourse(c: Course) = { Course.weight(c, weight); true == eval(weight > 8); }</pre><p>For this common use case, EMF-IncQuery provides a more convenient syntax as well, which has already been discussed before:</p><pre>pattern importantCourse(c: Course) = { Course.weight(c, weight); check(weight > 8); }</pre><h3><strong>Computed values vs. EMF-IncQuery</strong></h3><p>Having seen the motivation behind function evaluation in queries, let us focus now on the current capabilities of EMF-IncQuery.</p><p>Since the inception of the earliest prototypes and experiments in 2009, EMF-IncQuery has always supported the check() construct. Up to now, however, the more general case of eval(), where the result of the computation is captured by a variable and can be referred to, was not supported.</p><p>Thanks to my latest development sprint, <a target="_blank" href="http://https//hudson.eclipse.org/hudson/job/incquery-master/lastSuccessfulBuild/artifact/update-site/">nightly builds</a> of EMF-IncQuery now provide experimental support for eval() constructs with the Xbase expression language. While the new feature is not yet well-tested, simple constructs such as the pattern courseTuitionFee above work fine. Future iterations will improve internal indexing. Another remaining goal is to integrate the type inference mechanism of the Xbase language - at the moment, the result of the evaluation is treated as a generic Object by the type inference of EMF-IncQuery.</p><h3>Anatomy of a language feature</h3><p>Let us now see what steps were required to implement such a new feature.</p><p><strong>Rete-level</strong>. The incremental evaluator engine powering EMF-IncQuery is based on the Rete algorithm. Pattern matching is reduced into a Rete network, which is a system of incrementally computable elementary operations, each expressed as a Rete node.</p><p>The feature eval() required the addition of a new type of Rete node, that is capable of evaluating an Xbase expression based on the values of "input" pattern variables, and bind the non-null result to a new pattern variable. In case the expression evaluates to null (or throws an Exception), the combination of input variables is discarded, as it is not considered a match in this case. In case of a non-null result, the tuple of input variables (as substitued by the parent Rete node) is extended by the value of the result variable, and this "output" tuple is emitted by the Rete node (to be consumed by child Rete nodes). At the same time, the internal cache of the node saves the mapping of the input tuple to the output tuple. This helps to avoid recalculation: when the input tuple is later deleted (due to changes in the model), the corresponding output tuple can be looked up (and removed from) this cache, and then the retraction of the obsolete output tuple can be emitted by the Rete node; if the cache lookup returns empty, then there was no output tuple propagated before, so no action needs to be taken.</p><p>The previous blog post exemplified the basic behaviour of this new Rete node in case of the pattern courseTuitionFee: when the value of the weight attribute is assigned for a new course, the tuition fee will be computed using a complex formula, and the match (the pair formed of the course and its newly computed fee) will be stored in the incremental cache. When the weight of the course is changed, the course-weight pair will be removed from the cache of the constituent elementary query; the fee that was once computed for course can be looked up, and the result removed from the match set cache.</p><p><strong>Query planning</strong>. When the user requests the results of a previously unseen graph pattern, the EMF-IncQuery engine performs a chain of steps to design a construct a Rete network that incrementally maintains the result set of the pattern. This process involves reasoning about the variables and constraints of the graph pattern, for instance determining which variables need to be known before a certain constraint can be satisfied, and what additional variables will be substituted each way the constraint is satisfied.</p><p>As eval() expressions can be embedded in pattern constraints (e.g. as one of the arguments of a find constraint, or an equality constraint as shown in the above examples), the structure of the pattern must be simplified (canonicalized) so that query planner can process it. The logic in case of eval() expressions (similarly e.g. to count aggregations) is that the evaluation result is treated as a new anonymous variable in the pattern constraint where it is used, and eval() itself is represented by a separate pattern constraint that binds the result to this new variable.</p><p>There is no way to evaluate the expressions until the referenced variables are substituted, so the eval() Rete node can only be attached to a parent node where all of these variables already have a value. Moreover, different constraints may impose different types of variables; for type safety, evaluation is performed only when the input variables are guaranteed to be substituted for elements of the strictest type. Finally, the evaluator Rete node substitutes a value for the new result variable, so in some cases there is another constraint that the query planner can only schedule after the eval() computation. Alltogether, these are restrictions that the query planner needs to observe when building the Rete net.</p><p><strong>Language extension</strong>. Finally, eval() was added as a new language element. While this in itself is a very easy step (thanks to the power of the Xtext grammar), it gives rise to a large amount of supplementary tasks. They range from simply providing a new entry in the Outline view of the Eclipse-based EMF-IncQuery pattern editor; through extending the code generator and expression compiler; to fairly complex adjustments in the extensive set of static validators that support the query engineer by pointing out potential mistakes in the query code.</p><p>The most involving part of the incurrend tasks would be the integration of Xbase type inference to learn the types of eval() results. This is important for type checking (which is another kind of static validations), but also because the inferred types can be used by the code generator of EMF-IncQuery to synthetize more user-friendly patter-specific query APIs. Due to the complexity involved, this integration effort is left as future work, and the current version approximates the type by the universal supertype Object.</p><p><strong>Acknowledgement: this research was supported by the European Union and the State of Hungary, co-financed by the European Social Fund in the framework of TÁMOP 4.2.4. A/-11-1-2012-0001 ‘National Excellence Program’.</strong></p></div> | |
| <!-- <div class="author">Gábor Bergmann</div></div> --> | |
| </div> | |
| <div class="post"> | |
| <h2 class="title">Interview with our former student in the german Eclipse Magazine</h2> | |
| <div class="date">September 30, 2013</div> | |
| <div class="body"><p><strong>Aggregated From: </strong><br /><a target="_blank" href="https://inf.mit.bme.hu/en/news/2013/09/interview-our-former-student-german-eclipse-magazine">https://inf.mit.bme.hu/en/news/2013/09/interview-our-former-student-german-eclip...</a></p><p>The german Eclipse Magazin has published an interview with our former student, Donát Csikós, who is now working at CERN. Among a lot of interesting details about his job, he also mentioned our research group and the <a target="_blank" href="http://eclipse.org/incquery">EMF-IncQuery</a> project. The online version can be found at the following links: <a target="_blank" href="http://jaxenter.de/artikel/Eclipse-beim-CERN-167585">german original</a>, <a target="_blank" href="http://translate.google.com/translate?sl=auto&tl=en&js=n&prev=_t&hl=en&ie=UTF-8&u=http%3A%2F%2Fjaxenter.de%2Fartikel%2FEclipse-beim-CERN-167585&act=url">english translation by Google</a>.</p><p>Along with Dr. István Ráth and Tamás Szabó (who is also a former student), Donát will also be presenting at EclipseCon Europe this year. The abstracts to the presentations can be found at the following links:</p><ul><li>Dr. István Ráth (BME), Tamás Szabó (Itemis AG): <a target="_blank" href="http://www.eclipsecon.org/europe2013/xcore-meets-incquery-how-new-generation-dsls-are-made">Xcore meetings IncQuery - How the New Generation of DSLs Are Made</a></li><li>Donát Csikós (CERN), Jed Anderson (Genuitec): <a target="_blank" href="http://www.eclipsecon.org/europe2013/how-cern-scaled-eclipse-lhc">How CERN scaled up Eclipse for the LHC</a></li></ul></div> | |
| <!-- <div class="author">István Ráth</div></div> --> | |
| </div> | |
| <div class="post"> | |
| <h2 class="title">Providing incremental updates for queries, part I</h2> | |
| <div class="date">August 26, 2013</div> | |
| <div class="body"><p>After discussing the importance of <a target="_blank" href="https://incquery.net/blog/2013/01/modeling-why-bother">modeling</a> and the concept of <a target="_blank" href="https://incquery.net/blog/2013/02/primer-model-queries">model queries</a> (with OCL and EMF-IncQuery), one of the introductory blog posts presented the challenge posed by <a target="_blank" href="https://incquery.net/blog/2013/04/change-or-die-model-queries-evolving-models">model evolution.</a> Incremental query evluation was suggested then as a solution, without going into the details of <em>how</em> it can be achieved for a query language such as the one of EMF-IncQuery. Taking advantage of the previously discussed <a target="_blank" href="http://incquery.net/blog/2013/07/illogical-captain">foundations in formal logic</a>, the applied incremental strategy will be outlined here.</p><h3><strong>Elementary model queries</strong></h3><p>In analogy to elementary query statements introduced during the discussion of the propositional logic-based language subset, elementary model queries are the following:</p><ul><li>retrieve the model elements of a certain type,</li><li>retrieve pairs of model elements, where the first one points to the second one using a reference of a given type,</li><li>retrieve pairs of a model element and an attribute value, the the given attribute of the model element takes the associated value</li></ul><p>The first task is obtaining the results to these elementary queries. This involves traversing the entire model, and gather each object or edge that conforms to the types indicated in the queries. The results sets can then be cached for later use.</p><p>The second problem is that of providing incremental updates to the results of elementary queries. This requires us to register update notification listeners for the entire model. Whener the model is modified somehow, no matter how the change is performed and what initiated it, the listeners will be notified of this change. The result can be transformed and filtered, to find out which of the result caches should be updated and how.</p><p>For example, the elementary query "retrieve all school classes and students where the student is a member of the class" will be associated with a cache of class-student pairs. When a student is moved from one class to another, the model releases change notifications which are translated by the listeners into the action of removing the obsolete entry from the cache, and adding the updated one.</p><p>Note that equality and inequality were mentioned before as atomic formulas alongside these elementary model queries. Their results sets, however, can not and need not be cached in advance; they will be used as mere filters, as shown in the next example.</p><h3><strong>Connectives</strong></h3><p>Once incrementally maintained caches have been established for simpler queries, the results of more complex queries constructed from them using conjunctive, disjunctive and negative connectives, as well as quantification. The initial cache population is performed by applying set operations on the results of simlper queries: union for discjunction, relational join for conjunction, difference for negation, and relational projection for quantification.</p><p>Similarly to how elementary query caches reacted to changes of the model, the result of connectives has to be updated whenever the results of the constituent simple queries are.</p><p>For example, the set of all pairs of classmates is expressed as the following query:</p><pre>pattern classmates(s1: Student, s2: Student, cl: SchoolClass) = { SchoolClass.students(cl, s1); SchoolClass.students(cl, s2); s1 != s2; }</pre><p>Note that this query is a conjunction of two (equivalent) elementary queries, and an inequality statement. The match set of the pattern is therefore derived using a relational operation called "join" from the set of school class - student pairs, with an inequality filtering prepended. And when elementary query results for "SchoolClass.students" are updated by an insertion (i.e. a new student joins a class), other students from the same class are looked up from the cached query results, and thus new matches of the pattern are produced, ready to be stored in the cached match set (after filtering out the singular case where the inequality statement does not hold).</p><h3><strong>Attributes</strong></h3><p>It has been mentioned before that attribute expressions are outside the domain of the fundamental formal logic underpinning the query language, therefore they cannot be, in general, evaluated incrementally. However, all such attribute expressions are required to be deterministic, which enables the incremental evaluator to reuse previously computed values.</p><p>For example, consider the following pattern:</p><pre>pattern courseTuitionFee(c: Course, fee) = { Course.weight(c, weight); fee == eval(Math.max(450.0, 100.0 + weight * 40.0)); }</pre><p>When the value of the weight attribute is assigned for a new course, the tuition fee will be computed using a complex formula, and the match (the pair formed of the course and its newly computed fee) will be stored in the incremental cache. When the weight of the course is changed, the course-weight pair will be removed from the cache of the constituent elementary query; the fee that was once computed for course can be looked up, and the result removed from the match set cache.</p><p><strong>Acknowledgement: this research was supported by the European Union and the State of Hungary, co-financed by the European Social Fund in the framework of TÁMOP 4.2.4. A/-11-1-2012-0001 ‘National Excellence Program’.</strong></p><p> </p></div> | |
| <!-- <div class="author">Gábor Bergmann</div></div> --> | |
| </div> | |
| <div class="post"> | |
| <h2 class="title">Illogical, captain!</h2> | |
| <div class="date">July 29, 2013</div> | |
| <div class="body"><p>After the introductory blog posts on the importance of <a target="_blank" href="http://incquery.net/blog/2013/01/modeling-why-bother">modeling</a>, the concept of <a target="_blank" href="http://incquery.net/blog/2013/02/primer-model-queries">model queries</a> (with OCL and EMF-IncQuery) and<a target="_blank" href="http://incquery.net/blog/2013/04/change-or-die-model-queries-evolving-models">model evolution</a>, I demonstrated the <a target="_blank" href="http://incquery.net/blog/2013/04/relation-between-ocl-and-graph-patterns-pun-intended">translation of OCL expressions into the graph pattern language of EMF-IncQuery</a>, and outlined the general translation patterns in <a target="_blank" href="http://incquery.net/blog/2013/05/patterns-translating-patterns">two</a> consecutive <a target="_blank" href="http://incquery.net/blog/2013/06/patterns-translating-patterns-part-ii">posts</a>.</p><p>The current post will place the language of EMF-IncQuery in a broader context, show aspects where it its expressive power superior to certain other approaches, and where the current implementation needs to be extended.</p><h3><strong>Propositions over models</strong></h3><p>The basic, elementary statements (so-called <em>atomic formulas</em>) that can be formulated in EMF-IncQuery (or most other query approaches) are the following:</p><ul><li>a given model element is of a certain type,</li><li>there is a reference of a given type pointing from a given model element to another object, or to an attribute value,</li><li>two model elements are different / the same.</li></ul><p>There are examples to be found of all three kinds of elementary constraints in the following pattern:</p><pre>pattern translated(cl: SchoolClass, s1: Student, s2: Student) = { SchoolClass.students(cl, s2); s1 != s2; }</pre><p>The trick is that query definitions can compose such atomic statements using so-called Boolean / logical connectives:</p><ul><li>conjunction / "and": all of the following is true,</li><li>disjunction / "or": at least one of the following is true,</li><li>negation / "not": it is not true that...</li></ul><p>The previous sample pattern contained the conjunction of several pattern constraints - there is no special syntax to indicate the "and" connective. The following earlier example shows the usage of disjunction:</p><pre>pattern namesInClass(self: SchoolClass, x:EString) = { SchoolClass.students.name(self, x); } or { SchoolClass.homeroomTeacher.name(self, x); }</pre><p>While negation is exemplified by another one:</p><pre>pattern nonHomeroomTeacher(self: SchoolClass, x: Teacher) = { SchoolClass.courses.teacher(self, x); neg { SchoolClass.homeroomTeacher(self, x); } }</pre><p>These types of connectives can express a certain range of composite formulas over the elementary statements discussed before, which corresponds to a famous level of expressive power called <em>propositional calculus</em>.</p><p>The language of EMF-IncQuery supports non-recursive pattern composition as well. It is a convenient and concise way of structuring and reusing queries. By itself, composition does not increase the expressive power, since any pattern composition can be "flattened", i.e. the called pattern copied into the calling one. For instance, the following form of the <em>nameConflicts </em>query...</p><pre>pattern nameConflicts(clazz: SchoolClass, student1: Student, student2: Student, name: EString) = { find namedStudentOfClass(clazz, student1, name); find namedStudentOfClass(clazz, student2, name); student1 != student2; } pattern namedStudentOfClass(clazz, student, name) = { SchoolClass.students(clazz, student); Student.name(student, name); } </pre><p>... can be flattened into this single pattern:</p><pre>pattern nameConflicts(clazz: SchoolClass, student1: Student, student2: Student, name: EString) = { SchoolClass.students(clazz, student1); SchoolClass.students(clazz, student2); student1 != student2; Student.name(student1, name); Student.name(student2, name); }</pre><h3><strong>The power of first order logic</strong></h3><p>There are many useful queries, however, that cannot be expressed using these language elements only. The addition of quantifiers allows us to express properties relating to all model elements, as opposed to single ones, resulting in the more expressive logic calculus <em>first-order logic</em>:</p><ul><li>quantification "exists"/"for all": it is possible / not possible to substitute model elements for the given variables so that the following is true/false</li></ul><p>The language of EMF-IncQuery has two forms of quantification, the more important of the two is the ability to restrict the set of parameters of a pattern to a narrower set of variables. Take for example the following query :</p><pre>pattern nonHomeroomTeacher2(self: SchoolClass, x: Teacher) = { SchoolClass.courses.teacher(self, x); neg find homeroomTeacher(x); }</pre><pre>pattern homeroomTeacher(x: Teacher) = { SchoolClass.homeroomTeacher(y, x); }</pre><p>The pattern "<em>nonHomeroomTeacher2</em>" expresses that teacher <em>x</em> lectures school class <em>self</em> , and is not the homeroom teacher ofany classes (that's quantification!). Contrast with the pattern "<em>nonHomeroomTeacher</em>" shown earlier, which states that teacher <em>x</em>lectures school class <em>self</em> , and is not the homeroom teacher of the same class<em> self</em>.</p><p>The second form of quantification is basically just a notational shorthand with the same ultimate effect, without requiring us to modify the called pattern:</p><pre>pattern nonHomeroomTeacher2(self: SchoolClass, x: Teacher) = { SchoolClass.courses.teacher(self, x); neg find homeroomTeacher(x, _); } pattern homeroomTeacher(y:SchoolClass, x: Teacher) = { SchoolClass.homeroomTeacher(y, x); }</pre><p>Note there is a very wide range of formalisms, such as relational calculi, that have the expressiveness of first-order logic over a given set of atomic formulas - in this sense, the previousdly discussed elements of the graph pattern language are equivalent to many other languages used in computer science.</p><p>In particular, a large part of OCL - though not the entire language - can be expressed in first-order logic. The OCL to graph pattern translation shown in previous blog posts involved mostly, but not exclusively, these fragments of the language.</p><p>An interesting property of first-order logic is that even with all this expressive power, it is still manageable in some sense. For example, there are <a target="_blank" href="http://en.wikipedia.org/wiki/Automated_theorem_proving">automated theorem prover</a>s that can check e.g. whether it is possible for a given query (first-order formula) to have results in any instance model. Note that this is a much harder task than finding the results of a query over a specified instance model, which is what query engines do.</p><h3><strong>Theories for attributes</strong></h3><p>In addition to the model structure of objects and their relationships, the domains of various attributes may introduce relations themselves, such as "addition" and "greather than" in case of integers, or "concatenation" in case of character strings. Many of these do not admit a practical and complete first order axiomatization, meaning that the aforementioned automated theorem provers cannot prove all theorems involving e.g. numerical equation systems. Fortunately, model querying does not have to involve the most difficult cases of equation solving, and theorem provers can be extended by so-called <a target="_blank" href="http://en.wikipedia.org/wiki/Satisfiability_Modulo_Theories">theories</a> covering these domains.</p><p>As for EMF-IncQuery, statements about attributes can be made in check expressions:</p><pre>pattern importantCourse(c: Course) = { Course.weight(c, weight); check(weight > 8) }</pre><p>OCL expressions also support such Boolean-valued data checks, and more: the result of such a computation can be the result of an OCL expression. Currently, the EMF-IncQuery tool does not implement this capability, but the corresponding <em>eval</em> language element has already been designed and <a href="http://www.inf.mit.bme.hu/en/research/publications/graph-query-language-emf-models">published</a>:</p><pre>pattern courseTuitionFee(c: Course, fee) = { Course.weight(c, weight); fee == eval(weight * 50.0); }</pre><p>My colleagues Ágnes Barta, Ákos Horváth, Oszkár Semeráth, Zoltán Szatmári and Dániel Varró are currently investigating the translation of OCL into logic statements for which automated theorem proving can be applied. This is a follow-up of <a target="_blank" href="http://incquery.net/publications/dslvalid">previous research</a> on determining whether a given metamodel is satisfiable at all.</p><h3><strong>Beyond first order logic</strong></h3><p>EMF-IncQuery supports at least two additional features that are beyond the expressive power of first order logic, and cannot simply be added by "theories":</p><ul><li>Transitive closure</li><li>Aggregation / accumulation</li></ul><p>These have been covered in the preceding blog posts. Note that the current implementation of EMF-IncQuery provides partial support for the language proposal in both cases. Note also that OCL is more expressive in terms of collection accumulation.</p><p><strong>Acknowledgement: this research was realized in the frames of TÁMOP 4.2.4. A/1-11-1-2012-0001 „National Excellence Program – Elaborating and operating an inland student and researcher personal support system”. The project was subsidized by the European Union and co-financed by the European Social Fund.</strong></p></div> | |
| <!-- <div class="author">Gábor Bergmann</div></div> --> | |
| </div> | |
| <div class="post"> | |
| <h2 class="title">Release 0.7.0 available</h2> | |
| <div class="date">July 16, 2013</div> | |
| <div class="body"><p>The <a target="_blank" href="http://eclipse.org/incquery">EMF-IncQuery</a> project is happy to report that our first release with the version 0.7.0 is available now from the <a target="_blank" href="http://download.eclipse.org/incquery/updates/release">Eclipse.org download servers</a> or the <a target="_blank" href="https://marketplace.eclipse.org/node/450505">Eclipse Marketplace</a>.</p> <img src="http://static1.squarespace.com/static/5614faafe4b03f677dc3822b/56153118e4b022593e35e24b/56211606e4b015f422b016d0/1445008904591//img.png" alt=""/> <p>The most important highlights of this first release include:</p><ul><li>a high performance incremental graph search engine supporting the combination of graph patterns and side effect free Xbase expressions;</li><li>a user-friendly Java API (improved using end-user feedback);</li><li>full compatibility with Xtext 2.4 (available in Kepler);</li><li>complete migration to the Eclipse.org infrastructure.<p>An important note to our existing users: for a smooth upgrade, please make sure to read <a target="_blank" href="http://wiki.eclipse.org/EMFIncQuery/Releases/MigrateTo0.7">the migration guide</a> on the Eclipse wiki.</p></li></ul><p>In addition to the core features, there are two major novel components added to this release:</p><ol><li><a target="_blank" href="http://wiki.eclipse.org/EMFIncQuery/DeveloperDocumentation/EventDrivenVM">Event-driven virtual machine (EVM)</a>: a high-level rule-based system with a Java API to support high performance live and incremental model transformations;</li><li><a target="_blank" href="http://wiki.eclipse.org/EMFIncQuery/UserDocumentation/IncQuery_Viewers">IncQuery Viewers</a>: a framework to create query-driven live user interfaces by supporting JFace and Zest Graph Viewers. Stay tuned for an upcoming blog post on these topics.</li></ol><p>For a complete list of fixed issues see <a target="_blank" href="https://bugs.eclipse.org/bugs/buglist.cgi?list_id=6116573&query_format=advanced&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&version=0.7.x&product=Incquery">Bugzilla</a>. We encourage everyone to ask questions in the <a target="_blank" href="http://www.eclipse.org/forums/index.php/f/255/">Eclipse Forums</a> (none will be left unanwered) and make sure to follow our blog at <a target="_blank" href="http://incquery.net/">http://incquery.net</a>!</p></div> | |
| <!-- <div class="author">Zoltán Ujhelyi</div></div> --> | |
| </div> | |
| <div class="post"> | |
| <h2 class="title">Patterns of translating to patterns (part II)</h2> | |
| <div class="date">June 24, 2013</div> | |
| <div class="body"><p>After the introductory blog posts on the importance of <a target="_blank" href="http://incquery.net/blog/2013/01/modeling-why-bother">modeling</a>, the concept of <a target="_blank" href="http://incquery.net/blog/2013/02/primer-model-queries">model queries</a> (with OCL and EMF-IncQuery) and<a target="_blank" href="http://incquery.net/blog/2013/04/change-or-die-model-queries-evolving-models">model evolution</a>, I demonstrated the <a target="_blank" href="http://incquery.net/blog/2013/04/relation-between-ocl-and-graph-patterns-pun-intended">translation of OCL expressions into graph patterns</a>. Continuing from <a target="_blank" href="http://incquery.net/blog/2013/05/patterns-translating-patterns">last time</a>, I present patterns that can be applied to translate OCL expressions to the query language of EMF-IncQuery.</p><p>From the collection operations, we have previously covered <em>select()</em>, <em>reject()</em>, and <em>collect()</em>. Let us now see another set of the collection operations included in the OCL Standard Library, as defined by the OCL standard. OCL supports the usual binary set operations such as union, intersection, set difference, symmetric difference, as well as equality and the inclusion or exclusion of elements. Their translation to graph patterns is very straightforward.</p><h3><strong>Union and inclusion, difference and exclusion</strong></h3><p>Union and inclusion can be handled by the 'or' language element of EMF-IncQuery.</p><pre>some_set->union(other_set) </pre><p>and</p><pre>some_set->including(other_element) </pre><p>will both translate to graph patterns like this:</p><pre>{ TRANSLATED<some_set>; } or { TRANSLATED<other_set>; }</pre><p>Let us apply this on the following OCL definition:</p><pre>context SchoolClass def: namesInClass(): Set(EString) = students.name->including(homeroomTeacher.name)</pre><p>The result of the translation will be:</p><pre>pattern namesInClass(self: SchoolClass, x:EString) = { SchoolClass.students.name(self, x); } or { SchoolClass.homeroomTeacher.name(self, x); } </pre><p>Difference and exclusion, on the other hand, require negative pattern composition. The OCL definition below:</p><pre>context SchoolClass def: nonHomeroomTeacher(): Set(Teacher) = courses.teacher->excluding(homeroomTeacher)</pre><p>will translate to the following (shown in simplified syntax, support for this syntactic sugar not implemented yet):</p><pre>pattern nonHomeroomTeacher(self: SchoolClass, x: Teacher) = { SchoolClass.courses.teacher(self, x); neg { SchoolClass.homeroomTeacher(self, x); } }</pre><h3><strong>Intersection, product, emptyness and other operations</strong></h3><p>Cartesian product is very straightforward:</p><pre>some_set->product(other_set) </pre><p>simply translates to:</p><p> TRANSLATED<some_set>(x);<br /> TRANSLATED<other_set>(y);</p><p>as constraints in a graph pattern body are conjunctive. For the very same reason, intersection is also handled the same way:</p><pre>some_set->intersect(other_set) </pre><p>will translate to:</p><p> TRANSLATED<some_set>(x);<br /> TRANSLATED<other_set>(x);</p><p>Note that the only difference is that the two translated constraints are expressed on the same variables in this case.</p><p>Emptyness checking can be simply achieved by excluding the pattern variables from the pattern parameter list:</p><pre>context SchoolClass def: hasNameConflicts(): Boolean = self->nameConflicts()->notEmpty()</pre><p>becomes</p><pre>pattern hasNameConflicts(self: SchoolClass /* the rest are not parameters */) = { find nameConflicts(self, _anyStudent1, _anyStudent2, _anyName); } </pre><p>Derived set operations such as symmetric difference, (in)equality, subset / membership checks can be expressed using the previously discussed patterns of translation.</p><h3><strong>Accumulating ("reduce" / "fold" / "aggregate") operators</strong></h3><p>Aggregation operations condense a whole set into a single value. This includes <em>size()</em>, which counts the elements of a set, as well as the self-explanatory <em>sum()</em>, <em>min()</em> and <em>max()</em>. These operations can be mapped to aggregation operations in EMF-IncQuery (currenlty only counting is implemented). For example:</p><pre>self.courses->sum(weight)</pre><p>would be equivalent with the following constraint:</p><pre>sum(x) find helper_pattern(self, x);</pre><p>where the helper pattern is defined as follows:</p><pre>pattern helper_pattern(self: ScholClass, x: EInt) = { SchoolClass.courses(self, y); // translated from the set expression Course.weight(y,x); // translated from the summed up expression }</pre><p>More generally, one could argue that <em>select()</em>, <em>collect(),</em> etc., as discussed in the previous post, also belong in this family of operations. The most general case is <em>iterate()</em>, however, it cannot be always expressed by graph patterns, as it is very heavily dependent on ordering.</p><p>One final related operation is <em>closure()</em>, the iterated-to-fixpoint version of <em>collect()</em>, commonly used to compute transitive closures. The transitive closure language element of EMF-IncQuery can be used in this case as a translation.</p><h3><strong>Further collection operations</strong></h3><p>Collections of collections can be flattened to a single collection of elements using OCL's <em>flatten()</em>. In graph patterns, this happens automatically, so no corresponding code has to be generated. On the contrary, "<a target="_blank" href="http://incquery.net/blog/2013/04/relation-between-ocl-and-graph-patterns-pun-intended">relationification</a>" and the graph pattern translation might not be possible at all unless such multi-level OCL collections are flattened.</p><p>Speaking of which, mathematical relations and thus graph patterns have inherent set semantics. OCL collections (<em>Bag, OrderedSet, List</em>), created e.g. by applying the operation <em>sortedBy()</em>, are therefore untranslatable with the exception of<em> Set</em>s. Although in some cases, it is enough to consider the support set (i.e. the set of all contained elements, regardless of ordering and multiplicity) of such collection data structures, as it may be enough to evaluate a large portion of operations. For instance,</p><pre>some_list->select(those_with_some_property)->containsAll(some_other_elements) </pre><p>is equivalent to</p><pre>some_list->asSet()->select(those_with_some_property)->containsAll(some_other_elements) </pre><p>which is translatable to graph pattern; this simplification is in fact crucial to the applicability of the whole approach, since multi-valued references in EMF are actually ordered sets. As counter-examples, there are collection operations such as <em>count()</em>, which is the number of times an element is included in the collection, as well as e.g. equality; these have significantly different semantics in the various collection types, and are therefore translateable in case of true OCL <em>Set</em>s only.</p><p><strong>Acknowledgement: this research was realized in the frames of TÁMOP 4.2.4. A/1-11-1-2012-0001 „National Excellence Program – Elaborating and operating an inland student and researcher personal support system”. The project was subsidized by the European Union and co-financed by the European Social Fund.</strong></p></div> | |
| <!-- <div class="author">Gábor Bergmann</div></div> --> | |
| </div> | |
| <div class="post"> | |
| <h2 class="title">Patterns of translating to patterns</h2> | |
| <div class="date">May 30, 2013</div> | |
| <div class="body"><p>My previous introductory blog posts talked about the importance of <a target="_blank" href="http://incquery.net/blog/2013/01/modeling-why-bother">modeling</a>, the concept of <a target="_blank" href="http://incquery.net/blog/2013/02/primer-model-queries">model queries</a> (with OCL and EMF-IncQuery) and <a target="_blank" href="http://incquery.net/blog/2013/04/change-or-die-model-queries-evolving-models">model evolution</a>. Last time, I demonstrated the <a target="_blank" href="http://incquery.net/blog/2013/04/relation-between-ocl-and-graph-patterns-pun-intended">translation of OCL expressions into graph patterns</a>. Now it is time to discuss <em>how</em> the various OCL constructs can be mapped to graph patterns of EMF-IncQuery.</p><h3>Navigation</h3><p>Let's start with the simplest of OCL language elements: navigation.</p><pre>cl.students</pre><p>Last time we discussed interpreting OCL expressions as relations. The above OCL expression correspons to a binary relation between the value of "cl" (which can be statically inferred to be of type SchoolClass) and another variable (let's say "x") created by the relationification (ugh, I made this ugly word up on the spot), which will be assigned to the various students belonging to "cl". Thus the graph pattern equivalent would look like this:</p><pre>pattern translated(cl: SchoolClass, x: Student) = { SchoolClass.students(cl, x); }</pre><p>And we're done... for now. Keep in mind that more complex constructs will add additional elements to the pattern body, and possibly maipulate the set of parameters, as seen below.</p><p>Note that the same translation method actually goes for attribute access as well:</p><pre>s1.name</pre><p>translates to:</p><pre>pattern translated(s1: Student, y: EString) = { Student.name(s1, y); }</pre><h3>Selection, rejection, collection, (in)equality</h3><p>Last time the result of navigation was processed further by a selection expression - it is a type of OCL function that can be applied to a collection to filter its contents. Recalling the OCL snippet from last time:</p><pre>cl.students->select(s2 | s1 <> s2)</pre><p>we can see that it generalizes to the following form:</p><pre>some_collection_expression->select(x | boolean_expression_involving_x_and_possibly_other_variables(x,..) )</pre><p>This can be generally translated as a graph pattern body like this:</p><pre>pattern translated(...,x) = { TRANSLATED<some_collection_expression>(...,x); TRANSLATED<boolean_expression_involving_x_and_possibly_other_variables>(x,...); } </pre><p>Recalling last months's solution, the above example translates to:</p><pre>pattern translated(cl: SchoolClass, x: Student, s2: Student) = { SchoolClass.students(cl, x); x != s2; }</pre><p>...where an attentive reader can notice that "x != s2" is the straightforward translation of the inequality check "x <> s2", while e.g. "x = s2" would be translated as "x == s2". Which brings as to an alternative way to specifíing an equivalent OCL expression:</p><pre>cl.students->reject(s2 | s1 = s2)</pre><p>And since this involves rejection instead of selection, the corresponding graph pattern must use the negated criterion. The translator is either smart enough to recognize that the negation of equality is simple inequality, thus yielding the translation given above; or else resorting to the negation feature in the graph pattern language:</p><pre>pattern translated(cl: SchoolClass, x: Student, s2: Student) = { SchoolClass.students(cl, x); neg find translated_2(x,s2); } pattern translated_2(x: Student, y: Student) = { x == y; }</pre><p>Finally, OCL's collect() function is very similar to select(), however the given expression does not have to be boolean-valued, and the returned collection will consist of all such computed values (instead of the original elements of collection on which select() is applied on). This means that the graph pattern translation will look pretty much the same.</p><h3>Boolean operations</h3><p>Let's see the following expression:</p><pre>self.students->select(s2 | s2.name = s1.name and s1 <> s2)</pre><p>According to the previous rule, this translates to:</p><pre>pattern translated(self:SchoolClass, s1:Student, s2:Student) = { SchoolClass.students(self,s2); TRANSLATED<s2.name = s1.name and s1 <> s2>(s1,s2); }</pre><p>Along the logical connective "and", the latter constraint can be split into two conjunctive constraints:</p><pre>pattern translated(self:SchoolClass, s1:Student, s2:Student) = { SchoolClass.students(self,s2); TRANSLATED<s2.name = s1.name>(s1,s2); TRANSLATED<s1 <> s2>(s1,s2); }</pre><p>We already now how to transcribe both new constraints. Note that the first one introduces a local variables "y" and "z" that are not among pattern prameters:</p><pre>pattern translated(self:SchoolClass, s1:Student, s2:Student) = { SchoolClass.students(self,s2); Student.name(s1,y); Student.name(s2,z); y == z; s1 != s2; }</pre><p>Other logical connectives include "or", which can be translated to disjunctive pattern bodies ("or" keyword in EMF-IncQuery); "not" which is negation (handled similarly to reject(), as seen above); and "implies" where "a implies b" is equivalent to "not a or b".</p><h3>Putting it all together</h3><p>Let's go back to our first ever <a target="_blank" href="http://incquery.net/blog/2013/02/primer-model-queries">OCL expression from February</a>:</p><pre>context SchoolClass def: nameConflicts(): Set(TupleType(student1: Student, student2:Student, name:EString)) = self.students->collect(s1 | self.students->select(s2 | s2.name = s1.name and s1 <> s2)-> collect(s2 | Tuple{student1 = s1, student2 = s2, name = s1.name}))</pre><p>The named OCL expression nameConflicts corresponds to a relation between the SchoolClass "self", Student instances"student1", "student2", and data value "name" of type EString. This determines the pattern parameters, and the rest could be translated according to the patterns of mapping introduced earlier. See the first step, the translation of the collect() function application:</p><pre>pattern nameConflicts(self: SchoolClass, student1: Student, student2:Student, name:EString) = { TRANSLATED<self.students>(self,s1); TRANSLATED<self.students->select(s2 | s2.name = s1.name and s1 <> s2)->collect(s2 | Tuple{s1 = s1, s2 = s2, name = s1.name})>(self,students1,students2,name) } </pre><p>Applying the translation rule for navigation and collection:</p><pre>pattern nameConflicts(self: SchoolClass, student1: Student, student2:Student, name:EString) = { SchoolClass.students(self,s1); TRANSLATED<self.students->select(s2 | s2.name = s1.name and s1 <> s2)>(self,s1,s2); TRANSLATED<Tuple{s1 = s1, s2 = s2, name = s1.name})>(self,students1,students2,name); }</pre><p>Applying an already familiar transcription:</p><pre>pattern nameConflicts(self: SchoolClass, student1: Student, student2:Student, name:EString) = { SchoolClass.students(self,s1); SchoolClass.students(self,s2); Student.name(s1,y); Student.name(s2,z); y == z; s1 != s2; TRANSLATED<Tuple{s1 = s1, s2 = s2, name = s1.name})>(self,students1,students2,name); }</pre><p>For the last time, we use the navigation rule to (somewhat redundantly) factor out the attribute access:</p><pre>pattern nameConflicts(self: SchoolClass, student1: Student, student2:Student, name:EString) = { SchoolClass.students(self,s1); SchoolClass.students(self,s2); Student.name(s1,y); Student.name(s2,z); y == z; s1 != s2; Student.name(s1,w); TRANSLATED<Tuple{s1 = s1, s2 = s2, name = w})>(self,students1,students2,name); }</pre><p>And we're done, we just have to rename internal variables to be consistent with the parameter names:</p><pre>pattern nameConflicts(self: SchoolClass, student1: Student, student2:Student, name:EString) = { SchoolClass.students(self,student1); SchoolClass.students(self,student2); Student.name(student1,y); Student.name(student2,z); y == z; student1 != student2; Student.name(student1,name); }</pre><p>Following these simple rules, we have arrived at a complete graph pattern transcription of the original OCL expression. And it's only a bit less concise than its original, manually written equivalent:</p><pre>pattern nameConflicts(clazz: SchoolClass, student1: Student, student2: Student, name: EString) = { SchoolClass.students(clazz, student1); SchoolClass.students(clazz, student2); student1 != student2; Student.name(student1, name); Student.name(student2, name); }</pre><p>Nice, isn't it?</p><p><strong>Acknowledgement: this research was realized in the frames of TÁMOP 4.2.4. A/1-11-1-2012-0001 „National Excellence Program – Elaborating and operating an inland student and researcher personal support system”. The project was subsidized by the European Union and co-financed by the European Social Fund.</strong></p></div> | |
| <!-- <div class="author">Gábor Bergmann</div></div> --> | |
| </div> | |
| <div class="post"> | |
| <h2 class="title">EMF-IncQuery 0.7M3 published</h2> | |
| <div class="date">May 23, 2013</div> | |
| <div class="body"><p>The EMF-IncQuery project is happy to report that we have reached our third <a target="_blank" href="https://bugs.eclipse.org/bugs/buglist.cgi?list_id=4807922&classification=Modeling&query_format=advanced&target_milestone=M3&product=Incquery">milestone</a>, with a special focus on finalizing the API in preparation for the 0.7.0 release in the summer. Important note: please read the <a target="_blank" href="http://wiki.eclipse.org/EMFIncQuery/Releases/MigrateTo0.7#0.7-M3">migration guide</a> to ensure a smooth upgrade path for existing EMF-IncQuery projects. We recommend to update your EMF-IncQuery installation from the <a target="_blank" href="http://marketplace.eclipse.org/node/450505">Marketplace</a>, or using the <a target="_blank" href="http://eclipse.org/incquery/download.php">update sites</a>.</p></div> | |
| <!-- <div class="author">István Ráth</div></div> --> | |
| </div> | |
| <div class="post"> | |
| <h2 class="title">The relation between OCL and graph patterns (pun intended)</h2> | |
| <div class="date">April 29, 2013</div> | |
| <div class="body"><p>My previous introductory blog posts talked about the importance of <a target="_blank" href="http://incquery.net/blog/2013/01/modeling-why-bother">modeling</a>, the concept of <a target="_blank" href="http://incquery.net/blog/2013/02/primer-model-queries">model queries</a> (with OCL and EMF-IncQuery) and <a target="_blank" href="http://incquery.net/blog/2013/04/change-or-die-model-queries-evolving-models">model evolution</a>. Now it is time to give a glimpse into my research: translating OCL expressions to graph patterns, so that incremental evaluation techniques (see EMF-IncQuery) developed for graph patterns can be applied to queries formulated in OCL.</p><h3><strong>Example model</strong></h3><p>Similarly to the previous posts starting from <a target="_blank" href="http://incquery.net/blog/2013/02/primer-model-queries">this one</a>, I will use the <a target="_blank" href="http://incquery.net/incquery/examples/school">school example</a> as a toy domain to formulate my examples in. My very simple example model will consist of one school with two school years, three school classes and five students like this:</p><ul><li>school: Gunnerkrigg Court<ul><li>year: 7<ul><li>class: Q<ul><li>student (name="Antimony")</li><li>student (name="Katerina")</li><li>student (name="Jack")</li></ul></li><li>class: C</li><li>student (name="Zimmy")</li></ul></li><li>year: 10<ul><li>class: T<ul><li>student (name="Parsley")</li></ul></li></ul></li></ul></li></ul><p> Let's ignore courses and teachers for now.</p><h3><strong>Anatomy of an OCL expression</strong></h3><p>Let's see an OCL expression that is to be evaluated on this model:</p><pre>cl.students->select(s2 | s1 <> s2)</pre><p>This is an almost verbatim part of the example OCL query from before, and means that from all students of "cl", we select all except "s1".</p><p>In order to be able to evaluate this expression, we need the value of OCL variable "cl". A closer inspection reveals that we need the value of "s1" as well. However, no value has to be assigned to the variable name "s2"; it is not a free variable, but rather introduced within the expression. Therefore the input variables of this expression will be "cl" and "s1". From the context of the expression, it is known that "cl" will be of type SchoolClass, while "s1" will be a Student.</p><p>When we evaluate the expression, the result is a set of things (students in this case), one for each value of "s2" that fits the selection criteria. The fact that the result will be a set of Students is discernible from the type of input variables (dependant on the context, as indicated above) and the OCL operations performed on these variables.</p><p>Altogether, we can say that this OCL expression is a function that maps input variables "cl" and "s1" to a set of Students. Let's now see the evaluation result for each possible combination of input values from the above instance model:</p><p><table border="1" cellpadding="1" cellspacing="1" height="221" width="525"> <tbody> <tr> <td style="width: 119px;"> <pre><strong>cl : SchoolClass</strong></pre></td> <td style="width: 186px;"> <pre><strong>s1 : Student</strong></pre></td> <td style="width: 75px;"> <strong>Result : Set(Student)</strong></td> </tr> <tr> <td colspan="1" rowspan="4" style="width: 119px;"> 7Q</td> <td style="width: 186px;"> Antimony</td> <td style="width: 75px;"> {Katerina,Jack}</td> </tr> <tr> <td style="width: 186px;"> Katerina</td> <td style="width: 75px;"> {Antimony,Jack}</td> </tr> <tr> <td style="width: 186px;"> Jack</td> <td style="width: 75px;"> {Antimony,Katerina}</td> </tr> <tr> <td style="width: 186px;"> Zimmy or Parsley</td> <td style="width: 75px;"> {Antimony,Katerina,Jack}</td> </tr> <tr> <td colspan="1" rowspan="2" style="width: 119px;"> 7C</td> <td style="width: 186px;"> Zimmy</td> <td style="width: 75px;"> {}</td> </tr> <tr> <td style="width: 186px;"> Antimony, Katerina, Jack or Parsley</td> <td style="width: 75px;"> {Zimmy}</td> </tr> <tr> <td colspan="1" rowspan="2" style="width: 119px;"> 10T</td> <td style="width: 186px;"> Parsley</td> <td style="width: 75px;"> {}</td> </tr> <tr> <td style="width: 186px;"> Antimony, Katerina, Jack or Zimmy</td> <td style="width: 75px;"> {Parsley}</td> </tr> </tbody> </table> </p><h3><strong>Relationify!</strong></h3><p>Graph patterns are fundamentally different from OCL expressions. While variables in graph patterns can refer to model elements or attribute values, they are incapable of representing sets, sequences or other structures. On the other hand, graph patterns can have several matches, while an OCL expression has a single result only (though it can be e.g. a set of elements). A graph pattern therefore defines a mathematical relation (see e.g. relational algebra) between its variables.</p><p>The key to translating OCL expressions to graph patterns is interpreting the expression as a mathematical relation between its input variables. Let's see what combination of input values and result students there are in the results of the expression! This involves "flattening" each element "s2" of the result set to its separate line:</p><p><table border="1" cellpadding="1" cellspacing="1" style="width: 396px;"> <tbody> <tr> <td style="width: 119px;"> <pre><strong>cl : SchoolClass</strong></pre></td> <td style="width: 101px;"> <pre><strong>s1 : Student</strong></pre></td> <td style="width: 158px;"> <strong>s2 : Student</strong></td> </tr> <tr> <td colspan="1" rowspan="12" style="width: 119px;"> 7Q</td> <td colspan="1" rowspan="2" style="width: 101px;"> Antimony</td> <td style="width: 158px;"> Katerina</td> </tr> <tr> <td style="width: 158px;"> Jack</td> </tr> <tr> <td colspan="1" rowspan="2" style="width: 101px;"> Katerina</td> <td style="width: 158px;"> Antimony</td> </tr> <tr> <td style="width: 158px;"> Jack</td> </tr> <tr> <td colspan="1" rowspan="2" style="width: 101px;"> Jack</td> <td style="width: 158px;"> Antimony</td> </tr> <tr> <td style="width: 158px;"> Katerina</td> </tr> <tr> <td colspan="1" rowspan="3" style="width: 101px;"> Zimmy</td> <td style="width: 158px;"> Antimony</td> </tr> <tr> <td style="width: 158px;"> Katerina</td> </tr> <tr> <td style="width: 158px;"> Jack</td> </tr> <tr> <td colspan="1" rowspan="3" style="width: 101px;"> Parsley</td> <td style="width: 158px;"> Antimony</td> </tr> <tr> <td style="width: 158px;"> Katerina</td> </tr> <tr> <td style="width: 158px;"> Jack</td> </tr> <tr> <td colspan="1" rowspan="4" style="width: 119px;"> 7C</td> <td style="width: 101px;"> Antimony</td> <td colspan="1" rowspan="4" style="width: 158px;"> Zimmy</td> </tr> <tr> <td style="width: 101px;"> Katerina</td> </tr> <tr> <td style="width: 101px;"> Jack</td> </tr> <tr> <td style="width: 101px;"> Parsley</td> </tr> <tr> <td colspan="1" rowspan="4" style="width: 119px;"> 10T</td> <td style="width: 101px;"> Antimony</td> <td colspan="1" rowspan="4" style="width: 158px;"> Parsley</td> </tr> <tr> <td style="width: 101px;"> Katerina</td> </tr> <tr> <td style="width: 101px;"> Jack</td> </tr> <tr> <td style="width: 101px;"> Zimmy</td> </tr> </tbody> </table></p><p>Note however, that it is not possible to preserve the ordering of an OCL sequence in such an interpretation; graph patterns and mathematical relations are fundamentally unordered. Therefore there are some properties that are expressible in OCL but not using graph patterns.</p><h3><strong>Heureka!</strong></h3><p>Now all that's left is constructing a graph pattern whose match set will be the relation above.</p><p>Obviously, the parameter variables of the graph pattern will be cl: SchoolClass, s1: Student, s2: Student. The pattern needs pattern constraints as well, otherwise all combinations of students and classes would appera in the match set / relation. The pattern constraints are chosen such that they reflect the relationships encoded in the OCL expression, namely that "s2" can be chosen from the students of "cl", and that the two students have to be different.</p><pre>pattern translated(cl: SchoolClass, s1: Student, s2: Student) = { SchoolClass.students(cl, s2); s1 != s2; }</pre><p>And that's where I call it a day. Next time, we will see <em>how</em> one should construct such a graph pattern.</p><p><strong>Acknowledgement: this research was realized in the frames of TÁMOP 4.2.4. A/1-11-1-2012-0001 „National Excellence Program – Elaborating and operating an inland student and researcher personal support system”. The project was subsidized by the European Union and co-financed by the European Social Fund.</strong></p></div> | |
| <!-- <div class="author">Gábor Bergmann</div></div> --> | |
| </div> | |
| <div class="post"> | |
| <h2 class="title">Change or die: model queries on evolving models</h2> | |
| <div class="date">April 2, 2013</div> | |
| <div class="body"><h3><strong>...the only constant</strong></h3><p>Modeling and model queries were discussed in <a target="_blank" href="https://incquery.net/category/tags/jedlik">my previous blog posts</a>. Now it is time to turn our attentions towards a great challenge: that of evolving models.</p><p>In a model-driven engineering process, models usually do not exist as static, immutable truths, but are rather undergoing constant evolution; implying that any previously conducted model analysis must be re-evaluated, and the impact can extend to other models derived from this one as well. This evolution may happen due to requirement changes (potentially as late as years after the delivery of the system), or on a shorter time-scale the creation of ever newer model versions according to iterative development methodologies, or simply the consequence of fixing problems detected by model validation. In fact, model editing actually consist of a sequence of small, atomic manipulation operations; this can also be regarded as the continuous evolution of a model, during which e.g. immediate feedback of model validation would be useful. </p><h3><strong>Spare any change? The cost of evolution</strong></h3><p>Repeatedly processing a (large scale) model after each small change can lead to significant performance issues. It can be more advantageous to apply <em>incremental</em> evaluation techniques, taking into account the evolving nature of the model. In certain use cases (e.g. well-formedness checks) incremental queries have a great performance advantage<a target="_blank" href="https://incquery.net/performance#Papers_and_reports">[see benchmarks]</a>.</p><p><em>Source incrementality </em>is the property of model processing that it only re-evaluates the changed parts of the source model. One of the central topics of my thesis and my current research is efficient evaluation of queries against evolving models through providing source incrementality.</p><p><em>Target incrementality</em>, on the other hand, means that when an evolving model is processed or transformed, only the necessary parts of the result (which is a potentially large model) are modified, there is no need to recreate the new results from scratch. The latter property, beyond direct gains in performance, has the benefit that connections, references between the result model and other external models are left intact and need not be recreated. Moreover, if the target model contains pieces of information (such as platform-specific design decisions in a PSM mapped from PIM) that do not stem from the source model, then the lack of target incrementality would lead to outright information loss.</p><p>After model evolution, the traditional approach restores the logical correspondence between source and target models by re-executing the transformation (which is efficient in case of source and target incrementality). A live transformation, however, is continuously active, immediately reacting to changes of the source model by keeping the target model in synch. In this case source and target incrementality is strongly recommended. </p><h3><strong>Incremental model queries: an example</strong></h3><p>In case of model queries, the challenge is source incrementality. Let's see how <a target="_blank" href="http://incquery.net/blog/2013/02/primer-model-queries">the example from the previous post (multiple students with the same name in the same class) </a>can be evaluated incrementally. First, we need to evaluate the query on the model once; this can be done as usual. The query results will be stored, so that they can be cheaply retrieved again. So far, so good. The interesting part comes when we change the model.</p><p>What happens if a student is transferred from a class to a different one? We have to check if there are any students in the new class sharing their name with the transfer student; if so, they are reported as new name conflicts in the query result. But we are not ready yet: it is possible that the old class already had some students with the same name; these name conflicts would no longer hold after the transfer, so these obsolete conflicts have to be removed from the query results.</p><p>What happens if a student changes her name, such as due to marriage? We have to add any new conflicts with students in the same class sharing the new name. Analogously, conflicts with student in the class who shared the old name will no longer hold.</p><p>What happens if a new homeroom teacher is assigned to supervise the class? Fortunately, nothing; this kind of change has no impact on our query results.</p><h3><strong>Incremental model queries over EMF</strong></h3><p>The previous short example was enough to demonstrate that providing incremental maintenance for query results is a time-consuming and error-prone task to implement. Fortunately, if one uses a declarative query specification, it is possible, at least in theory, to lift this burden off the shoulders of the developer.</p><p>One of the key selling points of EMF-IncQuery (see <a target="_blank" href="http://incquery.net/blog/2013/02/primer-model-queries">previous post</a>) is that it provides source incrementality out-of-the-box, in a completely automatic way, for queries over EMF models formulated using graph patterns.</p><p>On the other hand, the industrially well-known formalism of OCL, by default, supports batch evaluation only. There are some solutions<a target="_blank" href="http://jordicabot.com/research/IncrementalOCL/">[Cabot]</a>, however, that aim to provide incremental evaluation. The goal of my research is to provide such a solution, where a large subset of OCL is translated into graph patterns, to be evaluated incrementally by EMF-IncQuery.</p><p><strong>Acknowledgement: this research was realized in the frames of TÁMOP 4.2.4. A/1-11-1-2012-0001 „National Excellence Program – Elaborating and operating an inland student and researcher personal support system”. The project was subsidized by the European Union and co-financed by the European Social Fund.</strong></p></div> | |
| <!-- <div class="author">Gábor Bergmann</div></div> --> | |
| </div> | |
| <div class="post"> | |
| <h2 class="title">EMF-IncQuery presentation for Itemis</h2> | |
| <div class="date">March 19, 2013</div> | |
| <div class="body"><p>EMF-IncQuery has been presented to <a target="_blank" href="http://www.itemis.de/">Itemis</a> developers by Tamás Szabó, our former student and freshly enrolled software engineer for Itemis in Stuttgart. The slides are available on <a target="_blank" href="http://www.slideshare.net/IstvanRath/inc-query-itemis2013-17325572">SlideShare</a>, and the example projects can be downloaded from <a target="_blank" href="https://github.com/ujhelyiz/EMF-IncQuery-Examples/tree/master/stochsim">GitHub</a>.</p></div> | |
| <!-- <div class="author">István Ráth</div></div> --> | |
| </div> | |
| <div class="post"> | |
| <h2 class="title">EMF-IncQuery 0.7M2 published</h2> | |
| <div class="date">March 8, 2013</div> | |
| <div class="body"><p>We have reached our second <a target="_blank" href="https://bugs.eclipse.org/bugs/buglist.cgi?list_id=4807922&classification=Modeling&query_format=advanced&target_milestone=M2&product=Incquery">milestone</a>, with a special focus on stability and bug fixes. We recommend to update your EMF-IncQuery installation from the <a target="_blank" href="http://marketplace.eclipse.org/node/450505">Marketplace</a>, or using the <a target="_blank" href="http://eclipse.org/incquery/download.php">update sites</a>.</p></div> | |
| <!-- <div class="author">István Ráth</div></div> --> | |
| </div> | |
| <div class="post"> | |
| <h2 class="title">A primer to model queries</h2> | |
| <div class="date">February 25, 2013</div> | |
| <div class="body"><h3><strong>Models are not black holes</strong></h3><p>The principle of <em>model-driven engineering </em>(MDE) was discussed in <a target="_blank" href="http://incquery.net/blog/2013/01/modeling-why-bother">my previous blog post</a>. When one reads about MDE, there is a lot of talk about creating models, as if all the engineers ever do was creating models using shiny diagram editors; like "the focus of the engineering approach is to build models of the system under design, first on a high level of abstraction, then gradually approaching platform-specific design decisions", and so on. One could even start to believe that models are some kind of information theory black hole: information is only put in, but never comes out. Well, this is not the case.</p><p>The purpose of models is not just to archive knowledge and ideas, but to contain, structure, organize, preserve and communicate them, to make them available for use in the engineering workflow. The information within models is put there exactly because it will be used later. Processing models is as much a key part of MDE as the act of creating models. In fact, the aforementioned shiny diagram editors typically also rely on extraction of information from models somewhere under the hood. A good example of this would be such an editor offering options to fill in some data somewhere; for instance the choices available for the type of a field in a class model of an object-oriented system are gathered by processing the same class model.</p><h3><strong>Why else do we need to process models?</strong></h3><p>Apart from basic editing support, model processing is relevant in a number of scenarios. Most importantly, it is vital in supporting the analysis of models. The most straightforward kind of analysis is <em>static analysis</em>, which may range from simple cases such as finding missing elements (e.g. unspecified carrier bus for a signal in embedded system design) to more complex cases such as detecting subtle contradictions (e.g. scheduling conflict among signals of the same bus).</p><p>There is also <em>dynamic analysis</em>, which emulates a behavioural model to examine its trajectories (possible course of events). Use cases include testing, performance and reliability simulation, and model checking of safety-critical systems. A discrete-time dynamic analysis will, at each visited state of the system, determine potential evolution by processing the model and identifying state transitions that are currently enabled.</p><p>In case of MDE, one should not forget that models are very often derived from other existing models. <em>Model transformation</em> is the automation of these steps, the task of processing a model to create, extend or change models based on the information contained within it. As a special case, <em>code generation</em> or <em>model-to-text (M2T) transformation</em> applies the concept to synthesizing textual targets, typically program code.</p><h3><strong>What are model queries?</strong></h3><p>In all of the cases discussed above, the processing of models is performed by the modeling / model analysis / model transformation tools . These are software programs that were developed in an arbitrary programming language to form a modeling environment specific to the modeling domain and engineering workflows; see the previous discussion on domain-specific modeling. Complex model processing, however, requires error-prone and labour-intensive tool development for each DSML, and the resulting tooling might not conform to performance best practices.</p><p>The solution to this family of problems is well-known in the software industry, particularly in the field of databases. Instead of implementing the entire task of model processing in a general-purpose programming language, industry prefers the separation of the <em>declarative query specification</em> (concisely and intuitively expressing the model processing intent of the tool developer) from the<em>query evaluator engine (</em>specialized for efficiently processing models of a DSM technology such as EMF to obtain the correct query results).</p><h3><strong>How does one issue model queries?</strong></h3><p>Queries can be issued by writing a query specification in a dedicated <em>query language</em>, and passing it to an evaluator engine along with the instance model to be processed.</p> <img src="http://static1.squarespace.com/static/5614faafe4b03f677dc3822b/56153118e4b022593e35e24b/5620fab9e4b0dc6edcbb1d6d/1445001917285//img.png" alt=""/> <p>For instance, in the toy example EMF-based DSM language of <a target="_blank" href="http://incquery.net/incquery/examples/school">this tutorial page</a>, one can record the students, classes and teachers of schools. Let's say we want to know whether there are multiple students with the same name in the same class; we would presumably want to reassign some of these students to parallel classes in order to simplify bookkeeping. If the query engine was a human being capable of understanding plain English, a query could be "for this particular SchoolClass, find all pairs of Students among the students of the SchoolClass, for which the two Students share their name". Now we only need a formal language for the precise specification of this query, and a query engine that understands this language.</p><p>Below, we will briefly discuss how one can deal with this problem in two industrial model query languages.</p><h3><strong>OCL</strong></h3><p>The Object Constraint Language<a target="_blank" href="http://www.omg.org/spec/OCL/2.3.1/">[OMG Spec]</a>, abbrev. OCL, is a well-known query formalism for MOF, EMF and many other modeling technologies. The following code is an OCL formalization of the above query:</p><pre>context SchoolClass def: nameConflicts(): Set(TupleType(student1: Student, student2:Student, name:EString)) = self.students->collect(s1 | self.students->select(s2 | s2.name = s1.name and s1 <> s2)-> collect(s2 | Tuple{student1 = s1, student2 = s2, name = s1.name}))</pre><p>For each ScoolClass, this OCL code defines an unparameterized named expression "nameConflicts" that will return a set of tuples formed by two students and a character string. The result is obtained this way: for the SchoolClass (which will hencefort be known as "self"), we take the list of students; then for each student "s1" on this list, we collect the tuples of name conflicts involving that specific student. How do we do the latter? Again from all students of the SchoolClass "self", we first select a limited set consisting only of those Students "s2" that have the same name as "s1" and are different from "s1" ("<>" means "not the same as"). Then for each Student "s2" to be found in this limited selection, we collect a tuple composed of "s1", "s2" and the name of "s1".</p><p>An in-depth introduction of OCL is not given here; the standardized specification document contains a formal definition as well as an informal introduction of the language.</p><h3><strong>Graph patterns and EMF-IncQuery</strong></h3><p>Graph patterns are a highly declarative way of intuitively specifying certain kinds of model queries. In case of the EMF platform, EMF-IncQuery<a target="_blank" href="http://incquery.net/">[homepage]</a> is a query technologyfeaturing a query language based on graph patterns. The following code is an EMF-IncQuery formalization of the above query:</p><pre>pattern nameConflicts(clazz: SchoolClass, student1: Student, student2: Student, name: EString) = { SchoolClass.students(clazz, student1); SchoolClass.students(clazz, student2); student1 != student2; Student.name(student1, name); Student.name(student2, name); } </pre><p>The above code introduces a graph pattern with the four parameter variables "clazz" of type SchoolClass, "student1" and "student2" of type Student, and "name" of type EString. By the semantics of the language, the pattern has a set of <em>matches</em> that are tuples formed of four elements, each taken from the model and offered as substitution for one of the four parameter variables. The match set will contain exactly those tuples whose variable substitutions satisfy the <em>pattern constraints</em>. In this case, the constraints are that(a) both "student1" and "student2" are reachable from "clazz" via a SchoolClass,students edge, (b) "student1" and "student2" are different, as denoted here by the "!=" operator, and (c) both Students have the value of variable "name" as their name.</p><p>The actual query would be this graph pattern, with the parameter variable "clazz" bound to a given input SchoolClass. In this case, the <em>pattern matcher</em> will only return those matches that belong to the given value of "clazz".</p><p><strong>Acknowledgement: this research was realized in the frames of TÁMOP 4.2.4. A/1-11-1-2012-0001 „National Excellence Program – Elaborating and operating an inland student and researcher personal support system”. The project was subsidized by the European Union and co-financed by the European Social Fund.</strong></p></div> | |
| <!-- <div class="author">Gábor Bergmann</div></div> --> | |
| </div> | |
| <div class="post"> | |
| <h2 class="title">EMF-IncQuery 0.7M1 published</h2> | |
| <div class="date">February 20, 2013</div> | |
| <div class="body"><p>Today the <a target="_blank" href="http://eclipse.org/incquery">EMF-IncQuery project</a> finished its first <a target="_blank" href="http://wiki.eclipse.org/EMFIncQuery/Releases/MigrateTo0.7">milestone</a> towards its first release at Eclipse.org. Version 0.7.0-M1 features the same performant model query engine and development tooling as our previous 0.6.x series, but also adds some new features:</p><ul><li>A generic <strong>event-driven rule engine</strong> was introduced. This engine is already used in the integration components data bindingand live model validation already shipped with EMF-IncQuery, but it can directly be integrated into applications.<ul><li>You can find more details on the wiki page <a target="_blank" href="http://wiki.eclipse.org/EMFIncQuery/DeveloperDocumentation/EventDrivenVM">EMFIncQuery/DeveloperDocumentation/EventDrivenVM</a>.</li></ul></li><li>Work has already began on two additional major features:<ul><li>A new integration component called EMF-IncQuery Viewers, that supports binding query results to user interface components such as JFace Viewers or Zest graphs.</li><li>A first step to support Query Libraries, queries reusable between projects, was the introduction of java imports. However, there are some issues to be ironed out before the final 0.7.0 release.</li></ul></li><li>And a lot of bug fixes, including support for EMF subpackages or better detection of GMF and Graphiti-based editors, and more...</li></ul><p>However, as EMF-IncQuery relies on generating integration code for various applications, migrating from previous (0.6.x) versions of EMF-IncQuery, some manual adjustments are needed. For details, see the wiki page <a target="_blank" href="http://wiki.eclipse.org/EMFIncQuery/Releases/MigrateTo0.7">EMFIncQuery/Releases/MigrateTo0.7</a>. Although, we recommend all users of the 0.6 series to upgrade to 0.7M1, as all development happens in the new version.</p><p>The new milestone is available from <a target="_blank" href="http://eclipse.org/incquery/download.php">http://eclipse.org/incquery/download.php</a>, and it can also be installed through the <a target="_blank" href="https://marketplace.eclipse.org/node/450505">Eclipse Marketplace</a>.</p><p>We hope to introduce some further useful features until the planned 0.7.0 release in the end of June (after Kepler), but we need your feedback - check out our development plan on the <a target="_blank" href="http://projects.eclipse.org/projects/release/0.7.0-6">Eclipse Project portal</a>. Please feel free to try out our first milestone, ask questions in the <a target="_blank" href="http://www.eclipse.org/forums/index.php/f/255/">Forum</a> or report issues through the <a target="_blank" href="https://bugs.eclipse.org/bugs/describecomponents.cgi?product=Incquery">Bugzilla</a>.</p></div> | |
| <!-- <div class="author">Zoltán Ujhelyi</div></div> --> | |
| </div> | |
| <div class="post"> | |
| <h2 class="title">Modeling... why bother?</h2> | |
| <div class="date">January 29, 2013</div> | |
| <div class="body"><h3><strong>Modeling in software engineering... why bother?</strong></h3><p>When I first heard about modeling in software engineering, I was quite skeptical. After all, why bother to create models first, when one can jump right into coding the software?</p><p>The typical answer I heard was that real engineers always create models before building a product - architects are always drawing blueprints before the bricklayers actually start building the house, mechanical engineers always draw cross-sections and design models before manufacturing the item, etc. This answer never really satisfied me; after all, while building a house or manufacturing an item using the lathe is much costlier to do (and to get wrong) than doing revisions of a floorplan or blueprint, the same can not always be said of software: source code and model that describe source code are all just bytes in a computer, without significant material investment. And it is quite apparent that a part of the software industry, in fact the majority, does quite okay without UML or other kinds of modeling. All in all, it seemed that modeling software is just not worth it.</p><p>So what did I miss here? What I failed to take into account at the time was that software engineers <em>always</em> construct a model of the behaviour of a software before writing the software itself - a mental model, that is. And most of the time, the mental model is enough. Software developers receive requirements, think about them for a while, and then produce code, all without leaving a trace of diagrams.</p><p>The trick is that under certain circumstances, engineers choose to extract this mental model (or parts of it) from their minds into some kind of document. There are numerous good reasons to do so:</p><ul><li>Often there are multiple software engineers in the team, so that they can finish a project faster. Usually they cannot split their work into completely independent chunks, so they need some form of coordination. They can use documented models to <em>communicate</em> their mental models to each other.</li><li>Sometimes a multi-engineer project grows so large that nobody can fit a sufficiently detailed mental model of the entire system in their heads. A documented model can play an analogous role to an external storage, a subset of which can be cached in the mind of each engineer.</li><li>The engineer who creates a model and the engineer who reads it need not be different people; they can be the same person, at different points of time. Sometimes, a model is useful for recording design decisions that might not be remembered a while later.</li></ul><p>So far, the form of this documented version of the mental model was unrestricted - anything goes, as long as the other party will be able to understand it; plain text documentation (such as Javadoc) is actually quite common. Adhering to some conventions of denotation and semantics can be useful and productive, but not absolutely required, especially if the original designer is available for clarification upon requests. Yet, there are other cases where representing the model according to informal or formal conventions is highly recommended, or even mandatory:</p><ul><li>Sometimes a previously designed component or module is reused within, or interfaced with, a new system under design. Proper integration requires some form of communication between the engineers responsible for each of these systems. This time, the engineers involved typically do not belong to the same team or company, and do not have any other way to communicate.</li><li>If the target of the communication is a <em>computer</em>, the model must be formal. The great realization of model-driven engineering (see below) is that automated processing of formal models can provide a lot of help, from analysis to derivation of output artifacts. Depending on the development workflow, such automated steps may increase quality and save time and resources.</li></ul><p>Of course, the extraction of the mental model into a documented form (especially in a strict formalism) requires some amount of effort from the engineer. And it is not enough to do it once; whenever the engineer changes her mind, she must (well, should) update said document accordingly. Nevertheless, in certain industries and application domains the advantages (including those listed above) outweigh the costs, and even formal modeling is part of the engineering routine. This is the full answer I can give to my skeptic self.</p><h3><strong>The paradigm of model-driven engineering</strong></h3><p>In certain areas of software and system engineering, primarily where faults can lead to human injury or significant damage in property, the discipline of <em>model-driven engineering</em> (MDE) is gaining more and more prominence, as it delivers higher-quality products in a shorter development lifecycle. According to this approach, the focus of the engineering process is on creating and analyzing abstract models, and deriving them from other models; these models conform to various <em>modeling languages</em>.</p><p>Modeling may start in an early phase of the engineering process, when <em>requirements</em> against the system under design are elicited. In light of the requirements, <em>system design</em> commences with creating high-level abstract models, then arriving after a series of refining steps upon models enriched with design decisions and realization considerations. The models can be continuously subjected to checks in order to find mistakes and design faults as soon as possible. As components for <em>embedded systems</em> are often required to be realized upon various target platforms corresponding to different technologies, such design processes may involve a <em>platform-independent</em> model (PIM), which encompasses the significant application-specific behavioural principles and realization parameters, but technological aspects are not detailed yet. Afterwards, depending on the available technological context, the PIM may be mapped to various <em>platform-specific</em> models (PSM), from which program modules realizing the designed software components can finally be produced (partially automatically). <a target="_blank" href="http://www.omg.org/mda/">[OMG Technology Perspective]</a></p><p>The concept of models is vague in the sense that it may even involve differential equations or spatial configurations in certain domains of system engineering; however, models involved in software engineering are essentially labeled graphs, and are typically sparse (i.e. the number of edges is roughly linearly proportional to the number of vertices). The labels applicable for vertices and edges of a modeling language (including types and attributes), along with their rules of interconnection, are defined by the <em>metamodel</em> of the language. It is important to point out that it is the abstract, formal structure of the model (the so-called <em>abstract syntax</em>) that is assumed here to be graph-like; the user-friendly visual depiction of the model (<em>concrete syntax</em>) can independently be of diagram, text, or any other form.</p><p>While there are some extensible formalisms intended as a universal way of representing models (such as UML<a target="_blank" href="http://www.omg.org/spec/UML/2.4.1/">[OMG Spec]</a>, SysML<a target="_blank" href="http://www.omg.org/spec/SysML/1.3/">[OMG Spec]</a>), industrial practice seems to ever increasingly prefer <em>domain-specific</em> modeling languages (DSML) instead, which can be tailored to the needs of application domains and actual design processes. However, developing such a DSML, along with associated tool support, is a cost-intensive task requiring special skills; therefore so-called DSM technologies have emerged to provide aid. The <em>Eclipse Modeling Framework</em> (EMF<a target="_blank" href="http://www.eclipse.org/emf/">[home]</a>), built on the Eclipse platform, is a leading DSM technology that is considered as a de facto industrial standard. A DSML development process with EMF involves defining an own metamodel (using the Ecore formalism), from which several components of the modeling tool can be automatically derived. Numerous generative or generic technologies help in creating tool support for EMF-based DSMLs; one can define a textual concrete syntax using a grammar or a visual concrete syntax using graphical elements, while code generators can be created by specifying textual templates for the modeling language.</p><p><strong>Acknowledgement: this research was realized in the frames of TÁMOP 4.2.4. A/1-11-1-2012-0001 „National Excellence Program – Elaborating and operating an inland student and researcher personal support system”. The project was subsidized by the European Union and co-financed by the European Social Fund.</strong></p></div> | |
| <!-- <div class="author">Gábor Bergmann</div></div> --> | |
| </div> | |
| <div class="post"> | |
| <h2 class="title">Kicking off my research blog</h2> | |
| <div class="date">January 29, 2013</div> | |
| <div class="body"><h3><strong>Welcome!</strong></h3><p>First of all: hi everyone, this is <a target="_blank" href="http://home.mit.bme.hu/~bergmann/en">Gábor Bergmann</a>. I'm currently pursuing my PhD in model-driven software design, and I will blog from time to time some interesting tidbits about my research and its relationship with EMF-IncQuery.</p><p>Before I can start explaining my specific area and the focus of my investigations, a very brief introduction to the paradigm of model-driven engineering is due. In <a target="_blank" href="http://incquery.net/blog/2013/01/modeling-why-bother">this first blog post</a>, I try to give an overview of what "model-driven" means, and why people are using this approach.</p><p>Upcoming blog posts will introduce the concept of model queries and the problems in this field that my PhD research aims to solve. Afterwards, the topic will finally be able to veer towards current developments and results, keeping track of what I will be doing at the time.</p></div> | |
| <!-- <div class="author">Gábor Bergmann</div></div> --> | |
| </div> | |
| <div class="post"> | |
| <h2 class="title">Presentation of EMF-IncQuery at EclipseCon Europe 2012</h2> | |
| <div class="date">November 12, 2012</div> | |
| <div class="body"><p><strong>Aggregated From: </strong><br /><a target="_blank" href="https://inf.mit.bme.hu/en/news/2012/11/presentation-emf-incquery-eclipsecon-europe-2012">https://inf.mit.bme.hu/en/news/2012/11/presentation-emf-incquery-eclipsecon-europe-2012</a></p> <img src="http://static1.squarespace.com/static/5614faafe4b03f677dc3822b/56153118e4b022593e35e24b/561fa5bfe4b09b5b49f4bfa1/1444914624738//img.png" alt=""/> <p>Representing our research group, Dr. István Ráth has presented the new version of our open source incremental model query framework called <a target="_blank" href="http://viatra.inf.mit.bme.hu/incquery">EMF-IncQuery</a> at EclipseCon Europe 2012, intended for industrial applications. As an acknowledgement of our work, Ed Merks (the creator of the de-facto industry standard Eclipse Modeling Framework) has lauded EMF-IncQuery as one of the most significant innovations of recent times.</p> <p id="yui_3_17_2_1_1444902787948_489964">On the conference, EMF-IncQuery has been featured in two talks:</p><ul><li>Entitled "Fast, Faster and Super-fast Model Queries", our <a target="_blank" data-cke-saved-href="https://viatra.inf.mit.bme.hu/node/147" href="https://viatra.inf.mit.bme.hu/node/147">talk</a> with Ed Willink, the developer of Eclipse OCL highlighted the state-of-the-art scalability and performance of the EMF-IncQuery framework in complex model-driven applications using very large instance models of several millions of elements in size,</li><li>the <a target="_blank" data-cke-saved-href="http://viatra.inf.mit.bme.hu/incquery/demos/jnect" href="http://viatra.inf.mit.bme.hu/incquery/demos/jnect">demo</a> "Get Your Eclipse Moving" presented by our friends at EclipseSource (Dr. Jonas Helming and Eugen Neufeld) featured a novel tech demonstrator combining EMF-IncQuery with the Esper Complex Event Processor to provide realtime complex gesture recognition over live EMF models.</li></ul></div> | |
| <!-- <div class="author">István Ráth</div></div> --> | |
| </div> | |
| <div class="post"> | |
| <h2 class="title">Presentation at EclipseCon Europe 2012</h2> | |
| <div class="date">October 24, 2012</div> | |
| <div class="body"><p>EMF-IncQuery has been featured in a <a target="_blank" href="http://www.eclipsecon.org/europe2012/sessions/fast-faster-and-super-fast-model-queries">presentation</a> at EclipseCon Europe 2012: Fast, Faster and Super-fast Model Queries by Ed Willink and István Ráth.</p><p>Just in time for the conference, EMF-IncQuery version 0.6.7 has been released to the <a target="_blank" href="http://marketplace.eclipse.org/node/450505">Marketplace</a>.</p> <iframe src="https://www.slideshare.net/slideshow/embed_code/key/3NtihuRCtDgDfa?wmode=opaque" width="427" height="356" frameborder="0" marginwidth="0" marginheight="0" scrolling="no" style="border:1px solid #CCC; border-width:1px; margin-bottom:5px; max-width: 100%;" allowfullscreen=""> </iframe> <div style="margin-bottom:5px"> <strong> <a href="https://www.slideshare.net/EdWillink/fast-faster-and-superfast-queries" title="Fast, Faster and Super-Fast Queries" target="_blank">Fast, Faster and Super-Fast Queries</a> </strong> from <strong><a href="http://www.slideshare.net/EdWillink" target="_blank">Edward Willink</a></strong> </div> <p id="yui_3_17_2_1_1444902787948_446501"><strong><a data-cke-saved-href="http://www.slideshare.net/EdWillink/fast-faster-and-superfast-queries" href="http://www.slideshare.net/EdWillink/fast-faster-and-superfast-queries" target="_blank">Fast, Faster and Super-Fast Queries</a></strong> from <strong><a data-cke-saved-href="http://www.slideshare.net/EdWillink" href="http://www.slideshare.net/EdWillink" target="_blank">EdWillink</a></strong></p></div> | |
| <!-- <div class="author">István Ráth</div></div> --> | |
| </div> | |
| <div class="post"> | |
| <h2 class="title">Presentations at the MODELS 2012 conference</h2> | |
| <div class="date">October 3, 2012</div> | |
| <div class="body"><p><strong>Aggregated From:</strong> <br /><a target="_blank" href="https://inf.mit.bme.hu/en/news/2012/10/presentations-models-2012-conference">https://inf.mit.bme.hu/en/news/2012/10/presentations-models-2012-conference</a></p> <img src="http://static1.squarespace.com/static/5614faafe4b03f677dc3822b/56153118e4b022593e35e24b/561fa6c8e4b0667ac1ab183a/1444914889870//img.png" alt=""/> <p id="yui_3_17_2_1_1444902787948_544426">Representing our research group, Dániel Varró and Ábel Hegedüs presented at the <a target="_blank" data-cke-saved-href="http://www.modelsconference.org/" href="http://www.modelsconference.org/">MODELS 2012</a> (International Conference on Model Driven Engineering Languages & Systems) conference and the <a target="_blank" data-cke-saved-href="http://msdl.cs.mcgill.ca/conferences/AMT/" href="http://msdl.cs.mcgill.ca/conferences/AMT/">AMT 2012</a> (Workshop on Analysis of Model Transformations) workshop, held in Innsbruck.</p><p>Ábel Hegedüs presented a new use case of the <a target="_blank" data-cke-saved-href="http://viatra.inf.mit.bme.hu/incquery" href="http://viatra.inf.mit.bme.hu/incquery">EMF-IncQuery</a> incremental model query engine for supporting <a target="_blank" data-cke-saved-href="https://inf.mit.bme.hu/research/publications/query-driven-soft-interconnection-emf-models" href="https://inf.mit.bme.hu/research/publications/query-driven-soft-interconnection-emf-models">soft interconnections</a> between EMF model fragments.</p><p>Dániel Varró presented the <a target="_blank" data-cke-saved-href="https://viatra.inf.mit.bme.hu/incquery/documentation/ui" href="https://viatra.inf.mit.bme.hu/incquery/documentation/ui">interactive query development</a> features of the <a target="_blank" data-cke-saved-href="http://viatra.inf.mit.bme.hu/incquery" href="http://viatra.inf.mit.bme.hu/incquery">EMF-IncQuery</a> engine.</p><p>Additional material (slides) related to the presentation is available on the <a target="_blank" data-cke-saved-href="https://viatra.inf.mit.bme.hu/node/139" href="https://viatra.inf.mit.bme.hu/node/139">VIATRA </a>portal.</p><p>Benedek Izsó presented a method for <a target="_blank" data-cke-saved-href="http://www.slideshare.net/izso/owl2swrl-to-emfiqpl" href="http://www.slideshare.net/izso/owl2swrl-to-emfiqpl">designing EMF metamodels and constraints based on ontologies</a>.</p><p><strong>Related content: </strong><br><a target="_blank" data-cke-saved-href="https://inf.mit.bme.hu/en/research/publications/query-driven-soft-interconnection-emf-models" href="https://inf.mit.bme.hu/en/research/publications/query-driven-soft-interconnection-emf-models">Query-driven soft interconnection of EMF models</a></p></div> | |
| <!-- <div class="author">Ábel Hegedüs</div></div> --> | |
| </div> | |
| <div class="post"> | |
| <h2 class="title">EMF-IncQuery 0.6.5 Released</h2> | |
| <div class="date">October 3, 2012</div> | |
| <div class="body"><p>Just in time for our presentation at the <a target="_blank" href="http://models2012.info/index.php?option=com_content&view=article&id=50&Itemid=39">MODELS 2012 Conference</a> in Innsbruck, we have reached a major milestone: the brand new version 0.6.5 of EMF-IncQuery has been released. You can get it from the <a target="_blank" href="http://incquery.net/node/107">getting started</a> page.</p><p>Together with this milestone, we are also pleased to inform everyone that the Creation Review for the Eclipse.org EMF-IncQuery subproject has been <a target="_blank" href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=380841">scheduled</a> for October 10th, and EMF-IncQuery is also available from the <a target="_blank" href="http://marketplace.eclipse.org/node/450505">Eclipse Marketplace</a>!</p><p>The main highlights of version 0.6.5 are the followings:</p><ul><li>Since the last officially publicized milestone (0.4), more than 30 man-months of development effort have been invested into the project.<ul><li>The new version features a significantly rewritten pattern matching engine using IncQuery <a target="_blank" href="http://incquery.net/node/127">Base</a>. IncQuery's pattern matcher, as in previous versions, is capable of nearly instantaneous query (re)evaluation performance for very complex queries over large instance models up to several million EObjects in size. Version 0.6.5 improves on 0.4's core capabilities by including support for <a target="_blank" href="http://incquery.net/node/106">efficient transitive closures</a>.</li><li>EMF-IncQuery now has a state-of-the-art Xtext-based <a target="_blank" href="http://incquery.net/node/125">Eclipse UI</a>.</li><li>Interpretative query evaluation (originally appearing in 0.6.0) enables the query developers to <a target="_blank" href="http://incquery.net/node/129">test their queries without generating code from them first</a>. Of course, the generated version performs better (due to compiled check expressions) and has an easier-to-use, pattern-specific generated API.</li><li>In addition to the powerful graph-pattern based query language, IncQuery also has experimental support for Xbase check expressions so that you can include (side effect free) imperative logic and even Java code into your queries.</li><li>The query language features automated variable type inference and several other validation rules to make the development of complex, structured queries easier and faster.</li></ul></li><li>Notable additional top-level features include:<ul><li>Support for <a target="_blank" href="http://incquery.net/node/131">query-backed derived features</a> and <a target="_blank" href="http://incquery.net/publications/query-driven-soft-links">soft links</a> (as presented at MODELS 2012)</li><li>A rewritten<a href="http://incquery.net/node/130"> Validation Engine</a> that provides high-performance on-the-fly evaluation for complex model validation rules.</li></ul></li><li>We have also put a lot of work into the website, most notably:<ul><li>The documentation section has been extended to cover all important aspects of the technology, including the <a target="_blank" href="http://incquery.net/node/125">User Interface</a>, the <a target="_blank" href="http://incquery.net/node/66">Query Language</a>, and the <a target="_blank" href="http://incquery.net/node/128">Java API</a>.</li><li>The continuously maintained and expanded <a target="_blank" href="http://incquery.net/incquery/examples">Examples section</a> provides starting points and hints for new as well as experienced users.</li></ul></li></ul></div> | |
| <!-- <div class="author">István Ráth</div></div> --> | |
| </div> | |
| <div class="post"> | |
| <h2 class="title">Query-driven soft links and Developing Queries using EMF-IncQuery presented at MODELS 2012 and AMT 2012</h2> | |
| <div class="date">October 3, 2012</div> | |
| <div class="body"><p>EMF model fragments can now be connected using soft links defined by advanced model queries in EMF-IncQuery to achieve high performance (through incremental evaluation) and standard EMF integration (proper change notifications). We presented this new use case at the <a target="_blank" href="http://www.modelsconference.org/">MODELS 2012</a> conference, held this year in Innsbruck.</p><p>We also presented the <a target="_blank" href="http://incquery.net/node/129">interactive query development</a> features of EMF-IncQuery at the <a target="_blank" href="http://msdl.cs.mcgill.ca/conferences/AMT/">AMT 2012</a> workshop.</p> <iframe src="https://www.slideshare.net/slideshow/embed_code/key/zH57H8TdtisXfz?wmode=opaque" width="427" height="356" frameborder="0" marginwidth="0" marginheight="0" scrolling="no" style="border:1px solid #CCC; border-width:1px; margin-bottom:5px; max-width: 100%;" allowfullscreen=""> </iframe> <div style="margin-bottom:5px"> <strong> <a href="https://www.slideshare.net/abelhegedus/querydriven-soft-interconnection-of-emf-models" title="Query-driven soft interconnection of EMF models" target="_blank">Query-driven soft interconnection of EMF models</a> </strong> from <strong><a href="http://www.slideshare.net/abelhegedus" target="_blank">Ábel Hegedüs</a></strong> </div> <p><strong><a target="_blank" href="http://www.slideshare.net/abelhegedus/querydriven-soft-interconnection-of-emf-models">Query-driven soft interconnection of EMF models</a></strong> from <strong><a target="_blank" href="http://www.slideshare.net/abelhegedus">Ábel Hegedüs</a></strong></p> <iframe src="https://www.slideshare.net/slideshow/embed_code/key/ooqX76TB1H8RBO?wmode=opaque" width="427" height="356" frameborder="0" marginwidth="0" marginheight="0" scrolling="no" style="border:1px solid #CCC; border-width:1px; margin-bottom:5px; max-width: 100%;" allowfullscreen=""> </iframe> <div style="margin-bottom:5px"> <strong> <a href="https://www.slideshare.net/stampie/developing-and-visualizing-live-model-queries" title="Developing and Visualizing Live Model Queries" target="_blank">Developing and Visualizing Live Model Queries</a> </strong> from <strong><a href="http://www.slideshare.net/stampie" target="_blank">Zoltán Ujhelyi</a></strong> </div> <p><strong><a target="_blank" href="http://www.slideshare.net/stampie/developing-and-visualizing-live-model-queries">Developing and Visualizing Live Model Queries</a></strong> from <strong><a target="_blank" href="http://www.slideshare.net/stampie">Zoltán Ujhelyi</a></strong></p><p>To try the example presented at the conference, check out the following website: <strong><a target="_blank" href="http://incquery.net/publications/query-driven-soft-links">Query-driven soft interconnection of EMF models</a></strong></p></div> | |
| <!-- <div class="author">Ábel Hegedüs</div></div> --> | |
| </div> | |
| <div class="post"> | |
| <h2 class="title">Presentations on ICGT 2012</h2> | |
| <div class="date">October 1, 2012</div> | |
| <div class="body"><p><strong>Aggregated From: </strong><br /><a target="_blank" href="https://inf.mit.bme.hu/en/news/2012/10/presentations-icgt-2012">https://inf.mit.bme.hu/en/news/2012/10/presentations-icgt-2012</a></p> <img src="http://static1.squarespace.com/static/5614faafe4b03f677dc3822b/56153118e4b022593e35e24b/561fa916e4b00e50405e7b23/1444915478830//img.gif" alt=""/> <p id="yui_3_17_2_1_1444915289648_41453">This year the <a target="_blank" data-cke-saved-href="http://www.informatik.uni-bremen.de/icgt2012/" href="http://www.informatik.uni-bremen.de/icgt2012/">Sixth International Conference on Graph Transformation - Modeling and Analysis of Dynamic Structures (ICGT 2012)</a>, which is the biannual gathering of mathematicians and engineers forming the graph transformation research community, was hosted along with its satellite events between 24 and 29 September in Bremen, Germany.</p><p>Our research group was represented by two papers in the "Applications" track of the main conference, both of which was presented by Gábor Bergmann. The first article demonstrated solutions for various practical problems arising in efficient (incremental) graph transformation execution in relational databases. The second one addressed the efficient computation of transitive reachability, which often plays an important role in network, behavioural and hierarchical models.</p><p>Saturday's satellite event <a target="_blank" data-cke-saved-href="http://users.informatik.haw-hamburg.de/~padberg/Workshops/PNGT2012/index.html" href="http://users.informatik.haw-hamburg.de/~padberg/Workshops/PNGT2012/index.html">Fifth International Workshop on Petri Nets, Graph Transformation and other Concurrency Formalisms (PNGT 2012)</a> featured Varró-Gyapay Szilvia presenting her research on graph transformation with time.</p><p><strong>Related content:</strong><br><a target="_blank" data-cke-saved-href="https://inf.mit.bme.hu/en/research/publications/incremental-pattern-matching-efficient-computation-transitive-closure" href="https://inf.mit.bme.hu/en/research/publications/incremental-pattern-matching-efficient-computation-transitive-closure">Incremental pattern matching for the efficient computation of transitive closure</a><br><a target="_blank" data-cke-saved-href="https://inf.mit.bme.hu/en/research/publications/applying-incremental-graph-transformation-existing-models-relational-databases" href="https://inf.mit.bme.hu/en/research/publications/applying-incremental-graph-transformation-existing-models-relational-databases">Applying Incremental Graph Transformation to Existing Models in Relational Databases</a></p><div class="image-gallery-wrapper"> <img src="http://static1.squarespace.com/static/5614faafe4b03f677dc3822b/56153118e4b022593e35e24b/561f6a96e4b05aa01f936b72/1444899478364/P9280192.JPG" /> <img src="http://static1.squarespace.com/static/5614faafe4b03f677dc3822b/56153118e4b022593e35e24b/561f6a9ae4b096cf99c8e532/1444899483118/P9250079.JPG" /> <img src="http://static1.squarespace.com/static/5614faafe4b03f677dc3822b/56153118e4b022593e35e24b/561f6bbee4b0110181864fc4/1444899774268/P9270139.JPG" /> <img src="http://static1.squarespace.com/static/5614faafe4b03f677dc3822b/56153118e4b022593e35e24b/561fa8eee4b0146c20a55304/1444915438775/P9280258.JPG" /> <img src="http://static1.squarespace.com/static/5614faafe4b03f677dc3822b/56153118e4b022593e35e24b/561f6bbde4b05c4e86decb24/1444899774042/P9250089.JPG" /> <img src="http://static1.squarespace.com/static/5614faafe4b03f677dc3822b/56153118e4b022593e35e24b/561f6bbde4b0110181864fc2/1444899774043/P9250098.JPG" /> </div></div> | |
| <!-- <div class="author">Gábor Bergmann</div></div> --> | |
| </div> | |
| <div class="post"> | |
| <h2 class="title">Presentation at the ECMFA 2012 conference</h2> | |
| <div class="date">July 5, 2012</div> | |
| <div class="body"><p><strong>Aggregated From: </strong></p><p> <a target="_blank" href="https://inf.mit.bme.hu/en/news/2012/07/presentation-ecmfa-2012-conference">https://inf.mit.bme.hu/en/news/2012/07/presentation-ecmfa-2012-conference</a></p> <img src="http://static1.squarespace.com/static/5614faafe4b03f677dc3822b/56153118e4b022593e35e24b/561fa996e4b0f4418bced7f9/1444915606748//img.png" alt=""/> <p>Representing our research group, Ábel Hegedüs presented the new use case of the <a target="_blank" href="http://viatra.inf.mit.bme.hu/incquery">EMF-IncQuery </a>incremental model query engine for integrating queries into efficient <a target="_blank" href="https://inf.mit.bme.hu/en/research/publications/derived-features-emf-integrating-advanced-model-queries">derived features</a> in EMF at the <a target="_blank" href="http://www2.imm.dtu.dk/conferences/ECMFA-2012/">ECMFA 2012</a> (European Conference on Modelling Foundations and Applications) conference, held in Kgs. Lyngby.</p><p>Additional material (slides) related to the presentation is available on the <a target="_blank" href="http://viatra.inf.mit.bme.hu/node/121">VIATRA </a>portal.</p><p><strong>Related content: </strong> <br /><a href="https://inf.mit.bme.hu/en/research/publications/derived-features-emf-integrating-advanced-model-queries">Derived Features for EMF by Integrating Advanced Model Queries</a></p></div> | |
| <!-- <div class="author">Ábel Hegedüs</div></div> --> | |
| </div> | |
| <div class="post"> | |
| <h2 class="title">Derived Features by integrating EMF-IncQuery presented at ECMFA 2012</h2> | |
| <div class="date">July 5, 2012</div> | |
| <div class="body"><p>Derived features for EMF can now be defined using advanced model queries in EMF-IncQuery to achieve high performance (through incremental evaluation) and standard EMF integration (proper change notifications). We presented this new use case at the <a target="_blank" href="http://www2.imm.dtu.dk/conferences/ECMFA-2012/">ECMFA 2012</a> conference, held this year in Kgs. Lyngby.</p><p><strong><a target="_blank" href="http://www.slideshare.net/abelhegedus/derived-features-for-emf-by-integrating-advanced-model-queries">Derived Features for EMF by Integrating Advanced Model Queries</a></strong></p> <iframe src="https://www.slideshare.net/slideshow/embed_code/key/1D7vq5KWGj6DO?wmode=opaque" width="427" height="356" frameborder="0" marginwidth="0" marginheight="0" scrolling="no" style="border:1px solid #CCC; border-width:1px; margin-bottom:5px; max-width: 100%;" allowfullscreen=""> </iframe> <div style="margin-bottom:5px"> <strong> <a href="https://www.slideshare.net/abelhegedus/derived-features-for-emf-by-integrating-advanced-model-queries" title="Derived Features for EMF by Integrating Advanced Model Queries" target="_blank">Derived Features for EMF by Integrating Advanced Model Queries</a> </strong> from <strong><a href="http://www.slideshare.net/abelhegedus" target="_blank">Ábel Hegedüs</a></strong> </div> <p>View more PowerPoint from <a target="_blank" href="http://www.slideshare.net/abelhegedus">abelhegedus</a></p><p>To try the example presented at the conference, check out the following website: <a target="_blank" href="http://incquery.net/node/92">Derived features using queries</a></p></div> | |
| <!-- <div class="author">Ábel Hegedüs</div></div> --> | |
| </div> | |
| <div class="post"> | |
| <h2 class="title">Presentation at the TOOLS 2012 conference</h2> | |
| <div class="date">June 5, 2012</div> | |
| <div class="body"><p><strong>Aggregated From: </strong><br /><a target="_blank" href="https://inf.mit.bme.hu/en/news/2012/06/presentation-tools-2012-conference">https://inf.mit.bme.hu/en/news/2012/06/presentation-tools-2012-conference</a></p> <img src="http://static1.squarespace.com/static/5614faafe4b03f677dc3822b/56153118e4b022593e35e24b/561faa03e4b01a261978d82b/1444915716028//img.gif" alt=""/> <p id="yui_3_17_2_1_1444915289648_116854">Representing our research group, Dr. István Ráth has presented the <a target="_blank" data-cke-saved-href="https://inf.mit.bme.hu/en/research/publications/integrating-efficient-model-queries-state-art-emf-tools" href="https://inf.mit.bme.hu/en/research/publications/integrating-efficient-model-queries-state-art-emf-tools">newest version</a> of the <a target="_blank" data-cke-saved-href="http://viatra.inf.mit.bme.hu/incquery" href="http://viatra.inf.mit.bme.hu/incquery">EMF-IncQuery</a> incremental model query tool at the 50th <a target="_blank" data-cke-saved-href="http://tools2012.fit.cvut.cz/" href="http://tools2012.fit.cvut.cz/">TOOLS Europe</a> International Conference on Objects, Models, Components, Patterns held in Prague.</p><p>We would like to thank all our student contributors who have helped us making IncQuery better.</p><ul><li>Developers: Márk Czotter, Tamás Szabó</li><li>Testers: Tamás Tóth, Gábor Szárnyas, and the students of the <a target="_blank" data-cke-saved-href="http://inf.mit.bme.hu/edu/courses/mdsd" href="http://inf.mit.bme.hu/edu/courses/mdsd">Model-based software design</a> course</li></ul><p>Additional material (slides) related to the presentation is available on the <a target="_blank" data-cke-saved-href="http://viatra.inf.mit.bme.hu/node/116" href="http://viatra.inf.mit.bme.hu/node/116">VIATRA portal</a>.</p></div> | |
| <!-- <div class="author">István Ráth</div></div> --> | |
| </div> | |
| <div class="post"> | |
| <h2 class="title">EMF-IncQuery 0.6 introduced at the TOOLS 2012 conference</h2> | |
| <div class="date">May 30, 2012</div> | |
| <div class="body"><p>We are happy to announce the immediate availability of EMF-IncQuery v0.6-preview, a preview release of the new generation IncQuery technology. This preview release has been presented at the (last) <a target="_blank" href="http://tools2012.fit.cvut.cz/">TOOLS Europe conference</a>, held this year in Prague. A big thanks to all the contributors who have made this possible!</p><p><strong><a target="_blank" href="http://www.slideshare.net/IstvanRath/emfincquery-presentation-at-tools-2012">EMF-IncQuery presentation at TOOLS 2012</a></strong></p> <iframe src="https://www.slideshare.net/slideshow/embed_code/key/duKZzuu2hlUEiR?wmode=opaque" width="427" height="356" frameborder="0" marginwidth="0" marginheight="0" scrolling="no" style="border:1px solid #CCC; border-width:1px; margin-bottom:5px; max-width: 100%;" allowfullscreen=""> </iframe> <div style="margin-bottom:5px"> <strong> <a href="https://www.slideshare.net/IstvanRath/emfincquery-presentation-at-tools-2012" title="EMF-IncQuery presentation at TOOLS 2012" target="_blank">EMF-IncQuery presentation at TOOLS 2012</a> </strong> from <strong><a href="http://www.slideshare.net/IstvanRath" target="_blank">Istvan Rath</a></strong> </div> <p>View more <a target="_blank" href="http://www.slideshare.net/thecroaker/death-by-powerpoint">PowerPoint</a> from <a target="_blank" href="http://www.slideshare.net/IstvanRath">Istvan Rath</a></p><p>To try the examples presented at the conference, check out the following websites:</p><ul><li><a target="_blank" href="http://incquery.net/node/107">Getting started</a></li><li><a target="_blank" href="http://incquery.net/incquery/examples/school">School example</a></li><li><a target="_blank" href="http://incquery.net/incquery/examples/bpmn">BPMN example</a></li></ul><p>The performance measurements can be found <a target="_blank" href="http://incquery.net/performance">here</a>.</p><p> </p></div> | |
| <!-- <div class="author">István Ráth</div></div> --> | |
| </div> | |
| <div class="post"> | |
| <h2 class="title">The Eclipse.org project proposal for EMF-IncQuery has been posted</h2> | |
| <div class="date">May 27, 2012</div> | |
| <div class="body"><p>The <a target="_blank" href="http://www.eclipse.org/proposals/modeling.emf.incquery/">project proposal</a> for EMF-IncQuery has been officially posted on Eclipse.org. We would like to thank our mentors, Ed Merks and Cédric Brun, and all our interested parties for their help and support.</p></div> | |
| <!-- <div class="author">István Ráth</div></div> --> | |
| </div> | |
| <div class="post"> | |
| <h2 class="title">Presentation at the ICST'12 conference</h2> | |
| <div class="date">April 27, 2012</div> | |
| <div class="body"><p><strong>Aggregated From: </strong></p><p> <a target="_blank" href="https://inf.mit.bme.hu/en/news/2012/04/presentation-icst12-conference">https://inf.mit.bme.hu/en/news/2012/04/presentation-icst12-conference</a></p> <img src="http://static1.squarespace.com/static/5614faafe4b03f677dc3822b/56153118e4b022593e35e24b/561faaece4b09b5b49f4e057/1444915952351/DSC_0020.JPG" alt=""/> <p>Zoltán Ujhelyi, PhD student attended at the Fifth International Conference on Software Testing, Verification and Validation in Montreal, Canada between April 17-20, 2012. During the conference a presentation he presented his work related to slicing model transformations in a debugging scenario called <em>Dynamic Backward slicing of Model Transformations</em>.</p> <img src="http://static1.squarespace.com/static/5614faafe4b03f677dc3822b/56153118e4b022593e35e24b/561fab59e4b0f197c39566cd/1444916064546/DSC_0033.JPG" alt=""/> <p id="yui_3_17_2_1_1444915289648_179479">In the conference 200 researchers attended from more that 20 nations wordwide, and presented their results related to software quality and testing.</p></div> | |
| <!-- <div class="author">Zoltán Ujhelyi</div></div> --> | |
| </div> | |
| <div class="post"> | |
| <h2 class="title">EMF-IncQuery presentation at the Workshop on Eclipse Open Source Software and OMG Open Specifications (Co-located with EclipseCon 2012)</h2> | |
| <div class="date">March 25, 2012</div> | |
| <div class="body"><p>A talk on High-performance model queries using EMF-IncQuery has been presented by István Ráth at the <a target="_blank" href="http://www.omg.org/news/meetings/tc/dc-12/special-events/Eclipse_Program.htm">Third Biannual Workshop on Eclipse Open Source Software and OMG Open Specifications,</a> co-located with EclipseCon 2012 in Reston.</p><p><strong>Topics covered</strong></p><ul><li>scalability problems in modeling tools</li><li>comparing modeling technologies by benchmarking</li><li>how to build scalable tools?</li><li>IncQuery New Generation overview</li></ul><p><strong>Pointers</strong></p><ul><li><a target="_blank" href="http://incquery.net/incquery/new">IncQuery New Generation overview</a></li><li><a target="_blank" href="https://viatra.inf.mit.bme.hu/publications/trainbenchmark">Instance model validation benchmark (comparing SPARQL engines and EMF tools)</a></li></ul><p><strong><a target="_blank" href="http://www.slideshare.net/IstvanRath/highperformance-model-queries">High-performance model queries</a></strong></p> <iframe src="https://www.slideshare.net/slideshow/embed_code/key/NkNaQhXYkRRJH3?wmode=opaque" width="427" height="356" frameborder="0" marginwidth="0" marginheight="0" scrolling="no" style="border:1px solid #CCC; border-width:1px; margin-bottom:5px; max-width: 100%;" allowfullscreen=""> </iframe> <div style="margin-bottom:5px"> <strong> <a href="https://www.slideshare.net/IstvanRath/highperformance-model-queries" title="High-performance model queries" target="_blank">High-performance model queries</a> </strong> from <strong><a href="http://www.slideshare.net/IstvanRath" target="_blank">Istvan Rath</a></strong> </div> <p>View more <a target="_blank" href="http://www.slideshare.net/thecroaker/death-by-powerpoint">PowerPoint</a> from <a target="_blank" href="http://www.slideshare.net/IstvanRath">Istvan Rath</a></p></div> | |
| <!-- <div class="author">István Ráth</div></div> --> | |
| </div> | |
| <div class="post"> | |
| <h2 class="title">EMF-IncQuery New Generation development progress</h2> | |
| <div class="date">March 6, 2012</div> | |
| <div class="body"><p>A new, completely redesigned EMF-IncQuery is now in the works, with many new features - including an Xtext2-based query development tool and an interpretative query API to allow queries without having to generate code. Check out details at the <a target="_blank" href="http://www.eclipse.org/membership/showMember.php?member_id=1179">corresponding page</a>.</p></div> | |
| <!-- <div class="author">István Ráth</div></div> --> | |
| </div> | |
| <div class="post"> | |
| <h2 class="title">EMF-IncQuery presented at EclipseCon Europe 2011</h2> | |
| <div class="date">December 10, 2011</div> | |
| <div class="body"><p><a target="_blank" href="http://incquery.net/incquery">EMF-IncQuery</a> was presented by István Ráth at <a target="_blank" href="http://eclipsecon.org/europe2011/">EclipseCon Europe 2011</a>, at the Modeling Symposium. We have talked about performance characteristics as well as presented our plans for the new architecture in the upcoming v0.7 release. More details about the symposium are found <a target="_blank" href="http://mariot-thoughts.blogspot.com/2011/11/modeling-symposium-eclipsecon-europe.html">here</a>.</p></div> | |
| <!-- <div class="author">István Ráth</div></div> --> | |
| </div> | |
| <div class="post"> | |
| <h2 class="title">ACM Distinguished Paper Award at IEEE/ACM International Conference On Automated Software Engineering 2011 conference</h2> | |
| <div class="date">November 11, 2011</div> | |
| <div class="body"><p><strong>Aggregated From: </strong></p><p> <a target="_blank" href="https://inf.mit.bme.hu/en/news/2011/11/acm-distinguished-paper-award-ieeeacm-international-conference-automated-software-engin">https://inf.mit.bme.hu/en/news/2011/11/acm-distinguished-paper-award-ieeeacm-int...</a></p> <img src="http://static1.squarespace.com/static/5614faafe4b03f677dc3822b/56153118e4b022593e35e24b/561fabd5e4b0f4418bcee6b7/1444916192685//img.jpg" alt=""/> <p id="yui_3_17_2_1_1444915289648_200446">Between November 6-12, Lawrence, Kansas (US) hosted the 26th<strong><a target="_blank" data-cke-saved-href="http://www.continuinged.ku.edu/programs/ase/" href="http://www.continuinged.ku.edu/programs/ase/"> IEEE/ACM International Conference On Automated Software Engineering (ASE '11)</a></strong>, which is one of the most widely accepted and respected scientific forum on software and systems engineering.</p><p id="yui_3_17_2_1_1444915289648_200447">Altogether, our group presented four different papers on the conference:</p><ul id="yui_3_17_2_1_1444915289648_200448"><li><p>First, Ákos Horváth gave a tutorial about the EMF-IncQuery framework for querying large EMFmodels</p></li><li><p>Then, Dániel Varró presented our ongoing research on design space exploration titled, <a target="_blank" data-cke-saved-href="https://inf.mit.bme.hu/en/research/publications/model-driven-framework-guided-design-space-exploration" href="https://inf.mit.bme.hu/en/research/publications/model-driven-framework-guided-design-space-exploration"><strong>A Model-driven Framework for Guided Design Space Exploration</strong></a>, which won the prestigious ACM Distinguished Paper Award that was given to only 3 selected papers accepted to the conference!</p></li><li><p>It was followed by a presentation of Dániel on <a target="_blank" data-cke-saved-href="https://inf.mit.bme.hu/en/research/publications/towards-dynamic-backward-slicing-model-transformations" href="https://inf.mit.bme.hu/en/research/publications/towards-dynamic-backward-slicing-model-transformations">Dynamic Backward Slicing of Model Transformations</a> that described a novel approach for debugging model transformation.</p></li><li><p>Finally, Ákos closed the groups contribution with a talk on how EMF-IncQuery can be used for the effective validation on EMF models.</p></li></ul> <p><strong>Related content: </strong><br /><a target="_blank" href="http://inf.mit.bme.hu/en/research/publications/towards-dynamic-backward-slicing-model-transformations">Towards Dynamic Backward Slicing of Model Transformations</a><br /><a target="_blank" href="http://inf.mit.bme.hu/en/research/publications/model-driven-framework-guided-design-space-exploration">A Model-driven Framework for Guided Design Space Exploration</a><br /><a target="_blank" href="http://inf.mit.bme.hu/en/research/publications/implementing-efficient-model-validation-emf-tools-tool-demonstration">Implementing Efficient Model Validation in EMF Tools: Tool Demonstration</a></p></div> | |
| <!-- <div class="author">Ákos Horváth</div></div> --> | |
| </div> | |
| <div class="post"> | |
| <h2 class="title">EMF-IncQuery Base first release</h2> | |
| <div class="date">November 3, 2011</div> | |
| <div class="body"><p>Just in time for EclipseCon Europe 2011, the first early release of <a target="_blank" href="http://incquery.net/node/83">IncQuery Base</a> is available! More details to follow soon.</p></div> | |
| <!-- <div class="author">István Ráth</div></div> --> | |
| </div> | |
| <div class="post"> | |
| <h2 class="title">VL/HCC 2011 conference in Pittsburgh</h2> | |
| <div class="date">September 26, 2011</div> | |
| <div class="body"><p><strong>Aggregated From: </strong><br /><a target="_blank" href="https://inf.mit.bme.hu/en/news/2011/09/vlhcc-2011-conference-pittsburgh">https://inf.mit.bme.hu/en/news/2011/09/vlhcc-2011-conference-pittsburgh</a></p> <img src="http://static1.squarespace.com/static/5614faafe4b03f677dc3822b/56153118e4b022593e35e24b/561fac6ae4b02b88a9b64dec/1444916339360//img.jpg" alt=""/> <p id="yui_3_17_2_1_1444915289648_224810">The <a target="_blank" data-cke-saved-href="http://www.cs.cmu.edu/~vlhcc2011/" href="http://www.cs.cmu.edu/~vlhcc2011/">VL/HCC sympsium</a> (IEEE Symposium on Visual Languages and Human-Centric Computing) was hosted by Pittsburgh (PA) between September 18-22. Established in 1984, the mission of the conference is to support the design, theory, application and evaluation of computing technologies and languages for programming, modeling and communicating, which are easier to learn, use, and understand by people. Some of the companies participating in the conference are National Instruments (LabView), Microsoft, Northwoods, and AgentSheets. </p><p>Ábel Hegedüs presented our <a target="_blank" data-cke-saved-href="http://incquery.net/en/research/publications/quick-fix-generation-dsmls" href="http://incquery.net/en/research/publications/quick-fix-generation-dsmls">scientific paper</a>, about generating quick fixes for <a target="_blank" data-cke-saved-href="http://en.wikipedia.org/wiki/Domain-specific_modeling" href="http://en.wikipedia.org/wiki/Domain-specific_modeling">domain-specific modeling languages</a>, similarly to<a target="_blank" data-cke-saved-href="http://wiki.eclipse.org/FAQ_What_is_a_Quick_Fix%3F" href="http://wiki.eclipse.org/FAQ_What_is_a_Quick_Fix%3F">existing approaches</a> in programming environments. Moisés C. Branco (University of Waterloo), who is a co-author along with Ákos Horváth, István Ráth and Dániel Varró, also participated in the conference.</p><div class="image-gallery-wrapper"> <img src="http://static1.squarespace.com/static/5614faafe4b03f677dc3822b/56153118e4b022593e35e24b/561facdbe4b048525fcee091/1444916445875/HPIM1024+%281%29.JPG" /> <img src="http://static1.squarespace.com/static/5614faafe4b03f677dc3822b/56153118e4b022593e35e24b/561facdee4b048525fcee098/1444916450836/HPIM1136+%281%29.JPG" /> </div><p><strong>Related content: </strong><br /><a target="_blank" href="http://inf.mit.bme.hu/en/research/publications/quick-fix-generation-dsmls">Quick fix generation for DSMLs</a></p></div> | |
| <!-- <div class="author">IncqueryLabs</div></div> --> | |
| </div> | |
| <div class="post"> | |
| <h2 class="title">Transformation Tool Contest 2010</h2> | |
| <div class="date">July 1, 2010</div> | |
| <div class="body"><p>We have submitted a solution to this year's Transformation Tool Contest (<a target="_blank" href="http://is.tm.tue.nl/staff/pvgorp/events/TTC2010/">TTC2010</a>), to the "ECore to GenModel" case. You can also check the<a target="_blank" href="https://www.youtube.com/watch?v=XfR-53B6Da0">YouTube screencast</a> which describes the solution in detail.</p></div> | |
| <!-- <div class="author">Zoltán Ujhelyi</div></div> --> | |
| </div> | |
| <div class="post"> | |
| <h2 class="title">VIATRA2 Release 3.1 video</h2> | |
| <div class="date">April 29, 2010</div> | |
| <div class="body"><p>Check out the VIATRA2 Release 3.1 video on <a target="_blank" href="http://vimeo.com/7412871">Vimeo.com</a>! The text is in Hungarian, but the screen captures towards the end highlight the most important features.</p></div> | |
| <!-- <div class="author">István Ráth</div></div> --> | |
| </div> | |
| <div class="post"> | |
| <h2 class="title">VIATRA2 Release 3.1 complete</h2> | |
| <div class="date">March 23, 2010</div> | |
| <div class="body"><p>VIATRA2 Release 3.1 is finally complete. More information available at <a target="_blank" href="http://wiki.eclipse.org/VIATRA2/ReleaseNotes3.1">the release notes wiki page</a>.</p><p>For this release, we completely redesigned the VIATRA2 wiki and added lots of new content. This content is also included in the VIATRA2 online help. The official Release3.1 source tree will be available from Eclipse.org SVN as well as the update site as soon as the IP check process is completed. In the mean time, you can get the binaries from our official mirror update site at <a target="_blank" href="http://incquery.net/node/4">our download page.</a></p></div> | |
| <!-- <div class="author">István Ráth</div></div> --> | |
| </div> |