Bug 512809

Description Peter Cigehn 2017-02-28 07:23:38 EST

Now when a fix for Bug 492356 and its related Bug 509653 in Papyrus have been merged, it becomes evident that the same kind of issue as identified in Bug 50926 also exist for ports (and partly capsule parts).

The most critical aspect is that if you create a port based on a system protocol, then the (too) advanced editor for a port cannot resolve the system protocol (in the run-time model library). Instead an error marker is put on the port, and an additional comment element is created in the model owned by the port. This is just plain confusing and gives a really bad user experience, since the user have done nothing at all in practice.

Steps to reproduce:

1) Create a UML-RT model based on the "UML-RT for C++" template.
2) Create a capsule in this model
3) Create a new port in this capsule using the "New UML-RT Child" menu
4) When the popup appears, select one of the system protocol (Frame, Log, or Timing)
5) The port is created and the direct editor is activated for the port
6) Now either just click somewhere else (or possibly press return) to leave "edit mode".
7) Observe how an error marker appears on the port and how comment element (owned by the port) gets created in the model

The reason seem to be that the direct editor is not able to resolve the system protocol in the run-time model library. If a port based on a (new or existing) user defined protocol, then no error marker is put on the port.

Suggestion is to replace, or override, the current edit for port, and also capsule part, with a simple name editor, in the same was as it was solved for the direct editor for a transition (as tracked by Bug 476365). 

Preferably this should be done already for the 0.9 release to reduce the bad user experience this will have when someone creates a port based on a system protocol (vid the new child menu in the model explorer).

If needed, at a later point in time, a new improved, but still simplified editor could be introduced for ports and capsule parts, e.g. that includes the possibility of changing the type (which then of course needs to handle the aspect with system protocols). Initially though, it should be sufficient with just being able to change the name.