Reduce the amount of rule generic boilerplate code in rule action definitions

[eclipse-viatra-bot]

| --- | --- | | Bugzilla Link | 464493 | | Status | UNCONFIRMED | | Importance | P3 enhancement | | Reported | Apr 13, 2015 05:53 EDT | | Modified | Aug 18, 2016 10:04 EDT | | Version | 0.7.0 | | Reporter | Peter Lunk |

Description

During the definition of VIATRA transformation rules, a significant percentage of the code base consists of completely rule independent boilerplate code.

For example, a typical transformation rule creates a target object, sets up a trace relation between it and the source object, and it initializes the target elements attributes. In this case, the target object creation and attribute initialization is dependent on the actual transformation at hand, however the trace creation is a generic operation.

As seen on the code snippet below, during the definition of a typical transformation rule, these the completely transformation-generic trace creations produce serious amount of boilerplate code.

//Method responsible for describing the actions taken if a new source element appears\ override appeared(Match match) {\ //Rule specific parts\ val umlObject = match.umlObject\ val xtumlrtObject = createXtumlrtObject\ //Generic parts\ addTrace(umlObject, xtumlrtObject)\ logger.debug('''Transformed «umlObject» to «xtumlrtObject»''')\ }

Summary: A solution is needed to decrease the amount of rule generic code required during rule definition.

[eclipse-viatra-bot]

By Istvan David on Apr 13, 2015 09:24

I don't really see the point here. How is creating a target object different from creating a trace object? What do you mean by a "typical" transformation rule?

Also, sticking to your example: how would you declare the ends of a trace if not by explicitly invoking the addTrace() method with those two specific parameters?

What you are referring to is essentially AOP (with concerns of traceability and logging in your example).

[eclipse-viatra-bot]

By Zoltan Ujhelyi on Apr 13, 2015 10:06

If you have only a single rule, then there is no difference. But if you have tens of rules, handling traces in a unified way quickly becomes cumbersome. Especially, if you want to modify it.

Basically, the problem with trace generation is that it is transformation-dependent, but often you don't want to make it rule-dependent. If possible, it would be nice to have some way to define these common properties.

I don't have any clean solution (yet), but wanted to have this issue open, as I believe this would be a nice upgrade over the EVM API.

[eclipse-viatra-bot]

By Istvan David on Apr 13, 2015 10:41

I can see why you consider traceability a common element of MTs, and I can definitely see the values of adding such a feature to the tool, but I think this leads a bit further.

handling traces in a unified way quickly becomes cumbersome.\ Especially, if you want to modify it.

My two cents are that this problem raises the need for some sort of a general abstraction mechanism, which can then facilitate encapsulating transformation rule concerns (such as traceability, logging, etc) into different components.

Since the DSL was explicitly tailored for Xtend and to utilize its functional features, I suspect looking into the direction of higher-order functions and currying might be interesting here.

Or were you thinking about a more pragmatic approach here?

[eclipse-viatra-bot]

By Zoltan Ujhelyi on Apr 13, 2015 10:48

I was thinking among similar lines (and this is also a reason I have told Peter not to remove the logging statement from the example snippet as it can also be a similar aspect). :)

But still, I have only very early-phase ideas and don't know when I will have the time to provide this aspect, so I am open to other, pragmatic solutions as well if it helps in the short-term.

[eclipse-viatra-bot]

By Istvan David on Apr 13, 2015 11:21

I have no quick solution either. (Plus: I'm in favor of doing this properly if we can live with the problem for a while.)

In the meantime I took a quick glance at the features of Sigma to gain some motivation, but couldn't find anything similar. A second look would be useful though. Should we find something there, we could try bridging the semantic gap between Scala and Xtend.

[eclipse-viatra-bot]

By Zoltan Ujhelyi on Mar 17, 2016 08:34

Updated 0.9 target milestones to 1.2

[eclipse-viatra-bot]

By Zoltan Ujhelyi on Mar 17, 2016 08:47

Postponed tickets to 1.3

[eclipse-viatra-bot]

By Zoltan Ujhelyi on May 26, 2016 08:41

Postponed.