Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

EMF Compare/Specifications/StereotypedElementChangePostProcessor

Evolution Specification: Creation of differences for UML profile dsl

Current status is DRAFT

Introduction

Profiles are more and more used to create DSL. This means that a UML element which is stereotyped should be handled as a single semantic element:

  • Atomic merge.
  • It should handle and display the same way stereotype attribute differences and base class attribute differences.

The aim of this evolution is to improve the way stereotyped elements are handled by EMF Compare to help a better integration of UML DSL profiles.

Detailed Specification

In order to create the previous described features we have to focus on two tasks:

  • Core:
    • Create a new type of difference which is able to link the based element and the stereotype applications.
    • Handle the merge of those differences.
  • UI:
    • Improve the way stereotype attributes are displayed.
    • Find a way to displayed the newly created difference in the structure merge viewer as it was an atomic element.
    • Create or reuse a filter to hide unnecessary differences.

Here are the requirement for those tasks:

  • CORE_010: If EMF Compare detects both the creation of the base element and an application of a stereotype (of the new created element) it should create a new "header difference". This difference should be a UMLDslElementChange of kind ADD.
  • CORE_020: If EMF Compare detects both the deletion of the base element and a removal of a stereotype (of the deleted element) it should create a new "header difference". This difference should be a UMLDslElementChange of kind DELETE. TBD since each time a UML element will be deleted all its stereotypes will be removed automatically
  • CORE_030: If several stereotypes are applied "in the same time" on a newly created base element then EMF Compare should only create one difference handling all stereotypes.
  • CORE_040: If several stereotypes are removed "in the same time" on a deleted base element then EMF Compare should only create one difference handling all stereotypes.
  • CORE_050: A UMLDslElementChange should be stored under the same element as the difference of base element creation/deletion. TBD
  • CORE_060: A UMLDslElementChange should be refined by the difference of the creation/deletion of the base element and by all the differences of stereotype application/removal on this element.
  • CORE_070: A UMLDslElementChange should keep track of the base element creation/deletion difference (discriminant) and all the stereotype application/removal differences (new feature) for UI uses.
  • CORE_080: Merging a UMLDslElementChange should merge both the base element difference (creation/deletion) and all stereotype application differences (application/removal).
  • UI_10: ALL stereotyped element should be displayed as described bellow.
  • UI_20: A difference on a stereotyped element should have its label built like described bellow:
LABEL :=  STEREOTYPE_LABEL," ",BASE_ELEMENT_LABEL," ", ACTION_NAME
STEREOTYPE_LABEL := "<", STEREOTYPE_CLASS_NAME, ("," , STEREOTYPE_CLASS_NAME)*, ">" //Name of all stereotyped being applied on current element
BASE_ELEMENT_LABEL := NAMED_ELEMENT_NAME | "" //If the base element is a Named_Element then display it's name if not nothing
ACTION_NAME := "[",DIFFERENCE_KIND," ",FEATURE_NAME,"]"
  • UI_30 := A match element of a stereotyped element should have its label built like described bellow:
LABEL :=  STEREOTYPE_LABEL, " ", BASE_ELEMENT_LABEL
STEREOTYPE_LABEL := "<", STEREOTYPE_CLASS_NAME, ("," , STEREOTYPE_CLASS_NAME)*, ">" //Name of all stereotyped being applied on current element
BASE_ELEMENT_LABEL := NAMED_ELEMENT_NAME | "" //If the base element is a Named_Element then display it's name if not nothing
  • UI_40 : External components should be able to specify an icon for a stereotyped element.
  • UI_50 : A difference or a match of a stereotyped element should be displayed with a custom icon. To select it EMF Compare should use the following algorithm:
    • FOR ALL: Stereotypes try to get a custom icon:
      • IF A custom icon has been specified for this stereotype (in the profile model) then use it THEN BREAK
      • ELSE IF The stereotype is a static stereotype and a ItemProvider has been provided then use the icon define inside THEN BREAK
    • IF still no icon selected use the icon of the base element.
  • UI_60: A stereotyped element property should be displayed the same way a base element property is. That is to say:
    • It should be displayed under the base element.
    • It should have the same kind of label.
    • It should have the same kind of icon.
  • UI_70: A StereotypedElementChange should hide all differences it refines (creation/deletion of the base element and application/removal of its stereotypes).
  • UI_80: A StereotypedElementChange should have its icon set to the stereotype icon like described in UI_50 .
  • UI_90: A StereotypedElementChange should have its label built like described in UI_20.
  • UI_100: The application/removcal of a new stereotype should not use the rules describe above.

Backward Compatibility and Migration Paths

No migration needed.

Metamodel Changes

Creation of a new element in UMLCompare.ecore :

  • UMLDslElementChange -> UMLDiff
    stereotypeApplications [0..*] : EObjects

User Interface Changes

See UI_* requirements.

Documentation Changes

A new section on the documentation should be created.

Back to the top