Community
Participate
Working Groups
Created attachment 250696 [details] PW protected test case Separate profile applications does not work for models split into submodels, like the attached test case, coming from an imported model. When loading the model-with-submodels and its newly separated profile application all the stereotypes are. The reason seem to be that the separate profile application and its stereotypes is not persisted into the profile application file, so the stereotypes are lost in binary space. Everything seem to work fine until you close the model and open it again. Check the attached test case and slides. (PW same as earlier)
Externalizing profiles seems to be okay when the sub-models are packages, because then they have their own profile applications. The problem seems to be with sub-models that are non-packages. However, in this case, I don't find that stereotype applications are lost. Rather, that they aren't extracted from the sub-model resource into the profile-application resource. That certainly is a problem, but it's a different one. The slides included in the attachment don't actually show the steps to reproduce the problem. Could you be more specific about what steps cause the stereotype applications to be lost? Thanks.
I have pushed commit 34c82d81e164fa682c5dd7406e6742a8b721410d that fixes the problem of stereotype applications in non-package model units not being moved into the decorator model resource when a profile application is externalized. Includes JUnit for that scenario and a new regression test verifying that stereotype applications pertaining to repeated profile applications in nested packages are not moved when the application of the same profile at a higher level of nesting is externalized. Still haven't reproduced the problem of stereotype applications being lost entirely.
(In reply to Christian W. Damus from comment #1) > Externalizing profiles seems to be okay when the sub-models are packages, > because then they have their own profile applications. Main initial requirements here are Bug 394887, Bug 399872 and Bug 394833. According to Bug 399872 Comment 3 we can create a submodel for any element. (implicitly including their profile applications) > The problem seems to be with sub-models that are non-packages. However, in > this case, I don't find that stereotype applications are lost. Rather, that > they aren't extracted from the sub-model resource into the > profile-application resource. That certainly is a problem, but it's a > different one. From the user point of view, they are lost. > The slides included in the attachment don't actually show the steps to > reproduce the problem. Could you be more specific about what steps cause > the stereotype applications to be lost? Thanks. It's explained on slide 6, after the profile application have been externalized for the fragmented model: 2) …then close the model open it, and load the Profile Application… It seems to work fine as long as you still work on the in-memory model of it, so something seems to be incorrectly persisted into the model files, since the profile application is lost next time the model and its profile application is loaded.
This bugzilla is still in status UNCONFIRMED btw.
(In reply to Toni Siljamäki from comment #4) > This bugzilla is still in status UNCONFIRMED btw. Right, because I hadn't actually managed to reproduce it. Now I am able to. The problem I had before was that I hadn't noticed that, when I refactored a class a sub-model unit, Papyrus added a redundant application of the profile to the package containing that class (in the parent model unit). When creating a sub-model unit, Papyrus tries to give it its own profile applications so that it can be edited on its own, without having to load it via the parent unit. This works fine for units that are packages, but it seems that it tries the same for units that aren't packages, which probably it shouldn't. Anyways, because of that, when I externalized the profile application, I was only externalizing the application on the root package of the model and this redundant one on a nested package was remaining. Therefore, when closing and re-opening the model, the child (class) unit would load and properly resolve its stereotype applications because the parent unit still had the profile applications that it needed. The externalized profile application had nothing to do with it. So, I repeated the experiment with a twist to come up with a scenario that reproduces this bug: 1. Create a model like so: <Model> root <Profile Application> UML Standard Profile <Package> package1 <<utility>> <Class> Class1 <Package> package2 <<utility>> <Class> Class1 2. Create a new sub-model fragment on Class2. Save --> Note that Papyrus has applied the UML Standard Profile to package2 3. Open the root model unit *.uml file in a text editor and delete the profile application from package2. This makes the model now more like a model imported from RSA, which would not have stand-alone sub-model units with their own profile applications (even for package units). 4. Open the model in the Papyrus editor. See that the <<utility>> stereotype shows as applied on both Class1 and Class2. 5. Externalize the UML Standard Profile application. Save and close the model. --> Observe in a text editor that the profile application is moved to the profile-application model resource but the Class2.uml unit still contains Class2's application of the <<utility>> stereotype 6. Open the model. Observe that neither Class1 nor Class2 shows the <<utility>> stereotype. --> In Class1's case, because the profile-application resource is not loaded --> In Class2's case, because the UML2 API has destroyed the stereotype application because the profile application does not exist that defines it 7. Load the profile-application model. Observe that now Class1 shows the <<utility>> stereotype, but Class2 does not, because in the latter case the UML2 API had destroyed the stereotype application
Now that I have a reproducible scenario as illustrated in comment 5, I can say that the change committed earlier (comment 2) does fix that problem because with that change the stereotype applications of a non-package unit are now correctly moved into the profile-application resource. Also, in the case that Papyrus creates the redundant profile application for the class unit in the parent unit (the fragmented model is not imported from RSA), I can assert that externalizing the profile application of the root package has no effect on the nested package's application of the same profile nor on the stereotypes of any of its contained elements, including the class unit. Which is all as it should be.
I think the dependency relationship with bug 459488 is rather the other way around.
YES, Halleluja!!! It seems to work now, almost, but something weird is going on... :( Been testing and investing this for some time. The problem is the same for the fragmented and non-fragmented test model. 1) Externalize the profile application for the test case model. 2) Unload the profile application. 3) ...or close the model an open it without loading the profile application. 4) Check the first class, then its 1st activity, then the 1st AcceptEventAction. Stereotyped AcceptEventAction's are still stereotyped?! I REOPEN this one. I guess you need to help me open a new bugzilla before closing this one... I don't know what the problem is, and if there are other possibly-stereotyped kinds of elements that would be missing from the externalized profile application. Something is wrong here...
Another strange thing is that those stereotyped AcceptEventAction's are stereotyped in Model Explorer, but not in the Properties view. :(
Maybe there is a need for _several_ new bugzillas here, right?
(In reply to Toni Siljamäki from comment #8) > > 1) Externalize the profile application for the test case model. > 2) Unload the profile application. > 3) ...or close the model an open it without loading the profile application. > 4) Check the first class, then its 1st activity, then the 1st > AcceptEventAction. > > Stereotyped AcceptEventAction's are still stereotyped?! This is because of a regression in the creation of new stereotype applications that was caused by the profile externalization feature. New stereotype applications were always being created in the resource containing the profile application, not the resource containing the base element extended by the stereotype application. The two can be different in Papyrus in the case that * the stereotype is applied to an element in a sub-model unit that is not a package (because the sub-model unit cannot contain the profile application, itself) * the stereotype is applied to an element in a sub-model unit that is imported from another tool such as RSA that does not re-apply profiles to sub-unit packages as Papyrus does The referenced commit fixes this problem, with a new JUnit test case to catch further regressions in this behaviour. So, because the stereotype applications were being created in the parent unit, I suspect that the externalization of the profile application (before the comment 2 commit that fixed the externalization algorithm) somehow missed them and so didn't move them into the profile-application model. I can't reproduce any problem with activity action stereotypes in externalized profiles in the absence of sub-model units. Are you sure this happened to you also in models that are all in one unit? > I REOPEN this one. Okay, I re-resolve it. :-) > I guess you need to help me open a new bugzilla before closing this one... I don't know why you would need help creating new bugzillae. But in this case, we don't need a new one.
(In reply to Toni Siljamäki from comment #9) > Another strange thing is that those stereotyped AcceptEventAction's > are stereotyped in Model Explorer, but not in the Properties view. :( I think the Model Explorer and the Properties views use different APIs to determine the applied stereotypes. The one that Model Explorer uses can report stereotypes as applied even if there is no profile application that would make them applicable (a gap in the UML2 API). There may already be a bugzilla about this discrepancy. If not, it would certainly be a different bugzilla as it is obviously unrelated to this one.
PHEW!!! Problem solved. :) The "problem" comes from the imported model. There are AcceptEventAction's with a certain named stereotype applied. But in this (+ other) Activity Diagram the AcceptEventAction's have instead been given a keyword with the same name as the stereotype. Those keywords becomes annotations on the elements: <node xmi:type="uml:AcceptEventAction" xmi:id="_gp8IkFzqEeO_VaMkIu9tTQ" name="TimeAdv" outgoing="_uiPuoI-dEeGXMYTlyF02gA"> <eAnnotations xmi:type="ecore:EAnnotation" xmi:id="_gp8IkVzqEeO_VaMkIu9tTQ" source="http://www.eclipse.org/uml2/2.0.0/UML"> <details xmi:type="ecore:EStringToStringMapEntry" xmi:id="_gp8IklzqEeO_VaMkIu9tTQ" key="HiveGOTOlabel"/> </eAnnotations> </node> ...but in Model Explorer they get displayed as stereotypes <<HiveGOTOlabel>> and (of course) remain in the model after the profile application is unloaded, so in Model Explorer it looked like there were still stereotypes in the model. Very confusing... These keywords (annotations) can only be found when digging deep down in the model using the "advanced ModelExplorer". Keywords is an issue handled separately. This one is fixed and works fine. :) Thanx.
Oh, that is interesting. Thanks for following this up. Do you suppose the keywords were somehow automatically added to replace stereotypes that once were applied but for some reason became nonviable? I wonder whether Papyrus needs to look out for that in the importer to implement the reverse substitution...
> Do you suppose the keywords were somehow automatically added to replace stereotypes that once were applied but for some reason became nonviable? I wonder whether Papyrus needs to look out for that in the importer to implement the reverse substitution... I doubt so, unless UML itself does it, but I've never experienced that for any profile. My guess is that these keywords already exist in the source model, and are migrated as-is.
(In reply to Camille Letavernier from comment #15) No, the UML2 API doesn't do anything like that. I thought maybe that RSA did and this might be why the source model has these keywords. Entirely speculation on my part, but I thought it worth mentioning.
The keywords are input to transformations. Perhaps the keywords were added to the model before updating the profile with a corresponding stereotype. We will stereotyp'ify all different keywords where needed.
