Proposed VIATRA solution and some clarifications

[szarnyasg]

We (@steindani, @abelhegedus) are working on a solution for the extended version of the case and would like to get some feedback whether we’re on the right track. Our tooling does not support bi-directional transformations so the solution would look like this:

1. Parse the source code to an abstract syntax tree graph (using JDT)
2. Use visitors to transform the syntax graph to an EMF model conforming the proposed Type Graph metamodel.
3. Transform the EMF model to the refactored EMF model (using VIATRA).
4. Keep the JDT syntax graph and the EMF model in sync (using VIATRA).
5. Transform the syntax graph to source code (using JDT).

We have the following questions: a. This approach uses the proposed type graph and provides a way to solve the challenges, but it seems a bit over-engineered and requires a lot of code to implement. Do you see this as a well-designed solution for the case?

b. It is not entirely clear how the solution should produce code with statements (capable of printing to the console) without storing and thus moving (pulling up) the statements in the proposed type graph?

c. If we are only allowed to work with the information stored in the type graph, should we discard the ASG (reverse-engineered with JDT), and when we’re done with the M2M transformation of the type graph, build a new JDT model and use it to serialize the solution to the test?

[SvenPeldszus]

We appreciate your efforts and can assure you that you are on the right track.

1. Parse the source code to an abstract syntax tree graph (using JDT)
2. Use visitors to transform the syntax graph to an EMF model conforming the proposed Type Graph metamodel.
3. Transform the EMF model to the refactored EMF model (using VIATRA).
4. Keep the JDT syntax graph and the EMF model in sync (using VIATRA).
5. Transform the syntax graph to source code (using JDT).

The procedure of your solution is very close to our solution and the other ones known to us. The synchronization part is the "heart" of any solution and of course we don´t know how you´ve implemented that part and how often you back-propagate the changes from the PG to the AST. However, your questions show us that you are working on a suitable solution.

a. This approach uses the proposed type graph and provides a way to solve the challenges, but it seems a bit over-engineered and requires a lot of code to implement. Do you see this as a well-designed solution for the case?

Indeed, we think it is well-designed, see above.

c. If we are only allowed to work with the information stored in the type graph, should we discard the ASG (reverse-engineered with JDT), and when we’re done with the M2M transformation of the type graph, build a new JDT model and use it to serialize the solution to the test?

Without persisting the intermediate representation, we do not see the possibility to synchronize the changes, when this is assigned by ARTE.

b. It is not entirely clear how the solution should produce code with statements (capable of printing to the console) without storing and thus moving (pulling up) the statements in the proposed type graph?

As the PG only contains structural information, the synchronization of a pull-up refactoring performed on the PG would result in relocating the corresponding method node in the AST. Having a correct synchronisation mechanism, this should also mean that all its child nodes are relocated as well and, thus, it results in a correct refactored AST without loss or change of functionality.

We look forward to your solution and an interesting discussion!

[SvenPeldszus]

Sorry, of course we didn´t want to close the issue without your consent :)

[tsdh]

@szarnyasg I just wanted to mention that my solution design is almost exactly the same as yours. Simply replace JDT with EMFText JaMoPP and VIATRA with FunnyQT.

I've never used JDT programmatically but you might want to have a look at EMFText JaMoPP. It has the benefit that you immediately get an EMF model (a resource set) for your Java sources instead of some custom data structure (Not sure, but I think I remember JDT ASGs are no EMF models). Also, when you modify the JaMoPP model, to serialize it back to java you only do

for (Resource r : myJamoppResourceSet.getResources()) {
    r.save(null);
}

and that's it.

[szarnyasg]

@SvenPeldszus: thanks for answer and confirming that we are on the right track.

@tsdh: thanks for the info!