Issues for Mailing list of the Action Language for fUML 1.1 (ALF) Revision Task Force

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 15627: Why not include Model to Text for generating ALF for (a subset of) UML?
Issue 16427: Definition of “Collection Class”
Issue 16428: Some Derived Associations Should Be Composite
Issue 16430: Allow Expressions to Just Conform to Primitive Types
Issue 16433: BehaviorInvocationExpression Should Have a Derived Implicit Binding
Issue 16438: Derivation of the Type of a ConditionalTestExpression
Issue 16446: NameExpression::assignment Derivation for a Parameter Name
Issue 16461: : ConcurrentClauses Should Have a Derived assignmentBefore
Issue 16465: Empty Type Names for Initialization Sequence and Construction Expressions
Issue 16466: NonFinalClause and SwitchClause Should Have Derived assignmentBeefore and assignmentAfter
Issue 16471: NamespaceDefinition::member type
Issue 16475: ActivityDefinition and OperationDefinition Bodies
Issue 16488: Non-deterministic behavior on "if statement"
Issue 16597: Indexing in sequence access expressions should be 0-based
Issue 16598: Need to clarify how objects are compared by collection classes
Issue 16599: The semantics of destroying part objects without accessible destructor must be specified
Issue 16600: Is it allowed to omit super destructor calls in an explicit destructor?
Issue 16601: Need a syntax for local names with composite semantics
Issue 16602: Missing syntax for RaiseExceptionAction
Issue 16604: Missing syntax for defining exception handlers
Issue 16605: Traditional for-statement not supported by Alf?
Issue 17509: Sequence feature invocation expressions
Issue 17512: Primitive type casts
Issue 18233: IncrementOrDecrementExpression::operator attribute is missing
Issue 18267: NameLeftHandSide needs a feature constraint
Issue 18281: Classify statements should start classifier behaviors
Issue 18393: Alf should be based on fUML 1.1
Issue 18451: The resolution of Issue 17517 was incomplete
Issue 18497: Alf should support Real
Issue 18520: CollectionClasses::Map::Bag<Value> references the wrong template parameter
Issue 18521: Parameters of some constructor operations in collection classes have incorrect types
Issue 18522: Multiplicity element errors in parameters in the CollectionClasses package
Issue 18526: The actual parameter for the template binding of Bag<T> is wrong

Issue 15627: Why not include Model to Text for generating ALF for (a subset of) UML? (alf-rtf)

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

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.

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.

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

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

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

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.

Subclause: 14.2.8 ConcurrentClauses

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

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).

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.

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.

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.

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.

The proposal is to change 


For example, given the sequence
a = Integer[]{10, 20, 30, 40}
the sequence access expression a[3] evaluates to 30. Note that indexing is from 1.


to


For example, given the sequence
a = Integer[]{10, 20, 30, 40}
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.

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.

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


class C {
  public a: A = new A();
  public b: compose B = new B();
}


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.

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.

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();

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).

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++) { ... }

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 expansions (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.

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

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.

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.

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.

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.)

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.

 

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.

 

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.

 

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

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).

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.