Hi,
This is by design. At least the aspect that the name field is disabled and greyed out on the UML-RT tab. It does not really make sense to redefine a port with another name. It would be rather confusing if the inherited action code from the superclass referenced the port with the name in the superclass, and the local action code added/redefined in the subclass would reference, the same port, with another name (or possibly mixing references both with the original and the redefined name).
The legacy tooling does not allow it either. In RoseRT the name field is also disabled and greyed out. RSARTE have the name field greyed out, but still enabled. So you can change the name of the port in the context of the subclass and "redefine" it. But this causes the port of the superclass to be renamed at the same time. So in practice this is not a redefinition of the name (even though a redefinition is established in the semantic model). The latter behavior in RSARTE I found pretty confusing, and hence I proposed that we should simply make the name field disabled and greyed out (as it was in RoseRT). See
bug 507552 for more information about what should be possible to redefine related to ports and capsule parts.
The other aspect regarding the UML tab is a completely separate, and much more general problem/issue/aspect. What shall we do about the UML tab? Since the UML tab is in practice brought in "as-is" from Papyrus and base UML, with no Papyrus-RT specific customization/adaptation at all, we will get into "issues" like this. I made a comment related to this on the forum, see
this thread for example. I have heard discussions before about removing the UML tab completely, which maybe could be applicable for some specific configuration of Papyrus-RT which will *only* be used for UML-RT, whereas other configurations of Papyrus-RT, where we want to mix UML-RT with UML, probably still should have the UML tab available. Until then, I think that we should make the documentation clear why and what the UML-RT vs. the UML tab should be used for. But yes, the fact that the UML tab is brought in from base Papryus, "as-is" will probably cause confusion and issues like this.
/Peter Cigéhn
