An Alf-Text can be transformed into an Element of a model (e.g. an Activity). Both representations are equivalent. Nonetheless it makes sense, to store both representations, since both might have user defined formating, that we want to preserve. The specification defines a means for this:

[the original Alf text is stored] by attaching a comment to the top-level element resulting from the processing of an Alf model unit with the Alf text for the unit as the body.

This asks for the Alf model unit, which is not included on full conformance level:

Full Conformance. Conformance at this level requires the ability to process all the syntax defined in Clauses 8 and 9, but none of the syntax defined in Clause 10 [Units].

suggested addition

A tool supporting only full conformance level (that doesn't include units) may show the behavioral constructs only.

problem
This means there will be two ways how a Textual Representation will show up in the xmi-file. This may cause problems for the interoperability. Maybe we can define, that however the tool displays a Textual Representation, the serialization should always include the full Alf Unit.

Hi,

there is this really minor bug, that on page 308 is some text "This page is intentionally left blank" in the background.

Best,
Christian

Annex A.3 Composite Structure discusses (non-normatively) the use of Alf with UML composite structure models. This should be updated, now that the Precise Semantics of UML Composite Structures (PSCS) specification has been adopted, providing a formal fUML-based semantics for composite structures.

Defer

The RTF agrees that this is an issue worth considering, but, due to lack of time, decided to defer its resolution to a future RTF working on this specification.

Annex A.3 Composite Structure discusses (non-normatively) the use of Alf with UML composite structure models. This should be updated, now that the Precise Semantics of UML Composite Structures (PSCS) specification has been adopted, providing a formal fUML-based semantics for composite structures.

Several of the operations in the collection classes require that two general objects can be compared for equality (one example is Collection::includes).
The standard should clarify how the equality comparison is done. Will the equality operator == always be used, or is it possible for the user to define the condition for how to compare objects of a user-defined class?
If the equality operator == is used for all objects, this will limit the usefulness of the collection library. For some kinds of objects a comparison based on object identity is not appropriate.
We propose that object identity comparisons is only the default for class objects, and that it can be customized by defining an equals operation in the class.

Why not include Model to Text for generating ALF for (a subset of) UML?

It would be very good if the ALF standard could support a syntax for defining local names with "composite semantics". That is, names for which the value will be automatically destroyed when leaving the current scope. As it is now, objects for local names need to be created explicitly with 'new' and then destroyed explicitly by calling a destructor on the object. It is a very common pattern that objects only should live while inside a particular scope, and then it is error-prone to have to destroy all such objects manually.
Note that the proposed syntax must be within the minimum conformance subset of the language. Our proposal is to use a syntax similar to the following:

auto<MyClass> var = new MyClass();

When we read chapter 9.12 we conclude that the traditional for-statement of languages such as C/C++ and Java, is not supported by Alf. Only for-statements that iterate based on collections are supported now.
We think the traditional for-statement with loop variable initialization, termination condition and iteration step should be supported. For example
for (Integer i = 0; i < x; i++)

We are missing an Alf statement corresponding to the UML RaiseExceptionAction. Such a statement is needed in order to raise exceptions from Alf code. The syntax should be within the minimum conformance subset ("throw").

There should be an Alf statement that allows to define an exception handler for a block. The syntax should be within the minimum conformance subset (try - catch).

Why not include Model to Text for generating ALF for (a subset of) UML?

Defer

The RTF agrees that this is an issue worth considering, but, due to lack of time, decided to defer its resolution to a future RTF working on this specification.

When we read chapter 9.12 we conclude that the traditional for-statement of languages such as C/C++ and Java, is not supported by Alf. Only for-statements that iterate based on collections are supported now.
We think the traditional for-statement with loop variable initialization, termination condition and iteration step should be supported. For example
for (Integer i = 0; i < x; i++)

Defer

The RTF agrees that this is an issue worth considering, but, due to lack of time, decided to defer its resolution to a future RTF working on this specification.

There should be an Alf statement that allows to define an exception handler for a block. The syntax should be within the minimum conformance subset (try - catch).

Defer until fUML provides exceptions

The semantic basis for Alf is fUML, and, as of v1.2.1, fUML does not provide a specification of the semantics for exceptions. While exception raising and handling would be useful in Alf, its inclusion is deferred until the semantics for this are specified in fUML.

We are missing an Alf statement corresponding to the UML RaiseExceptionAction. Such a statement is needed in order to raise exceptions from Alf code. The syntax should be within the minimum conformance subset ("throw").

Defer until fUML provides exceptions

The semantic basis for Alf is fUML, and, as of v1.2.1, fUML does not provide a specification of the semantics for exceptions. While exception raising and handling would be useful in Alf, its inclusion is deferred until the semantics for this are specified in fUML.

It would be very good if the ALF standard could support a syntax for defining local names with "composite semantics". That is, names for which the value will be automatically destroyed when leaving the current scope. As it is now, objects for local names need to be created explicitly with 'new' and then destroyed explicitly by calling a destructor on the object. It is a very common pattern that objects only should live while inside a particular scope, and then it is error-prone to have to destroy all such objects manually.
Note that the proposed syntax must be within the minimum conformance subset of the language. Our proposal is to use a syntax similar to the following:

auto<MyClass> var = new MyClass();

Defer

The RTF agrees that this is an issue worth considering, but, due to lack of time, decided to defer its resolution to a future RTF working on this specification.

Several of the operations in the collection classes require that two general objects can be compared for equality (one example is Collection::includes).
The standard should clarify how the equality comparison is done. Will the equality operator == always be used, or is it possible for the user to define the condition for how to compare objects of a user-defined class?
If the equality operator == is used for all objects, this will limit the usefulness of the collection library. For some kinds of objects a comparison based on object identity is not appropriate.
We propose that object identity comparisons is only the default for class objects, and that it can be customized by defining an equals operation in the class.

Defer

The RTF agrees that this is an issue worth considering, but, due to lack of time, decided to defer its resolution to a future RTF working on this specification.

The Alf 1.0.1 specification still references fUML 1.1, even though the latest version of fUML (at the time of the creation of this issue) is 1.2.1. Alf 1.1 should reflect the latest version of fUML at the time the new specification is completed (at least fUML 1.2.1, but, more likely, fUML 1.3).

Change fUML reference to v1.3

Actually, the resolution to issue ALF11-68 already updates the fUML version to 1.2.1. However, the fUML 1.3 RTF is now finishing its work, so it makes sense to further update the referenced fUML version to 1.3. This requires both changing the cited version under Clause 3 Normative References and changing certain sublause references throughout the document, since a number of new subclauses were added to the fUML 1.3 specification, changing the number of some old subclauses.

Issue ALF11-44 points out that the multiplicity conformance rules currently in Alf allow a behavior or operation with a mandatory parameter (multiplicity lower bound greater than 1) to be called with a null value for that parameter. The result is not an error, but that the behavior or operation is not actually invoked – and that it does not produce any results on its output and return parameters, not even a null token. The proposed solution is to add a "null coalescing" operator to Alf and to then tighten the multiplicity conformance rules.

While a null-coalescing operator would, indeed, be useful to handle the identified problem, it does this at the expense of being backward incompatible. The tightened multiplicity rules would make illegal many invocations that are now legal, especially since the default parameter multiplicity in UML is 1..1, but local names get a multiplicity lower bound of 0. This could require that usage of the null-coalescing operator be inserted in a lot of places, which would be annoying.

An alternate approach would be to better track the statically known multiplicity and typing of local names, based both on their latest assignments and on certain statically analyzable Boolean expressions (such as checks for null and for type classification). Since, many times, calls involving mandatory parameters will already be surrounded by such statically analyzable checks, this would allow these calls to remain legal, and such typical paradigms to continue to be used, even with the tighter multiplicity rules.

Adjust local names for multiplicity and typing

The problem addressed in this issue can be highlighted by a simple example:

activity GetNextLine() : String[0..1];

activity WriteNextLine() {
    line = GetNextLine();
    WriteLine("Next line: " + line);
}

According to the rules of Alf 1.0.1, the local name line is given the multiplicity 0..1. This is allowable in the string concatenation but, since line has a multiplicity lower bound of 0, the derived multiplicity lower bound for the result of the concatenation is also 0. Again, this is currently statically allowable for an argument to the WriteLine activity, even though the declared multiplicity of the in parameter for that activity is 1..1.

However, the return parameter of the GetNextLine is declared to be 0..1, meaning that it may return null. If it does, line is then assigned null, but there is no “null pointer exception” when line is used in the next statement. Instead, due to the UML semantics of null as meaning “no value”, the null value for line essentially gets propagated. Because the string concatenation operator receives no value ("null") for its second operand, it cannot execute, so the concatenation expression also does not produce a value. The call to WriteLine thus receives no input value and, because its input parameter has multiplicity 1..1, it cannot execute, either. The result is that nothing is printed, not “Next line:”, not even a carriage return. Most people seem to find this behavior unexpected.

There are a number of possible ways to avoid this behavior by specifically testing whether line is null. Here are three of the possible alternatives:

// Alternative 1
activity WriteNextLine() {
    line = GetNextLine();
    if (line == null) {
        line = "<none>";
    }
    WriteLine("Next line: " + line);
}

// Alternative 2
activity WriteNextLine() {
    line = GetNextLine();
    WriteLine("Next line: " + (line == null? "<none>": line));
}

// Alternative 3
activity WriteNextLine() {
    line = GetNextLine();
    if (line == null) {
        WriteLine("No next line");
    } else {
        WriteLine("Next line: " + line);
    }
}

Each of these alternatives represents a common paradigm for avoiding this problem, similar to the approaches used to avoid a null pointer exception in other languages. However, since the original version produces subtle and unexpected behavior at runtime, rather than some obvious exception, it would be preferable to make the original version statically illegal by disallowing an expression with multiplicity lower bound of 0 from being an argument for a mandatory parameter. Unfortunately, this would also make all three of the above alternative versions illegal.

A null-coalescing operator, as proposed in issue ALF11-44, could be used to make the above alternatives legal again. However, this would require modifying working code for no functional change. It would also be particularly pointless in the third alternative, in which an entirely different message is written if line is null.

What would be more desirable instead would be to track more carefully the statically known multiplicity of a local name after each assignment/reassignment and based on simple tests such as line == null. In this case, it could be determined that, in each of the above alternatives, the second operand expression in the string concatenation expression could never actually be null at that point, and so that operand expression can be considered to have a multiplicity lower bound of 1. In this case, it would be possible to strengthen the multiplicity conformance rules such that the original version of this example would be illegal, while allowing each of the presented alternatives to remain legal.

In addition, since casting in Alf "filters out" values that cannot be cast, rather than producing a cast exception, cast expressions can also result in null (if everything is filtered out). For example, consider the following:

abstract class A;
class B specializes A;
class C specializes A;

activity getA() : A;
activity doSomethingB(in b: B);
activity doSomethingC(in c: C);

activity doSomething() {
    a = getA();
    if (a instanceof B) {
        doSomethingB((B)a);
    } else if (a instanceof C) {
        doSomethingC((C)a);
    }
}

This is currently legal, even though the cast expressions (B)a and (C)a have multiplicity lower bounds of 0 (because, e.g., (B)a would result in null if the value assigned to a was actually of type C), while the in parameters to doSomethingB and doSomethingC have multiplicity 1..1 (by default). But, with tighter multiplicity rules, both of the doSomethingB and doSomethingC calls would become illegal, unless it was also tracked that a is actually known to have the subtype B in the first clause of the if statement and subtype C in the second clause. Indeed, if this were tracked, then it would be possible to allow the use of a in each of the calls without having to do a cast at all.

Finally, it should be possible to track local name multiplicity and type classification information based on compound conditions using, at least, conditional-logical and Boolean negation operators. For instance, it should be possible to deduce from a != null && a instanceof B both that a is not null and that a has the subtype B. (Note that the UML object classification action in UML presumes a non-null object input.) This should be a sufficient level of analytical capability for the language at this time. More sophisticated analysis could be added in the future, if experiences shows its worth.

By default, the multiplicity of a parameter in UML is 1..1, indicating that a value is required for that parameter. A call action for an activity or operation with such a mandatory parameter will not fire unless a value is provided for that parameter. Since Alf behavior and operation invocation expressions map to call actions, if an argument for a mandatory parameter evaluates to null, the behavior or operation will simply not be called, and the entire expression then evaluates to null. This is usually unexpected behavior.

Alf rules currently allow an expression with multiplicity lower bound of 0 to be used as an argument for a parameter with multiplicity lower bound greater than 0. This is because it is often the case that an expression that statically has multiplicity lower bound of 0 is really known at run time to be non-null. For example, the expression a != null? a: 1, presuming a is a local name, is statically determined to have multiplicity lower bound of 0 (because that is the lower bound of the second operand a). Dynamically, however, the expression will never really evaluate to null.

It would be useful for Alf to have a specific operator that checks a value for null and, if it is null, provides an alternate value for it. Such an operator exists in a number of current programming languages, and is generically known as a "null coalescing" operator. The symbol "??" is used for this operator in, e.g., C#, Swift and PHP. With such an operator, the example above would be notated a??1, which could be easily given a static multiplicity lower bound of 1 (that of the second operand 1), without having to do any fancy analysis of conditional expressions and possible paths.

If such an operator existed in Alf, it would then also be possible to strengthen the rule for argument multiplicity to invalidate the use of a possibly null argument for a mandatory operation, since the null coalescing operator could always be used to provide a non-null argument. This would prevent the kind of non-intuitive invocation behavior described at the outset.

Add a null-coalesing operator

As discussed in issued ALF11-77, introduction of a null-coalescing operator is not absolutely necessary for resolving the problem identified in this issue. Nevertheless, presuming the tightening of multiplicity conformance rules proposed in the resolution to ALF11-77, it would still often be useful to have a null-coalescing operator.

Further, given the adoption of multiplicity and type tracking, as also proposed in the resolution to ALF11-77, it would not be necessary require the inclusion of null-coalescing expressions at the Alf minimum conformance level. If, on the other hand, null-coalescing expressions were to be adopted along with the tighter multiplicity rules, but multiplicity and type tracking were not adopted, then it would be necessary to include null-coalescing expressions at the minimum conformance level, because, otherwise, there would be no way to get around the multiplicity checks by dynamically checking for null. And this would be a problem, since Java syntax does not include a null-coalescing operator, and Alf minimum conformance is suppose to reflect a common syntax with Java.

In subclause 9.8 "if Statements", under Semantics/Names it says "New local names may only be defined in the clause blocks of an if statement that has a final else clause and then only if the same names are defined in every clause." This effectively prevents the use of local names even for values needed only within just one clause of an if statement, or defining such local names at all in the case of an if statement without an else clause. There is a similar rule for switch statements.

This is inconsistent with the rules for local names defined in, e.g., while statements. In subclause 9.10 "while statements", under Semantics/Names, it states "Local names within the body block of a while statement may be used within that block, but they are prohibited from being used outside the block. This is because they could be uninitialized if the while statement does not execute its body." This is a more convenient rule, covering basically the same concern for uninitialized local names as in the case of if statements.

The rules for local names defined in if and switch statements should be eased and made consistent with the rule for the body of a while statement.

Make local name definition rules consistent

In 9.1 (Overview for Clause 9 Statements) it states that "The scope of...local names is generally from the point at which they are defined lexically to the end of the statement sequence, though there are special rules for conditional statements...and loop statements...." The simplest thing to do would be to just remove the special rules for conditional statements and loop statements. Rather than have (somewhat complicated and currently inconsistent) rules for what local names are defined after conditional and loop statements, local names first defined within conditional and loop statements would always continue to be defined in statements lexically after the conditional or loop statement. In the case that the conditional or loop clause within which the local name is defined is not actually executed, then the value of the local name would simply be null. This is also consistent with the overall design decision for Alf to not have "block scoping" of local names (per the general rule quoted above) and to not require declaration of local names before their first assignment.

In order to map this, any clause of an if or switch statement that does not contain a definition of a name defined in some other clause would be mapped with a value specification action that generated a null value for the name. There would actually not need to be any update to the mapping of for loop statements, since, in this case, the loop node mapped from the statement already has an output pin for any name defined within it, and this will simply be empty ('null") if not set because the body of the loop did not execute.

While not mentioned in the issue (or, currently, in 9.1), there are also similar special rules for names defined in the blocks of accept clauses of compound accept statements. These rules can also be removed, with mapping handled similarly to the case of conditional statements.

Further, to be consistent, the rules for conditional logical and conditional test expressions should also be changed in a similar way. That is, local names defined only in a single the conditionally-evaluated operand of these expressions should be allowed, with their value being null if the operand is not evaluated. (This will also fix a problem with the current mapping of conditional logical expressions, which is done in terms of equivalent conditional text expressions, but which does not take into account that the restrictions on local names are not actually currently consistent between conditional logical and conditional test expressions.)

Clause: 13 Expression Abstract Syntax

In general, constraints for expressions to be of a certain standard primitive type should, instead, allow them to be of a type that conforms to the required type. This allows for user-defined primitive types that are subtypes of the standard types

Loosen certain constraints requiring standard primitive types

Agreed.

Specification: Action Language for Foundational UML (Alf): Concrete Syntax for a UML Action Language, FTF-Beta 2 (ptc/2012-08-43)

Once Alf has been updated to be semantically based fUML 1.1 (see Issue 18393), Alf should also be updated to support the new Real type from UML 2.4.1 that is included in fUML 1.1. This would require both updating the Alf Standard Model Library to provide a RealFunctions package of primitive behaviors and the core Alf syntax and semantics for typing by Real and for operations involving Real values.

Add Real support

Adding support for Real expressions and functions to Alf is an involved but extremely important update to the language. The proposal is to update the language as follows:

1. Add real literals to the lexical structure of the language. The syntax of these literals should be consistent with the textual syntax given for LiteralReal in UML 2.4.1, subclause 7.3.29/UML 2.5, subclause 8.2.4, with two exceptions:
   a) underscores should be support between digits, as in Alf natural literals, and
   b) a decimal point should be required if there is no exponent part, to avoid ambiguity between natural literals and real literals. (It is also considered sufficient to only support decimal notation for real literals.)
2. Add real literal expressions as a new kind of literal expression.
3. Import the RealFunctions package from the Foundational Model Library to the Alf Standard Model Library.
4. Add a ToReal function to the IntegerFunctions package, to convert an integer value to a real value. (Rationale: The Foundational Model Library does not actually provide an IntegerFunctions::ToReal function. However, it does provide an IntegerFunctions::'/' function that divides two integer values, producing a real value. It is thus possible to convert an integer value to a real value by performing real division by the integer value 1. But the Alf syntax already uses / for truncating integer division of integer values, and introducing another operator for real division of integer values would be difficult. Therefore, it is more straightforward to include a ToReal conversion function, whose functionality is equivalent to dividing by 1 using the fUML IntegerFunctions::'/' function.)
5. Add a real conversion condition that allows the assignability of an Integer-typed element to a Real-typed element, with the integer value converted to a real value using the IntegerFunctions::ToReal function introduced above. (Rational: The UML primitive type Integer is not a subtype of Real, so integer values and real values are not at all formally related in the UML type system. However, mathematically, integer values are a subset of real values, and a typical user expectation is that "1" represents the same number as "1.0". Automatic real conversion maps integer values to corresponding real values, so that a user can consider the set of integers to be essentially "embedded" in the set of reals. Automatic conversion is not provided in the other direction, from Real to Integer, though, since there are a number of ways to truncate or round real values to integer values, and it is better that the user chooses explicitly how to do this. This is consistent with the situation that would exist if Integer was a subtype of Real – up-casting from Integer to Real would be automatic, but down-casting from Real to Integer would require an explicit cast or conversion.)
6. Update the semantics of sequence construction expressions to allow Integer-typed elements to be used, with real conversion, in the context of constructing a sequence of real values.
7. Update the constraints on increment and decrement expressions and numeric unary expressions to allow operands of type Real.
8. Update the constraints on arithmetic and relational expressions to allow operands of type Real. Also allow the case in which one operand is of type Integer and one is of type Real, with automatic real conversion performed on the Integer operand. (Rationale: This is consistent with the introduction of real conversion for assignability.)
9. Update the semantics of equality expressions for the case of one operand of type Integer and one of type Real, such that real conversion is performed on the Integer operand before the equality test. (Rationale: The underlying fUML test identity action used to define the semantics of the Alf equality operator always produces false when comparing values of types unrelated by generalization. Since Integer and Real types are not so related, an integer value is never considered equal to a real value by this action. Thus, as equality is currently defined, the Alf expression 1 == 1.0 would evaluate to false, which would probably be unexpected by most users. By introducing automatic real conversion, this expression becomes equivalent to IntegerFunctions::ToReal(1) == 1.0 or 1.0 == 1.0, which is true, as would be expected.)
10. Allow real values for tagged values in stereotype annotations.

Subject: Sequence feature invocation expressions

Subclauses: 8.3.10 Feature Invocation Expression, 13.2.17 FeatureInvocationExpression

· A feature invocation expression with a primary whose multiplicity is 0..1 should not be considered a sequence feature expression, since the optionality is handled without the need for an expansion region.

· Subclause 8.3.10 states that a sequence feature invocation expression is equivalent to a sequence expansion (collect) expression for the invocation. However, local names may not be assigned within the argument expression of a sequence expansion expression (because a sequence expansion expression maps to an expansion region, and fUML does not allow flows out of such regions other than through output expansion nodes). For a sequence feature invocation expression, the invocation tuple is repeatedly re-evaluated inside the argument expression of the equivalent sequence expansion expression. Therefore, local variable assignments should not be allowed within the expressions in the tuple of a feature invocation expression.

These changes should also be accounted for in the constraints in Subclause 13.2.17.

Add constraint for sequence feature invocations

It is NOT agreed that "As feature invocation expression with a primary whose multiplicity is 0..1 should not be considered a sequence feature expression". The semantics for a feature invocation with a primary of multiplicity 0..1 should at least be consistent with the case of the limiting case of invocation of a sequence of multiplicity 0..1. But this requires, in the case that the actual cardinality is 0, that not only does the call not take place, but any tuple expressions are also not evaluated. Further, the expression should have an actual "null" result, not just "no execute" (as would be the case of a call operation or send signal action without an object input value). The simplest way to ensure such consistent semantics are to treat the case of mulitplicity 0..1 as a sequence feature invocation.

However, it IS agreed that, in the case of a sequence feature invocation, assignments should not be allowed in tuple expressions.

Under Semantics/OperationCall for Feature Invocation Expressions, step 3 is to "select the most specific operations". Note that this is plural, indicating that there may be more than one. The paragraph following step 3 states that "If there is a single operation remaining...this is the operation to be called", and a later paragraph indicates that "If there are no operations left...the feature invocation expression is illegal, with one exception". However, the case of more than one operation remaining after step 3 is not mentioned explicitly.

Recommendation:
It should be explicitly stated that the expression is illegal in the case of more than one operation remaining after step 3.

Add clarification to overloading resolution rules

Agreed.

In subclause 8.3.20, it states that "The sequence expansion expression has the same...multiplicity upper bound as its primary expression...". However, subclause 13.2.44 includes the constraint selectOrRejectExpressionUpperDerivation, which states "A select or reject expression has a multiplicity upper bound of *", which is inconsistent with 8.3.20.

Recommendation:
Since a select or reject expression really cannot result in more values than produced by its primary expression, the statement in 8.3.20 make sense and the derivation in 13.2.44 should be updated to be consistent with it.

Update selectOrRejectExpressionUpperDerivation constraint

Agreed.

Table 9.1 incorrectly lists "@determined" as an allowable annotation. This should be "@determinate".

Correct Table 9.1

Agreed.

In 8.3.12 Instance Creation Expression, it states that "if the class of the object being created is active, then the classifier behavior for that class is automatically started once the object is created and after any constructor call completes." In 17.12, this is mapped to a start object behavior action.

However, if the class of the object being created is a specialization, then, as stated, only a classifier behavior owned by that class (if any) will be started, not any classifier behaviors that may be owned by parent classes and inherited by the specialization. It is possible in fUML to start such parent classifier behaviors, by using a start object behavior action with an object input pin typed by the parent class. But there is no way to express this in Alf, meaning that the active behaviors of parent classes are essentially lost in any specializations.

It would seem better to update the Alf semantics for instance creation so that, in addition starting any classifier behavior owned by the class of an object being created, any classifier behaviors owned by any parent classes are also started.

Start parent classifier behaviors

In addition to what is mentioned in the issue, the Alf 1.0.1 specification also states in 10.4.3 Active Classes that "The classifier behavior of an active class is specified as an activity that is a private owned behavior of the class". However, it says a little later that "an instance of an active class with active superclasses will have the behavior specified for all its superclasses, as well as any behavior specified for the subclass". This latter statement is not supported by the current semantics and mapping of the instantiation of active classes as given 8.3.2 and 17.12, so there is a specification inconsistency that needs to be resolved.

It is generally expected that the behavior of a subclass is a specialization of the behavior of its superclass(es). Thus, when an active class is a subclass of another active class, the active behavior specified for the subclass should include the behavior specified for the superclass – this is the intent of the statement made in 10.4.3. However, if only the subclass classifier behavior is started, this will not be the case. Instead, the active behavior of the subclass would essentially replace the behavior of the superclass.

Consider, for example, an active class that defines and responds to a certain set of signals. Since a subclass of of this class inherits the public receptions from its superclass, an instance of the subclass can also receive any of the signals defined for the superclass. However, if the superclass classifier behavior is not started, then the subclass will not automatically provide any response to these signals. The behavior specified in the superclass would have to be specified again in any subclass, even if it was to be unchanged, and then specified again in any further levels of subclassing. This seems untenable, leading to the conclusion that the classifier behaviors of the superclasses of an active object should also be started when the object is created.

Now, a more elegant solution would be to have the classifier behavior of a subclass redefine the classifier behavior of its superclass, so behavior could be incrementally added in the subclass without having to re-specify the behavior defined in the superclass. However, the semantics of the redefinition of activities is only loosely defined in UML and, as of fUML 1.2.1, behavior redefinition is not allowed at all in fUML.

Nevertheless, the Precise Semantics of UML State Machines (PSSM) specification (in preparation at the time of the writing of this resolution) is expected to include semantics for the redefinition (a.k.a. extension) of state machines. While state machines are not included in the Alf language, it should be possible to use Alf notation to create an instance of an externally defined class with a state machine as its classifier behavior, possibly redefining a state machine that is a superclass classifier behavior. In this case, the redefining state machine in the subclass already includes the behavior of the redefined state machine in the superclass, so only the subclass state machine should be started.

With all this in mind, the proposal is to resolve this issue as follows: update the Alf semantics for instance creation so that, in addition to starting any classifier behavior owned by the class of the object being created, all classifier behaviors owned by any parent classes are also started except for classifier behaviors that are redefined by other parent-owned classifier behaviors.

Subclause 8.8 Assignment Expressions, under Semantics for Simple Assignment, includes the example "WriteLine(a = 3)". Unfortunately, the standard WriteLine activity only allows a strings as arguments, not integers, so the example is not legal. A string value should be used in the example, rather than an integer.

Correct example

Agreed.

The constraint assignmentExpressionIsFeatureDerivation has the description: "The left hand side of an assignment expression is a feature if it is a kind of FeatureLeftHandSide." However, such an expression can also have a feature as its left-hand side if the left-hand side is a name left-hand side for a name that disambiguates to a feature. There is a similar problem with the constraint incrementAndDecrementExprssionIsFeatureDerivation.

Fix isFeature derivations

The indicated derivations need to be fixed.

The proposal is to change

For example, given the sequence
a = Integer[]

the sequence access expression a[2] evaluates to 30. Note that indexing is from 0.

Indexing in sequence access expressions should be 0-based. The main reason is that most popular languages use 0-based indexing. In particular this is true for Java, which Alf is syntactically compatible with at the minimum conformance level. Besides from confusing users, 1-based indexing makes it unnecessary hard to copy/paste existing Java code to be reused in an Alf context.
Also, the ALF standard says the following in the introduction: "Alf has a largely C-legacy (“Java like”) syntax, since that is most familiar to the community that programs detailed behaviors."
In the same spirit of being familiar to the community, Alf really should use 0-based indexing.

Add indexing annotations

In UML, indexing of ordered multiplicity elements is clearly 1-based. Further, while the issue only suggests that 0-based indexing be used for sequence access expressions, it would be inconsistent to use 0-based indexing for that but not also for indexing in relevant sequence and collection library functions (e.g., at, includingAt, etc.). However, the Alf sequence and collection functions are intentionally similar to corresponding functions in OCL, which are also 1-based.

Nevertheless, the possible confusion between 0-based indexing and 1-based indexing is a reasonable concern, particularly the difficulty mentioned in the issue description with copying and pasting existing C-like code that might be syntactically compatible with Alf but would assume 0-based indexing. A compromise would be to provide means for both 0-based and 1-based indexing in Alf. The following options were considered to allow this.

1. Provide alternate notations and library functions for 0-based and 1-based indexing.
   Pro: This option would allow the free intermixing of the use of 0-based and 1-based indexing, at the preference of the modeler, with the syntax clearly showing which is being used at any one point.
   Con: This option would add complexity in the language, with duplicative notations and functions for essentially the same capabilities. Further, the current indexed notation (such as "a[i]") would need to become 0-based, since that is the C-like notation used in other languages, with an alternate notation (such as "a@1") introduced for 1-based indexing, which would be backwards incompatible. There is a similar problem with certain existing 1-based-indexing collection functions (such as addAt) that have the same names as 0-based-indexing library operations in Java.
2. Allow implementations to have a global option for using 0-based or 1-based indexing or allow them as different conformance points.
   Pro: This option would require no syntactic change to Alf and would be a simple semantic variation to implement.
   Con: This option would mean that syntactically identical Alf code within identical UML models would execute differently in different implementations, which would violate the intent of rigorous, standard semantics for Alf. (The only semantic variation currently allowed in Alf is that allowed by the fUML specification.)
3. Leave indexing from 1 as the default, but add an IndexFrom0 stereotype to the existing ActionLanguage profile. When this stereotype was applied to an Alf unit, or to a UML namespace containing Alf text somewhere within it, then indexing would be 0-based within that scope.
   Pro: This option would allow 0-based indexing to be used within as wide a scope as desired by the modeler, but its use would still be identified explicitly in the model.
   Con: When looking at an Alf text snippet within a wider UML model, it would not be clear whether 0-based or 1-based indexing was being used, without looking at all containing namespaces to see if the stereotype was applied. Also accidentally removing an application of the stereotype, or moving Alf text outside of its scope, could significantly change the semantics of the Alf text, without any local change being made.
4. Leave indexing from 1 as the default, but introduce a statement-level @indexFrom0 annotation such that 0-based indexing was used within the statement so annotated (which could, e.g., be a block statement containing a sequence of nested statements, for all of which 0-based indexing would apply).
   Pro: With this option, the use of 0-based indexing would be clearly identified locally in the Alf text where it is used.
   Con: If 0-based indexing is to be used generally or widely within a UML model, with the Alf text spread throughout the model, then the annotation would need to be applied within each snippet of Alf that was to use 0-based indexing. It would also not be possible to specify indexing from 0 for property initialization or other uses of Alf expressions outside the context of Alf statements.

After consideration, it was decided to select option 4. The disadvantage of this option is that, of the options considered, it makes it the most difficult to use 0-based indexing generally with Alf within a UML model. However, 1-based indexing is what is consistent with the underlying UML semantics of Alf, and the intent is not to accommodate moving away from this, but, rather, to allow the easy migration from existing pre-Alf action code, when appropriate. Option 4 allows for this, while also clearly marking, in a standard way, those areas of Alf text using (non-default) 0-based indexing.

Specification: Action Language for Foundational UML (Alf): Concrete Syntax for a UML Action Language, FTF-Beta 2 (ptc/2012-08-43)

Subclause: 9.16 classify Statements

The semantics of classify statements does not mention what happens if any of the classes in the from list are active classes. The semantics of a UML reclassify object action are to NOT start the classifier behaviors of any such active classes. However, Alf does not provide any way to explicitly start classifier behaviors (this normally happens implicitly when an active object is constructed), so it would seem that the Alf classify statement SHOULD have the stated semantics of starting the classifier behaviors of any active classes in the from list. Otherwise, there would be no way to do so.

Have classify statements start classifier behaviors

Agreed.

Subject: Primitive type casts

Subclauses: 8.5.5 CastExpressions

Cast expressions should allow casting between Integer and UnlimitedNatural and between Integer and BitString, performing appropriate conversions

Add cast functionality for Integer, Real, UnlimitedNatural and BitString

Agreed. (Note that this resolution presumes the resolution to Issue ALF11-29, Alf should support Real.)

Assume we have an object typed by a class C which inherits another class D. If an object of C is destroyed by calling an explicit destructor, and this destructor does not contain any call to a super destructor of D, what will then happen? Will the object be destroyed without calling any destructor in the super class? This would seem error-prone. We need a clarification whether this is allowed or not, and if it is allowed how the super-class part of the object will be destroyed.

Close, with explanation

In 10.5.3.2, it clearly states

When an object is destroyed using an explicit destructor, the default destructor behavior is not performed, so any desired calls to superclass or composite part destructors must be made explicitly.

There is no requirement that any superclass or composite part destructor calls actually be made, however – to do so is a modeler responsibility. The intent is that an explicit destructor overrides the default behavior, and it is up to the modeler to decide what the replacement behavior should be, which includes whether or not to call any other destructors. This is similar to the freedom allowed in a constructor on whether or not to call superclass constructors.

Whether or not an explicit destructor makes calls to any relevant superclass or composite part desctructors, a destructor call on an object always results in the entire object being destroyed. That is because, as stated in 8.3.10, the actual destruction of the object happens "after the completion of the call to the destructor", regardless of what the destructor does or does not do. And this destruction happens using a destroy object action with isDestroyOwnedObjects=true (see 17.10), so composite parts are also always destroyed, whether or not destructors have been called on them.

In the section "Composition" of 10.5.2 we have the following example:

class C

When an instance of class C is destroyed, the object it holds for attribute b will also be automatically destroyed, but the object it holds for attribute a will not.

However, assume now that the class B has no accessible destructor. For example, it may have an explicit destructor with parameters and/or non-public visibility so that the default destructor is no longer available (see 10.5.3.2). What will then happen when the C instance is destroyed?
We think there should be a constraint that types of composite attributes must have a public constructor with no parameters. If this is missing, it is a static semantic error.

Close

If a class is defined using Alf, as is the example class in the description of this issue, then it will always have at least one destructor, and its instances can only be destroyed using Alf by calling a destructor. Even c.destroy() will call the default destructor, if no explicit destructor has been specified.

Since C::a is not composite, the default destructor will not call the A destructor on a – this is basic to the semantics of composite attributes in Alf, and may be exactly what is desired. If it is desired that the object in a be destroyed, then it is the responsibility of the modeler to provide an explicit destructor that does this. There does not seem any reason to make this mandatory.

On the other hand, if an instance of c is destroyed using a destroy-object action, outside of Alf, then the semantics for that will, presumably, be as given by fUML. In that case, there is even an option on the action to not destroy objects referenced via composite attributes and links. No rules in Alf can prevent possible problems from using such low-level actions.

The normative reference to the fUML Specification should be updated to Version 1.2.1 (the latest version as of the submission of this issue). In addition, all references to the fUML Specification in later text should be checked to make sure they are consistent with the latest fUML version.

Update fUML version to 1.2.1

Agreed.

Subclause: 11.6 Collection Classes

The rule for collection class in Section 11.6 would allow a class that multiply inherited from collection class instantiations, resulting in ambiguity of the call to toSequence. Perhaps the simplest rule would be to just consider as a “collection class” any class with a toSequence operation and an appropriate constructor.

Loosen definition of "collection class".

Agreed. (Note that, in the Alf 1.0.1 formal specification, "Collection Classes" is subclause 11.7, not 11.6.)

The non-deterministic behavior is an issue to evaluate the correctness of algorithm written in ALF. it is very difficult to test and check non determinist behavior. The formal approach use for ALF is the good right but also support a determinitic behavior.

Sequential if statement clauses are deterministic

Alf syntax allows both sequential clauses (if/else if/else) and concurrent clauses (if/or if). As the name indicates, the execution of sequential clauses is sequential and determinate, just as for a traditional if statement. So, one can avoid introducing indeterminate behavior by just not using concurrent clauses.

(One can also annotate an if statement as @determinate, which indicates that at most one condition will evaluate to true. This asserts determinate behavior even when using concurrent clauses. However, it is a modeler responsibility to ensure this assertion is true, and there is no required language check of this.)

Subclauses: 15.2.2 ActivityDefinition and 15.2.16 OperationDefinition

OperationDefinition and ActivityDefinition should have derived attributes for their actual body that gets the subunit body if they are stubs (in all other cases, resolving subunits can be handled via the derivation of the members for the stub). They should also have constraints that there are no assignments before the actual body.

Add effectiveBody derived properties

Agreed.

Subclause: 15.2.15 NamespaceDefinition

It would be better if NamespaceDefinition::member had type ElementReference instead of Member, to account for members inherited from non-Alf UML elements.

Use the existing ImportedMember instead

It is agreed that there is an issue in that members inherited from external classifiers are not currently addressed explicitly. While changing the type of NamespaceDefinition to ElementReference might be a consistent way to use the general element referencing mechanism to do that, it represents a substantial change to the abstract syntax model. It would also require updating how imported members are handled and introducing a mechanism for consistently accessing member properties through general element references.

An alternative is to simply use the existing ImportedMember class also for referencing external members that are inherited (i.e., they are first "implicitly imported"). This may be less elegant as an overall design, but it requires no change to the abstract syntax model and is thus a much smaller change while still solving the problem. It would also automatically handle checks for distinguishability with inherited members, since such checks are already covered for imported members.

Subclauses: 14.2.17 NonFinalClause and 14.2.21 SwitchClause

NonFinalClause should have derived assignmentBefore and assignmentAfter associations, since these are mentioned in the description of the nonFinalClauseAssignmentsBefore and nonFinalClauseAssignmentsAfter constraints, respectively. Similarly for SwitchClause.

Make minor constraint updates

The referenced constraints "nonFinalClauseAssignmentsAfter" and "nonFinalClauseAssignmentsBefore" don't actually exist. Instead, NonFinalClause has helper operations that given the assignmentsAfter and assignmentsBefore such a clause. SwitchClause has similar operations.

However, the "assignments before" non-final clauses are referenced in the concurrentClausesAssignmentsBefore constraint in a way that makes them seem to be a property that can be set. However, this can be easily fixed by simply changing the wording in this clause to refer to the "assignments before the condition of each of the clauses", rather than before the clauses themselves. Similarly, the wording of the switchStatementAssignmentsBefore can be changed to reference the "assignments before the case expressions of all clauses".

Subclauses: 14.2.15 LocalNameDeclarationStatement and 15.2.19 PropertyDefinition

In order to handle instance and sequence initialization expressions (per Subclauses 9.6 and 10.5.2), constraints for LocalNameDeclarationStatement and PropertyDefinition should allow for instance construction and sequence construction expressions with empty type names (which means the constructor name for an instance construction expression must also be optional).

Allow for instance construction and sequence construction expressions with empty constructor/type names

Agreed.

Specification: Action Language for Foundational UML (Alf): Concrete Syntax for a UML Action Language, FTF – Beta 2 (ptc/2012-08-43)

Subclause: 13.2.2 AssignmentExpression

Issue 17517 Error in AssignmentExpression constraints had two points. Both were agreed to, but the revised text did not include any revisions to address the first point:

In Subclause 13.2.2 AssignmentExpression, the constraint assignmentExpressionSimpleAssignmentTypeConformance should require the type of the right-hand side to conform to the type of the left-hand side, not the other way around.

Correct the assignmentExpressionSimpleAssignementTypeConformance constraint

Agreed.

Specification: Action Language for Foundational UML (Alf): Concrete Syntax for a UML Action Language, v1.0, FTF Beta 2 (ptc/2012-08-43)

Subclause: 13.2.35 NameLeftHandSide

The FeatureLeftHandSide class has the constraint: “The expression of the feature reference of a feature left-hand side must have a multiplicity upper bound of 1.” A NameLeftHandSide needs to have a similar constraint, in the case that its target name disambiguates to a feature reference.

Add nameLeftHandSideFeatureExpression constraint

Agreed.

Specification: Action Language for Foundational UML (Alf) FTF Beta 2 (ptc/2012-08-43)

Subclause: 8.4 Increment and Decrement Expressions

The BNF in Subclause 8.4 parses the operator string of an increment or decrement expression into an “operator” attribute of the instance of IncrementOrDecrementExpression. However, no operator attribute is actually defined for IncrementOrDecrementExpression.

Add IncrementOrDecrementExpression::operator property

Agreed that this property needs to be added.

Specification: Action Language for Foundational UML (Alf) v1.0.1, formal/2013-09-01

Subclause: 10.5.3

In Subclause 10.5.3 Operations, under “Operation Method” it says “An abstract operation does not have a method.” However, the syntax allows an abstract operation to have a body, and there is no constraint in the abstract syntax for OperationDefinition (Subclause 15.2.16) to disallow this.

An OperationDefinition for an abstract operation should be disallowed from having a body, either in the syntax or through a static semantic check.

Add constraint preventing an abstract OperationDefinition from having a body

Agreed that an abstract OperationDefinition should not be allowed to have a body. Making this a constraint, rather than a syntax error, would be less severe, since parsing could continue even with such an error. However, the concrete syntax production should still be updated so that an abstract OperationDefinition without a body is not considered to be a stub (otherwise the MemberStub constraint would be violated for all abstract OperationDefinitions).

Subclause: 13.2.3 BehaviorInvocationExpression

BehaviorInvocationExpression should have a derived attribute that is the implicit binding when the referent behavior is a template whose argument types can be inferred for the invocation. There should also be a constraint on when this is allowed

Add derived InvocationExpression::boundReferent property

Agreed in principle. However, implicit template binding may occur for sequence operation expressions, as well as behavior invocation expressions. Therefore, the derived property should be on InvocationExpression, the common superclass of BehaviorInvocationExpression and SequenceOperationExpression.

Clauses: All of Part III on Abstract Syntax

Derived associations whose derivations create new syntax elements, rather than referring to existing elements in the abstract syntax tree (e.g., ExtentOrExpression::expression) should be composition associations. This makes the ownership of these derived elements clear for the purpose of walking the abstract syntax tree to check static semantic constraints.

Make certain derived properties composite

Generally agreed, though the specific example given (ExtentOrExpression::expression) is already composite in the Alf 1.0.1 abstract syntax.

Subclause: 14.2.8 ConcurrentClauses

ConcurrentClauses should have a derived assignmentBefore association, since this is mentioned in the description of the concurrentClausesAssignmentsBefore condition.

Add assignmentBefore association to ConcurrentClauses

Agreed.

Subclause: 13.2.34 NameExpression

For a parameter name, nameExpressionAssignmentDerivation should only give the assignment as the assignment before the expression if there is one. Otherwise, it should create an effective assignment with the formal parameter as its source element, unless the parameter is an out parameter. If the parameter is a non-Alf element, then this will need to be wrapped in a new ExternalParameter syntax element.

Allow an assigned source to be an external reference

Agreed in principle. However, rather than introduce a new ExternalParameter class, a better solution would seem to be to make the source of an AssignedSource an ElementReference, rather than a SyntaxElement. This would reuse the general mechanism to allow a reference to be to either an internal or external element.

Subclause: 13.2.13 ConditionalTestExpression

The derivation for the type of a ConditionalTestExpression should account for the case in which one of the result operands is empty, in which case the type of the conditional test expression should be the type of the other expression

Not necessary

All the synthesized properties for the operands of a conditional test expression have multiplicity 1..1, so a conditional test expression with an "empty result operand" is already syntactically ill-formed. An implementation may wish to provide a type for the expression that allows for further processing even in such a case, but there is no need for the specification to provide a formal type derivation for it.

Specification: Action Language for Foundational UML (Alf): Concrete Syntax for a UML Action Language, FTF-Beta 2 (ptc/2012-08-43)

In the normative Alf-Library.xmi, the actual parameter in the template binding for Alf::Library::CollectionClasses::List::Bag<T> should be the parametered element of the template parameter for List, not for Bag.

The actual parameter for the template binding of Bag<T> is wrong

Agreed.

Specification: Action Language for Foundational UML (Alf): Concrete Syntax for a UML Action Language, FTF-Beta 2 (ptc/2012-08-43)

In the normative Alf-Library.xmi, the following parameters within the CollectionClasses package need to be corrected:

· The return parameter for the operation OrderedSet::subOrderedSet should have isUnique=true and isOrdered=false (rather than isUnique=false and isOrdered=true).

· The input parameter for the operation Queue::retainAll should have multiplicity 0..* (rather than 1..1).

Multiplicity element errors in parameters in the CollectionClasses package

Agreed. And the first change also needs to be made in CollectionClasses::Impl::OrderedSet.

Specification: Action Language for Foundational UML (Alf): Concrete Syntax for a UML Action Language, FTF-Beta 2 (ptc/2012-08-43)

The type of the input parameters of the following constructor operations of templates in the CollectionClasses package in the normative Alf-Library.xmi have incorrect types (in all cases, the type should be the parametered element of the template parameter of the template class owning the operation):

· Alf::CollectionClasses::Bag

· Alf::CollectionClasses::Impl::Bag::Bag

· Alf::CollectionClasses::Impl::Deque

· Alf::CollectionClasses::Impl::List::List

· Alf::CollectionClasses::Impl::OrderedSet::OrderedSet

· Alf::CollectionClasses::Impl::Queue

Parameters of some constructor operations in collection classes have incorrect types

Generally agreed, though the qualified names in the bullet list are not entirely correct, but the intent is clear. And the parameter type for Alf::Library::CollectionClasses::Bag::Bag is actually already correct in the XMI.

Specification: Action Language for Foundational UML (Alf): Concrete Syntax for a UML Action Language, FTF-Beta 2 (ptc/2012-08-43)
Subclause: 11.6.6 Map<Key, Value>

The collection class template Alf::Library:CollectionClasses::Map<Key, Value> owns a nested instantiation Bag<Value> of the Bag template ( which is the return type of the values operation). However, in the normative Alf-Library.xmi, the formal parameter in the template parameter substitution of the template binding for Bag<Value> is incorrectly set to the template parameter of Set rather than the template parameter of Bag.

CollectionClasses::Map::Bag<Value> references the wrong template parameter

Agreed.

Specification: Action Language for Foundational UML (Alf): Concrete Syntax for a UML Action Language, FTF-Beta 2 (ptc/2012-08-43)

The Alf syntax and the description of its semantics are based in UML 2.4.1. However, the formal semantic mapping is to fUML 1.0, which is based on UML 2.3. This means that the normative XMI for the Alf Standard Model Library is also UML 2.3, since it uses the fUML 1.0 Foundational Model Library. This situation occurred because the fUML 1.1 revision, based on UML 2.4.1, was not completed in time before the Alf 1.0 FTF had to deliver its report. Now that fUML 1.1 has been adopted, the Alf specification should be updated to use it as the target of the normative semantic mapping, which would also allow the Alf Standard Model Library to be UML 2.4.1.

(Note that this issue is not intended to request that Alf incorporate the new Real type, which would require syntactic changes to the language and extension of the Standard Model Library. It is simply intended to request that the technical specification and normative artifacts for Alf all be consistently based on UML 2.4.1.)

Alf should be based on fUML 1.1

Actually, the finalized Alf 1.0 spec still references UML 2.4 in Clause 3 Normative References. This should be updated to UML 2.4.1, along with updating the fUML reference to fUML 1.1. Once this is done, no change is necessary to the mapping specification, since that only generically refers to fUML and UML, not to specific versions.
For the Standard Model Library, Subclause 11.2 Primitive Types needs to be updated to replace the use of the UML::AuxiliaryConstructs::PrimitiveTypes package from UML 2.3 with the separate PrimitiveTypes package from the UML 2.4.1 infrastructure. Then the normative XMI for the library needs to be regenerated as a UML 2.4.1/XMI 2.4.1 file.