Skip to main content
Jump to: navigation, search

EMF Compare/Specifications/UMLDanglingStereotypes

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.

Copyright © Eclipse Foundation, Inc. All Rights Reserved.