|
|
|
| Re: Bug in default trace resolution? [message #1856653 is a reply to message #1856465] |
Wed, 21 December 2022 08:54   |
 Yves BERNARD
Messages: 146
Registered: July 2014 |
Senior Member |
|
|
I have investigated further on this issue and my conclusion is that it comes from either a bug in the SysMLv2 pilot implementation or, at least, an incompatibility between that implementation and the way ATL reference the model elements internally.
Indeed, I discovered that I can succeed in getting the specialization relationships transformed if I implement my own "ad hoc" traceability mechanism.T his was set up easily by creating a global map that way:
helper def: elementMap: Map(String, OclAny) = Map{};
Then, the generic rule for the classifiers was modified in order to register any created UML::Classifier together with the xmi:id of its source element in the "do" section:
abstract rule FromClassifierCommon extends FromNamedElement {
from src: SYSML2!Classifier
to tgt: UML!Classifier (
isAbstract <- src.isAbstract
)
do {
thisModule.elementMap <- thisModule.elementMap->including(src.__xmiID__, tgt);
}
}
Based on this, I modified the rule for the specialization in order to rely on this global map:
unique lazy rule FromSpecialization {
from src: SYSML2!Specialization
to tgt: UML!Generalization (
__xmiID__ <- src.getStableID()
,general <- thisModule.elementMap->get(src.general.__xmiID__)
,specific <- thisModule.elementMap->get(src.specific.__xmiID__)
)
}
With this new version, the UML::Generalization relationships are properly created.
Then, as an experiment, I modified the global map so that it uses direct object references rather than xmi:id strings as keys:
helper def: elementMap2: Map(OclAny, OclAny) = Map{};
I adjusted the rest of the code accordingly but I cannot make this version work because the map is unable to retrieve the key corresponding to the reference of the source element registered before.
I also witnessed that this issue with element reference is not limited to specialization relationships. It looks like it impact any element reference like, for instance, feature redefinitions.
My best guess at that point is that the references to the objects that the SysMLv2 pilot implementation provides are not stable. I don't think that there is any bug in the ATL engine here.
Yves
|
|
|
|
|
|
| Re: Bug in default trace resolution? [message #1858167 is a reply to message #1858153] |
Sat, 18 March 2023 22:19 |
|
Ah, that sounds like an EMF aliasing problem, where the same model is loaded twice via alternative routes. If the URI via which you load your external file is different from the URI that results from following the href reference, then EMF will consider the href'ed model as a different model than the preloaded model, and load it all over again inside a different EMF Resource. ATL will transform only the elements inside expressly loaded models, while the SYSML2!Specialization references a model element in the separate, href'ed model.
I haven't managed to run your example yet: the SysMLv2 pre-release I downloaded and imported seems to be very slow to build... no .kermlx models, just .kerml models...
Cheers,
Dennis
|
|
|
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.02449 seconds
] 
Search
Help
Register
Login
Home
