UMLR — UML 2.5: UML redefinition mechanism insufficiently granular

The current mechanism for redefining the elements of a classifier is not refined enough for cases where the redefined elements are complex hierarchical namespaces. As presently defined, in those situations, the mechanism results in needless duplication that creates maintenance difficulties and excessive memory overhead.

To illustrate the problem, take, for example, the perfectly reasonable scenario where we have a high-level (e.g., abstract) state machine (which is a kind of Class), which we would like to refine in a subclass by adding a new state to one of its nested regions. This is achieved via the state machine redefinition mechanism as specified in section 14.3 of the 2.5 spec, which is based on the standard UML::RedefinableElement abstraction. In UML, a State is part of the namespace of a Region, which is either part of the namespace of a containing hierarchical State or, in case of the topmost Region, of the StateMachine itself. To add a State using this mechanism, it is necessary to redefine (i.e., “extend”) the Region defined in the superclass to which we wish to add the new State. Unfortunately, because of the all-or-nothing nature of the current redefinition mechanism, it is not sufficient to simply define a new redefining Region and include the new State within it. Because of the insufficient granularity of UML redefinition, it is also necessary to clone all the other elements that currently exist in the redefined region (i.e., all States, Pseudostates, Transitions, etc.). Furthermore, because the redefined Region is part of a higher-level namespace (State or StateMachine), that namespace must also be redefined, since it now contains a different Region than the original one. Which, in turn, requires redefinition of the next higher namespace (with all the requisite cloning), and so on. This chain of cloning redefinitions must necessarily continue all the way up to the topmost Region of the StateMachine, terminating in an almost complete clone the original StateMachine, even though we only wanted to add a single State to the original StateMachine.

Needless to say, cloning presents a maintenance issue, since any changes in a superclass have to be propagated to all the affected clones in all the subclasses. Even worse, this approach results in potentially large and completely unnecessary memory overheads.

It seems that redefinition should be based on an incremental approach, just like inheritance. That is, only the differences from the redefined element should be explicitly specified in the redefining element, while everything else existing in the namespace of the redefined element should be implicitly “inherited”.