CreateAction links to only one classifier. It should be multiple.

Decline

Summary: A synchronous action is defined as a request where the sending
object pauses to wait for results. Synonym: synchronous request [OMA].

1) The OMA is not specific on this issue, but the understanding in
CORBA is that a request is only specific with respect to a thread.

• So, in UML, does the sending object truly pause to wait for results?
• Or is it just a thread of that object that pauses for results?
  (in that case, the definition should be clarified)

2) Another possible interpretation of a synchronous action is that
such a request is always associated with a response (contrarily to
an asynchronous request which has no associated response ?).
The sending object has then an obligation to collect that response.

If that interpretation was true, then synchronous action would
map to both synchronous request and def

Fixed in adopted spec

The Alf standard says
"A return statement may only be used within the definition of a behavior that has a return parameter."
We think it must be allowed to always use a return statement. If the context behavior has no return parameter then no expression should be provided in the return statement.

This is a duplicate of Issue 16419.

The signature of replaceOne is :
replaceOne<T> (in seq: T[*] sequence, in element: T, in newElement: T): T[*] sequence

The direction of parameter “seq” should probably be “inout”.

agreed

Currently, the signature of CollectionFunctions::removeAll is:

removeAll<T> (inout seq: T[*] sequence, in element: T)

According to the associated description, it should probably be (taking into account issue 16426 which requires a return parameter):

removeAll<T> (inout seq1: T[*] sequence, in seq2:T[*] sequence) : T[*] sequence

And the description should also be corrected to read “Remove all elements of seq2 from seq1” (“from” instead of “to”).

agreed

I think there is a typo page 184:

Difference

(in seq1: any[*] sequence,

in seq2: any[*] sequence nonunique):

any[*] sequence

it’s not necessary to show “nonunique” for seq2.

I don’t recall having seen something about that in existing issues (sorry if I missed it). I’ll raise an issue for that.

agreed

Need to replace the CMOF file for the abstract syntax by a UML file for UML 2.4

Agreed, the Alf abstract syntax is supposed to be based on UML 2.4.

The Model file includes the UML Primitive Types package rather than referencing it.

This occurs in the Alf Standard Library model XMI file. This file actually contains a spurious UML package, with a nested AuxiliaryConstructs, with PrimitiveTypes nested within that (as well as a number of other, empty packages). This included UML package should be removed. Note that all primitive type references elsewhere in the file already use hrefs with normative URIs, not references to the nested PrimitiveTypes package

The abstract syntax defined in Section 8.3.7 (Invocation Expressions) and
Section 8.3.9 (Behavior Invocation Expressions) will not match this
expression...

this.monitor.getActiveSensor().getReading()

(NOTE: the above expression is used as an example in Section 8.5.6 - Isolation
Expressions)

The issue seems to be that the definition of InvocationExpression does not
repeat.

Here is the current definition for InvocationExpression...

InvocationExpression= InvocationTarget Tuple
InvocationTarget= BehaviorInvocationTarget

Maybe the definition for InvocationTarget should be something like this?...

InvocationExpression= InvocationTarget Tuple

The expression “this.monitor.getActiveSensor().getReading()” is not a behavior invocation expression, it is a feature invocation expression. The production needed is the one for FeatureInvocationTarget in Subclause 8.3.10:

FeatureInvocationTarget(e: FeatureInvocationExpression)
= FeatureReference(e.target) | "this"

The expression given in the issues parses in full as follows:

FeatureInvocationExpression
FeatureInvocationTarget
FeatureReference
FeatureTargetExpression
NonNamePrimaryExpression
InvocationExpression [ <- Note recursion on InvocationExpression here ]
FeatureInvocationExpression
FeatureInvocationTarget
FeatureReference
FeatureTargetExpression
NonNamePrimaryExpression
PropertyAccessExpression
FeatureReference
FeatureTargetExpression
NonNamePrimaryExpression
ThisExpression
NameBinding
Name
“monitor”
NameBinding
Name
“getActiveSensor”
Tuple
NameBinding
Name
“getReading”
Tuple