Community
Participate
Working Groups
UML allows to redefine feature values of redefinable elements, such as properties. Technically, a redefinition is a plain UML element -- the redefining element -- that references another UML element via RedefinableElement.getRedefinedElements(). Both elements must have the same type, which in turn must be a sub-class of RedefinableElement. Every feature value of this redefining element overwrites -- "redefines" -- the respective feature value of the redefined element. Imho, from a users' point of view, the following cases that are not adequately addressed by EMF Compare's default behavior have to be addressed: 1. If a redefining element is added or deleted, users would like to see the affected redefined values rather than the addition / deletion of the plain redefining element which doesn't explicitly reveal what has been redefined or which redefinition has been deleted. 2. If an existing redefining element is changed or a new one is added that introduces redefining values, the displayed original value of the redefined feature should be the one of the redefined element rather than the default element of the redefining element, which would be the default behavior. 3. If a redefining element is added on both sides for the same redefinable element in a three-way comparison, EMF Compare will see two added, independent UML elements, whereas they should eventually be joined into one redefining element. 4. If a redefining element is added on both sides for the same redefinable element in a three-way comparison, there may be conflicts, depending on whether the same feature values are redefined to be different values in the added redefining elements. The conflict should not be between the two additions but rather only between the two contradicting redefinitions of feature values. Would you agree with this list? Am I missing use cases? Currently, I have troubles getting my head around how to deal with changes concerning elements that redefine multiple other elements. What should be displayed or happen during the merge in the cases below? Are these even valid use cases? If not, should we fall back to how EMF Compare would deal with that generically? * Concurrent additions of new redefining elements that have an overlapping but unequal list of RedefinableElement.getRedefinedElements(). * Changes in the list of RedefinableElement.getRedefinedElements() at existing redefining elements, which implicitly may add/remove multiple redefinitions of feature values.
The UML-RT implementation in Papyrus-RT supports only single inheritance and single redefinition. So, I think the last two scenarios mentioned in comment 0 need not be a concern: they could just fall back to the standard EMF Compare behaviour. I like the idea of the visualization of differences showing only the specific attributes that are redefined. This reinforces the notion that an inherited element already implicitly exists in the inheriting context, so that "adding" redefinition is really only modifying attributes of that redefinition. That happens to be how we've actually implemented it in our metamodel, but that's not important.
I think that this sounds like reasonable. I just made a quick test of the legacy compare/merge tool and as you indicated in case 1, redefining the first value of an element, e.g. redefining the type of a port, only gets displayed as a port being added to the subclass (which does not say much, since the user in practice only changed the type of the inherited port). So this would be an improvement over the legacy compare/merge tool.
Thanks for your feedback! One additional feedback that I'd like to record here is the "overlap of customization" between redefinition and opaque behaviors: <quote author="Christian Damus"> In general, in UML-RT, we use the capability of RedefinableElements from UML to link model elements to the definitions that they redefine. So, for example, a Transition that in the state machine of a subclass overrides its inherited effect code is created as a redefinition that references the parent state machine’s transition as its redefinedTransition and gets the «RTRedefinedElement» stereotype applied to it. Also, because the effect is an OpaqueBehavior that, like all behaviours in UML, is redefinable, the overriding effect likewise references the redefined transition’s effect as a redefinedBehavior and has the stereotype applied. </quote>
