Description Peter Cigehn 2017-02-06 11:47:24 EST

This is a continued elaboration regarding the aspect of redefining ordinary operations owned by capsules and classes, see Bug 507552 Comment 8. In the legacy tooling the support for redefining operations is only using the limited redefinition support in base UML, i.e. whenever an operation is redefined, its parameter list gets copied, and duplicated, into the subclass. 

So the principle in UML-RT where as little as possible is persisted in the subclass, to avoid duplication, and everything else is inherited from the supercass is not used. The UML-RT specific stereotype RTRedefinedElement, with the rootFragment references is not being used either, only the ordinary redefinedElement/redefinedOperation reference in base UML is beign used.

It should be elaborated, and probably clarified in the UML-RT profile document, which principle should be used in UML-RT for Papyrus-RT.

It is probably beneficial if the same redefinition principle with limited duplication in the subclass can be used for operations as well, including the consistent use of the RTRedefinedElement stereotype to indicate the redefinition.

The main use case for redefinition of operations in UML-RT, when C++ is used as action language, is to perform an override of a virtual function, i.e. the same name and exactly the same parameter list, and you only override the body of the function. It would then of course be beneficial if the parameter list simply was inherited from the operation in superclass, instead of duplicating it.

It should probably be elaborated also whether there is a need for an explicit redefine action on the operation. In the legacy tooling, this is done by right clicking on the inherited operation in the list of operations in the properties view (see Bug 507530 for improvements in the properties view for a capsule to include the list operations, including the inherited operations) and select "Redefine Operation", which creates a redefined operation, with a copy of the parameter list from the superclass operation, including an "empty" opaque behavior (with a TODO comment), which can directly edited in the code snippet view (see  Bug 494288 regarding the code snippet view).

This is however not very consistent to other "gestures" for redefining other elements, e.g. the effect code of a transitions, where the user simply edits the effect code in the code snippet view, and the redefinition of the transition and its effect code is done automatically simply based on the edit gesture of the effect code. The same principle could be used also for redefining an operation, i.e. when you select the inherited operation in the list of operations in the properties view for a capsule/class, and you simply start edit the body code of the operation, then the redefinition is established in the corresponding way as for a transition.