| [Epsilon] Aspects [message #753595] |
Thu, 27 October 2011 22:22  |
|
Hello,
We have a model based variability tool that was built to work with oaw. The tool allows you to tailor specific aspects of the transformation rules so that a user can change some of the elements of the output model based on a configuration of the transformation. In oaw this was accomplished by defining aspects. The tool generated a new oaw workflow which used aspects to intercept transformation rules and modify them during execution of the transformation. Aspects allow invocation of alternative rules for a specific element and deciding whether to intercept it or not depending on properties of the transformed element. This means that rule superposition as supported natively by epsilon is not "fine grained" enough.
I was wondering if something similar has been thought for Epsilon. I mean: using aspects in epsilon. An initial thought would be to use the presection to validate a variable or element attribute and set another variable or flag that can be used inside the rule to affect outcome. However, on of the nice things about aspects if that you don't have to mess with the original sources in order to make it work.
I was just wondering if Dimitris or Luise could maybe point me in another direction or share some thoughts that could help me come up with an elegant solution.
Regards,
Horacio Hoyos Rodriguez
Kinori Tech
Need professional support for Epsilon, EMF?
Go to: https://kinori.tech
|
|
|
| Re: [Epsilon] Aspects [message #754836 is a reply to message #753595] |
Fri, 04 November 2011 14:56  |
|
Hi Horacio,
Unfortunately, I can't think of anything that would allow you to do this in an elegant way and wouldn't involve making significant changes to Epsilon (e.g. add support for notifications before/after rules are executed) - but we'd be more than happy to help if you decide to have a go at making changes towards this direction.
Cheers,
Dimitris
|
|
|
| Re: [Epsilon] Aspects [message #783015 is a reply to message #754836] |
Tue, 24 January 2012 22:40 |
|
Hello,
After some deeper thought we came up with a solution that uses current epsilon languages. I post this info hoping someone might find it useful.
In aspect-oriented programing we have three principal elements:
1. Pointcut: Pointcuts determine whether a given condition occur. If the condition is met, the aspect is invoked.
2. Aspect: The code to run when the pointcut occurs. Aspects are runed at a join points.
3. Joint Point: These are the points in a running program where additional behavior can be usefully joined.
The execution framework or machine is responsible for evaluating the pointcuts and running the aspects in the specified Joint Point
In the our case: models, transformations + configurations it can be viewed as:
1. Pointcut: Pointcuts determine whether a given condition occur, pointcuts are determined by a particular configuration. The configuration information is stored in a model. Determining if a condition occur consists of querying the model for a value. If the condition is met, the aspect rule is invoked.
2. Aspect rule: The transformation to run when the pointcut occurs. Aspect rules are ran/invoked instead of the base rules.
3. Joint Point rule: These are the base rules.
The execution framework is the selected transformation language engine.
Within Epsilon this can be seen as:
We consider that the EML engine is best suited for providing the required behavior.
1. Pointcut: ECL rule. The ECL rule allows us to validate if a given condition occur. Here we "compare" our source model (or models) with our configuration model to see if a specific configuration is selected for an element of the source model. The resultant trace of running the ECL rules will have information of all the conditions that where met.
2. Aspect rule: The transformation to run when the pointcut occurs. Aspect rules are ran/invoked instead of the base rules. Since we use the EML engine, merge rules are the equivalent to aspect rules.
3. Joint Point rule: These are the base rules. In this case, base rules are the original ETL rules of the transformation.
It is important to notice that in this case the execution of our approach is a two step process: first, pointcuts are evaluated; second, aspect rules are executed for valid pointcuts.
How this works? The EML engine will use the ECL trace to decide if the aspect rule should be invoked for a specific element of the source model. If the EML engine does not find a match for the specific element it will invoke the joint point rule, provided the EML source includes the ETL rules (this can be easily achieved by doing a #include joinpointrules.etl in the EML source file).
I know this is not so easy to digest but I will gladly discuss it in more detail with any one interested. I think the following step would be to see if it is possible to propose a new epsilon language, and its engine, so that the pointcut and the aspect could be defined in a single rule and to make the process in one step (i.e. evaluate the pointcut and invoke the aspect rule in a single execution). Possibly also making the join point explicit so it does not only depends on the type of the elements of the rule (currently if a match is not found in the trace, the eml engine executes the ETL rule for which the to and from elements have the same type as the merge rule.
Regards,
Horacio Hoyos Rodriguez
Kinori Tech
Need professional support for Epsilon, EMF?
Go to: https://kinori.tech
[Updated on: Tue, 24 January 2012 22:51] Report message to a moderator |
|
|
Powered by
FUDForum. Page generated in 0.02944 seconds
] 
Search
Help
Register
Login
Home
