Jargon "Virtualized Connector" is a (weird) implementation of clear requirements

[adepreter]

End users sometimes want to create several views of the same element on the same diagram.
They also want to tell which connector needs to be visible for each view on the element (diagram object).
They don't want to create a "virtual connector". How could they think about such terminology when searching the documentation?
=>

1) Bug: The documentation provides documentation on the implementation i.e. "virtual connector"
It should instead on the end user's feature i.e. getting several views on the same element on the same diagram.

2) Questioning the implementation
Why not creating virtual diagram objects instead of "virtual connectors". These virtual diagram objects would not visible in the project browser (like text, boundary etc...)??
Users would then explicitly hide the connectors they don't what to see for the virtual object.
So it would be also more flexible for the end-user.
And it would be a direct implementation of the requirement.

[Paolo F Cantoni]

Ah yes, Alain,

The perennial problem of the language of the code NOT representing the concept involved.   Who'd have thought that there should be consistency between what the code implies it does and what it actually does?

As our colleague says...
Concistency, konsistency, consistensy! ^TM_{Uffe - after Paolo}

Paolo

[RoyC]

I was developing a long and detailed argument about this, but I don't have the time. Quickly, I think you have two requirements and you are saying that the very simple solution (the Virtual Connector End) for one requirement (show that element X in the top left of the diagram has a relationship with element Y far away in the bottom right of the diagram) should be the solution to a different requirement (I want to show different views of element X). For that requirement, one solution is to create instances of element X on your diagram and modify each accordingly.

[Paolo F Cantoni]

I was developing a long and detailed argument about this, but I don't have the time. Quickly, I think you have two requirements and you are saying that the very simple solution (the Virtual Connector End) for one requirement (show that element X in the top left of the diagram has a relationship with element Y far away in the bottom right of the diagram) should be the solution to a different requirement (I want to show different views of element X). For that requirement, one solution is to create instances of element X on your diagram and modify each accordingly.

I was talking about the API method VirtualizeConnector which actually virtualizes the connector end (doesn't it?).
It may be Alain was also talking about that also.  In the English Language version (at least), the UI clearly states that you are Virtualizing the Connector End.

Paolo