Ad/2010-08-01 Concrete Syntax for a uml action Language for Foundational uml (Alf) Second Revised Submission

8.3.9Behavior Invocation Expressions

The same syntax may also be used with the qualified behavior of an association end as the target. In this case, the argument expressions in the tuple give the values for each of the other ends of the association. The result of the expression is a sequence of values of the target end for all links of the association that have the given values for the other ends.

Behavior Invocation

ComputeInterest(amount)

Start(monitor => systemMonitor)

including(Integer[]{1,2,3}, 4)

Association Read

Roster::player(team=>t, season=>y)

Roster.player(t,y)

Owns::house(jack)

Syntax

BehaviorInvocationTarget(e: BehaviorInvocationExpression)
= PotentiallyAmbiguousQualifiedName(e.target)

Figure 8 10 Abstract Syntax for Behavior Invocation Expressions

1. 
   QualifiedName see Subclause 8.2
   
2. 
   PotentiallyAmbiguousQualifiedName see Subclause 8.2
   
3. 
   InvocationExpression see Subclause 8.3.7
   

A behavior invocation expression is evaluated by first evaluating the argument tuple (see Subclause 8.3.8). The completion of the evaluation then depends on whether the target name resolves to a behavior or an association end. The given target name must identify either a visible behavior or an association end within the current scope of the behavior invocation expression. The target cannot be a template, though it may be a binding of a template behavior or association end (see Subclause 8.2).

Behavior Invocation

If the target is a behavior, then arguments are matched with parameters of the behavior as described in Subclause 8.3.8. Normally, each argument expression of the invocation must be statically compatible with the corresponding parameter. That is:

• 
  For an in parameter, the argument expression must be assignable to the parameter (see Subclause 8.8 for the definition of assignability).
  
• 
  For an out parameter, the parameter must be assignable to the argument expression.
  
• 
  For an inout parameter, the argument expression and the parameter must be assignable to each other.
  

• 
  For each classifier template parameter, the argument type is the effective common ancestor of the types of all the argument expressons corresponding to the in and inout parameters of the template behavior that have the classifier template parameter as their type, if such an effective common ancestor exists (see Subclause 8.7 for the definition of effective common anscestor). If a relevant parameter has a multiplicity upper bound greater than 1 and the type of an argument expression is a collection class (see Subclause 11.6), then the type of the result of the toSequence operation of that collection class should be used, rather than the type of the argument expression itself.
  
• 
  If there are no in or inout parameters that have a classifier template parameter as their type, or there is no effective common ancestor of the relevant argument expression types, then the argument type for that classifier template parameter is any.
  

For example, the including function from the standard library CollectionFunctions package (see Subclause 11.5) has the signature

including(in seq: T[] sequence, in element: T):
T[] sequence

The invocation

including(Integer[]{1,2,3}, 4)

is then equivalent to

including(Integer[]{1,2,3}, 4)

Since the literal 4 has type Natural (see Subclause 7.7.2) and the effective common ancestor of Integer and Natural is Integer (since Integer generalizes Natural—see Subclause 11.2.1). The result is a sequence of Integer values.

When a behavior invocation expression is evaluated, the values resulting from the evaluation of each input argument expression are assigned to the appropiate in and inout parameter and the behavior is invoked. Once the behavior completes execution, the result values for each inout and out parameter are assigned to their corresponding output arguments. (Note that these assignments may involve implicit conversions, as discussed in Subclause 8.8.)

If the named behavior has a return parameter, then the behavior invocation expression evaluates to the value of that parameter. The type and multiplicity of the behavior invocation expression are the same as for the return parameter.

If the named behavior does not have a return parameter, then it evaluates to the null (empty) collection. It is untyped with multiplicity [0..0].

Association Read

When an association end name is used in a behavior invocation expression, the association end may be thought of as a function from the values of the other association ends to the values on the target association. Arguments are matched to the ends of the association other than the target end. For the purposes of this matching, the non-target association ends are treated as if they were in parameters. Each argument expression must be statically compatible with the type of the corresponding association end, as described above.

The expression evaluates to all values of the target end of the links of the association whose other ends have the values given as arguments. The type and multiplicity of the invocation expression are the same as the type and multiplicity of the target association end.

For example, given the association

assoc Roster {

public team: Team[*];

public season: Year[*];

public player: Player[*];

}

the expression

or, equivalently,

Roster.player(t,y)

evaluates to the collection of players who played on team t in year y.

The behavior invocation expression notation for reading an association can be used for associations with any number of ends. This is in contrast to the property access expression notation (see Subclause 8.3.6), which can only be used to read binary associations. Of course, the behavior invocation form may also be used to read binary associations. So, for example, the expression

Owns::house(jack)

is equivalent to

jack.house