-
|
Up to now - at least up to v4.11 (I didn't checked 4.12) -, it is necessary to have the profile applied on an owning package before it is possible to apply a profile. If it could globally make sense to require this consistency at the end of the transformation, requiring it at any time is actually problematic. Indeed, since we didn't control the order of execution of the transformations, it is impossible to make sure the profile is already applied to the package when transformations will have to apply stereotypes to the element it owns directly or indirectly. Because of this, we its requires convoluted processing and post-processing in order to get the expected result. Is there any way to release this constraint? |
Beta Was this translation helpful? Give feedback.
Replies: 6 comments 2 replies
-
|
I retrieved this old discussion that, I think, we had together with Dennis: https://www.eclipse.org/forums/index.php/t/1109920/ However, I struggle in understanding how UML2Accessors.atl can actually works better. Indeed, at the time applyStereotype() is executed in the "do" section of the public PublicPropertySingle is executed the "setDep" element has potentially no owner defined since UML2Accessor.atl is not a refinement |
Beta Was this translation helpful? Give feedback.
-
|
Investigating further, I tried to check the owner of an UML Datatype in the "do" section" of the rule that create it, and where I would like to apply a stereotype. I got this error message:
If the test of the owner is removed, I got back the initial error message: I can fix the issue by generating a temporary package in the entry rule and applying it the required profile. In the "do" section of my rule above, I "push" my created DataType in that temporary package before applying the stereotype: So, if the actual owner of the created element is not "readable" at that time, it's unlikely that it can be used by UML2 to check whether the proper profile is applied or not. How does it works, actually? |
Beta Was this translation helpful? Give feedback.
-
|
Let's start with the first problem: can the profile/stereotype constraint verification be postponed until after the transformation is complete? From the perspective of the developers of the Eclipse UML Plugin: no. They've implemented the UML constraints by enforcing every constraint to hold as changes to the model are made. This makes sense for any UML editors built on top of the UML Plugin, as UML itself forces you to follow the correct order of things, and guides you one error at a time. If you were to postpone validation until the end, it may not be clear how to solve all the errors you've created all at once. Simply put: postponing validation is more difficult to implement in the tool as well as more difficult to deal with as the user of a UML editor. The UML Plugin developers are therefore unlikely to change this, especially for some model transformation tool that is not part of UML. Consequently, it is up to ATL to deal with the quirks of specific metamodels, such as UML. Because UML constraints prescribe certain model changes to happen in a certain order, ATL attempts to provide language constructs to exert some control on execution order: entrypoint rules, to blocks, do blocks, endpoint rules. As noted in the linked ATL forum thread, however, the Profile had to be applied in a previous transformation execution, before its Stereotypes could be applied in a second transformation execution. The transformation modules in this thread were not refinement transformations, and therefore the target UML model had to be built up far enough for the constraints to hold by the time any of the Profile- or Stereotype-specific code was invoked. This only worked because of how the rules were ordered in the transformation modules, which influences the order in which the rules are executed. It is not advisable to rely on the order in which individual rules are executed, as this order may be jostled by spreading rules across different modules, and importing them from other modules. Instead, one can best rely on the order of the execution phases of an ATL transformation (for matched rules):
If you apply a Profile in phase 3, such as in UML2Profiles.atl, it is better to start a new transformation for applying stereotypes, rather than relying on rule execution order within phase 3. In UML2Accessors.atl, the stereotypes (and tagged values) are also applied in phase 3, which works because the entire model has already been copied in phase 2. Finally, the "Cannot read properties of ..., as it is contained in an output model" constraint comes from ATL itself, and has nothing to do with UML specifically. It has been introduced to prevent people from creating conditional code within rules that relies on the state of the output model, therefore creating intricate and possible cyclic ordering constraints on the rules themselves. Reading your own output does not make sense for a mapping-style transformation, where all input is matched at most once. Only in a rewriting-style transformation does reading your own output make sense, as you recursively build your output (and ordering is not an issue, as rules are re-applied as long as they match). If you really want to introspect your output model for debugging purposes, you can adapt the transformation's launch configuration to specify the target model as an in/out model instead of an output model. |
Beta Was this translation helpful? Give feedback.
-
|
Hi Dennis, |
Beta Was this translation helpful? Give feedback.
-
|
I found the solution! EMF provides an utility class: org.eclipse.uml2.uml.util.UMLUtil that expose a static operation named safeApplyStereotype() that has the following description : "Safely applies the specified stereotype to the specified element, i.e. applies the profile if not already applied" I tried it using the refInvokeStaticOperation() provided by ATL in the "do" section and it works! |
Beta Was this translation helpful? Give feedback.
-
|
That's great news! That indeed solves most - if not all - of the headache related to stereotypes! |
Beta Was this translation helpful? Give feedback.
-
|
Yes, even if there is a side effect: there are ProfileApplication added in almost all packages in the resulting model! |
Beta Was this translation helpful? Give feedback.
-
|
Additional comment: In order to tackle the issue completely, I had to set up a mechanism that postpone the management of stereotypes in the endpoint rule. |
Beta Was this translation helpful? Give feedback.
I found the solution!
EMF provides an utility class: org.eclipse.uml2.uml.util.UMLUtil that expose a static operation named safeApplyStereotype() that has the following description : "Safely applies the specified stereotype to the specified element, i.e. applies the profile if not already applied"
I tried it using the refInvokeStaticOperation() provided by ATL in the "do" section and it works!