Missing edge tools for managing owned elements

[jerome-obeo]

Although edge descriptions are defined, some edge tools are not defined.

Observed behavior

Create an ActionUsage as a child of a PartDefinition using New object of its contextual menu from the Explorer. Then drag and drop this child ActionUsage in the diagram The composition edge between the ActionUsage and the PartDefinition will automatically be displayed.

Create an ActionUsage on the diagram Drag an edge from this ActionUsage to a PartDefintion. No edge tool palette is presented, and a dependency edge is added between those elements.

Expected behavior

An edge tool palette should be displayed with a Become nested Action tool.

Clue for fixing

The class org.eclipse.syson.diagram.common.view.services.ViewEdgeToolSwitch is in charge of defining all edges tools for elements.

[gdaniel]

I looked into it and there are actually quite a few of missing 'Become nested' tools. As you pointed out these tools are created in ViewEdgeToolSwitch, while UsageNestedUsageEdgeDescriptionProvider instances are created in the diagram description providers (see for example GeneralViewDiagramDescriptionProvider#addCompositeEdgeProviders). Both things (and also the 'Add as nested' tool) need to know about the possible containers of an element, it could be interesting to refactor these methods and extract this "get container candidates" method to factorize this information. This way we could systematically create these tools/edges based on metamodel information, and not add them manually for each created type.

Note that the metamodel is quite permissive (Usage#nestedUsage and Definition#ownedUsage means that an Usage can be contained in any Usage or Definition). It would be interesting to see if:

1. This makes sense w.r.t. the textual/graphical syntax (KerML has some loose references like that which aren't as permissive in practice)
2. These generic references are enough to create the edge/tools we want to create. In this case we can forget about the other nestedXXX references, and the "get container candidates" become quite simple since it won't be based on concrete subtypes.