Action Language for Foundational UML Avatar
  1. OMG Specification

Action Language for Foundational UML — Closed Issues

  • Acronym: ALF
  • Issues Count: 174
  • Description: Issues resolved by a task force and approved by Board
Closed All
Issues resolved by a task force and approved by Board

Issues Summary

Key Issue Reported Fixed Disposition Status
ALF11-70 Annex A.3 should take PSCS into account ALF 1.0 ALF 1.1 Deferred closed
ALF11-1 Why not include Model to Text for generating ALF for (a subset of) UML? ALF 1.0b1 ALF 1.1 Deferred closed
ALF11-21 Traditional for-statement not supported by Alf? ALF 1.0b1 ALF 1.1 Deferred closed
ALF11-20 Missing syntax for defining exception handlers ALF 1.0b1 ALF 1.1 Deferred closed
ALF11-19 Missing syntax for RaiseExceptionAction ALF 1.0b1 ALF 1.1 Deferred closed
ALF11-18 Need a syntax for local names with composite semantics ALF 1.0b1 ALF 1.1 Deferred closed
ALF11-15 Need to clarify how objects are compared by collection classes ALF 1.0b1 ALF 1.1 Deferred closed
ALF11-90 The Alf 1.1 specification should reflect the latest version of fUML ALF 1.0 ALF 1.1 Resolved closed
ALF11-77 Multiplicity and typing of local names should be better tracked ALF 1.0 ALF 1.1 Resolved closed
ALF11-44 Alf should have a "null coalescing" operator ALF 1.0 ALF 1.1 Resolved closed
ALF11-43 Inconsistent rules for local names defined in if and switch statement clauses. ALF 1.0 ALF 1.1 Resolved closed
ALF11-4 Allow Expressions to Just Conform to Primitive Types ALF 1.0b2 ALF 1.1 Resolved closed
ALF11-29 Alf should support Real ALF 1.0 ALF 1.1 Resolved closed
ALF11-22 Sequence feature invocation expressions ALF 1.0b2 ALF 1.1 Resolved closed
ALF11-35 Overload resolution for feature invocation expressions should be specific about the case of multiple most-specific operations. ALF 1.0 ALF 1.1 Resolved closed
ALF11-37 Multiplicity upper bound of a select or reject expression should be based on its primary expression ALF 1.0 ALF 1.1 Resolved closed
ALF11-36 Table 9.1 incorrectly lists "@determined" instead of "@determinate". ALF 1.0 ALF 1.1 Resolved closed
ALF11-67 Instance creation should start classifier behaviors of parent classes ALF 1.0 ALF 1.1 Resolved closed
ALF11-87 Bad assignment example ALF 1.0 ALF 1.1 Resolved closed
ALF11-75 Incorrect derivation of AssignmentExpression::isFeature ALF 1.0 ALF 1.1 Resolved closed
ALF11-14 Indexing in sequence access expressions should be 0-based ALF 1.0b1 ALF 1.1 Resolved closed
ALF11-26 Classify statements should start classifier behaviors ALF 1.0 ALF 1.1 Resolved closed
ALF11-23 Primitive type casts ALF 1.0b2 ALF 1.1 Resolved closed
ALF11-17 Is it allowed to omit super destructor calls in an explicit destructor? ALF 1.0b1 ALF 1.1 Closed; No Change closed
ALF11-16 The semantics of destroying part objects without accessible destructor must be specified ALF 1.0b1 ALF 1.1 Closed; No Change closed
ALF11-68 The referenced fUML version should be updated to 1.2.1 ALF 1.0 ALF 1.1 Resolved closed
ALF11-2 Definition of “Collection Class” ALF 1.0b2 ALF 1.1 Resolved closed
ALF11-13 Non-deterministic behavior on "if statement" ALF 1.0b1 ALF 1.1 Closed; No Change closed
ALF11-12 ActivityDefinition and OperationDefinition Bodies ALF 1.0b2 ALF 1.1 Resolved closed
ALF11-11 NamespaceDefinition::member type ALF 1.0b2 ALF 1.1 Resolved closed
ALF11-10 NonFinalClause and SwitchClause Should Have Derived assignmentBefore and assignmentAfter ALF 1.0b2 ALF 1.1 Resolved closed
ALF11-9 Empty Type Names for Initialization Sequence and Construction Expressions ALF 1.0b2 ALF 1.1 Resolved closed
ALF11-28 The resolution of Issue 17517 was incomplete ALF 1.0 ALF 1.1 Resolved closed
ALF11-25 NameLeftHandSide needs a feature constraint ALF 1.0 ALF 1.1 Resolved closed
ALF11-24 IncrementOrDecrementExpression::operator attribute is missing ALF 1.0 ALF 1.1 Resolved closed
ALF11-34 An abstract operation should not be allowed to have a body ALF 1.0 ALF 1.1 Resolved closed
ALF11-5 BehaviorInvocationExpression Should Have a Derived Implicit Binding ALF 1.0b2 ALF 1.1 Resolved closed
ALF11-3 Some Derived Associations Should Be Composite ALF 1.0b2 ALF 1.1 Resolved closed
ALF11-8 ConcurrentClauses Should Have a Derived assignmentBefore ALF 1.0b2 ALF 1.1 Resolved closed
ALF11-7 NameExpression::assignment Derivation for a Parameter Name ALF 1.0b2 ALF 1.1 Resolved closed
ALF11-6 Derivation of the Type of a ConditionalTestExpression ALF 1.0b2 ALF 1.1 Closed; No Change closed
ALF11-33 The actual parameter for the template binding of Bag is wrong ALF 1.0 ALF 1.1 Resolved closed
ALF11-32 Multiplicity element errors in parameters in the CollectionClasses package ALF 1.0 ALF 1.1 Resolved closed
ALF11-31 Parameters of some constructor operations in collection classes have incorrect types ALF 1.0 ALF 1.1 Resolved closed
ALF11-30 CollectionClasses::Map::Bag references the wrong template parameter ALF 1.0 ALF 1.1 Resolved closed
ALF11-27 Alf should be based on fUML 1.1 ALF 1.0 ALF 1.1 Resolved closed
ALF-50 UML RTF 1.4 Issue: CreateAction links to only one classifier. ALF 1.0b1 ALF 1.0b2 Resolved closed
ALF-49 Synchronous action ALF 1.0b1 ALF 1.0b2 Resolved closed
ALF_-78 Inherited abstract operations ALF 1.0b2 ALF 1.0 Resolved closed
ALF_-77 Classifier behavior required for an active class ALF 1.0b2 ALF 1.0 Resolved closed
ALF_-76 Assignment of out parameters in if and switch statements ALF 1.0b2 ALF 1.0 Resolved closed
ALF_-75 Derivation of SequenceOperationExpression::isCollectionConversion ALF 1.0b2 ALF 1.0 Resolved closed
ALF_-73 InstanceCreationExpression class must not be abstract ALF 1.0b2 ALF 1.0 Resolved closed
ALF_-72 Indexed feature left hand sides ALF 1.0b2 ALF 1.0 Resolved closed
ALF_-71 Referent of a signal send ALF 1.0b2 ALF 1.0 Resolved closed
ALF_-74 Assigned name must not be template binding ALF 1.0b2 ALF 1.0 Resolved closed
ALF_-67 Inconsistency on being constructorless ALF 1.0b2 ALF 1.0 Resolved closed
ALF_-70 Constructor in a BehaviorInvocationExpression ALF 1.0b2 ALF 1.0 Resolved closed
ALF_-69 Error in AssignmentExpression constraints ALF 1.0b2 ALF 1.0 Resolved closed
ALF_-68 AssignmentExpression as a data value update ALF 1.0b2 ALF 1.0 Resolved closed
ALF_-66 @determined should be @determinate ALF 1.0b2 ALF 1.0 Resolved closed
ALF_-65 Error in bit string conversion ALF 1.0b2 ALF 1.0 Resolved closed
ALF_-64 SequenceExpressionList::element should be ordered ALF 1.0b2 ALF 1.0 Resolved closed
ALF_-63 Error in Data Value Creation Expression ALF 1.0b2 ALF 1.0 Resolved closed
ALF-46 Problem with parameters of CollectionFunctions::removeAll ALF 1.0b1 ALF 1.0b2 Resolved closed
ALF-45 Typo in sequence functions? ALF 1.0b1 ALF 1.0b2 Resolved closed
ALF_-62 Errors in Subclause 8.2 ALF 1.0b2 ALF 1.0 Resolved closed
ALF-48 Should be allowed to use return statement in all behaviors ALF 1.0b1 ALF 1.0b2 Resolved closed
ALF-47 Problem with parameters of CollectionFunctions::replaceOne ALF 1.0b1 ALF 1.0b2 Resolved closed
ALF_-61 Errors in the Collection Classes Implemenation ALF 1.0b2 ALF 1.0 Resolved closed
ALF_-60 Errors in the Property Management Service Example ALF 1.0b2 ALF 1.0 Resolved closed
ALF_-59 Errors in the Online Bookstore Example ALF 1.0b2 ALF 1.0 Resolved closed
ALF_-58 Errors in QuickSort Example ALF 1.0b2 ALF 1.0 Resolved closed
ALF_-57 Errors in Constraint Names ALF 1.0b2 ALF 1.0 Resolved closed
ALF_-56 Description of SignalDefinition::isSameKindAs ALF 1.0b2 ALF 1.0 Resolved closed
ALF_-55 Assignments Before a Property Initializer ALF 1.0b2 ALF 1.0 Resolved closed
ALF_-52 NamespaceDefinition::ownedMember Should Be Ordered ALF 1.0b2 ALF 1.0 Resolved closed
ALF_-51 Errors in ImportedMember ALF 1.0b2 ALF 1.0 Resolved closed
ALF_-50 ElementImportReference Constraint ALF 1.0b2 ALF 1.0 Resolved closed
ALF_-54 Constructor Return Type ALF 1.0b2 ALF 1.0 Resolved closed
ALF_-53 Description of operationDefinitionRedefinition ALF 1.0b2 ALF 1.0 Resolved closed
ALF_-49 Errors in Descriptions of SwitchStatement constraints ALF 1.0b2 ALF 1.0 Resolved closed
ALF_-48 SwitchClause Should Have a switchClauseCase Constraint ALF 1.0b2 ALF 1.0 Resolved closed
ALF_-47 Derivation of LocalNameDeclaration::type ALF 1.0b2 ALF 1.0 Resolved closed
ALF_-42 Correction to shiftExpressionOperands Constraint ALF 1.0b2 ALF 1.0 Resolved closed
ALF_-45 ForStatement Should Have a Composition Association to Block ALF 1.0b2 ALF 1.0 Resolved closed
ALF_-44 Block Assignment Constraints ALF 1.0b2 ALF 1.0 Resolved closed
ALF_-43 Correction to superInvocationExpressionTarget Constraint ALF 1.0b2 ALF 1.0 Resolved closed
ALF_-46 localNameDeclarationStatementAssignmentsAfter constraint ALF 1.0b2 ALF 1.0 Resolved closed
ALF_-41 SequenceOperationExpression Constraints ALF 1.0b2 ALF 1.0 Resolved closed
ALF_-40 SequenceOperationExpression Should Override parameterElements ALF 1.0b2 ALF 1.0 Resolved closed
ALF_-38 SequenceConstructionExpression Constraints ALF 1.0b2 ALF 1.0 Resolved closed
ALF_-39 SequenceConstructionExpression Needs to Override updateAssignments ALF 1.0b2 ALF 1.0 Resolved closed
ALF_-37 SequenceConstructionExpression::typeName May Be Empty ALF 1.0b2 ALF 1.0 Resolved closed
ALF_-34 Error in propertyAccessExpressionLowerDerivation ALF 1.0b2 ALF 1.0 Resolved closed
ALF_-33 PositionalTuple Needs a Constraint ALF 1.0b2 ALF 1.0 Resolved closed
ALF_-36 Error in qualifiedNameDisambiguationDerivation ALF 1.0b2 ALF 1.0 Resolved closed
ALF_-35 QualifiedName::templateName Needs a Description ALF 1.0b2 ALF 1.0 Resolved closed
ALF_-30 NamedTuple Needs a Constraint ALF 1.0b2 ALF 1.0 Resolved closed
ALF_-29 Problem with the NamedExpression Conversion Constraints ALF 1.0b2 ALF 1.0 Resolved closed
ALF_-28 Errors in LogicalExpression Constraints ALF 1.0b2 ALF 1.0 Resolved closed
ALF_-27 literalExpressionTypeDerivation Is Not Necessary ALF 1.0b2 ALF 1.0 Resolved closed
ALF_-32 Problems with NameLeftHandSide Constraints ALF 1.0b2 ALF 1.0 Resolved closed
ALF_-31 NameExpression Should Override updateAssignments ALF 1.0b2 ALF 1.0 Resolved closed
ALF_-26 Corrections to InvocationExpression::parameterElements ALF 1.0b2 ALF 1.0 Resolved closed
ALF_-24 Constraint Needed on FeatureLeftHandSide ALF 1.0b2 ALF 1.0 Resolved closed
ALF_-23 Corrections to updateAssignments for ConditionalTestExpression ALF 1.0b2 ALF 1.0 Resolved closed
ALF_-25 Derivations of type, lower and upper for Invocation Expressions ALF 1.0b2 ALF 1.0 Resolved closed
ALF_-22 Require Non-Template Classifier ALF 1.0b2 ALF 1.0 Resolved closed
ALF_-21 Derived Attributes for LeftHandSide ALF 1.0b2 ALF 1.0 Resolved closed
ALF_-20 binaryExpressionOperandMultiplicity Constraint is Too Strong for EqualityExpression ALF 1.0b2 ALF 1.0 Resolved closed
ALF_-19 Errors in BehaviorInvocationExpression Constraints ALF 1.0b2 ALF 1.0 Resolved closed
ALF_-18 Type Conformance for Compound Assignments for Bit Strings ALF 1.0b2 ALF 1.0 Resolved closed
ALF_-15 IndexOf Return Type ALF 1.0b2 ALF 1.0 Resolved closed
ALF_-14 Synthesis of the Name of a Reception Definition ALF 1.0b2 ALF 1.0 Resolved closed
ALF_-17 Errors in Abstract Syntax Attribute Names ALF 1.0b2 ALF 1.0 Resolved closed
ALF_-16 Errors in Collection Function Table ALF 1.0b2 ALF 1.0 Resolved closed
ALF_-13 Constructors and Diamond Inheritance ALF 1.0b2 ALF 1.0 Resolved closed
ALF_-9 Return Statements with no Expression ALF 1.0b2 ALF 1.0 Resolved closed
ALF_-12 Error in ProcessQueue Example ALF 1.0b2 ALF 1.0 Resolved closed
ALF_-11 Error in Singleton Examples ALF 1.0b2 ALF 1.0 Resolved closed
ALF_-10 Implicit Imports ALF 1.0b2 ALF 1.0 Resolved closed
ALF_-8 Evaluation of Loop Variable Definitions ALF 1.0b2 ALF 1.0 Resolved closed
ALF_-5 Error in Synthesis of Null Expressions ALF 1.0b2 ALF 1.0 Resolved closed
ALF_-4 Boolean Literals Cannot Be Used as Identifiers ALF 1.0b2 ALF 1.0 Resolved closed
ALF_-7 Missing Cross Reference in Subclause 9.6 ALF 1.0b2 ALF 1.0 Resolved closed
ALF_-6 Parenthesizing Left Hand Sides ALF 1.0b2 ALF 1.0 Resolved closed
ALF_-2 Correction to Section 8.3.6, Property Access Expressions ALF 1.0b2 ALF 1.0 Resolved closed
ALF_-1 StructuredMember should be renamed to StructuredElement ALF 1.0b2 ALF 1.0 Resolved closed
ALF-44 Need to replace the CMOF file for the abstract syntax by a UML file for UML 2.4 ALF 1.0b1 ALF 1.0b2 Resolved closed
ALF-43 The Model file includes the UML Primitive Types package rather than referencing it. ALF 1.0b1 ALF 1.0b2 Resolved closed
ALF_-3 Null Template Binding Arguments ALF 1.0b2 ALF 1.0 Resolved closed
ALF-42 Messaging action language examples ALF 1.0a ALF 1.0b1 Resolved closed
ALF-41 Runtime Instance ALF 1.0a ALF 1.0b1 Resolved closed
ALF-40 Variable to VariableAction association should have multiplicity * ALF 1.0a ALF 1.0b1 Resolved closed
ALF-39 PrimitiveFunction shouldn't be restricted to datatypes ALF 1.0a ALF 1.0b1 Resolved closed
ALF-38 TestIdentityAction should have an output ALF 1.0a ALF 1.0b1 Resolved closed
ALF-37 PrimitiveFunction should have a supertype ALF 1.0a ALF 1.0b1 Resolved closed
ALF-36 Preserving state across reclassification ALF 1.0a ALF 1.0b1 Resolved closed
ALF-35 Inconsistent style of action semantics sections of updated UML specificatio ALF 1.0a ALF 1.0b1 Resolved closed
ALF-29 More Typos ALF 1.0a ALF 1.0b1 Resolved closed
ALF-28 Action for starting procedure ALF 1.0a ALF 1.0b1 Resolved closed
ALF-27 Multiplicity from Attribute to AttributeAction should be 0..* ALF 1.0a ALF 1.0b1 Resolved closed
ALF-34 CORBA's operation invocation styles. ALF 1.0a ALF 1.0b1 Resolved closed
ALF-33 Make spec reflect package structure. ALF 1.0a ALF 1.0b1 Resolved closed
ALF-32 Hard/soft deletion actions. ALF 1.0a ALF 1.0b1 Resolved closed
ALF-31 include Actions.idl ALF 1.0a ALF 1.0b1 Resolved closed
ALF-30 Exceptions across procedure boundaries. ALF 1.0a ALF 1.0b1 Resolved closed
ALF-22 Messaging action language examples ALF 1.0a ALF 1.0b1 Resolved closed
ALF-21 Interaction rule ALF 1.0a ALF 1.0b1 Resolved closed
ALF-24 Add one-way navigation ALF 1.0a ALF 1.0b1 Resolved closed
ALF-23 Add IsReplaceAll for ReclassifyObjectAction. ALF 1.0a ALF 1.0b1 Resolved closed
ALF-26 Rename ReadLinkAction to ReadLinksAction? ALF 1.0a ALF 1.0b1 Resolved closed
ALF-25 Rename ClearAssociationAction to ClearLinkAction? ALF 1.0a ALF 1.0b1 Resolved closed
ALF-6 Enforcement of multiplicity ALF 1.0a ALF 1.0b1 Resolved closed
ALF-5 Multiple owners of Clause ALF 1.0a ALF 1.0b1 Resolved closed
ALF-20 Pins in class semantics ALF 1.0a ALF 1.0b1 Resolved closed
ALF-19 Profile for Resolution of Operations and Signals ALF 1.0a ALF 1.0b1 Resolved closed
ALF-4 Procedure attached to what? ALF 1.0a ALF 1.0b1 Resolved closed
ALF-3 Type of Pin ALF 1.0a ALF 1.0b1 Resolved closed
ALF-2 Typos ALF 1.0a ALF 1.0b1 Resolved closed
ALF-8 Attributes of association classes ALF 1.0a ALF 1.0b1 Resolved closed
ALF-7 end object terminology ALF 1.0a ALF 1.0b1 Resolved closed
ALF-14 Input/Output sections ALF 1.0a ALF 1.0b1 Resolved closed
ALF-13 ReadLinkAction clarification ALF 1.0a ALF 1.0b1 Resolved closed
ALF-10 Unsupported core features ALF 1.0a ALF 1.0b1 Resolved closed
ALF-9 Instantiating classifiers ALF 1.0a ALF 1.0b1 Resolved closed
ALF-16 ordered congruent collection clarification ALF 1.0a ALF 1.0b1 Resolved closed
ALF-15 MarshallAction, marshalType ALF 1.0a ALF 1.0b1 Resolved closed
ALF-12 Multiplicity of ReadExtentAction pins ALF 1.0a ALF 1.0b1 Resolved closed
ALF-11 Classifiers fo ReadExtentAction ALF 1.0a ALF 1.0b1 Resolved closed
ALF-18 Messaging action examples ALF 1.0a ALF 1.0b1 Resolved closed
ALF-17 ReduceAction subaction ALF 1.0a ALF 1.0b1 Resolved closed
ALF-1 [ALF] Issue with Section 8.3.6 - Invocation Expressions ALF 1.0b1 ALF 1.0b2 Resolved closed

Issues Descriptions

Annex A.3 should take PSCS into account

  • Key: ALF11-70
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    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.

  • Reported: ALF 1.0 — Wed, 20 Apr 2016 19:03 GMT
  • Disposition: Deferred — ALF 1.1
  • Disposition Summary:

    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.

  • Updated: Tue, 14 Jul 2020 19:26 GMT

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

  • Key: ALF11-1
  • Legacy Issue Number: 15627
  • Status: closed  
  • Source: agnos.ai UK Ltd ( Pete Rivett)
  • Summary:

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

  • Reported: ALF 1.0b1 — Thu, 23 Sep 2010 04:00 GMT
  • Disposition: Deferred — ALF 1.1
  • Disposition Summary:

    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.

  • Updated: Tue, 14 Jul 2020 19:26 GMT

Traditional for-statement not supported by Alf?

  • Key: ALF11-21
  • Legacy Issue Number: 16605
  • Status: closed  
  • Source: IBM ( Mattias Mohlin)
  • Summary:

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

    { ... }

  • Reported: ALF 1.0b1 — Fri, 14 Oct 2011 04:00 GMT
  • Disposition: Deferred — ALF 1.1
  • Disposition Summary:

    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.

  • Updated: Tue, 14 Jul 2020 19:26 GMT

Missing syntax for defining exception handlers

  • Key: ALF11-20
  • Legacy Issue Number: 16604
  • Status: closed  
  • Source: IBM ( Mattias Mohlin)
  • Summary:

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

  • Reported: ALF 1.0b1 — Fri, 14 Oct 2011 04:00 GMT
  • Disposition: Deferred — ALF 1.1
  • Disposition Summary:

    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.

  • Updated: Tue, 14 Jul 2020 19:26 GMT

Missing syntax for RaiseExceptionAction

  • Key: ALF11-19
  • Legacy Issue Number: 16602
  • Status: closed  
  • Source: IBM ( Mattias Mohlin)
  • Summary:

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

  • Reported: ALF 1.0b1 — Fri, 14 Oct 2011 04:00 GMT
  • Disposition: Deferred — ALF 1.1
  • Disposition Summary:

    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.

  • Updated: Tue, 14 Jul 2020 19:26 GMT

Need a syntax for local names with composite semantics

  • Key: ALF11-18
  • Legacy Issue Number: 16601
  • Status: closed  
  • Source: IBM ( Mattias Mohlin)
  • Summary:

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

  • Reported: ALF 1.0b1 — Fri, 14 Oct 2011 04:00 GMT
  • Disposition: Deferred — ALF 1.1
  • Disposition Summary:

    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.

  • Updated: Tue, 14 Jul 2020 19:26 GMT

Need to clarify how objects are compared by collection classes

  • Key: ALF11-15
  • Legacy Issue Number: 16598
  • Status: closed  
  • Source: IBM ( Mattias Mohlin)
  • Summary:

    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.

  • Reported: ALF 1.0b1 — Fri, 14 Oct 2011 04:00 GMT
  • Disposition: Deferred — ALF 1.1
  • Disposition Summary:

    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.

  • Updated: Tue, 14 Jul 2020 19:26 GMT

The Alf 1.1 specification should reflect the latest version of fUML

  • Key: ALF11-90
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

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

  • Reported: ALF 1.0 — Sun, 8 Jan 2017 05:40 GMT
  • Disposition: Resolved — ALF 1.1
  • Disposition Summary:

    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.

  • Updated: Thu, 22 Jun 2017 16:40 GMT

Multiplicity and typing of local names should be better tracked

  • Key: ALF11-77
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    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.

  • Reported: ALF 1.0 — Mon, 1 Aug 2016 14:45 GMT
  • Disposition: Resolved — ALF 1.1
  • Disposition Summary:

    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.

  • Updated: Thu, 22 Jun 2017 16:40 GMT

Alf should have a "null coalescing" operator

  • Key: ALF11-44
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    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.

  • Reported: ALF 1.0 — Thu, 17 Dec 2015 23:58 GMT
  • Disposition: Resolved — ALF 1.1
  • Disposition Summary:

    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.

  • Updated: Thu, 22 Jun 2017 16:40 GMT

Inconsistent rules for local names defined in if and switch statement clauses.

  • Key: ALF11-43
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    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.

  • Reported: ALF 1.0 — Thu, 17 Dec 2015 23:06 GMT
  • Disposition: Resolved — ALF 1.1
  • Disposition Summary:

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

  • Updated: Thu, 22 Jun 2017 16:40 GMT

Allow Expressions to Just Conform to Primitive Types

  • Key: ALF11-4
  • Legacy Issue Number: 16430
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    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

  • Reported: ALF 1.0b2 — Fri, 29 Jul 2011 04:00 GMT
  • Disposition: Resolved — ALF 1.1
  • Disposition Summary:

    Loosen certain constraints requiring standard primitive types

    Agreed.

  • Updated: Thu, 22 Jun 2017 16:40 GMT

Alf should support Real

  • Key: ALF11-29
  • Legacy Issue Number: 18497
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    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.

  • Reported: ALF 1.0 — Sat, 23 Feb 2013 05:00 GMT
  • Disposition: Resolved — ALF 1.1
  • Disposition Summary:

    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.
  • Updated: Thu, 22 Jun 2017 16:40 GMT

Sequence feature invocation expressions

  • Key: ALF11-22
  • Legacy Issue Number: 17509
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    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.

  • Reported: ALF 1.0b2 — Thu, 19 Jul 2012 04:00 GMT
  • Disposition: Resolved — ALF 1.1
  • Disposition Summary:

    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.

  • Updated: Thu, 22 Jun 2017 16:40 GMT

Overload resolution for feature invocation expressions should be specific about the case of multiple most-specific operations.

  • Key: ALF11-35
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    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.

  • Reported: ALF 1.0 — Mon, 22 Jun 2015 20:27 GMT
  • Disposition: Resolved — ALF 1.1
  • Disposition Summary:

    Add clarification to overloading resolution rules

    Agreed.

  • Updated: Thu, 22 Jun 2017 16:40 GMT

Multiplicity upper bound of a select or reject expression should be based on its primary expression

  • Key: ALF11-37
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    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.

  • Reported: ALF 1.0 — Mon, 22 Jun 2015 21:05 GMT
  • Disposition: Resolved — ALF 1.1
  • Disposition Summary:

    Update selectOrRejectExpressionUpperDerivation constraint

    Agreed.

  • Updated: Thu, 22 Jun 2017 16:40 GMT

Table 9.1 incorrectly lists "@determined" instead of "@determinate".

  • Key: ALF11-36
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

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

  • Reported: ALF 1.0 — Mon, 22 Jun 2015 20:30 GMT
  • Disposition: Resolved — ALF 1.1
  • Disposition Summary:

    Correct Table 9.1

    Agreed.

  • Updated: Thu, 22 Jun 2017 16:40 GMT

Instance creation should start classifier behaviors of parent classes

  • Key: ALF11-67
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    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.

  • Reported: ALF 1.0 — Wed, 20 Apr 2016 15:48 GMT
  • Disposition: Resolved — ALF 1.1
  • Disposition Summary:

    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.

  • Updated: Thu, 22 Jun 2017 16:40 GMT

Bad assignment example

  • Key: ALF11-87
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    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.

  • Reported: ALF 1.0 — Thu, 25 Aug 2016 19:44 GMT
  • Disposition: Resolved — ALF 1.1
  • Disposition Summary:

    Correct example

    Agreed.

  • Updated: Thu, 22 Jun 2017 16:40 GMT

Incorrect derivation of AssignmentExpression::isFeature

  • Key: ALF11-75
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    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.

  • Reported: ALF 1.0 — Fri, 22 Jul 2016 19:14 GMT
  • Disposition: Resolved — ALF 1.1
  • Disposition Summary:

    Fix isFeature derivations

    The indicated derivations need to be fixed.

  • Updated: Thu, 22 Jun 2017 16:40 GMT

Indexing in sequence access expressions should be 0-based

  • Key: ALF11-14
  • Legacy Issue Number: 16597
  • Status: closed  
  • Source: IBM ( Mattias Mohlin)
  • Summary:

    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.

  • Reported: ALF 1.0b1 — Fri, 14 Oct 2011 04:00 GMT
  • Disposition: Resolved — ALF 1.1
  • Disposition Summary:

    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.

  • Updated: Thu, 22 Jun 2017 16:40 GMT

Classify statements should start classifier behaviors

  • Key: ALF11-26
  • Legacy Issue Number: 18281
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    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.

  • Reported: ALF 1.0 — Sun, 25 Nov 2012 05:00 GMT
  • Disposition: Resolved — ALF 1.1
  • Disposition Summary:

    Have classify statements start classifier behaviors

    Agreed.

  • Updated: Thu, 22 Jun 2017 16:40 GMT

Primitive type casts

  • Key: ALF11-23
  • Legacy Issue Number: 17512
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    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

  • Reported: ALF 1.0b2 — Thu, 19 Jul 2012 04:00 GMT
  • Disposition: Resolved — ALF 1.1
  • Disposition Summary:

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

  • Updated: Thu, 22 Jun 2017 16:40 GMT

Is it allowed to omit super destructor calls in an explicit destructor?

  • Key: ALF11-17
  • Legacy Issue Number: 16600
  • Status: closed  
  • Source: IBM ( Mattias Mohlin)
  • Summary:

    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.

  • Reported: ALF 1.0b1 — Fri, 14 Oct 2011 04:00 GMT
  • Disposition: Closed; No Change — ALF 1.1
  • Disposition Summary:

    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.

  • Updated: Thu, 22 Jun 2017 16:40 GMT

The semantics of destroying part objects without accessible destructor must be specified

  • Key: ALF11-16
  • Legacy Issue Number: 16599
  • Status: closed  
  • Source: IBM ( Mattias Mohlin)
  • Summary:

    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.

  • Reported: ALF 1.0b1 — Fri, 14 Oct 2011 04:00 GMT
  • Disposition: Closed; No Change — ALF 1.1
  • Disposition Summary:

    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.

  • Updated: Thu, 22 Jun 2017 16:40 GMT

The referenced fUML version should be updated to 1.2.1

  • Key: ALF11-68
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    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.

  • Reported: ALF 1.0 — Wed, 20 Apr 2016 15:51 GMT
  • Disposition: Resolved — ALF 1.1
  • Disposition Summary:

    Update fUML version to 1.2.1

    Agreed.

  • Updated: Thu, 22 Jun 2017 16:40 GMT

Definition of “Collection Class”

  • Key: ALF11-2
  • Legacy Issue Number: 16427
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    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.

  • Reported: ALF 1.0b2 — Fri, 29 Jul 2011 04:00 GMT
  • Disposition: Resolved — ALF 1.1
  • Disposition Summary:

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

  • Updated: Thu, 22 Jun 2017 16:40 GMT

Non-deterministic behavior on "if statement"

  • Key: ALF11-13
  • Legacy Issue Number: 16488
  • Status: closed  
  • Source: THALES ( Laurent Rioux)
  • Summary:

    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.

  • Reported: ALF 1.0b1 — Tue, 9 Aug 2011 04:00 GMT
  • Disposition: Closed; No Change — ALF 1.1
  • Disposition Summary:

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

  • Updated: Thu, 22 Jun 2017 16:40 GMT

ActivityDefinition and OperationDefinition Bodies

  • Key: ALF11-12
  • Legacy Issue Number: 16475
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    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.

  • Reported: ALF 1.0b2 — Fri, 29 Jul 2011 04:00 GMT
  • Disposition: Resolved — ALF 1.1
  • Disposition Summary:

    Add effectiveBody derived properties

    Agreed.

  • Updated: Thu, 22 Jun 2017 16:40 GMT

NamespaceDefinition::member type

  • Key: ALF11-11
  • Legacy Issue Number: 16471
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    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.

  • Reported: ALF 1.0b2 — Fri, 29 Jul 2011 04:00 GMT
  • Disposition: Resolved — ALF 1.1
  • Disposition Summary:

    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.

  • Updated: Thu, 22 Jun 2017 16:40 GMT

NonFinalClause and SwitchClause Should Have Derived assignmentBefore and assignmentAfter

  • Key: ALF11-10
  • Legacy Issue Number: 16466
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    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.

  • Reported: ALF 1.0b2 — Fri, 29 Jul 2011 04:00 GMT
  • Disposition: Resolved — ALF 1.1
  • Disposition Summary:

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

  • Updated: Thu, 22 Jun 2017 16:40 GMT

Empty Type Names for Initialization Sequence and Construction Expressions

  • Key: ALF11-9
  • Legacy Issue Number: 16465
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

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

  • Reported: ALF 1.0b2 — Fri, 29 Jul 2011 04:00 GMT
  • Disposition: Resolved — ALF 1.1
  • Disposition Summary:

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

    Agreed.

  • Updated: Thu, 22 Jun 2017 16:40 GMT

The resolution of Issue 17517 was incomplete

  • Key: ALF11-28
  • Legacy Issue Number: 18451
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    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.

  • Reported: ALF 1.0 — Wed, 9 Jan 2013 05:00 GMT
  • Disposition: Resolved — ALF 1.1
  • Disposition Summary:

    Correct the assignmentExpressionSimpleAssignementTypeConformance constraint

    Agreed.

  • Updated: Thu, 22 Jun 2017 16:40 GMT

NameLeftHandSide needs a feature constraint

  • Key: ALF11-25
  • Legacy Issue Number: 18267
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    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.

  • Reported: ALF 1.0 — Sat, 17 Nov 2012 05:00 GMT
  • Disposition: Resolved — ALF 1.1
  • Disposition Summary:

    Add nameLeftHandSideFeatureExpression constraint

    Agreed.

  • Updated: Thu, 22 Jun 2017 16:40 GMT

IncrementOrDecrementExpression::operator attribute is missing

  • Key: ALF11-24
  • Legacy Issue Number: 18233
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    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.

  • Reported: ALF 1.0 — Fri, 26 Oct 2012 04:00 GMT
  • Disposition: Resolved — ALF 1.1
  • Disposition Summary:

    Add IncrementOrDecrementExpression::operator property

    Agreed that this property needs to be added.

  • Updated: Thu, 22 Jun 2017 16:40 GMT

An abstract operation should not be allowed to have a body

  • Key: ALF11-34
  • Legacy Issue Number: 19184
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    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.

  • Reported: ALF 1.0 — Tue, 14 Jan 2014 05:00 GMT
  • Disposition: Resolved — ALF 1.1
  • Disposition Summary:

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

  • Updated: Thu, 22 Jun 2017 16:40 GMT

BehaviorInvocationExpression Should Have a Derived Implicit Binding

  • Key: ALF11-5
  • Legacy Issue Number: 16433
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    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

  • Reported: ALF 1.0b2 — Fri, 29 Jul 2011 04:00 GMT
  • Disposition: Resolved — ALF 1.1
  • Disposition Summary:

    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.

  • Updated: Thu, 22 Jun 2017 16:40 GMT

Some Derived Associations Should Be Composite

  • Key: ALF11-3
  • Legacy Issue Number: 16428
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    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.

  • Reported: ALF 1.0b2 — Fri, 29 Jul 2011 04:00 GMT
  • Disposition: Resolved — ALF 1.1
  • Disposition Summary:

    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.

  • Updated: Thu, 22 Jun 2017 16:40 GMT

ConcurrentClauses Should Have a Derived assignmentBefore

  • Key: ALF11-8
  • Legacy Issue Number: 16461
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    Subclause: 14.2.8 ConcurrentClauses

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

  • Reported: ALF 1.0b2 — Fri, 29 Jul 2011 04:00 GMT
  • Disposition: Resolved — ALF 1.1
  • Disposition Summary:

    Add assignmentBefore association to ConcurrentClauses

    Agreed.

  • Updated: Thu, 22 Jun 2017 16:40 GMT

NameExpression::assignment Derivation for a Parameter Name

  • Key: ALF11-7
  • Legacy Issue Number: 16446
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    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.

  • Reported: ALF 1.0b2 — Fri, 29 Jul 2011 04:00 GMT
  • Disposition: Resolved — ALF 1.1
  • Disposition Summary:

    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.

  • Updated: Thu, 22 Jun 2017 16:40 GMT

Derivation of the Type of a ConditionalTestExpression

  • Key: ALF11-6
  • Legacy Issue Number: 16438
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    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

  • Reported: ALF 1.0b2 — Fri, 29 Jul 2011 04:00 GMT
  • Disposition: Closed; No Change — ALF 1.1
  • Disposition Summary:

    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.

  • Updated: Thu, 22 Jun 2017 16:40 GMT

The actual parameter for the template binding of Bag is wrong

  • Key: ALF11-33
  • Legacy Issue Number: 18526
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    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.

  • Reported: ALF 1.0 — Tue, 5 Mar 2013 05:00 GMT
  • Disposition: Resolved — ALF 1.1
  • Disposition Summary:

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

    Agreed.

  • Updated: Thu, 22 Jun 2017 16:40 GMT

Multiplicity element errors in parameters in the CollectionClasses package

  • Key: ALF11-32
  • Legacy Issue Number: 18522
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

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

  • Reported: ALF 1.0 — Sun, 3 Mar 2013 05:00 GMT
  • Disposition: Resolved — ALF 1.1
  • Disposition Summary:

    Multiplicity element errors in parameters in the CollectionClasses package

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

  • Updated: Thu, 22 Jun 2017 16:40 GMT

Parameters of some constructor operations in collection classes have incorrect types

  • Key: ALF11-31
  • Legacy Issue Number: 18521
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    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

  • Reported: ALF 1.0 — Sun, 3 Mar 2013 05:00 GMT
  • Disposition: Resolved — ALF 1.1
  • Disposition Summary:

    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.

  • Updated: Thu, 22 Jun 2017 16:40 GMT

CollectionClasses::Map::Bag references the wrong template parameter

  • Key: ALF11-30
  • Legacy Issue Number: 18520
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    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.

  • Reported: ALF 1.0 — Sat, 2 Mar 2013 05:00 GMT
  • Disposition: Resolved — ALF 1.1
  • Disposition Summary:

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

    Agreed.

  • Updated: Thu, 22 Jun 2017 16:40 GMT

Alf should be based on fUML 1.1

  • Key: ALF11-27
  • Legacy Issue Number: 18393
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

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

  • Reported: ALF 1.0 — Tue, 29 Jan 2013 05:00 GMT
  • Disposition: Resolved — ALF 1.1
  • Disposition Summary:

    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.

  • Updated: Thu, 22 Jun 2017 16:40 GMT

UML RTF 1.4 Issue: CreateAction links to only one classifier.

  • Key: ALF-50
  • Legacy Issue Number: 3286
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

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

  • Reported: ALF 1.0b1 — Sat, 5 Feb 2000 05:00 GMT
  • Disposition: Resolved — ALF 1.0b2
  • Disposition Summary:

    Decline

  • Updated: Sat, 7 Mar 2015 02:00 GMT

Synchronous action

  • Key: ALF-49
  • Legacy Issue Number: 2005
  • Status: closed  
  • Source: Anonymous
  • Summary:

    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

  • Reported: ALF 1.0b1 — Mon, 28 Sep 1998 04:00 GMT
  • Disposition: Resolved — ALF 1.0b2
  • Disposition Summary:

    Fixed in adopted spec

  • Updated: Sat, 7 Mar 2015 02:00 GMT

Inherited abstract operations

  • Key: ALF_-78
  • Legacy Issue Number: 17526
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    Subject: Inherited abstract operations

    Subclauses: 15.2.4 ClassDefinition, 15.2.16 OperationDefinition

    There is currently a constraint for an OperationDefinition that it must owned by a non-abstract class. This isn’t strong enough, because it doesn’t prevent a non-abstract class from inheriting an abstract operation. Instead, there should be a constraint on ClassDefinition that all member operations (owned or inherited) are not abstract.

  • Reported: ALF 1.0b2 — Thu, 19 Jul 2012 04:00 GMT
  • Disposition: Resolved — ALF 1.0
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 21:49 GMT

Classifier behavior required for an active class

  • Key: ALF_-77
  • Legacy Issue Number: 17525
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    Subject: Classifier behavior required for an active class

    Subclause: 15.2.1 ActiveClassDefinition

    A non-abstract active class must have a classifier behavior, because this is required by StartObjectBehaviorAction

  • Reported: ALF 1.0b2 — Thu, 19 Jul 2012 04:00 GMT
  • Disposition: Resolved — ALF 1.0
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 21:49 GMT

Assignment of out parameters in if and switch statements

  • Key: ALF_-76
  • Legacy Issue Number: 17524
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    Subject: Assignment of out parameters in if and switch statements

    Subclauses: 14.2.13 ifStatement, 14.2.20 SwitchStatement

    According to Subclauses 9.8 and 9.9, it is not permitted to define a new local name in an if statement without an else clause or a switch statement without a default clause. The ifStatementAssignmentsAfter and switchStatementAssignments constraints in Subclauses 14.2.13 and 14.2.22 attempt to enforce this by requiring that the assignments after such if or switch statements be the same as those before the statement. However, this constraint is too strong. An out parameter does not have an assign source before it is first assignment, yet it is already defined as a local name. Therefore, the constraints should be loosened to allow an if statement without an else clause or a switch statement without a default clause to contain the first assignment of an out parameter.

  • Reported: ALF 1.0b2 — Thu, 19 Jul 2012 04:00 GMT
  • Disposition: Resolved — ALF 1.0
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 21:49 GMT

Derivation of SequenceOperationExpression::isCollectionConversion

  • Key: ALF_-75
  • Legacy Issue Number: 17523
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    Subject: Derivation of SequenceOperationExpression::isCollectionConversion

    Subclause: 13.2.50 SequenceOperationExpression

    In Subclause 13.2.50 SequenceOperationExpression, the derivation for isCollectionConversion should include the requirement that the multiplicity is upper bound is 1.

  • Reported: ALF 1.0b2 — Thu, 19 Jul 2012 04:00 GMT
  • Disposition: Resolved — ALF 1.0
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 21:49 GMT

InstanceCreationExpression class must not be abstract

  • Key: ALF_-73
  • Legacy Issue Number: 17521
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    Subject: InstanceCreationExpression class must not be abstract

    Subclause: 13.2.22 InstranceCreationExpression

    In Subclause 13.2.22 InstanceCreationExpression there should be a constraint that the class of a constructor operation, or the referent if it is a class or data type, must not be abstract. In the case in which this constraint would be violated, but there is an associated Impl class constructor per Subclause 8.3.12, the referent should be the Impl constructor

  • Reported: ALF 1.0b2 — Thu, 19 Jul 2012 04:00 GMT
  • Disposition: Resolved — ALF 1.0
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 21:49 GMT

Indexed feature left hand sides

  • Key: ALF_-72
  • Legacy Issue Number: 17520
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    Subject: Indexed feature left hand sides

    Subclauses: 13.2.18 FeatureLeftHandSide, 13.2.35 NameLeftHandSide

    In a FeatureLeftHandSide, if the left-hand side has an index, then the referenced feature must be a sequence (simply being ordered is not enough for the “replace” semantics of indexed assignment). Since a similar constraint is required for a NameLeftHandSide with an index, if the name

    disambiguates to a feature, the constraint is probably best handled in a unified way in the LeftHandSide superclass.

  • Reported: ALF 1.0b2 — Thu, 19 Jul 2012 04:00 GMT
  • Disposition: Resolved — ALF 1.0
  • Disposition Summary:

    To handle this constraint in a unified way in LeftHandSide superclass would probably require adding a derived referent property to be used for it, as well as adding derivations for it in each subclass. It is simpler instead to just add to each subclass the specific constraints necessary to resolve the issue.

  • Updated: Fri, 6 Mar 2015 21:49 GMT

Referent of a signal send

  • Key: ALF_-71
  • Legacy Issue Number: 17519
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    Subject: Referent of a signal send

    Subclauses: 13.2.3 BehaviorInvocationExpression, 13.2.17 FeatureInvocationExpression

    The description of the InvocationExpression::referent property in Subclause 13.2.23 is “The behavior, operation or signal being invoked.” The featureInvocationExpressionReferentDerivation in Subclause 13.2.17 derives this property as the referent of the feature of the FeatureInvocationExpression. The behaviorInvocationExpressionReferentDerivation in Subclause 13.2.3 has derives the referent similarly, in the case that the target name of a BehaviorInvocationExpression disambiguates to a feature reference. However, for a signal send, the feature being referenced will actually be a reception for the signal, not the signal itself. The derivations in Subclauses 13.2.3 and 13.2.17 should be revised to account for this.

  • Reported: ALF 1.0b2 — Thu, 19 Jul 2012 04:00 GMT
  • Disposition: Resolved — ALF 1.0
  • Disposition Summary:

    The constraint behaviorInvocationExpressionReferentDerivation actually already says “if the target disambiguates to a feature reference, the operation or signal being invoked”, which identifies that, for a signal send, the referent is the signal, not the reception. It is featureInvocationExpressionReferentDerivation that needs to be adjusted.

  • Updated: Fri, 6 Mar 2015 21:49 GMT

Assigned name must not be template binding

  • Key: ALF_-74
  • Legacy Issue Number: 17522
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    Subject: Assigned name must not be template binding

    Subclause: 13.2.35 NameLeftHandSide

    In Subclause 13.2.35 NameLeftHandSide, there needs to be a constraint that the name is not a template binding.

  • Reported: ALF 1.0b2 — Thu, 19 Jul 2012 04:00 GMT
  • Disposition: Resolved — ALF 1.0
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 21:49 GMT

Inconsistency on being constructorless

  • Key: ALF_-67
  • Legacy Issue Number: 17515
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    Subject: Inconsistency on being constructorless

    Subclause: 10.5.3.1 Constructors

    In Subclause 10.5.3.1 it says that the mapping of default constructors “means that the instantiation of a class defined using Alf textual notation is never ‘constructorless’ as defined in Subclause 8.3.12”. However, later in the same subclause it says “If a class has an explicit constructor definition, then the default constructor is no longer available, even if the defined constructor has a different name than the default constructor.” But if no default constructor is available, and there is no explicit constructor with the name of the class and no arguments, then a constructorless instantiation is possible.

  • Reported: ALF 1.0b2 — Thu, 19 Jul 2012 04:00 GMT
  • Disposition: Resolved — ALF 1.0
  • Disposition Summary:

    If a class has one or more explicit constructors, then the intent is that instances of the class be created using one of these constructors. Therefore, constructorless instantiation should not be allowed in this case, even if there is no default constructor.

  • Updated: Fri, 6 Mar 2015 21:49 GMT

Constructor in a BehaviorInvocationExpression

  • Key: ALF_-70
  • Legacy Issue Number: 17518
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    Subject: Constructor in a BehaviorInvocationExpression

    Subclause: 13.2.3 BehaviorInvocationExpression

    In Subclause 13.2.17, FeatureInvocationExpression contains the constraint featureInvocationExpressionAlternativeConstructor, which constrains the placement of an alternative constructor invocation within the method of a constructor operation. However, the target name of a BehaviorInvocationExpression may also disambiguate to a feature reference to a constructor. If such an invocation is within the method of a constructor operation, then it also needs to be similarly constrained as an alternative constructor invocation (perhaps by moving featureInvocationAlternativeConstructor constraint needs to be moved to the InvocationExpression superclass).

  • Reported: ALF 1.0b2 — Thu, 19 Jul 2012 04:00 GMT
  • Disposition: Resolved — ALF 1.0
  • Disposition Summary:

    Moving the constraint to the InvocationExpression superclass will not work, because this constraint limits when the referent of a feature invocation is a constructor. However, InstanceCreationExpression is also a subclass of InvocationExpression, and, in this case, the referent actually is supposed to be a constructor.

    Therefore, a similar constraint needs to be added to BehaviorInvocationExpression

  • Updated: Fri, 6 Mar 2015 21:49 GMT

Error in AssignmentExpression constraints

  • Key: ALF_-69
  • Legacy Issue Number: 17517
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    Subject: Error in AssignmentExpression constraints

    Subclause: 13.2.2 AssignmentExpression

    · In Subclause 13.2.1 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.

    · The type and multiplicity bounds of a compound AssignmentExpression should be those of the left-hand side, not the right-hand side.

  • Reported: ALF 1.0b2 — Thu, 19 Jul 2012 04:00 GMT
  • Disposition: Resolved — ALF 1.0
  • Disposition Summary:

    Agreed on the first bullet (except that the reference to 13.2.1 should be to 13.2.2).
    On the second bullet, the problem is that the current assignmentExpressionCompoundTypeConformance constraint requires that the left-hand side and the right-hand side have the same type. This works for arithmetic or Boolean operations, but it does not necessarily work for bit string operations (which may have an Integer right-hand side) or shift operations (which require and Integer right-hand side). In all cases, however, the type of the compound assignment will be the type of the left-hand side.
    The multiplicity upper bound for a compound assignment is required to always be 1. However, the multiplicity lower bound may be either 0 or 1, as determined by the multiplicity lower bound of the left-hand side.

  • Updated: Fri, 6 Mar 2015 21:49 GMT

AssignmentExpression as a data value update

  • Key: ALF_-68
  • Legacy Issue Number: 17516
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    Subject: AssignmentExpression as a data value update

    Subclause: 13.2.2 AssignmentExpression,

    · An assignment expression should only be allowed to be a data value update if its left hand side is a feature reference whose primary expression is a local name or parameter name.

    · The derivation of the assignment for an assignment expression needs to account for the cases of a data value update and an indexed left hand side.

  • Reported: ALF 1.0b2 — Thu, 19 Jul 2012 04:00 GMT
  • Disposition: Resolved — ALF 1.0
  • Disposition Summary:

    The deriviation of isDataValueUpdate is such that it is true only in the case mentioned in the first bullet. However, nothing currently prevents assignment to an attribute of a data type where the primary expression of the feature reference is not a local name or parameter. Such an assignment will not be mapped correctly, because it will not be considered a data value update and, so, the updated data value will be lost. Therefore, this case should be disallowed.
    In the case of a data value update for an indexed left-hand side, the multiplicity of the new assignment should not be that of the left-hand side (which will be 1) but, rather, should be * (since only a sequence can be indexed).

  • Updated: Fri, 6 Mar 2015 21:49 GMT

@determined should be @determinate

  • Key: ALF_-66
  • Legacy Issue Number: 17514
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    Subject: @determined should be @determinate

    Subclauses: 9.8 if Statement, 9.9 switch Statement, 14.2.13 IfStatement, 14.2.22 SwitchStatement

    The @determined annotation on if and switch statements should be @determinate, to correspond to the ConditionalNode attribute isDeterminate.

  • Reported: ALF 1.0b2 — Thu, 19 Jul 2012 04:00 GMT
  • Disposition: Resolved — ALF 1.0
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 21:49 GMT

Error in bit string conversion

  • Key: ALF_-65
  • Legacy Issue Number: 17513
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    Subject: Error in bit string conversion

    Subclause: 8.8 Assignment Expressions

    In Subclause 8.8 Assignment Expressions, under “Assignability”, the function referenced for bit string conversion should be ToBitString, not ToInteger.

  • Reported: ALF 1.0b2 — Thu, 19 Jul 2012 04:00 GMT
  • Disposition: Resolved — ALF 1.0
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 21:49 GMT

SequenceExpressionList::element should be ordered

  • Key: ALF_-64
  • Legacy Issue Number: 17511
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    Subject: SequenceExpressionList::element should be ordered

    Subclauses: 8.3.15 Sequence Construction Expressions, 13.1 Overview

    Since a SequenceExpressionList represents an ordered list of expressions, clearly SequenceExpressionList::element should be ordered.

  • Reported: ALF 1.0b2 — Thu, 19 Jul 2012 04:00 GMT
  • Disposition: Resolved — ALF 1.0
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 21:49 GMT

Error in Data Value Creation Expression

  • Key: ALF_-63
  • Legacy Issue Number: 17510
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    Subject: Error in Data Value Creation Expression

    Subclause: 8.3.12 Instance Creation Expressions

    In the second paragraph under “Data Value Creation Expression” in Subclause 8.3.12 Instance Creation Expressions, it says “Each argument expression must be to the corresponding attribute…”. This should be “Each argument expression must be assignable to the corresponding attribute…”.

  • Reported: ALF 1.0b2 — Thu, 19 Jul 2012 04:00 GMT
  • Disposition: Resolved — ALF 1.0
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 21:49 GMT

Problem with parameters of CollectionFunctions::removeAll

  • Key: ALF-46
  • Legacy Issue Number: 16591
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Arnaud Cuccuru)
  • Summary:

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

  • Reported: ALF 1.0b1 — Wed, 12 Oct 2011 04:00 GMT
  • Disposition: Resolved — ALF 1.0b2
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Typo in sequence functions?

  • Key: ALF-45
  • Legacy Issue Number: 16586
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Arnaud Cuccuru)
  • Summary:

    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.

  • Reported: ALF 1.0b1 — Mon, 10 Oct 2011 04:00 GMT
  • Disposition: Resolved — ALF 1.0b2
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Errors in Subclause 8.2

  • Key: ALF_-62
  • Legacy Issue Number: 17508
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    Subject: Errors in Subclause 8.2

    Subclause: 8.2 Qualified Names

    · In the example at the end of Subclause 8.2 Qualified Names it says “The standard library class Map has two template parameters, K and V.” Actually, the template parameters are “Key” and “Value”.

    · The references to UML specification subclauses in Subclause 8.2 are all off by one (e.g., 7.3.34 instead of 7.3.35 for Namespace) for UML 2.4.

  • Reported: ALF 1.0b2 — Thu, 19 Jul 2012 04:00 GMT
  • Disposition: Resolved — ALF 1.0
  • Disposition Summary:

    Agreed on the first bullet. On the second bullet, it is actually only references to subclauses with numbers greater than 7.3.28 that are wrong, because the UML 2.4.1 inserted a new Subclause 7.3.29 for LiteralReal.

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Should be allowed to use return statement in all behaviors

  • Key: ALF-48
  • Legacy Issue Number: 16606
  • Status: closed  
  • Source: IBM ( Mattias Mohlin)
  • Summary:

    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.

  • Reported: ALF 1.0b1 — Fri, 14 Oct 2011 04:00 GMT
  • Disposition: Resolved — ALF 1.0b2
  • Disposition Summary:

    This is a duplicate of Issue 16419.

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Problem with parameters of CollectionFunctions::replaceOne

  • Key: ALF-47
  • Legacy Issue Number: 16592
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Arnaud Cuccuru)
  • Summary:

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

  • Reported: ALF 1.0b1 — Wed, 12 Oct 2011 04:00 GMT
  • Disposition: Resolved — ALF 1.0b2
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Errors in the Collection Classes Implemenation

  • Key: ALF_-61
  • Legacy Issue Number: 16482
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    Subclause: C.4 Alf Standard Library Collection Classes Implementation

    • All the collection implementation classes have an incorrect namespace declaration containing “Collections::CollectionClasses”, rather than just “CollectionClasses”. They also import “Alf::Library::FunctionBehaviors::Collections::CollectionFunctions” rather than “Alf::Library::CollectionFunctions”.
    • Return types should not be given on constructors.
    • Several classes have destructors that call CollectionImpl<T>::destroy, but CollectionImpl has no such destructor.
    • The classes that have multiple specializations have to redefine indistinguishable operations inherited from both classes.
    • In C.4.2 CollectionImpl,
    o excludesAll and includesAll have seq as their parameter, but incorrectly use the name “element” in their bodies.
    o In the first statement of removeOne, “self” is used instead of “this”.
    o In the last statement of retainAll, there should not be “()” after “preSize”.
    • In C.4.3 OrderedCollectionImpl,
    o In the body of addAt, the call to “addAllAt” should be proceeded by “this.”.
    o In the body of indexOf, the reference to “indexof” should be “indexOf”.
    • In C.4.5 OrderedSet,
    o In the body of equals, “OrdredCollcetionImpl” should be “OrderedCollectionImpl”.
    o In the body of subOrderedSet, the constructor “OrderedSet” should be “OrderedSet<T>”.
    • In C.4.6 Bag, the super constructor call should be to CollectionImpl, not OrderedCollection.
    • In C.4.7 List,
    o CollectionClasses::Impl::List should specialize CollectionClasses::List, not CollectionClasses::OrderedSet.
    o subList should return List<T>, not OrderedSet<T>.
    o In subList, the constructor “List” should be “List<T>”.
    o The parameter for setContent should be a “sequence”.
    • In C.4.8 Queue,
    o Queue should specialize CollectionClasses::Queue, not CollectionClasses::Set.
    o In the body of removeFirst, “toSequence” should be “toSequence()”.
    o removeFirstOne should have a return multiploicity of 1..1.
    o The body of removeFirstOne should return the argument element or null, depending on whether the element was actually found for deletion.
    • In C.4.9 Deque,
    o Deque should specialize CollectionClasses::Deque in addition to Queue.
    o The super constructor call should be super.Queue<T>::Queue, not just super, and the super destructor call should be super.Queue<T>::destroy.
    o The implementation of removeLastOne removes all occurrences of the given element, not just the last one.
    o toSequence cannot return “this.content”, since “content” is private to Queue.
    o The (constructor) operation Queue is inherited from both superclasses and must be redefined.

  • Reported: ALF 1.0b2 — Fri, 29 Jul 2011 04:00 GMT
  • Disposition: Resolved — ALF 1.0
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Errors in the Property Management Service Example

  • Key: ALF_-60
  • Legacy Issue Number: 16481
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    Subclause: C.3 Property Management Service

    • To be consistent with the implementation of ‘create reply’, the association of Property to Location should be optional.

    • In the ‘create property’ example, the mandatory ‘property type’ needs to be set in the propertyData instance creation expression.

    • In the establish operation, two occurrences of “request.name” should be replaced with “request.’property name’”.

    • In the acquire, update, delete and retrieve operations, the reply and error out parameters need to be set to null values before the if statement and the select expressions should have “[1]” at the end.

    • In the acquire, update and dispose operations, the reference to ‘Property Type’ should be ‘Property Status’ and the assignment in the second if clause should be equality.

    • The update operation needs to import 'Property Management'::'Data Model'::Locations::Location. Also, “request.’property location’” should be “request.’property location identifier’” (three times), “request.’serial number’ “should be “request.’property serial number’” and “request.size” should be “request.’property size’”.

  • Reported: ALF 1.0b2 — Fri, 29 Jul 2011 04:00 GMT
  • Disposition: Resolved — ALF 1.0
  • Disposition Summary:

    Agreed, except that:
    • The second bullet should reference the ‘create reply’ activity (which has a propertyData instance creation expression) rather than ‘create property) which does not.
    • In the fifth bullet, the issue with assignment seems to have already been resolved.
    Revised Text:

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Errors in the Online Bookstore Example

  • Key: ALF_-59
  • Legacy Issue Number: 16480
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    Subclause: C.2 Online Bookstore

    • In the example class Order, the statement “accept (OrderDelivery)” should be “accept (OrderDelivered)”. Also, the nested activities have to be operations, because nested activities don’t have the containing class as their context.

    • In the example activity EstablishCustomer, “TIM::current_date” should be replaced with “TIM::GetCurrentDate()”.

    • The ProcessCharge activity should import Ordering::CreditCardCharge::ChargeData.

    • In the graphical model for the Ordering example, the Customer class is shown as having a purchasesMade attribute that is not set in the EstablishCustomer activity, but that activity instead shows a phone attribute being set that is missing from the class.

  • Reported: ALF 1.0b2 — Fri, 29 Jul 2011 04:00 GMT
  • Disposition: Resolved — ALF 1.0
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Errors in QuickSort Example

  • Key: ALF_-58
  • Legacy Issue Number: 16479
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    Subclause: C.1 Quicksort Activity

    In the “functional” QuickSort example:
    • x cannot be set only in the else part of an if statement
    • The sequence operation “remove” should be “removeAt”
    • The recursive call to “QuickSort” should be “Quicksort”.

  • Reported: ALF 1.0b2 — Fri, 29 Jul 2011 04:00 GMT
  • Disposition: Resolved — ALF 1.0
  • Disposition Summary:

    The first and third bullets are correct. However, the example already uses “removeAt”, not “remove”, so no change is necessary for that.
    Note also that Annex C should really be Annex B (since it is the second annex).

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Errors in Constraint Names

  • Key: ALF_-57
  • Legacy Issue Number: 16478
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    Subclauses: Various subclauses in Part III Abstract Syntax

    The following constraint names should be corrected as shown:
    • expressionAssignmentsAfterDerivation -> expressionAssignmentAfterDerivation
    • bitStringUnaryExpresionIsBitStringConversionDerivation -> bitStringUnaryExpressionIsBitStringConversionDerivation
    • loopVariableIsCollectionConversionDerivation -> loopVariableDefinitionIsCollectionConversionDerivation
    • importedElementNotStub -> importedMemberNotStub
    • importedElementFeatureDerivation -> importedMemberIsFeatureDerivation
    • forAllOrExistOrOneExpressionTypeDerivation -> forAllOrExistsOrOneExpressionTypeDerivation
    • forAllOrExistOrOneExpressionLowerDerivation -> forAllOrExistsOrOneExpressionLowerDerivation
    • forAllOrExistOrOneExpressionUpperDerivation -> forAllOrExistsOrOneExpressionUpperDerivation
    • forAllOrExistOrOneExpressionArgument -> forAllOrExistsOrOneExpressionArgument
    • relationalExpressionIsTypeDerivation -> relationalExpressionTypeDerivation
    • relationalExpressionIsLowerDerivation -> relationalExpressionLowerDerivation
    • relationalExpressionIsUpperDerivation -> relationalExpressionUpperDerivation
    • unboundedLiteralExpressionDerivation -> unboundedLiteralExpressionTypeDerivation
    • namespaceDefinitionMemberDistinguishaibility -> namespaceDefinitionMemberDistinguishability
    • operationDefinitionIsConstructorDefinition -> operationDefinitionIsDestructorDerivation
    • operationDefinitionIsDestructorDefinition -> operationDefinitionIsDestructorDerivation
    • operationDefinitionRedefinedOperationsDerivation -> operationDefinitionRedefinedOperationConstraint
    • propertyDefinitionIsBitStringConversion -> propertyDefinitionIsBitStringConversionDerivation
    • incrementOrDecrementExpressionIsDataValueUpdate -> incrementOrDecrementExpressionIsDataValueUpdateDerivation
    • incrementOrDecrementExpressionFeature -> incrementOrDecrementExpressionFeatureDerivation
    • incrementOrDecrementExpressionAssignment -> incrementOrDecrementExpressionAssignmentDerivation

  • Reported: ALF 1.0b2 — Fri, 29 Jul 2011 04:00 GMT
  • Disposition: Resolved — ALF 1.0
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Description of SignalDefinition::isSameKindAs

  • Key: ALF_-56
  • Legacy Issue Number: 16477
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    Subclause: 15.2.21 SignalDefinition

    The description of SignalDefinition::isSameKindAs mentions “Reception” where it should say “Signal”.

  • Reported: ALF 1.0b2 — Fri, 29 Jul 2011 04:00 GMT
  • Disposition: Resolved — ALF 1.0
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Assignments Before a Property Initializer

  • Key: ALF_-55
  • Legacy Issue Number: 16476
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    Subclause: 15.2.19 PropertyDefinition

    The propertyDefinitionInitializer constraint should also state that there are no assignments before the initializer expression.

  • Reported: ALF 1.0b2 — Fri, 29 Jul 2011 04:00 GMT
  • Disposition: Resolved — ALF 1.0
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 21:48 GMT

NamespaceDefinition::ownedMember Should Be Ordered

  • Key: ALF_-52
  • Legacy Issue Number: 16472
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    Subclause: 15.2.15 NamespaceDefinition

    NamespaceDefinition::ownedMember association should be ordered. (This is important at least for activity and operation parameters.)

  • Reported: ALF 1.0b2 — Fri, 29 Jul 2011 04:00 GMT
  • Disposition: Resolved — ALF 1.0
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Errors in ImportedMember

  • Key: ALF_-51
  • Legacy Issue Number: 16470
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    Subclause: 15.2.12 ImportedMember

    • The description of ImportedMember::isSameKind is written in terms of distinguishability rather than same kind.

    • An ImportedMember should not generally be considered a feature, even if it is a feature of the namespace it is imported from, since it is not a feature of the namespace it is imported into.

  • Reported: ALF 1.0b2 — Fri, 29 Jul 2011 04:00 GMT
  • Disposition: Resolved — ALF 1.0
  • Disposition Summary:

    • In the case of Alf members, it is appropriate to use the terminology “same kind”. However, in the case of two UML elements, the standard terminology of distinguishability still needs to be used.
    • No change is required for an ImportedMember no be considered a feature. The isFeature property inherited from Member is false by default and the default value is never changed for an ImportedMember.

  • Updated: Fri, 6 Mar 2015 21:48 GMT

ElementImportReference Constraint

  • Key: ALF_-50
  • Legacy Issue Number: 16469
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    Subclause: 15.2.8 ElementImportReference

    ElementImportReference should have a constraint that its referent must be a packageable element.

  • Reported: ALF 1.0b2 — Fri, 29 Jul 2011 04:00 GMT
  • Disposition: Resolved — ALF 1.0
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Constructor Return Type

  • Key: ALF_-54
  • Legacy Issue Number: 16474
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    Subclause: 15.2.16 OperationDefinition

    OperationDefinition must take into account that the return type of a constructor is not explicitly declared, but is still included in the operation signature (per Subclause 10.5.3.1).

  • Reported: ALF 1.0b2 — Fri, 29 Jul 2011 04:00 GMT
  • Disposition: Resolved — ALF 1.0
  • Disposition Summary:

    This needs to be accounted for in the definitions of the isSameKindAs and matchForStub helper operations.

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Description of operationDefinitionRedefinition

  • Key: ALF_-53
  • Legacy Issue Number: 16473
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    Subclause: 15.2.16 OperationDefinition

    In the description of OperationDefinition::operationDefinitionRedefinition, “signal referent” should be “single referent”.

  • Reported: ALF 1.0b2 — Fri, 29 Jul 2011 04:00 GMT
  • Disposition: Resolved — ALF 1.0
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Errors in Descriptions of SwitchStatement constraints

  • Key: ALF_-49
  • Legacy Issue Number: 16468
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    Subclause: 14.2.22

    • The description of the switchStatementExpression constraint should be “The expression of a switch statement must have a multiplicity no greater than 1.”

    • The description of the switchStatementEnclosedStatements constraint should be “A switch statement is the enclosing statement for the statements in all of its switch clauses.”

    • The switchStatementAssignmentsBefore constraint should state that the assignments before the clauses of a switch statement are the assignments after the expression of the switch statement.

  • Reported: ALF 1.0b2 — Fri, 29 Jul 2011 04:00 GMT
  • Disposition: Resolved — ALF 1.0
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 21:48 GMT

SwitchClause Should Have a switchClauseCase Constraint

  • Key: ALF_-48
  • Legacy Issue Number: 16467
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    Subclause: 14.2.21 SwitchClause

    SwitchClause should have a switchClauseCases constraint the states “All the cases expressions of a switch clause must have a multiplicity no greater than 1.”

  • Reported: ALF 1.0b2 — Fri, 29 Jul 2011 04:00 GMT
  • Disposition: Resolved — ALF 1.0
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Derivation of LocalNameDeclaration::type

  • Key: ALF_-47
  • Legacy Issue Number: 16464
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    Subclause: 14.2.15

    The localNameDeclarationTypeDerivation requires the type of the statement to be the type of the expression if no type name is given. However, this is not correct, since the only way that the type name could be empty is if it is given as “any”, in which case the local name should be untyped.

  • Reported: ALF 1.0b2 — Fri, 29 Jul 2011 04:00 GMT
  • Disposition: Resolved — ALF 1.0
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Correction to shiftExpressionOperands Constraint

  • Key: ALF_-42
  • Legacy Issue Number: 16458
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    Subclause: 13.2.53 ShiftExpression

    The description of the shiftExpressionOperands constraint should say “The first operand expression of a shift expression must have the type BitString or Integer. The second operand expression must have the type Integer.” (per Subclause 8.6.3).

  • Reported: ALF 1.0b2 — Fri, 29 Jul 2011 04:00 GMT
  • Disposition: Resolved — ALF 1.0
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 21:48 GMT

ForStatement Should Have a Composition Association to Block

  • Key: ALF_-45
  • Legacy Issue Number: 16462
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    Subclause: 14.2.12 for Statements

    ForStatement should have a composition association with its body Block.

  • Reported: ALF 1.0b2 — Fri, 29 Jul 2011 04:00 GMT
  • Disposition: Resolved — ALF 1.0
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Block Assignment Constraints

  • Key: ALF_-44
  • Legacy Issue Number: 16460
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    Subclause: 14.2.4 Block

    • The second sentence of the description of the Block::assignmentAfter derived property mentions “statement” twice when it should say “block”.

    • The blockAssignmentsBefore constraint should have the definition “The assignments before the first statement of a block are the same as the assignments before the block.”

  • Reported: ALF 1.0b2 — Fri, 29 Jul 2011 04:00 GMT
  • Disposition: Resolved — ALF 1.0
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Correction to superInvocationExpressionTarget Constraint

  • Key: ALF_-43
  • Legacy Issue Number: 16459
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    Subclause: 13.2.55 SuperInvocationExpression

    The superInvocationExpressionImplicitTarget constraint should include the condition that the containing behavior has only a single superclass

  • Reported: ALF 1.0b2 — Fri, 29 Jul 2011 04:00 GMT
  • Disposition: Resolved — ALF 1.0
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 21:48 GMT

localNameDeclarationStatementAssignmentsAfter constraint

  • Key: ALF_-46
  • Legacy Issue Number: 16463
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    Subclause 14.2.15 LocalNameDeclarationStatement

    The localNameDeclarationStatementAssignmentsAfter constraint states “The assignments after a local name declaration statement are the assignments before the statement plus a new assignment for the local name defined by the statement.” The assignments should be the assignments after the expression of the statement plus the new assignment (so as to include assignments made in the expression).

  • Reported: ALF 1.0b2 — Fri, 29 Jul 2011 04:00 GMT
  • Disposition: Resolved — ALF 1.0
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 21:48 GMT

SequenceOperationExpression Constraints

  • Key: ALF_-41
  • Legacy Issue Number: 16457
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    Subclause: 13.2.50 SequenceOperationExpression

    • SequenceOperationExpression needs a constraint that a name may not be assigned in both the primary expression and any tuple argument expression.

    • SequenceOperationExpression should have a derived association with an optional LeftHandSide that is created in the case of an “in place” operation and must have its constraints satisfied. The sequenceOperationExpressionTargetCompatibility constraint should also require that, for an “in place” operation, the primary expression have the form of a left-hand side and, if for a local name, the local name must already exist.

  • Reported: ALF 1.0b2 — Fri, 29 Jul 2011 04:00 GMT
  • Disposition: Resolved — ALF 1.0
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 21:48 GMT

SequenceOperationExpression Should Override parameterElements

  • Key: ALF_-40
  • Legacy Issue Number: 16456
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    Subclause: 13.2.50 SequenceOperationExpression

    SequenceOperationExpression should override the parameterElements operation to only return the parameters after the first, since the argument for the first parameter is given by the primary expression not in the tuple.

  • Reported: ALF 1.0b2 — Fri, 29 Jul 2011 04:00 GMT
  • Disposition: Resolved — ALF 1.0
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 21:48 GMT

SequenceConstructionExpression Constraints

  • Key: ALF_-38
  • Legacy Issue Number: 16454
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    Subclause: 13.2.46 SerquenceConstructionExpression

    • SequenceConstructionExpression needs constraints on the type and multiplicity of its sequence elements. However, the rules here (and as stated in Subclause 8.3.15) need to allow for bit string conversion of integer elements for a bit string sequence.

    • The description of the sequenceExpansionExpressionVariableSourceDerivation constraint should also state that the type of the assigned source for the expansion variable is the type of the primary expression and the multiplicity bounds are both 1.

    • SequenceExpansionExpression needs a constraint that no names defined before the argument expression may be reassigned in the argument expression (per the Semantics in Subclause 8.3.19), not just the expansion variable.

    • The description of the sequenceExpansionExpressionListUpperDerivation constraint says “lower bound” when in should say “upper bound”.

  • Reported: ALF 1.0b2 — Fri, 29 Jul 2011 04:00 GMT
  • Disposition: Resolved — ALF 1.0
  • Disposition Summary:

    Agreed. However, only the first bullet in the issue summary is for Subclause 13.2.46 SequenceConstructionExpression. The second bullet is for 13.2.48 SequenceExpansionExpression. The third bullet is for 13.2.49 SequenceExpressionList (not “SequenceExpansionExpressionList”).

  • Updated: Fri, 6 Mar 2015 21:48 GMT

SequenceConstructionExpression Needs to Override updateAssignments

  • Key: ALF_-39
  • Legacy Issue Number: 16455
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    Subclause: 13.2.46 SequenceConstructionExpression

    SequenceConstructionExpression needs to override updateAssignments. For a sequence expression list, the assignments before each element expression should be the assignment after the previous one and the assignments after the sequence construction expression are the assignments after the last element expression. For a sequence range the assignments before both expressions are the assignments before the sequence construction expression and the assignments after the sequence construction expression are the assignments after the expressions. There should also be a constraint on sequence ranges that the same local name cannot be assigned in both expressions

  • Reported: ALF 1.0b2 — Fri, 29 Jul 2011 04:00 GMT
  • Disposition: Resolved — ALF 1.0
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 21:48 GMT

SequenceConstructionExpression::typeName May Be Empty

  • Key: ALF_-37
  • Legacy Issue Number: 16453
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    Subclause: 13.2.46 SequenceConstructionExpression

    The description of the sequenceConstructionExpressionType constraint should make it clear that it is legal for the typeName property to be empty (corresponding to a type name notation of “any”).

  • Reported: ALF 1.0b2 — Fri, 29 Jul 2011 04:00 GMT
  • Disposition: Resolved — ALF 1.0
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Error in propertyAccessExpressionLowerDerivation

  • Key: ALF_-34
  • Legacy Issue Number: 16450
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    Subclause: 13.2.41 PropertyAccessExpression

    The propertyAccessExpressionLowerDerivation constraint description refers to upper bounds when it should refer to lower bounds

  • Reported: ALF 1.0b2 — Fri, 29 Jul 2011 04:00 GMT
  • Disposition: Resolved — ALF 1.0
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 21:48 GMT

PositionalTuple Needs a Constraint

  • Key: ALF_-33
  • Legacy Issue Number: 16449
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    Subclause: 13.2.40 PositionalTuple

    PositionalTuple should have a constraint that it does not have more arguments than its invocation has parameters.

  • Reported: ALF 1.0b2 — Fri, 29 Jul 2011 04:00 GMT
  • Disposition: Resolved — ALF 1.0
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Error in qualifiedNameDisambiguationDerivation

  • Key: ALF_-36
  • Legacy Issue Number: 16452
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    Subclause: 13.2.42 QualifiedName

    In the description of qualifiedNameDisambiguationDerivation, “If a qualified name is not ambiguous or it resolves to a namespace…” should be “If a qualified name is not ambiguous or it has a qualification that resolves to a namespace…”

  • Reported: ALF 1.0b2 — Fri, 29 Jul 2011 04:00 GMT
  • Disposition: Resolved — ALF 1.0
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 21:48 GMT

QualifiedName::templateName Needs a Description

  • Key: ALF_-35
  • Legacy Issue Number: 16451
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    Subclause: 13.2.42 QualifiedName
    QualifiedName::templateName needs a description

  • Reported: ALF 1.0b2 — Fri, 29 Jul 2011 04:00 GMT
  • Disposition: Resolved — ALF 1.0
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 21:48 GMT

NamedTuple Needs a Constraint

  • Key: ALF_-30
  • Legacy Issue Number: 16445
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    Subclause: 13.2.33 NamedTuple

    NamedTuple should have a constraint that its argument names all correspond to parameter names of its invocation and that no argument name appears more than once.

  • Reported: ALF 1.0b2 — Fri, 29 Jul 2011 04:00 GMT
  • Disposition: Resolved — ALF 1.0
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Problem with the NamedExpression Conversion Constraints

  • Key: ALF_-29
  • Legacy Issue Number: 16444
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    Subclause: 13.2.31 NamedExpression

    The constraints namedExpressionIsBitStringConversion and namedExpressionIsCollectionConversion cannot really be checked within the context of NamedExpression, since there is no way from that context to determine what the type of the “corresponding parameter” is.

  • Reported: ALF 1.0b2 — Fri, 29 Jul 2011 04:00 GMT
  • Disposition: Resolved — ALF 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Errors in LogicalExpression Constraints

  • Key: ALF_-28
  • Legacy Issue Number: 16443
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    Subclause: 13.2.29 LogicalExpression

    • The definitions of the logicalExpressionIsBitStringConversion1 and logicalExpressionIsBitStringConversion2 constraints mention “shift expression” when they should say “logical expression”.

    • The logicalExpressionOperands constraint should allow for BitString and Integer operands (per the semantics of logical expression in Subclause 8.6.7).

    • The logicalExpressionTypeDeriviation constraint should give the type BitString if the expression is bit-wise.

  • Reported: ALF 1.0b2 — Fri, 29 Jul 2011 04:00 GMT
  • Disposition: Resolved — ALF 1.0
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 21:48 GMT

literalExpressionTypeDerivation Is Not Necessary

  • Key: ALF_-27
  • Legacy Issue Number: 16442
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    Subclause: 13.2.28 LiteralExpression

    The constraint literalExpressionTypeDerivation (“The type of a literal expression is given by the type of the literal, as defined for each subclass below.”) is not necessary, since it doesn’t provide any actual constraint. (Plus, in the current document organization, not all of the subclasses are “below” the subclause on LiteralExpression.)

  • Reported: ALF 1.0b2 — Fri, 29 Jul 2011 04:00 GMT
  • Disposition: Resolved — ALF 1.0
  • Disposition Summary:

    Agreed.

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Problems with NameLeftHandSide Constraints

  • Key: ALF_-32
  • Legacy Issue Number: 16448
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    Subclause: 13.2.35 NameLeftHandSide

    • There needs to be a constraint on NameLeftHandSide that if its name is qualified, and does not disambiguate to a feature, then it resolves to a parameter of the behavior containing the left-hand side, and, if it disambiguates to a feature, it resolves to a single referent that is a structural feature.

    • In the nameLeftHandSideAssignmentAfterDerivation constraint, if the named left hand side has an index, then the assignments after the left hand side should be the assignments after the index.

    • The derivations for assignmentBefore and assignmentAfter for NameLeftHandSide need to account for the possibility of the name disambiguating to a feature reference

  • Reported: ALF 1.0b2 — Fri, 29 Jul 2011 04:00 GMT
  • Disposition: Resolved — ALF 1.0
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 21:48 GMT

NameExpression Should Override updateAssignments

  • Key: ALF_-31
  • Legacy Issue Number: 16447
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    Subclause: 13.2.34 NameExpression

    NameExpression should override updateAssignments to return the assignments after its derived propertyAccess expression, if it has one (i.e., if it disambiguates to a feature reference).

  • Reported: ALF 1.0b2 — Fri, 29 Jul 2011 04:00 GMT
  • Disposition: Resolved — ALF 1.0
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Corrections to InvocationExpression::parameterElements

  • Key: ALF_-26
  • Legacy Issue Number: 16441
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    Subclause: 13.2.23 InvocationExpression

    • The return parameter of the InvocationExpression::parameterElements helper operation should be ordered.

    • The definition of InvocationExpression::parameterElements should also handle the case in which the reference is an association end.

  • Reported: ALF 1.0b2 — Fri, 29 Jul 2011 04:00 GMT
  • Disposition: Resolved — ALF 1.0
  • Disposition Summary:

    Agreed. Though ordering the return parameter on parameterElements presumes a resolution to Issue 16472 such that the ownedMembers of a Namespace are ordered.

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Constraint Needed on FeatureLeftHandSide

  • Key: ALF_-24
  • Legacy Issue Number: 16439
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    Subclause: 13.2.18

    There needs to be a constraint on FeatureLeftHandSide that it resolves to a single referent that is a structural feature.

  • Reported: ALF 1.0b2 — Fri, 29 Jul 2011 04:00 GMT
  • Disposition: Resolved — ALF 1.0
  • Disposition Summary:

    Agreed. Note that the revised text below presumes the resolution for Issue 16435, which adds the referent derived property.

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Corrections to updateAssignments for ConditionalTestExpression

  • Key: ALF_-23
  • Legacy Issue Number: 16437
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    Subclause: 13.2.13 ConditionalTestExpression

    The description of the updateAssignments operation for ConditionalTestExpression should clearly state that assignments can be made in the first operand expression. It should also state that the type of newly defined names is the effective common ancestor of the types of the name in each of the second and third operands

  • Reported: ALF 1.0b2 — Fri, 29 Jul 2011 04:00 GMT
  • Disposition: Resolved — ALF 1.0
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Derivations of type, lower and upper for Invocation Expressions

  • Key: ALF_-25
  • Legacy Issue Number: 16440
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    Subclause: 13.2.23 InvocationExpression

    The derivations of type, lower and upper inherited in InvocationExpression are based on the return parameter of the referent of the expression. This doesn’t work for referents that are not behaviors or operations. Specifically:

    • For an InstanceCreationExpression, the referent may be a classifier (Class or DataType), in which case, the type needs to be the referent itself and lower and upper need to both be 1.

    • For a BehaviorInvocationExpression, the referent may be an association end, in which case the type, lower and upper need to be the same as for the end.

  • Reported: ALF 1.0b2 — Fri, 29 Jul 2011 04:00 GMT
  • Disposition: Resolved — ALF 1.0
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Require Non-Template Classifier

  • Key: ALF_-22
  • Legacy Issue Number: 16436
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    Subclauses: 13.2.8 CastExpression and 13.2.10 Classification Expression

    The castExpressionTypeResolution and classificationExpressionTypeName constraints should require a non-template classifier

  • Reported: ALF 1.0b2 — Fri, 29 Jul 2011 04:00 GMT
  • Disposition: Resolved — ALF 1.0
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Derived Attributes for LeftHandSide

  • Key: ALF_-21
  • Legacy Issue Number: 16435
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    Subclause: 13.2.6 LeftHandSide

    A left hand side should have derived type, lower and upper attributes, since these are defined in Subclause 8.8.

  • Reported: ALF 1.0b2 — Fri, 29 Jul 2011 04:00 GMT
  • Disposition: Resolved — ALF 1.0
  • Disposition Summary:

    Agreed (however, the correct subclause for LeftHandSide is 13.2.26, not 13.2.6). Constraints for AssignmentExpression also refer to the type and bounds of the left-hand side. Note, though, that the type and bounds for a left-hand side for the first assignment of a local name cannot be derived directly from the left-hand side, since they are determined by the right-hand side of the assignment. But this is already accounted for in the simple assignment multiplicity and type conformance constraints for an AssignmentExpression.

  • Updated: Fri, 6 Mar 2015 21:48 GMT

binaryExpressionOperandMultiplicity Constraint is Too Strong for EqualityExpression

  • Key: ALF_-20
  • Legacy Issue Number: 16434
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    Subclause: 13.2.4

    The binaryExpressionOperandMultiplicity constraint requires that the operands of a binary expression have a multiplicity upper bound of 1. However, an equality expression (a kind of binary expression) is allowed to compare to “null”, which has a multiplicity upper bound of zero.

  • Reported: ALF 1.0b2 — Fri, 29 Jul 2011 04:00 GMT
  • Disposition: Resolved — ALF 1.0
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Errors in BehaviorInvocationExpression Constraints

  • Key: ALF_-19
  • Legacy Issue Number: 16432
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    Subclause: 13.2.3 BehaviorInvocationExpression

    • The behaviorInvocationExpressionReferentDerivation should allow for resolution of the target to an association end.

    • The behaviorInvocationExpressionArgumentCompatibility constraint should note that it only applies if the target does not disambiguate to a feature reference.

  • Reported: ALF 1.0b2 — Fri, 29 Jul 2011 04:00 GMT
  • Disposition: Resolved — ALF 1.0
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Type Conformance for Compound Assignments for Bit Strings

  • Key: ALF_-18
  • Legacy Issue Number: 16431
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    Subclause: 13.2.2

    The assignmentExpressionCompoundAssignmentTypeConformance constraint should also handle compound assignments for bit string operators.

  • Reported: ALF 1.0b2 — Fri, 29 Jul 2011 04:00 GMT
  • Disposition: Resolved — ALF 1.0
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 21:48 GMT

IndexOf Return Type

  • Key: ALF_-15
  • Legacy Issue Number: 16425
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    Subclause: 11.3.6 Sequence Functions

    In Table 11-14, the return type of IndexOf should be Integer, not any.

  • Reported: ALF 1.0b2 — Fri, 29 Jul 2011 04:00 GMT
  • Disposition: Resolved — ALF 1.0
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Synthesis of the Name of a Reception Definition

  • Key: ALF_-14
  • Legacy Issue Number: 16424
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    Subclause 10.5.4: ReceptionDefinition

    In the syntax for ReceptionDefinition, the condition for d.name should be

    {d.name=d.signal.nameBinding->last().name}

    .

  • Reported: ALF 1.0b2 — Fri, 29 Jul 2011 04:00 GMT
  • Disposition: Resolved — ALF 1.0
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Errors in Abstract Syntax Attribute Names

  • Key: ALF_-17
  • Legacy Issue Number: 16429
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    Subclauses: 13.2.31 NamedExpression, 15.2.9 EnumerationDefinition, 15.2.15 NamespaceDefinition, and 15.2.16 OperationDefinition

    • NamedExpression::isBitStringConverstion should be isBitStringConversion
    • EnumerationDefinition::classDefinitionSpecializationReferent should be enumerationDefinitionSpecializationReferent
    • NamespaceDefinition::annotationAllowed should not be abstract.
    • OperationDefinition::redefinedOperations should be redefinedOperation

  • Reported: ALF 1.0b2 — Fri, 29 Jul 2011 04:00 GMT
  • Disposition: Resolved — ALF 1.0
  • Disposition Summary:

    Agreed. (Note, however, that “classDefinitionSpecializationReferent” and “annotationAllowed” are not an attributes, they are a constraint and a helper operation, respectively. But the indicated errors still need to be corrected.)

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Errors in Collection Function Table

  • Key: ALF_-16
  • Legacy Issue Number: 16426
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    Subclause: 11.5 Collection Functions

    In Table 11-15, “ordered nonuique” [sic] appears twice (first column, second and third rows) and should be replaced with “sequence”. remove, removeAll and removeOne should return “T[*] sequence”.

  • Reported: ALF 1.0b2 — Fri, 29 Jul 2011 04:00 GMT
  • Disposition: Resolved — ALF 1.0
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Constructors and Diamond Inheritance

  • Key: ALF_-13
  • Legacy Issue Number: 16423
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    Subclause: 10.5.3.1 Constructors

    At the end of Subclause 10.5.3.1 it states that: “In the absence of explicit constructor invocations at the start of a constructor body (and also in the case of the default constructor behavior), a super constructor invocation is made implicitly for each immediate superclass, in the order the superclasses appear in the specializes list of the class containing the constructor, before executing any statements in the constructor body.” However, if the immediate superclasses themselves have common ancestors (so called “diamond inheritance”), applying this rule recursively will result in the constructors of these common ancestors being called multiple times.

  • Reported: ALF 1.0b2 — Fri, 29 Jul 2011 04:00 GMT
  • Disposition: Resolved — ALF 1.0
  • Disposition Summary:

    Agreed. Handling diamond inheritance can be tricky. The approach proposed here leaves the current constructor semantics largely in place, and simply adds that, after a constructor from a certain class is called on an object, other calls on constructors from the same class have no effect. This could be implemented adding class-specific initialization flags to the implementation of the object or by “linearizing” the sequence of direct and indirect super constructor calls and removing any redundant calls.

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Return Statements with no Expression

  • Key: ALF_-9
  • Legacy Issue Number: 16419
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    Subclauses: 9.14 return Statements
    A return statement without an expression should be allowed for a behavior without a return parameter.

  • Reported: ALF 1.0b2 — Fri, 29 Jul 2011 04:00 GMT
  • Disposition: Resolved — ALF 1.0
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Error in ProcessQueue Example

  • Key: ALF_-12
  • Legacy Issue Number: 16422
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    Subclause: 10.4.3 Active Classes

    In the ProcessQueue example in Subclause 10.4.3, “sign” that appears twice in the classifier behavior should be “sig”.

  • Reported: ALF 1.0b2 — Fri, 29 Jul 2011 04:00 GMT
  • Disposition: Resolved — ALF 1.0
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Error in Singleton Examples

  • Key: ALF_-11
  • Legacy Issue Number: 16421
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    Subclause 10.4.2 Classes

    In the Singleton example use in Subclause 10.4.2 under Semantics, “allinstances” should be “allInstances”.

  • Reported: ALF 1.0b2 — Fri, 29 Jul 2011 04:00 GMT
  • Disposition: Resolved — ALF 1.0
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Implicit Imports

  • Key: ALF_-10
  • Legacy Issue Number: 16420
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    Subclause: 10.1 Overview

    It is only necessary to require implicit imports of standard model library packages into model units. Any direct or indirect subunits of a model library unit with implicit imports will have visibility upwards of the packages imported into the model unit. Also, applying «ModelLibrary» to a subunit cannot prevent this visibility of the standard model library packages, and so this stereotype is also actually only effective on a model unit.

  • Reported: ALF 1.0b2 — Fri, 29 Jul 2011 04:00 GMT
  • Disposition: Resolved — ALF 1.0
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Evaluation of Loop Variable Definitions

  • Key: ALF_-8
  • Legacy Issue Number: 16418
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    Subclause: 9.12 for Statements

    It should be made clear that the expressions in the loop variable definitions of a for statement are evaluated sequentially in the order of the loop variables (per the mapping). (Or, if the expressions are evaluated concurrently, then there needs to be a constraint that the same name cannot be assigned in more than one of those expressions.)

  • Reported: ALF 1.0b2 — Fri, 29 Jul 2011 04:00 GMT
  • Disposition: Resolved — ALF 1.0
  • Disposition Summary:

    Rather than adding a constraint (and changing the mapping), it seems easier to just make it clear that they are evaluated sequentially. And, in the abstract syntax, ForStatement::variableDefinition is ordered, which also indicates that sequential evaluation is the intent.

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Error in Synthesis of Null Expressions

  • Key: ALF_-5
  • Legacy Issue Number: 16415
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    Subclause: 8.3.15: Sequence Construction Expressions

    In Subclause 8.3.15, the parsing of a NullExpression should set the hasMultiplicity=true for the SequenceConstructionExpression, otherwise the derivation of the lower and upper attributes (see Subclause 13.2.46) will result in those both being 1 instead of both being 0.

  • Reported: ALF 1.0b2 — Fri, 29 Jul 2011 04:00 GMT
  • Disposition: Resolved — ALF 1.0
  • Disposition Summary:

    In Subclause 8.3.15 Sequence Construction Expressions, under Syntax, in the production for SequenceConstructionExpression, in the second line, after “NullExpression” add “(hasMultiplicity=true)”.

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Boolean Literals Cannot Be Used as Identifiers

  • Key: ALF_-4
  • Legacy Issue Number: 16414
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    Subclause 7.5: Names

    Subclause 7.5 should says that reserved words cannot be used as identifiers, but it should also note that Boolean literals (which are not classified as reserved words) can also not be used as identifiers.

  • Reported: ALF 1.0b2 — Fri, 29 Jul 2011 04:00 GMT
  • Disposition: Resolved — ALF 1.0
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Missing Cross Reference in Subclause 9.6

  • Key: ALF_-7
  • Legacy Issue Number: 16417
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    Subclause: 9.6 Local Name Declaration Statements

    Subclause 9.6 should have a cross reference to the abstract syntax class InstanceCreationExpression, since the InstanceInitializationExpression production creates an instance of that class.

  • Reported: ALF 1.0b2 — Fri, 29 Jul 2011 04:00 GMT
  • Disposition: Resolved — ALF 1.0
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Parenthesizing Left Hand Sides

  • Key: ALF_-6
  • Legacy Issue Number: 16416
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    Subclause: 8.8 Assignment Expressions

    It should be allowed to parenthesize a left hand side. This makes it possible to parse the left hand side simply as an expression and then check afterward if it is correct (as is done in the grammar given in the annex). It is also consistent with Java syntax.

  • Reported: ALF 1.0b2 — Fri, 29 Jul 2011 04:00 GMT
  • Disposition: Resolved — ALF 1.0
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Correction to Section 8.3.6, Property Access Expressions

  • Key: ALF_-2
  • Legacy Issue Number: 16015
  • Status: closed  
  • Source: RPC Software ( Ted Stockwell)
  • Summary:

    There is a small problem in section 8.3.6 regarding property access expressions.
    The problem is that the concrete syntax defined in that section will not
    actually match the examples given in that section.

    ---------
    Here is the concrete syntax defined in that section...

    PropertyAccessExpression(e: PropertyAccessExpression)
    = FeatureReference(e.featureReference)

    FeatureReference(f: FeatureReference)
    = FeatureTargetExpression(f.expression) "." NameBinding(f.nameBinding)

    FeatureTargetExpression(e: Expression)
    = NameTargetExpression(e)

    NonNamePrimaryExpression(e)

    NameTargetExpression(e: NameExpression)
    = ColonQualifiedName(e.name)

    Note that NameTargetExpression only allows ColonQualifiedName(s) to be used to
    define a PropertyAccessExpression.

    -------
    Here are the examples of property access expressions from the same section...

    poleValue.im
    this.node
    members.name
    jack.house

    Note that, because NameTargetExpression only allows ColonQualifiedName(s), none
    of the above examples matches the concrete syntax.

    ----------
    I suspect that NameTargetExpression should be defined to be a QualifiedName,
    which is defined to be either a DotQualifiedName, an UnqualifiedName, or a
    ColonQualifiedName, so...

    NameTargetExpression(e: NameExpression)
    = QualifiedName(e.name)

    where QualifiedName is defined elsewhere as:

    QualifiedName(q: QualifedName)
    = ColonQualifiedName(q)

    DotQualifiedName(q)
    UnqualifiedName(q)
  • Reported: ALF 1.0b2 — Mon, 7 Feb 2011 05:00 GMT
  • Disposition: Resolved — ALF 1.0
  • Disposition Summary:

    This is indeed a little confusing, but it is not actually an error in the spec. There is a note on page 38 that says:
    “See Subclause 8.2 for rules on the disambiguation of a qualified name using the dot notation to a property access expression. Such a potentially ambiguous expression is always initially parsed as a qualified name.”
    For example, as far as context-free parsing is concerned, an expression like “poleValue.im” is ambiguous – it could be a qualified name using the dot notation, or it could be a property access expression for the “im” attribute of the value of the name “poleValue”. Disambiguation requires using static semantic information on “poleValue” (e.g., is it a local name with a type that has an “im” property), as described in Subclause 8.2.
    Despite this conceptual ambiguity, the formal grammar is made unambiguous by always parsing “poleValue.im” initially as a qualified name. That is why a dot qualified name is not allowed as a name target expression. Possible disambiguation to a property access expression then happens as part of static semantic analysis (this is formally through the derived QualifiedName::disambiguation attribute specified in Subclause 13.2.42).
    Note also, by the way, that the grammar as given actually does parse “this.node” as a property access expression, because “this” is a reserved word, not a name. Thus, “this” is parsed as a NonNamePrimaryExpression (a ThisExpression, to be exact), not a NameTargetExpression.

  • Updated: Fri, 6 Mar 2015 21:48 GMT

StructuredMember should be renamed to StructuredElement

  • Key: ALF_-1
  • Legacy Issue Number: 16006
  • Status: closed  
  • Source: Anonymous
  • Summary:

    In order to play with ALF I have thrown together a parser for my own use.
    Along the way I have found a small error in the spec regarding the Abstract Syntax for ALF. Many clauses in the spec (Beta 1) refer to 'StructuredElement' and those same clauses say that StructuredElement is defined in clause 10.4.4. However, in clause 10.4.4 the element appears to be named 'StructuredMember' instead.

    It looks to me like StructuredMember should be renamed to StructuredElement since the term 'Element' appears to be the convention used throughout the rest of the spec.

  • Reported: ALF 1.0b2 — Wed, 2 Feb 2011 05:00 GMT
  • Disposition: Resolved — ALF 1.0
  • Disposition Summary:

    The intent was actually to change StructuredElement to StructuredMember (which is a better name for it), but the rest of the document outside Subclause 10.4.4 does not seem to have been properly updated for this (note that the parser grammar in the Annex uses StructuredMember).

  • Updated: Fri, 6 Mar 2015 21:48 GMT

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

  • Key: ALF-44
  • Legacy Issue Number: 15626
  • Status: closed  
  • Source: agnos.ai UK Ltd ( Pete Rivett)
  • Summary:

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

  • Reported: ALF 1.0b1 — Thu, 23 Sep 2010 04:00 GMT
  • Disposition: Resolved — ALF 1.0b2
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 21:48 GMT

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

  • Key: ALF-43
  • Legacy Issue Number: 15625
  • Status: closed  
  • Source: agnos.ai UK Ltd ( Pete Rivett)
  • Summary:

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

  • Reported: ALF 1.0b1 — Thu, 23 Sep 2010 04:00 GMT
  • Disposition: Resolved — ALF 1.0b2
  • Disposition Summary:

    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

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Null Template Binding Arguments

  • Key: ALF_-3
  • Legacy Issue Number: 16413
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    Subclause: 6.2 Templates

    The rule in Subclause 6.2 for constructing the name of an equivalent bound element does not account for the possibility that one of the arguments may be null (i.e., “any”). While the syntax for template bindings in qualified names (Subclause 8.2) does not allow “any” to be used as a template argument, such an argument can result from the rules for the implicit binding for a template behavior as given in Subclause 8.3.9.

  • Reported: ALF 1.0b2 — Fri, 29 Jul 2011 04:00 GMT
  • Disposition: Resolved — ALF 1.0
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Messaging action language examples

  • Key: ALF-42
  • Legacy Issue Number: 4925
  • Status: closed  
  • Source: International Business Machines ( Sridhar Iyengar)
  • Summary:

    [Sridhar Iyengar] 42. Page C-19, section C.5 Messaging Actions, 2nd
    para, the text refers to the local variable 'my_customer' and refers to
    object inuvocation of validate(). The class diagram in Page C-20, figure
    C-16, refers to the valdiate() operation but the figure shows a
    marshalAction on CustomerDeleteRequest class. Please fix the figure (Or
    remove it!) to be consistent with the example. Note that Figure C-17
    does show the validate() operaton invocation correctly.

  • Reported: ALF 1.0a — Tue, 5 Mar 2002 05:00 GMT
  • Disposition: Resolved — ALF 1.0b1
  • Disposition Summary:

    duplicate of 4924 --close issue

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Runtime Instance

  • Key: ALF-41
  • Legacy Issue Number: 4902
  • Status: closed  
  • Source: International Business Machines ( Sridhar Iyengar)
  • Summary:

    [Sridhar Iyengar] 4. I was confused when trying to interpret
    'runtimeinstance' data type - but after the explanation (from
    Conrad/Steve/Jim) about the removal of the execution model (with the
    associated ripple effect on change bars in most of the submission which
    slowed my review), I realize that this will not cause any interchange or
    interoperability problems. I recommend that this usage be clarified in
    the spec, so others dont get confused either.

    30. ReclassifyObjectAction class. The text specifies the Association
    'input' to be of type 'RuntimeObject'. This clearly cannot be right
    because 'RuntimeObject' is not defined as a class in the metamodel. The
    type should be 'InputPin'.

  • Reported: ALF 1.0a — Tue, 5 Mar 2002 05:00 GMT
  • Disposition: Resolved — ALF 1.0b1
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Variable to VariableAction association should have multiplicity *

  • Key: ALF-40
  • Legacy Issue Number: 5104
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    Variable to VariableAction association should have multiplicity *

  • Reported: ALF 1.0a — Tue, 2 Apr 2002 05:00 GMT
  • Disposition: Resolved — ALF 1.0b1
  • Disposition Summary:

    accept

  • Updated: Fri, 6 Mar 2015 20:57 GMT

PrimitiveFunction shouldn't be restricted to datatypes

  • Key: ALF-39
  • Legacy Issue Number: 5103
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    ApplyFunctionAction should work with any user-defined
    function, including those that operate on objects, and that
    have no outputs.

  • Reported: ALF 1.0a — Tue, 2 Apr 2002 05:00 GMT
  • Disposition: Resolved — ALF 1.0b1
  • Disposition Summary:

    decline

  • Updated: Fri, 6 Mar 2015 20:57 GMT

TestIdentityAction should have an output

  • Key: ALF-38
  • Legacy Issue Number: 5102
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    TestIdentityAction should have an output

  • Reported: ALF 1.0a — Tue, 2 Apr 2002 05:00 GMT
  • Disposition: Resolved — ALF 1.0b1
  • Disposition Summary:

    accept

  • Updated: Fri, 6 Mar 2015 20:57 GMT

PrimitiveFunction should have a supertype

  • Key: ALF-37
  • Legacy Issue Number: 5101
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    PrimitiveFunction should have a supertype

  • Reported: ALF 1.0a — Tue, 2 Apr 2002 05:00 GMT
  • Disposition: Resolved — ALF 1.0b1
  • Disposition Summary:

    accept

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Preserving state across reclassification

  • Key: ALF-36
  • Legacy Issue Number: 5095
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    The description of ReclassifyObjectAction does not specify whether the
    states of the object's state machines are preserved across
    reclassification. What if a current state before classification does
    not exist after reclassification? Are exit actions run? Can
    reclassification interrupt an RTC step?

  • Reported: ALF 1.0a — Fri, 29 Mar 2002 05:00 GMT
  • Disposition: Resolved — ALF 1.0b1
  • Disposition Summary:

    accept

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Inconsistent style of action semantics sections of updated UML specificatio

  • Key: ALF-35
  • Legacy Issue Number: 4981
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    Document: OMG Unified Modeling Language Specification (Action Semantics)
    Sections: 2.15 - 2.23

    Description:
    The style of the action semantics sections are not entirely consistent with the other sections in the Semantics chapter, and, to some extent are not even consistent among themselves (compare, for example, the structure of the Composition Actions, Read and Write Actions and Computation Actions chapters). While complete consistency of subsection organization is not necessary, at least the following should be consistent:

    o The use of the terms "abstract syntax", "well-formedness rules" and "semantics".
    o The style for presenting descriptions of attributes and associations.
    o The way OCL is presented (e.g., in the UML 1.4 spec, context clauses are used to define additional operations).

  • Reported: ALF 1.0a — Thu, 14 Mar 2002 05:00 GMT
  • Disposition: Resolved — ALF 1.0b1
  • Disposition Summary:

    decline

  • Updated: Fri, 6 Mar 2015 20:57 GMT

More Typos

  • Key: ALF-29
  • Legacy Issue Number: 4934
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    [Conrad Bock]

    Search for:

    A signal send symbol maps into a SendSignalAction on the incoming
    transition between it and the previous state.

    and insert "procedure containing a" before SendSignalAction.

    Search for:

    An expression string maps to an Expression element (possibly a
    particular subclass of Expression, such as BooleanExpression or
    TimeExpression). If an analyzer yields a procedure for calculating the
    value of the expression, then the body association from Expression to
    Procedure is used to record this.

    and replace "body association" with "procedure association".

  • Reported: ALF 1.0a — Tue, 5 Mar 2002 05:00 GMT
  • Disposition: Resolved — ALF 1.0b1
  • Disposition Summary:

    accept

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Action for starting procedure

  • Key: ALF-28
  • Legacy Issue Number: 4933
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    Conrad Bock] Add action for starting procedure (StartProcedureAction)

    [Jim Rumbaugh] FinishProcedureAction, ReturnFromCallAction.

  • Reported: ALF 1.0a — Tue, 5 Mar 2002 05:00 GMT
  • Disposition: Resolved — ALF 1.0b1
  • Disposition Summary:

    accept

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Multiplicity from Attribute to AttributeAction should be 0..*

  • Key: ALF-27
  • Legacy Issue Number: 4931
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    Multiplicity from Attribute to AttributeAction should be 0..*

  • Reported: ALF 1.0a — Tue, 5 Mar 2002 05:00 GMT
  • Disposition: Resolved — ALF 1.0b1
  • Disposition Summary:

    accept

  • Updated: Fri, 6 Mar 2015 20:57 GMT

CORBA's operation invocation styles.

  • Key: ALF-34
  • Legacy Issue Number: 4942
  • Status: closed  
  • Source: Anonymous
  • Summary:

    [Joaquin Miller] Does the messaging mode support CORBA's messaging styles?

    Joaquin,

    > But the three ways of invoking a procedure in CORBA are:
    >
    > One is synchronous, which works just as you write above.
    >
    > The second is asynchronous or one-way, which is not exactly
    > the same as you describe above for the action semantics.
    > But close enough, perhaps.

    I can't tell the difference.

    > The third has the silly name, deferred synchronous; it is a kind
    > of asynchronous invocation.

    The CORBA spec says this is a synchronous operation called
    asynchronously, but the caller still has the option to get the results
    at a later time. Action semantics does not support this. The
    workaround would be complicated.

  • Reported: ALF 1.0a — Tue, 5 Mar 2002 05:00 GMT
  • Disposition: Resolved — ALF 1.0b1
  • Disposition Summary:

    decline

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Make spec reflect package structure.

  • Key: ALF-33
  • Legacy Issue Number: 4941
  • Status: closed  
  • Source: International Business Machines ( Sridhar Iyengar)
  • Summary:

    Make spec reflect package structure.

  • Reported: ALF 1.0a — Tue, 5 Mar 2002 05:00 GMT
  • Disposition: Resolved — ALF 1.0b1
  • Disposition Summary:

    accept

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Hard/soft deletion actions.

  • Key: ALF-32
  • Legacy Issue Number: 4939
  • Status: closed  
  • Source: Ceira Technologies, Inc. ( Michael Latta)
  • Summary:

    [Michael Latta?] Deletion action should have option for executing or not
    executing the state machine exit actions, for example.

  • Reported: ALF 1.0a — Tue, 5 Mar 2002 05:00 GMT
  • Disposition: Resolved — ALF 1.0b1
  • Disposition Summary:

    Decline with clarification

  • Updated: Fri, 6 Mar 2015 20:57 GMT

include Actions.idl

  • Key: ALF-31
  • Legacy Issue Number: 4938
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Marit Skrede, marit.skrede@netcom.no] I suspect there should be an
    "#include Actions.idl" line at the start of ActivityGraphs.idl - and
    just thought I'd let you know. (BTW, I've jusst used the #includes as
    "lists" when using the idls for Java.)

  • Reported: ALF 1.0a — Tue, 5 Mar 2002 05:00 GMT
  • Disposition: Resolved — ALF 1.0b1
  • Disposition Summary:

    decline

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Exceptions across procedure boundaries.

  • Key: ALF-30
  • Legacy Issue Number: 4935
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    [Conrad Bock] More support for exceptions across procedure boundaries.

  • Reported: ALF 1.0a — Tue, 5 Mar 2002 05:00 GMT
  • Disposition: Resolved — ALF 1.0b1
  • Disposition Summary:

    Already supported

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Messaging action language examples

  • Key: ALF-22
  • Legacy Issue Number: 4924
  • Status: closed  
  • Source: International Business Machines ( Sridhar Iyengar)
  • Summary:

    [Sridhar Iyengar] 42. Page C-19, section C.5 Messaging Actions, 2nd
    para, the text refers to the local variable 'my_customer' and refers to
    object inuvocation of validate(). The class diagram in Page C-20, figure
    C-16, refers to the valdiate() operation but the figure shows a
    marshalAction on CustomerDeleteRequest class. Please fix the figure (Or
    remove it!) to be consistent with the example. Note that Figure C-17
    does show the validate() operaton invocation correctly.

  • Reported: ALF 1.0a — Tue, 5 Mar 2002 05:00 GMT
  • Disposition: Resolved — ALF 1.0b1
  • Disposition Summary:

    accept

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Interaction rule

  • Key: ALF-21
  • Legacy Issue Number: 4923
  • Status: closed  
  • Source: International Business Machines ( Sridhar Iyengar)
  • Summary:

    [Sridhar Iyengar] Wf rule for Interaction: The OCL expression appears to
    be wrong based on the associated text - I am not sure. I think there is
    an extra 'action' in the fragment 'm.action.action.allNestedActions'.
    Next para has a minor typo - change 'an procedure' to 'a procedure'.

  • Reported: ALF 1.0a — Tue, 5 Mar 2002 05:00 GMT
  • Disposition: Resolved — ALF 1.0b1
  • Disposition Summary:

    accept

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Add one-way navigation

  • Key: ALF-24
  • Legacy Issue Number: 4928
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    [Conrad Bock] Add one-way navigation from CreateLinkAction to
    LinkEndCreationData.

  • Reported: ALF 1.0a — Tue, 5 Mar 2002 05:00 GMT
  • Disposition: Resolved — ALF 1.0b1
  • Disposition Summary:

    accept

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Add IsReplaceAll for ReclassifyObjectAction.

  • Key: ALF-23
  • Legacy Issue Number: 4926
  • Status: closed  
  • Source: Object Management Group ( Stephen Mellor)
  • Summary:

    [Steve Mellor] Add IsReplaceAll for ReclassifyObjectAction.

  • Reported: ALF 1.0a — Tue, 5 Mar 2002 05:00 GMT
  • Disposition: Resolved — ALF 1.0b1
  • Disposition Summary:

    accepted

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Rename ReadLinkAction to ReadLinksAction?

  • Key: ALF-26
  • Legacy Issue Number: 4930
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    [Conrad Bock] Rename ReadLinkAction to ReadLinksAction?

  • Reported: ALF 1.0a — Tue, 5 Mar 2002 05:00 GMT
  • Disposition: Resolved — ALF 1.0b1
  • Disposition Summary:

    decline

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Rename ClearAssociationAction to ClearLinkAction?

  • Key: ALF-25
  • Legacy Issue Number: 4929
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    [Conrad Bock] Rename ClearAssociationAction to ClearLinkAction?

  • Reported: ALF 1.0a — Tue, 5 Mar 2002 05:00 GMT
  • Disposition: Resolved — ALF 1.0b1
  • Disposition Summary:

    decline

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Enforcement of multiplicity

  • Key: ALF-6
  • Legacy Issue Number: 4907
  • Status: closed  
  • Source: International Business Machines ( Sridhar Iyengar)
  • Summary:

    [Sridhar Iyengar] 20. In a number of places in the spec (see Page 2-261,
    para 3 for an example, Page 2-266 314 next to last paragraph...) , the
    following statement 20. In a number of places in the spec (see Page
    2-appears "The semantics of adding a value that violates the
    multiplicity of an attribute is undefined". Why did the submitters not
    choose to treat this event as a violation of well formedness rules and
    raise an exception (for example by invoking an exceptionAction)? For
    vendors that implement UML tools that implement these constraints, it
    would be better if the semantics of actions handles these violations
    consistently. At some point in time when enough tools implement the
    Action Semantics spec issues such as these will become more important
    for interoperability reasons. Imagine a programming language interface
    (MOF 2 IDL or JMI) used to manipulate a UML metamodel server which has
    been extended to support the Actions package. It would be good if
    conformant client implementations treated multiplicity violations
    consistently. (the fact that the spec leaves this undefined is one way
    to be consistent I suppose!). Should the spec reviewer assume that for
    those parts of the spec where the semantics is explicitly marked as
    undefined, we should raise a red flag for modelers using these
    capabilities because those models 'may not be executable'?

    See also Page 2-266, next to last para. 'creating a link that violates
    20. In a number of places in the spec (see Page 2-maximum multiplicities
    has undefined semantics'.. 'modeler must determine when minimum
    multiplicity associations should be enforced'. There isn't a standard
    way (I know of), this can be done consistently in UML. May be this will
    get sorted out as part of UML2 as part of the OCL Metamodel RFP.

    Multiplicity constraints are very popular in UML and we should look at
    providing some clear guidelines of when and how these (and other
    constraints) are checked or ignored in UML.

    Finally in Page 128 of revised submission the following text "When a
    semantic variation point' is mentioned.

    24. ClearAssociationAction class. I suggest that handling
    multiplicity be a semantic variation point as opposed to making the
    arbitrary choice that minimum muliplicity be violated when links of the
    association in which the object participats is destroyed.This could for
    example be handled by tags that can be customized (preferably at the
    package level) to (a) ignore multiplciity constraints (b) enforce them
    and raise an exception if the constraint is violated. I did notice the
    the choice to ignore minimum multiplicity is being consistently made -
    so this will minimize confusion.

  • Reported: ALF 1.0a — Tue, 5 Mar 2002 05:00 GMT
  • Disposition: Resolved — ALF 1.0b1
  • Disposition Summary:

    Decline

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Multiple owners of Clause

  • Key: ALF-5
  • Legacy Issue Number: 4906
  • Status: closed  
  • Source: International Business Machines ( Sridhar Iyengar)
  • Summary:

    [Sridhar Iyengar] 15.Page 2-238: Figure 2-41. Looking at the metamodel,
    it looks like the same 'Clause' can be owned by a LoopAction and a
    ConditionalAction. For pragmatic reasons, there should be an OCL
    constraint preventing this from happening - unless the submitters feel
    the same clause can be 'owned' by both types of Actions. (I tried to
    find the constraint and did not see one). I usually see a red flag when
    multiple composite associations point to the same Class. (In this case
    both LoopAction and ConditionalAction have a composite Association to
    Clause. In other parts of the spec where this pattern recurs, I did see
    the OCL constraint! (See Figure 3, Page 15 and related well formedness
    rule on Page 21 that makes sure an 'input pin must be owned by either an
    Action or a Procedure but not both'.

  • Reported: ALF 1.0a — Tue, 5 Mar 2002 05:00 GMT
  • Disposition: Resolved — ALF 1.0b1
  • Disposition Summary:

    accept

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Pins in class semantics

  • Key: ALF-20
  • Legacy Issue Number: 4922
  • Status: closed  
  • Source: International Business Machines ( Sridhar Iyengar)
  • Summary:

    [Sridhar Iyengar] 37. Page 2-274 : Changes to semantics of Class "a
    method realizing ... parameters of kind in and out match input pins...".
    For some one not concerned with implementing Action Semantics - it is an
    optional compliance point after all, adding this text to the basic Class
    specification causes additional confusion because this introduces new
    terminology 'pins' without providing appropriate context. This text can
    simply be in the Actions package specifciation and reference parameters
    without any loss of information. If for some reason submitters believe
    this explanatory text is important, please refer to the Action Semantics
    spec sections to provide additional context that explains why this
    information is relevant.

    [Conrad] BTW, the relation of parameters to pins is added to the seventh
    paragraph of the semantics of Class on page 2-74, starting with a
    modification of the seventh sentence (see asterisks)

    A method realizing an operation has the same signature as the
    operation and match those of a procedure implementing the
    specification of the operation. Pins of procedures have two
    direction: in and out, while method and operation parameters have
    direction in, out, inout, and return.

  • Reported: ALF 1.0a — Tue, 5 Mar 2002 05:00 GMT
  • Disposition: Resolved — ALF 1.0b1
  • Disposition Summary:

    accept

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Profile for Resolution of Operations and Signals

  • Key: ALF-19
  • Legacy Issue Number: 4921
  • Status: closed  
  • Source: International Business Machines ( Sridhar Iyengar)
  • Summary:

    [Sridhar Iyengar] 36. Messaging chapter: 'Optional profile for
    Resolution of Operations and Signals' May be this section is a carry
    over of some earlier work. Since the whole action semantics spec is an
    optional compliance point, what is the point of mentioning an additional
    optional profile? Is this is a separate compliance point? This is not
    called out in the Preface "Compliance Issues". The two stereotyped
    Associations - are these derivations of any existing MetaAssociations in
    UML 1.x.? If these are not, then these two associations are proposed
    changes to UML 1.4 and will change the UML 1.x DTD. Note that in
    general profiles are NOT intended to change the UML DTD. If these
    stereotyped Associations are expected to be implemented using 'Tagged
    Values', then that should be clearly specified - in which case the DTD
    does not change.

    So we now have an optional profile that is part of the optional Action
    Semantics spec? Please clarify the intent and if appropriate mark this
    proposed profile package as an additional optional compliance point.
    Also this profile is not documented in the same form as other UML
    profiles adopted by OMG.

  • Reported: ALF 1.0a — Tue, 5 Mar 2002 05:00 GMT
  • Disposition: Resolved — ALF 1.0b1
  • Disposition Summary:

    accept

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Procedure attached to what?

  • Key: ALF-4
  • Legacy Issue Number: 4905
  • Status: closed  
  • Source: International Business Machines ( Sridhar Iyengar)
  • Summary:

    [Sridhar Iyengar] 13. Page 22-223: 'Procedure is a set of actions that
    may be attached as a unit to other parts of the metamodel' It is not
    clear from the metamodel which model elements a procedure can attach to.
    Can a procedure be attached to a use-case? operation? statemachine? Some
    guidance would be useful.

  • Reported: ALF 1.0a — Tue, 5 Mar 2002 05:00 GMT
  • Disposition: Resolved — ALF 1.0b1
  • Disposition Summary:

    Fixed in the adopted spec.

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Type of Pin

  • Key: ALF-3
  • Legacy Issue Number: 4904
  • Status: closed  
  • Source: International Business Machines ( Sridhar Iyengar)
  • Summary:

    [Sridhar Iyengar] 11. page 2-231: States that 'Since UML does not
    provide any standard Classifier that is the ancestor of all classifiers,
    untyped pins can be used for the purpose of accepting input of "any"
    type' I think you mean a standard 'class' that is an ancestor of all
    modelelements - not just classifiers. (This would be similar to
    RefBaseObject in MOF or 'Object' in smalltalk or java.lang.object in
    Java - is this the intent?). Note that the 'type' of Pin is a
    'Classifier' in the metamodel.

  • Reported: ALF 1.0a — Tue, 5 Mar 2002 05:00 GMT
  • Disposition: Resolved — ALF 1.0b1
  • Disposition Summary:

    Decline

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Typos

  • Key: ALF-2
  • Legacy Issue Number: 4903
  • Status: closed  
  • Source: International Business Machines ( Sridhar Iyengar)
  • Summary:

    [Sridhar Iyengar] 6,8, 10. Typos:

    Page 2-209, Figure 2-36 heading "An fragment"

    Page 2-217, section 2.16.1 missing 'of' in last sentence.

    page 2-228 : Association 'antecedent' and page 2-221, figure
    2-38 Aciton foundation metamodel 'antecedant' in the Figure 3
    need to be consistent. P.S If the metamodel definition
    changes the association name, note that the IDL and XML DTD
    will need to be regenerated.

  • Reported: ALF 1.0a — Tue, 5 Mar 2002 05:00 GMT
  • Disposition: Resolved — ALF 1.0b1
  • Disposition Summary:

    accept

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Attributes of association classes

  • Key: ALF-8
  • Legacy Issue Number: 4909
  • Status: closed  
  • Source: International Business Machines ( Sridhar Iyengar)
  • Summary:

    [Sridhar Iyengar] 25. CreateLinkObjectAction class: Please clarify how
    attributes defined in AssociationClasses are handled - Do you simply use
    'AddAttributeValueAction'? - This was my assumption. See also comment 25
    which states semantics of creating instances of AssociationClasses is
    undefined.

  • Reported: ALF 1.0a — Tue, 5 Mar 2002 05:00 GMT
  • Disposition: Resolved — ALF 1.0b1
  • Disposition Summary:

    Accept

  • Updated: Fri, 6 Mar 2015 20:57 GMT

end object terminology

  • Key: ALF-7
  • Legacy Issue Number: 4908
  • Status: closed  
  • Source: International Business Machines ( Sridhar Iyengar)
  • Summary:

    [Sridhar Iyengar] 21. Page 2-262, Section 2.19.3 Identifying a Link :
    Please clarify the term 'end Objects' and this terms relationship to The
    terms 'link object' and 'link'. These terms are used - but not
    consistently when defining Association Actions. I could generally
    understand the intention (because in the MOF spec we describe this in
    gory detail!), but UML will be used a larger number of vendors and we
    should nail this better.

    22. Page 2-262 308, Para 2 , fix the grammar. Once again the spec says
    'link always have exactly one object at its ends', Hopefully you mean
    'link always has exactly one object reference at its end'. The
    difference between 'object' and 'object reference' is subtle in many
    systems and it looks like in this spec the term 'object' is used to mean
    both.

  • Reported: ALF 1.0a — Tue, 5 Mar 2002 05:00 GMT
  • Disposition: Resolved — ALF 1.0b1
  • Disposition Summary:

    Accept

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Input/Output sections

  • Key: ALF-14
  • Legacy Issue Number: 4915
  • Status: closed  
  • Source: International Business Machines ( Sridhar Iyengar)
  • Summary:

    [Sridhar Iyengar] 29. Various pages : I have come to the conclusion that
    parts of the spec where Inputs/Outputs are defined are not all that
    useful. I suggest the FTF consider whether these should be carried over
    in the spec. Since not much guidance is given on how to handle
    "RuntimeObject" and "RuntimeInstance" and this is left as an
    implementation issue anyway - I dont see the value. May be all that is
    needed are the examples in the Appendix. Note I had to read carefully to
    find out the intended differences between "RuntimeObject" "and
    RuntimeInstance" - I expected this to be a typo but then realized "that
    the former refers to 'objects' and the latter refers to 'values' - See
    especially Page 68. This is a bit too 'subtle'.

  • Reported: ALF 1.0a — Tue, 5 Mar 2002 05:00 GMT
  • Disposition: Resolved — ALF 1.0b1
  • Disposition Summary:

    decline

  • Updated: Fri, 6 Mar 2015 20:57 GMT

ReadLinkAction clarification

  • Key: ALF-13
  • Legacy Issue Number: 4914
  • Status: closed  
  • Source: International Business Machines ( Sridhar Iyengar)
  • Summary:

    [Sridhar Iyengar] 28. ReadLinkAction class : The explanatory text -
    first sentence - is confusing.

  • Reported: ALF 1.0a — Tue, 5 Mar 2002 05:00 GMT
  • Disposition: Resolved — ALF 1.0b1
  • Disposition Summary:

    accept

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Unsupported core features

  • Key: ALF-10
  • Legacy Issue Number: 4911
  • Status: closed  
  • Source: International Business Machines ( Sridhar Iyengar)
  • Summary:

    [Sridhar Iyengar] 26.5. I recommend that the FTF add a section that
    clearly identifies the parts of the UML::Foundation::Core package that
    are NOT supported by Action Semantics specification (ex: features that
    use TargetScope, Changeability, certain multiplicity constraints etc.) -
    This will serve as a useful guide for designers planning to use
    executable models who can chose to not use these capabilities of UML.

  • Reported: ALF 1.0a — Tue, 5 Mar 2002 05:00 GMT
  • Disposition: Resolved — ALF 1.0b1
  • Disposition Summary:

    decline

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Instantiating classifiers

  • Key: ALF-9
  • Legacy Issue Number: 4910
  • Status: closed  
  • Source: International Business Machines ( Sridhar Iyengar)
  • Summary:

    [Sridhar Iyengar] 26. CreateObjectAction class: "This action
    instantiates classifier" - It is later stated in the same para, the
    semantics is undefined for creating objects from abstract classifiers or
    from AssociationClasses. Note that since Classifier itself is an
    abstract class, the text in this section is confusing at best. Suggest
    it be reworded to 'This action instantiates a specific Class - instead
    of the general term 'classifier'. Since this spec does not say much
    about how any other subtype of Classifier (other than Class) is
    instantiated, let us keep it simple.

  • Reported: ALF 1.0a — Tue, 5 Mar 2002 05:00 GMT
  • Disposition: Resolved — ALF 1.0b1
  • Disposition Summary:

    accept

  • Updated: Fri, 6 Mar 2015 20:57 GMT

ordered congruent collection clarification

  • Key: ALF-16
  • Legacy Issue Number: 4918
  • Status: closed  
  • Source: International Business Machines ( Sridhar Iyengar)
  • Summary:

    [Sridhar Iyengar] 33.5: Also for the 'uninitiated' what is an '

    {ordered congruent collection}

    ' - see Figure 2-56, page 2-303. How is this
    constraint used? Is this what is meant by collection sizes and types of
    the collection have to be the same? If so a one line explanation in the
    spec that defines the term would be useful.

  • Reported: ALF 1.0a — Tue, 5 Mar 2002 05:00 GMT
  • Disposition: Resolved — ALF 1.0b1
  • Disposition Summary:

    References to congruent removed

  • Updated: Fri, 6 Mar 2015 20:57 GMT

MarshallAction, marshalType

  • Key: ALF-15
  • Legacy Issue Number: 4916
  • Status: closed  
  • Source: International Business Machines ( Sridhar Iyengar)
  • Summary:

    [Sridhar Iyengar] 32. MarshallAction : The type of marshalType in the
    text is 'Class' - but in the metamodel diagram - page 74, the type is
    Classifier'. If the intention is indeed 'Class' fix the metamodel.
    Class appears to be correct if the intention is not to support any other
    subtypes of Classifier. Note this comment also applies to
    UnmarshalAction on page 79.

  • Reported: ALF 1.0a — Tue, 5 Mar 2002 05:00 GMT
  • Disposition: Resolved — ALF 1.0b1
  • Disposition Summary:

    accept

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Multiplicity of ReadExtentAction pins

  • Key: ALF-12
  • Legacy Issue Number: 4913
  • Status: closed  
  • Source: International Business Machines ( Sridhar Iyengar)
  • Summary:

    [Sridhar Iyengar] 27.5 ReadExtentAction class: Check the multiplcity of
    the Output pins - it is 1 only in the metamodel diagram (see Other
    Actions diagram) - However there is a well formedness rule [3] which
    states that the result output pin has a multiplicity of unlimited -
    which would make sense since we are dealing with extents. Fix the
    metamodel multiplicity and removing the wellformedness rule would
    resolve this confusion.

  • Reported: ALF 1.0a — Tue, 5 Mar 2002 05:00 GMT
  • Disposition: Resolved — ALF 1.0b1
  • Disposition Summary:

    decline

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Classifiers fo ReadExtentAction

  • Key: ALF-11
  • Legacy Issue Number: 4912
  • Status: closed  
  • Source: International Business Machines ( Sridhar Iyengar)
  • Summary:

    [Sridhar Iyengar] 27. ReadExtentAction class : For what classifiers is
    this Action expected to be implemented ? Classes and AssociationClasses?

  • Reported: ALF 1.0a — Tue, 5 Mar 2002 05:00 GMT
  • Disposition: Resolved — ALF 1.0b1
  • Disposition Summary:

    accept

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Messaging action examples

  • Key: ALF-18
  • Legacy Issue Number: 4920
  • Status: closed  
  • Source: International Business Machines ( Sridhar Iyengar)
  • Summary:

    [Sridhar Iyengar] 35. General question : In describing messaging
    actions, most of the examples apply to programming language examples.
    However, examples related to middleware invocations (in CORBA, DCOM...)
    are equally if not more significant. Are these messaging actions,
    intended to be used with distributed component middleware or messaging
    middleware? What is the intended use case of this section of the spec?

  • Reported: ALF 1.0a — Tue, 5 Mar 2002 05:00 GMT
  • Disposition: Resolved — ALF 1.0b1
  • Disposition Summary:

    decline

  • Updated: Fri, 6 Mar 2015 20:57 GMT

ReduceAction subaction

  • Key: ALF-17
  • Legacy Issue Number: 4919
  • Status: closed  
  • Source: International Business Machines ( Sridhar Iyengar)
  • Summary:

    [Sridhar Iyengar] 34. ReduceAction para 2 : In the example, it looks
    like the result of the binary associative subaction addition should be
    the scalar 11. The spec says 9. Did I miss something?

  • Reported: ALF 1.0a — Tue, 5 Mar 2002 05:00 GMT
  • Disposition: Resolved — ALF 1.0b1
  • Disposition Summary:

    accept

  • Updated: Fri, 6 Mar 2015 20:57 GMT

[ALF] Issue with Section 8.3.6 - Invocation Expressions

  • Key: ALF-1
  • Legacy Issue Number: 16028
  • Status: closed  
  • Source: RPC Software ( Ted Stockwell)
  • Summary:

    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

    FeatureInvocationTarget
    SuperInvocationTarget

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

    InvocationExpression= InvocationTarget Tuple

    { "." InvocationTarget Tuple }
  • Reported: ALF 1.0b1 — Tue, 15 Feb 2011 05:00 GMT
  • Disposition: Resolved — ALF 1.0b2
  • Disposition Summary:

    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

  • Updated: Fri, 6 Mar 2015 20:57 GMT