MARTE11 — VSL - Absence of rule for calling behaviors

VSL doest not provide a rule for expressing behavior calls (i.e., it only supports call of operations). Since Behaviors are first class citizen of UML2, there is no fundamental reason for preventing this kind of expressions. Integrating a rule for calling behaviors does not require much effort (cf. following proposed resolution).

Proposed resolution:

• Modify text of B2.4 p.431 (p.443 of the pdf)
  Between paragraph starting with “An Operation Call Expression…” and paragraph starting with “This metamodel does not define…”, insert the following paragraph:
  A Behavior Call Expression refers to a behavior defined in a UML Namespace. The expression may contain a list of argument expressions if the behavior is defined to have parameters. In this case, the number and types of the arguments must match the parameters.

• Modify figure B.4 p.432 (p.444 of the pdf) as follows:
  . Add a class BehaviorCallExpression, and a generalization relationship between this class and Expression
  . Add a composition relationship between BehaviorCallExpression and ValueSpecification, identical to the composition relationship between OperationCallExpression and ValueSpecification (this is to capture the arguments of the call)
  . On the diagram, add an abstract class Behavior, with a grey background like classes Property and Operation.
  . Add an association between BehaviorCallExpression and Behavior, identical to the association between PropertyCallExpression and Property, except that the name of the role should : definingBehavior
  . Add the following derived property to BehaviorCallExpression: /behavior:String

• In section B.3.3.13:
  Replace:
  <expression> ::= <variable-call-expr> | <variable-declaration> | <property-callexpr>

  <operation-call-expr>	<conditional-expr> By: <expression> ::= <variable-call-expr>	<variable-declaration>	<property-callexpr>
  <operation-call-expr>	<behavior-call-expr>	<conditional-expr>

• p.453 (p.465 of the pdf), insert the following section (and increment the number of remaining sections):

// Beginning of section
B.3.3.17 Behavior Call Expressions
Behavior calls are particularly used in the MARTE context to call behaviors taking data type values as parameters.

<behavior-call-expr> ::= <behavior-name> '('[ <argument-value> [','<argument-value>]* ]')’
<behavior-name> ::= [<namespace> '.'] <body-text>
<namespace> ::= <body-text>

Expression typing
• The <behavior-call-expr> production rule should be evaluated to the type of the UML::Behavior that is called.
• The <argument-value> production rule must be evaluated to the corresponding to UML::Parameter's type of an existing UML::Parameter owned by the UML::Behavior.

Abstract syntax mapping
• The <behavior-call-expr> production rule maps to the BehaviorCallExpression domain element described in Annex F (Section F.13.XX).

Disambiguating rules
• <behavior-name> should correspond to an existing UML::Behavior name.
//end of section

• In annex F, insert a section F.13.1 as follows (and increment of remaining sections):

// beginning of section
F.13.1 BehaviorCallExpression (from Expressions)

Generalizations
• Expression (from Expressions) on page 560

Associations
• definingBehavior: Causality::CommonBehavior::Behavior [1]
Called Behavior.
• argument: VSL::ValueSpecification [*]

Arguments of the Operation Call.

Attributes
• /behavior: String [1]
String with the qualified name of the called Behavior. This is a derived value obtained from the definingBehavior.

Semantics
A Behavior Call Expression refers to a behavior defined in a UML Namespace. The expression may contain a list of argument expressions if the behavior is defined to have parameters. In this case, the number and types of the arguments must match the parameters.
// end of section

The absence of rules for calling behaviors indeed introduces an artificial limitation to the
applicability of VSL. Concretely, all the available behavior signatures are currently defined
following the object-oriented paradigm, in the form of operations (e.g., String.concat(String)),
belonging to data types of the standard MARTE libraries. These behavior signatures could
alternatively be defined following a procedural style (e.g. concat(String,String)). Designers who
are familiar with procedural languages would probably feel more comfortable with this approach.
Since UML natively offers support for describing behavior signatures in the procedural style, VSL
should not prevent the usage of this kind of behaviors, and a rule should be added to support call
of behaviors. The following figure illustrates the differences between the two paradigms, from
both the perspective of libraries definitions (left hand side of the figure) and the perspective of
usage in VSL (right hand side of the figure).