ST6RI-717 Function operation expressions are incorrectly parsed as OperatorExpressions

[seidewitz]

According to the KerML Specification, a “function operation expression” of the form x -> f(y, z, ...) should be parsed as a regular InvocationExpression, equivalent to f(x, y, z, ...). However, the implementation had been parsing this as an OperatorExpression, but with no value for the operator. This was both incorrect per the grammar in the specification, and it violated the mandatory operator property. This PR revises the parsing of function operation expressions so they are properly parsed as InvocationExpressions but not OperatorExpressions.

Background

In the specification grammar, the syntax for function operation expressions is given by the production:

FunctionOperationExpression : InvocationExpression =
    ownedRelationship += PrimaryExpressionMember '->'
    ownedRelationship += ReferenceTyping
    ( ownedRelationship += BodyExpressionMember
    | ownedRelationship += FunctionReferenceExpressionMember
    | ArgumentList )

However, since a FunctionOperationExpression is one of the alternatives of PrimaryExpressionMember, this production is left recursive and cannot be directly handled by the Xtext parser. Xtext provides tree rewrite actions to allow such left-recursive syntax to be implemented. To make it tractable to use this tree rewrite actions for the KerML expression grammar, a special non-normative operand feature was implemented for OperatorExpressions, allowing an operand Expression to be directly inserted into the parse tree without having to explicitly create a FeatureMembership for it in the grammar. This mechanism was also being used to parse function invocation expressions, even though they are not actually OperatorExpressions.

Resolution

1. The CustomUML2EcoreConverter in the org.omg.sysml.uml.ecore.importer project is updated to insert the operand feature into the EClass InvocationExpression, rather than OperatorExpression, in the generated Ecore metamodel.
2. The implementation mechanism for operand is moved from OperatorExpressionImpl to InvocationExpressionImpl.
3. The production PrimaryExpression in the grammar KerMLExpression.kerml has been updated so that function operation expressions are correctly parsed as InvocationExpressions but not OperatorExpressions:

   ...
     | {SysML::InvocationExpression.operand += current} '->' 
       ownedRelationship += ReferenceTyping 
       ( operand += BodyExpression 
       | operand += FunctionReferenceExpression 
       | ArgumentList
       )
   ...

[seidewitz]

@himi I don't think this will have any effect on the visualization code, but I thought you might want to take a look at it anyway.

[himi]

@seidewitz, thank you. At least I'll check how it works with the current visualizer.