Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
EMF Compare/Specifications/UMLDanglingStereotypes
Contents
UML Dangling Stereotypes
This specification page has been created to resolve the problem raised by https://bugs.eclipse.org/bugs/show_bug.cgi?id=467866.
The problem comes from UML dangling stereotypes in UML models. UML dangling stereotypes happen when a stereotype linked to a model element is still in a model while the model element has been removed.
Papyrus automatically detects and fixes dangling stereotypes by removing them.
Currently, such changes are wrongly detected and displayed as ResourceAttachmentChanges in the comparison models, and displayed to users as "uncontrolled from xxx.uml".
| Example | BEFORE | AFTER |
|---|---|---|
| LEFT MODEL |
ModelA <<Block>> ClassA <<Block> Stereotype |
ModelA |
| RIGHT MODEL |
ModelA <<Block>> ClassA <<Block> Stereotype |
ModelA <<Block> Stereotype |
Proposal
Core
A new type of ResourceAttachmentChange will be created in the org.eclipse.emf.compare.uml2/model/uml2compare.ecore metamodel. It will be a DanglingStereotypeApplication.
No specific merge work will be done on DanglingStereotypeApplication. That means DanglingStereotypeApplications will be mergeable from left to right or right to left (and accept/reject) without specific control. Thus, the dangling references could be merged into a "clean" model and make it "dirty".
UI
The DanglingStereotypeApplications will be displayed in red to warn users that there is problem(s) in their models. As a ResourceAttachmentChanges, DanglingStereotypeApplications will be displayed under MatchResources.
Cases
Possible Evolution
As a possible evolution, specific work could be done on merge to handle case where classes exist on one side and dangling references on the other side (see case XXX above), in order to "re-connect" class to their stereotype application.