RSART- Redefined operations don't propagate param changes

As part of the review process, we strive to be transparent about our intentions with each enhancement suggestion.

This idea is either outdated or has been implemented in one of the versions. Please check with latest version (V 12.0 at the time of writing)

The offering team has carefully reviewed this idea and has decided that it does not fit into our current plans, so the idea will be closed. The idea will be kept in IBM's ideas repository and may still be voted on. It might be reassessed or reopened for additional feedback in the future. We value your feedback and thank you for allowing us the privilege of partnering with you in developing our products.

Due to processing by IBM, this request was reassigned to have the following updated attributes:
Brand - WebSphere
Product family - Application Platform
Product - Software Architect Real Time Edition

For recording keeping, the previous attributes were:
Brand - Rational
Product family - Design & development
Product - Software Architect Real Time Edition

Unfortunately the UML representation is to duplicate the signature for a redefining operation. So each operation has its own signature representation, even an operation that redefines another operation and hence has exactly the same signature. Perhaps we should implement this RFE in two steps. The first step would be to extend the current way we propagate operation name changes to also cover other changes in the signature, but still limit this propagation to only work for loaded operations. The second step could then be to implement the proper refactoring command that would be able to update the signatures also for unloaded operations. If you agree with this approach we will investigate accordingly.

We can see the usefulness of this, but we typically load the open models into memory first, prior to doing anything else. The initial problem is that when we do so, we see a change to the base class function name take affect in redefined functions. We do not see the same change in parameters take affect.

We were hoping that something similar to how TC inheritence was being done- that the efx file on disk would have a link to the parent function, and have nothing else in that efx file aside from things that are overriden within that redefinition.

For example, looking at a TC file on the disk shows that the copyright field is not anywhere in that file, as it is provided by the parent TC. We could override it, which adds to the file, but for any non-overriden things, any updates to the parent get pushed down to the the child.

Currently planned for 8.5.1 CP2. We need to add a new refactoring in the Refactor context menu. The propagation cannot be automatic as this would force all models to be loaded (i.e. it would be slow).

Under Consideration