Home » Modeling » VIATRA » How should VIATRA be incorporated into an existing application
| How should VIATRA be incorporated into an existing application [message #1740485] |
Sun, 14 August 2016 18:54  |
|
Hello, I want to understand how I can gradually integrate VIATRA with an existing EMF application. The short-term goal is to add its Query API . The long-term goal is to explore using its Incremental Transformation API. Any suggestions or feedback to my comments below is greatly appreciated. Being new to model-driven development/engineering, apologies for being imprecise in my terminology / explanation.
The application currently accesses an instance of an EMF model, with the model being defined in an Ecore metamodel. The model instance is exposed to the application via an EditingDomain. This model instance is possibly shared to other consumers and persisted using EMFStore. (The merging of changes to this instance and its persistence are outside the scope of this discussion.) The application imperatively queries this model instance, using values populated from (often transient) non-UML domain-specific objects. The query is executed by performing direct traversals on a root object accessible via getContents() on the resource. Any missing results are imperatively added to the model instance, encapsulated in ChangeCommands. The modifications are unidirectional only; that is, no domain objects are created as a result of any actions occurring to this model instance.
As I understand VIATRA, as a first step, I could replace my custom queries with its Query API. I definitely see the value in using a known EMF-supported query language or technology than what I'm currently doing.
As a next step, I would create an EMF metamodel based on the domain-specific object relationships. The application would create a source model instance populated by the domain-specific objects, usually via some type of user interaction.
As an optional interim step, I would use this source model instance to populate the query values against the current application / target model instance (i.e. the one possibly persisted in EMFStore).
As a final step, I would then use VIATRA's incremental transformation API to transform the source model into the target model. This would involve porting the population of the queries and the resulting ChangeCommands to transformation rules.
Thanks for reading all the way to here! I hope I made sense. I also have a personal desire to learn more about model-driven development, so even if the above steps are a bit over-engineering, that's OK  Given all that, are the above steps as outlined an acceptable way to move my application to a more model-driven architecture based on VIATRA? Would you recommend different steps and is so, why?
|
|
|
| Re: How should VIATRA be incorporated into an existing application [message #1740498 is a reply to message #1740485] |
Mon, 15 August 2016 07:37  |
 Zoltan Ujhelyi
Messages: 392
Registered: July 2015 |
Senior Member |
|
|
Hi,
first of all, thanks for the interest in VIATRA; we hope, it will be a good match for your scenario. In general, your approach makes sense. The only part that is not entirely clear to me is the unidirectional query result population; but if I understand it correctly, it works as expected.
In general, VIATRA supports writing transformations with EMF transactions, but requires explicit setup: (1) you want to use a scheduler that is transaction-aware; such one is available from the org.eclipse.viatra.transformation.evm.transactions plug-in; this is required not to execute rules between transactions, and (2) if you use the model manipulation API with the transformations, set it up using the class ModelManipulationWithEditingDomain to make VIATRA emit change commands.
However, in order to support incremental queries and transformations the Query component of VIATRA behaves in a way that might be strange for someone using a client-server approach such as EMFStore: it traverses the entire model (or at least a set of resources) (1) to create an index, and (2) to register notification handlers to update the index on model changes. On a technical level, this works, but might require loading the entire model into the memory (that might be expensive).
One thing to consider: incremental query evaluation has a very different performance characteristics than a manually implemented search; to obtain optimal results the transformations are to be developed with the incremental query engine in mind. For example, if the query is executed only once with parameters bound, the cost of creating the Rete network might exceed simply searching for the solution. On the other hand, if you want to process all possible matches multiple times that is relatively cheap with incremental query evaluation. To handle this issue, we are actively working on a search-based approach reusing the pattern language of VIATRA, but without the incremental evaluation support. We believe, by combining the two approaches it becomes possible to select the best approach for any single problem.
So, to summarize, I guess your planned approach makes sense, as it allows you to experiment with the integration early (only using queries), and you can use further elements as required. If you have any concrete questions in the future, feel free to ask, and we do our best to help you start with VIATRA.
Best regards,
Zoltán
|
|
|
Goto Forum:
Current Time: Fri Apr 19 05:35:50 GMT 2024
Powered by FUDForum. Page generated in 0.01725 seconds |
] 
Search
Help
Register
Login
Home
