Home » Modeling » ATL » About stereotype management(Change request)
| About stereotype management [message #1851282] |
Fri, 01 April 2022 11:36  |
 Yves BERNARD
Messages: 146
Registered: July 2014 |
Senior Member |
|
|
In an ATL transformation it is possible to apply a stereotype using the EMF applyStereotype() operation. However if the profile to which the stereotype to be applied belong to has not been applied to a package that contains (directly or indirectly) the target element at the time the operation is executed an error is generated and the transformation fails.
Even if such a check can make sense, it is surprising that it is done in this specific case while they are many other constraints of the target metamodel that are not checked and that may remain violated in the resulting model (e.g. multiplicities).
However, the main issue is linked to the time at which this constraint is checked . The point is that it prevents from using automatic rules when your transformation have to apply stereotypes. Indeed, with automatic rules, one cannot control in which order the elements will be transformed. It is possible to implement some mechanisms that provide workarounds but they greatly increase the complexity of the transformation.
Is there any means to disable this checking and if not, is it something that could be added in a future release?
Thanks
Yves
|
|
|
| Re: About stereotype management [message #1851299 is a reply to message #1851282] |
Fri, 01 April 2022 17:40  |
|
The stereotype/profile check is performed by the UML plug-in, and is implemented in the Java code of the UML metamodel. They chose to perform this validation live, which means that this particular constraint may at no time be violated, even temporarily. As far as I know, the UML constraint validation cannot be configured or turned off.
That means that ATL will just have to work around it. EMFTVM introduced a third execution phase for this reason:
- Matching input elements
- Applying the to block
- Executing the do block
This phase model ensures that all rules' to blocks have been executed before the first do block is executed. When applying a stereotype inside a do block, it is guaranteed that the target model has been completely constructed, and it can be verified that the target element is - directly or indirectly - contained within a Model that has the corresponding profile applied to it.
That said, if you're applying the profile in the same transformation execution as the stereotype for that profile, it is possible that ATL/EMFTVM tries to apply the stereotype before the profile. This depends on rule order and rule inheritance structure. The only safe way to make sure that the profile is applied first, is to apply it in a separate transformation execution. In other words, you need to use a transformation chain.
Cheers,
Dennis
|
|
|
| Re: About stereotype management [message #1851442 is a reply to message #1851299] |
Tue, 05 April 2022 19:48 |
Yves BERNARD
Messages: 146
Registered: July 2014 |
Senior Member |
|
|
Hi Dennis,
Thank you for your answer, even if it's a bad news!
The point is that, according to what I have observed, the precedence of the "to" block on the "do" block applies only within the same rule. However, in most cases the "containment" of one element in the package cannot be managed from within the automatic rule that creates it because that package shall be created by another automatic rule.
Using a preliminary transformation for applying this profile will work only in the case where you don't have to create subpackages structure, and if it is actually the case, using a transformation chain is not necessary because you can do it in the entrypoint rule.
The workaround I use consists in creating in the entrypoint rule a construct of temporary elements that is able to store any element created by the transformation that requires the application of a stereotype. When the rules are executed, their "do" block can applied the stereotypes without error, after having stored them in that construct. Then, in the endpoint rule, those elements are eventually (re)dispatched in their appropriate (and newly created) containers.
A secondary transformation may be used to remove the temporary construct if necessary.
It works, but as I said before, this is quite convoluted... :-/
Yves
|
|
|
| Re: About stereotype management [message #1851822 is a reply to message #1851442] |
Mon, 18 April 2022 19:43 |
|
Yves BERNARD wrote on Tue, 05 April 2022 21:48Hi Dennis,
The point is that, according to what I have observed, the precedence of the "to" block on the "do" block applies only within the same rule. However, in most cases the "containment" of one element in the package cannot be managed from within the automatic rule that creates it because that package shall be created by another automatic rule.
EMFTVM does use three phases for each ATL matched rule: match ("from"), apply ("to"), postApply ("do"). See ExecEnvImpl.matchAllSingle(). In UML2Accessors.atl, rule PublicProperty, a stereotype is applied in a "do" block, so it can be done (it is actually designed to work this way).
That said, lazy rules are not executed in multiple phases, which can give rise to trouble with stereotypes. Lazy rules are executed within the execution phase of the code that calls the lazy rule. Also, an entrypoint rule is executed before anything else, and an endpoint rule is executed after everything else, but you've already figured that out ;-).
Quote:Using a preliminary transformation for applying this profile will work only in the case where you don't have to create subpackages structure, and if it is actually the case, using a transformation chain is not necessary because you can do it in the entrypoint rule.
The workaround I use consists in creating in the entrypoint rule a construct of temporary elements that is able to store any element created by the transformation that requires the application of a stereotype. When the rules are executed, their "do" block can applied the stereotypes without error, after having stored them in that construct. Then, in the endpoint rule, those elements are eventually (re)dispatched in their appropriate (and newly created) containers.
A secondary transformation may be used to remove the temporary construct if necessary.
It works, but as I said before, this is quite convoluted... :-/
I can't really say if your transformation is possible without the workaround. It depends on whether you can construct the full (containment) structure - with profiles applied - of the target model before applying the first stereotype. If not all of your (containment) structure is created by the end of the "apply" phase (i.e. "to" block of all rules executed), then applying stereotypes in "do" blocks can still fail.
Cheers,
Dennis
|
|
|
Goto Forum:
Current Time: Sat Nov 11 08:17:09 GMT 2023
Powered by FUDForum. Page generated in 0.05948 seconds |
] 
Search
Help
Register
Login
Home
