Exported "Open Exchange File" misses nesting relations in view definition

[Clmbs]

Archi Version

5.4.3

Operating System

Windows 11

Archi Plug-ins

jArchi 1.7.0, coArchi 0.9.2 (not relevant for this issue)

Description

For testing purpose I use the following diagram:

When exporting my model via the Archi app (File>Export>Model to Open Exchange File...) the output is correct (style info left out):

<views>
    <diagrams>
    <view identifier="id-bb2a6340fb004fc7b857efa70658681d" xsi:type="Diagram">
            <name xml:lang="nl">Startpagina</name>
            <documentation xml:lang="nl">Startpage</documentation>
            <node identifier="id-bc0d9ca232f245d39e43eb3f5d6406c5" elementRef="id-4a7fd084a6114c9596a4487591452d5b" xsi:type="Element" x="540" y="48" w="180" h="97">
            </node>
            <node identifier="id-0394ba105b51408c86be266e18a44d47" elementRef="id-9e14a26c2c474ba494bfb16820d4f82a" xsi:type="Element" x="570" y="180" w="120" h="55">
            </node>
            <connection identifier="id-c2c487a641b64be1b0f053e40e613140" relationshipRef="id-6ae4dc7278b34be9a343677030397a12" xsi:type="Relationship" source="id-bc0d9ca232f245d39e43eb3f5d6406c5" target="id-0394ba105b51408c86be266e18a44d47">
        </connection>
      </view>
    </diagrams>
  </views>

You see RelationRef is present. But when I nest the Technology Interface into the Node and nothing more

I get the following result:

  <views>
    <diagrams>
      <view identifier="id-bb2a6340fb004fc7b857efa70658681d" xsi:type="Diagram">
        <name xml:lang="nl">Startpagina</name>
        <documentation xml:lang="nl">Startpage</documentation>
        <node identifier="id-bc0d9ca232f245d39e43eb3f5d6406c5" elementRef="id-4a7fd084a6114c9596a4487591452d5b" xsi:type="Element" x="540" y="48" w="180" h="97">
          <node identifier="id-0394ba105b51408c86be266e18a44d47" elementRef="id-9e14a26c2c474ba494bfb16820d4f82a" xsi:type="Element" x="576" y="72" w="120" h="55">
          </node>
        </node>
      </view>
    </diagrams>
  </views>

Here RelationRef is lacking. Of course, it is present in other parts of the xml, but unrelated to the view. Btw, relationships between nested objects are rendered correctly, e.g.

For me, this xml output is very important because I transform it to a MySQL database which is used for analytics and reporting on Architecture progress. So if it cannot be solved I will be looking for a workaround.

Steps to reproduce

1. Create two objects with a composition relationship and nest the composed object into the composing object
2. Export to Open Exchange File
3. Check xml-file and see the in the part this relationship is missing
4. Do the same step but without nesting. Then the xml-file is OK

[Phillipus]

Hi,

The code for this part of the export is this:

archi/org.opengroup.archimate.xmlexchange/src/org/opengroup/archimate/xmlexchange/XMLModelExporter.java

Lines 886 to 913 in 2473902

	void writeConnections(IDiagramModel dm, Element parentElement) {
	for(Iterator<EObject> iter = dm.eAllContents(); iter.hasNext();) {
	EObject eObject = iter.next();
	// ArchiMate connection
	if(eObject instanceof IDiagramModelArchimateConnection) {
	// If it's nested don't write a connection
	if(!isNestedConnection((IDiagramModelArchimateConnection)eObject)) {
	writeConnection((IDiagramModelConnection)eObject, parentElement);
	}
	}
	// Other connection
	else if(eObject instanceof IDiagramModelConnection) {
	writeConnection((IDiagramModelConnection)eObject, parentElement);
	}
	}
	}
	/**
	* Check whether this is a nested connection - assume all nested connections should be hidden
	*/
	boolean isNestedConnection(IDiagramModelArchimateConnection connection) {
	if(connection.getSource() instanceof IDiagramModelArchimateObject && connection.getTarget() instanceof IDiagramModelArchimateObject) {
	IDiagramModelArchimateObject src = (IDiagramModelArchimateObject)connection.getSource();
	IDiagramModelArchimateObject tgt = (IDiagramModelArchimateObject)connection.getTarget();
	return src.getChildren().contains(tgt) || tgt.getChildren().contains(src);
	}
	return false;
	}

Note the comments "If it's nested don't write a connection" and "assume all nested connections should be hidden".

We made the decision some years ago (2015) not to export diagram connections where objects were nested, but I can't remember the reasons for doing this. @jbsarrodie Can you remember? Edit: the reason is that a connection can be inferred from the existence of the relationship in the model and the object is nested inside of the other.

[Clmbs]

Thank you for your fast reply. My point is that I want to do reporting only on the "Publishable" (folder) part of the model, not on views in WIP folders.
I created an aggregation and serving relation between the same objects in another diagram, exported the xml and then imported it as another model. Optically everything looks the same, but when I unnested the object in the original view I saw that the aggregation and serving relations were added there.

So in my transformation script I can identify nested objects based on the xml, but I cannot know whether the relationships between them were modeled in a Publishable or WIP view. Can you advise me on some workaround?

[Phillipus]

The relationship between Node and Technology Interface exists as a relationship in the relationships section of the XML. This is the important part.

To determine if the relationship is referenced as an implicit connection in a View (nested) in the XML you can get the relationship ends (source and target), find the nodes with elementRef that reference these and then if one node is inside the other (nested) then there is an implicit View connection between them.

but I cannot know whether the relationships between them were modeled in a Publishable or WIP view

I don't understand this. A relationship exists in the model whether it is referenced in a View or not. Its existence has nothing to do with its appearance in a View.

[Clmbs]

Thank you very much for your response!

The relationship between Node and Technology Interface exists as a relationship in the relationships section of the XML. This is the important part.
To determine if the relationship is referenced as an implicit connection in a View (nested) in the XML you can get the relationship ends (source and target), find the nodes with elementRef that reference these and then if one node is inside the other (nested) then there is an implicit View connection between them.

I understand and will add these via a SQL stored procedure, but my point was that I cannot relate nested relationships to views if there are more than one. I fully agree that this is not necessary from a model perspective, but as there are various contributors with different levels of experience I don't want to use unchecked/unfinished modeling work for the analytics and reporting dashboards.

Thanks again, if you know the reason behind the design decision I am still curious!

[Phillipus]

if you know the reason behind the design decision I am still curious!

If an element in a View is nested inside of another element and a model relation exists between them then that is the implicit "connection" or representation of the relationship. On the other hand, an explicit line connection can have visual properties. Nesting is a visual representation of a relationship, not something in the model relationship itself.

[jbsarrodie]

(Jumping on this issue)

I agree with @Clmbs that knowing which relationship is the one involved in a nesting is usually needed, because in real (and big) models we might have multiple relationships in the model that could be represented as a nesting, and we might also use a nesting for a relationship while the ArchiMate standard doesn't provide a default semantic (eg. nesting devices into a communication network to represent the associations expressing that the devices are some servers connected to the network and not some network equipments composing the network).

Archi's Automatic Relationships Management (ARM) feature is for me a big added value of Archi vs some other commercial tools.

But this (to my knowledge) is not supported by the current ArchMate Model Exchange File Format, but I can see with other Open Group members if we want to add it into the next version.