[2397] Display requirement derivations as edges in the General View

[kkkk1258999]

Fixes #2397

Follows the approach agreed in the issue: correct the shared connector-end resolution, then add a dedicated derivation edge.

Shared fix: connector end resolution
The ends declared with the end keyword inside a connection body are imported as plain FeatureMemberships owning a feature with isEnd = true, while getConnectorEnd() only collected the ends owned through an EndFeatureMembership. Every such end was filtered out, so connectorEnd, relatedFeature, sourceFeature and targetFeature were all empty.

KerML defines endFeature as the owned features having isEnd = true, an EndFeatureMembership being one syntactic form implying it, so both forms are now collected. The logic is duplicated between ConnectorImpl and ConnectorAsUsageImpl because of multiple inheritance, and both have been updated consistently.

Requirement derivation edge
SysML v2 has no dedicated metaclass for requirement derivation: it is a ConnectionUsage annotated with #derivation, or typed by DerivationConnections::Derivation. Three query services were added on MetamodelQueryElementService and exposed to AQL through ModelQueryAQLService:

isRequirementDerivation, recognizing both forms;
getDerivationOriginalEnd / getDerivationDerivedEnd, resolving the ends from the #original and #derive metadata they carry, falling back on the end order declared by DerivationConnections::Derivation when the ends are not annotated.
Resolving the ends from their metadata rather than from their declaration order keeps the direction correct whatever order the ends are written in.

RequirementDerivationEdgeDescriptionProvider renders the derivation from the derived requirement to the original one, as a dashed edge labelled «derive» with an arrow toward the original requirement, so it is distinguishable from the solid «satisfy» edge. Derivations are excluded from the generic ConnectionUsage edge precondition so a single edge is rendered.

Regression coverage
ConnectorEndTest (metamodel):

ends owned through EndFeatureMembership resolve;
ends owned through a plain FeatureMembership resolve;
an owned feature with isEnd = false is not returned as an end.
Each case checks connectorEnd, relatedFeature, sourceFeature and targetFeature.

MetamodelQueryElementServiceTest:

a #derivation connection is recognized, a plain one is not;
the ends are resolved from their metadata, including when the derived end is declared first;
the end order fallback applies when the ends carry no metadata.
GVRequirementDerivationEdgeTests (General View):

a derivation between two displayed requirements renders one edge, directed from the derived requirement to the original one, labelled «derive», dashed, with an arrow toward the original requirement;
the same model with the ends declared in the reverse order renders the same edge in the same direction;
exactly one visible edge is rendered and its description id is the derivation edge, so the generic connection edge does not duplicate it.

[AxelRICHARD]

Hello @kkkk1258999, thank your for providing this PR.

SysON is an eclipse project and as such, you must sign the Eclipse ECA or I won't be able to merge this PR.

Otherwise, it seems you followed our commit messages formatting rules, that's great!

Regards,

[kkkk1258999]

One note on the direct edit tool check that was failing: the «derive» label
is a constant, like «satisfy», «frame», «assume» and «require», so I kept the
edge without a direct edit tool and excluded it from the check instead, which
is how those edges are handled. I filtered it by description name rather than
by domain type, because the derivation edge shares its ConnectionUsage domain
type with the generic connection edge, whose label is the connection name and
must stay editable. Happy to add a direct edit tool instead if you prefer.

[AxelRICHARD]

One note on the direct edit tool check that was failing: the «derive» label is a constant, like «satisfy», «frame», «assume» and «require», so I kept the edge without a direct edit tool and excluded it from the check instead, which is how those edges are handled. I filtered it by description name rather than by domain type, because the derivation edge shares its ConnectionUsage domain type with the generic connection edge, whose label is the connection name and must stay editable. Happy to add a direct edit tool instead if you prefer.

No, it's ok like that, thank you.

[AxelRICHARD]

Thank you @kkkk1258999 for this contribution, we appreciate!

What would be great, is to provide (in a separate issue/PR) the edge tool allowing to create a derive Connection between two Requirements. If you have the time to do it, it would be great, if not it's ok I will do it at some point.

Thank you again.

Regards,