Virtual Connector End - Can't move Doppelganger with Encompassing

[Paolo F Cantoni]

When you create a Virtual Connector End (VCE) the Doppelganger (if visually embedded within an encompassing element) does not have the ability be moved with the encompassing element, even if its Z-order is correct.  Since one of the principal use cases (at least in our view) is to have multiple instances of an item visually embedded in a number of encompassing elements, this causes problems!

These types of problems could be overcome by having REAL t_diagramobjects marked as Doppelgangers.

Reported,
Paolo

[MichelvW]

I see some (old) feature requests and discussions (https://sparxsystems.com/forums/smf/index.php?topic=38768.0) about having multiple instances of an element on a diagram; We are running into the same 'issue'. There is a valid case to be made to create Archimate viewpoints that contain several instances of the same element for (business) readability purposes. Is there any know progress on this matter? Is this feature request on some list somewhere? Or is there anyone who has a feasible workaround (other than using VCE's)?

[Paolo F Cantoni]

I see some (old) feature requests and discussions (https://sparxsystems.com/forums/smf/index.php?topic=38768.0) about having multiple instances of an element on a diagram; We are running into the same 'issue'. There is a valid case to be made to create Archimate viewpoints that contain several instances of the same element for (business) readability purposes. Is there any know progress on this matter? Is this feature request on some list somewhere? Or is there anyone who has a feasible workaround (other than using VCE's)?

Hi, Michel,

With typical self inconsistency, while you can't create multiple instances of the same element on the one diagram, you can (used to be able to) with automation.  However, you are still left with which instance get's which relationship (if they are enabled).  Also, the long-term stability of the diagram is questionable.  That's why, if the VCE functionality were properly implemented, it would provide the correct and viable long-term solution.  But no matter what we as users think, Sparxians have different views, so you're left with the current, unviable VCE implementation.

Paolo

[MichelvW]

Thanks for your reply Paolo. Really interested in how this can/could be/would be achieved with automation. Agree with the relationships part, but isn't that also a question with the VCE 'solution'?

Makes me wonder how tools like Archi, or BizzDesign Enterprise Studio manage this.

[MichelvW]

To answer my curiosity i've created a simple viewpoint in Archi with two instances of one element and two related elements. Initially the two instances get both relations. I've hidden the obsolete ones. Resulting in each instance pointing to one of the related elements. Then i've created an export in the Open Exchange Format.

Code: [Select]

<view identifier="id-4a39575f37e94627a26f4a5f9c3b075e" xsi:type="Diagram">
<name xml:lang="en">Test multiple</name>
<node identifier="id-2490a0804d584b528e2c6c499f2d4edf" elementRef="EAID_5EEBAE39_7008_4a76_B3A8_1E442E87B591" xsi:type="Element" x="167" y="209" w="120" h="55">
  <style>
<fillColor r="245" g="222" b="170" a="100" />
<lineColor r="92" g="92" b="92" a="100" />
<font name="Segoe UI" size="9">
  <color r="0" g="0" b="0" />
</font>
  </style>
</node>
<node identifier="id-2373bc819e2b4c7787f74af03e0af248" elementRef="EAID_5EEBAE39_7008_4a76_B3A8_1E442E87B591" xsi:type="Element" x="372" y="209" w="120" h="55">
  <style>
<fillColor r="245" g="222" b="170" a="100" />
<lineColor r="92" g="92" b="92" a="100" />
<font name="Segoe UI" size="9">
  <color r="0" g="0" b="0" />
</font>
  </style>
</node>
<node identifier="id-65cd74d0dea345cba4b08f5e1ba1843f" elementRef="EAID_D09E70C7_7563_4fff_AB74_A743105DF150" xsi:type="Element" x="156" y="396" w="120" h="55">
  <style>
<fillColor r="245" g="222" b="170" a="100" />
<lineColor r="92" g="92" b="92" a="100" />
<font name="Segoe UI" size="9">
  <color r="0" g="0" b="0" />
</font>
  </style>
</node>
<node identifier="id-02819ca28c7e474eacb0960031eeb571" elementRef="EAID_24873B86_5650_4e39_8569_EBEE18D68836" xsi:type="Element" x="372" y="396" w="120" h="55">
  <style>
<fillColor r="245" g="222" b="170" a="100" />
<lineColor r="92" g="92" b="92" a="100" />
<font name="Segoe UI" size="9">
  <color r="0" g="0" b="0" />
</font>
  </style>
</node>
<connection identifier="id-4109374376e44bf086853e676b2d8a57" relationshipRef="EAID_90E9A7BD_13AE_4d48_B79F_1DEAA131F62A" xsi:type="Relationship" source="id-2490a0804d584b528e2c6c499f2d4edf" target="id-65cd74d0dea345cba4b08f5e1ba1843f">
  <style>
<lineColor r="0" g="0" b="0" />
<font name="Segoe UI" size="9">
  <color r="0" g="0" b="0" />
</font>
  </style>
</connection>
<connection identifier="id-f4bbb55d3016401c9f326797c2dcc6ba" relationshipRef="EAID_60A3BAFE_9A8B_477f_B0BD_85FEED0923A6" xsi:type="Relationship" source="id-2373bc819e2b4c7787f74af03e0af248" target="id-02819ca28c7e474eacb0960031eeb571">
  <style>
<lineColor r="0" g="0" b="0" />
<font name="Segoe UI" size="9">
  <color r="0" g="0" b="0" />
</font>
  </style>
</connection>
  </view>

Findings:
Within the model:
- There's a section with elements (containing element properties)
- There's a section with relationships where source and target are pointing to elements
- There's a section with diagrams (see snippet from my test diagram above)
Within the diagram:
- The instances are stored as nodes with a reference to the element. Notice two nodes with the same elemenRef
- There are connections with a source and target pointing to the nodes. Initially the relationships from the model are copied as connections between nodes on the diagram. These can be altered alter as i did by removing the duplicate connections.