| M2M increamental transformation of CPS benchmark [message #1769178] |
Thu, 27 July 2017 05:32  |
Eclipse User |
|
|
|
As you described in "https://www.eclipse.org/forums/index.php/m/1769154/#msg_1769154". "Explicit traceability M2M transformation" can handle restarts to bypass the second model transformation. In my opinion, the VQL is more complex and difficult in explicit traceability than base incremental. So I add some code in "org.eclipse.viatra.examples.cps.xform.m2m.incr.viatra". It seems like to solve this problem too. Are there some bugs in this way?
Blew is the adding code(red color) in getHostRule() in "org.eclipse.viatra.examples.cps.xform.m2m.incr.viatra.rules.RuleProvider.xtend":
if (hostRule == null) {
hostRule = createRule.precondition(HostInstanceMatcher.querySpecification).action(
CRUDActivationStateEnum.CREATED) [
debug('''Mapping host with IP: «hostInstance.nodeIp»''')
//if the target element has existed, return directly
val query1 = engine.cps2depTrace.getAllValuesOfdepElement(null, null, hostInstance).filter(
DeploymentHost)
if (!query1.isEmpty){
return;
}
val deploymentHost = cps2dep.deployment.createChild(deployment_Hosts, deploymentHost)
deploymentHost.set(deploymentHost_Ip, hostInstance.nodeIp)
val hostTrace = cps2dep.createChild(CPSToDeployment_Traces, CPS2DeploymentTrace)
hostTrace.addTo(CPS2DeploymentTrace_CpsElements, hostInstance)
hostTrace.addTo(CPS2DeploymentTrace_DeploymentElements, deploymentHost)
]
Hope for your reply!
|
|
|
| Re: M2M increamental transformation of CPS benchmark [message #1769376 is a reply to message #1769178] |
Mon, 31 July 2017 04:02  |
| Eclipse User |
|
|
|
Hi,
in general, your proposed solution should work without any issues. The decision where to handle the extra conditions is mainly philosophical, however, I have a few remarks:
* First of all, instead of using `cps2depTrace.getAllValuesOfdepElement(null, null, hostInstance).filter[...]`, it would be perform better to do something like `if (cps2depTrace.hasMatches(null, null, hostInstance)) { return; }` This approach performs better in case of large match sets, as the query engine does not have to enumerate all possible matches.
* If there are a lot of matches of the precondition pattern where the related pattern has the matches, the transformation engine could perform better as it has enough information to know that nothing needs to be executed in the action part.
* Finally, you _have_ to make sure that it is handled correctly if the called pattern has or has no matches, e.g. you have to check for the matches to exist. The action parts are not allowed to throw any exceptions.
To summarize, in my opinion it is better to keep mandatory conditions in patterns because of performance optimization, and using appropriate `find` constructs the patterns could be kept readable. I believe, it is a good idea to keep all application conditions in the precondition part, and keep the action parts as simple as possible. However, if you find the patterns harder to read, moving these conditions to the action part should work as well.
I hope this has helped,
Zoltán
|
|
|
Powered by
FUDForum. Page generated in 0.03875 seconds
Home