${taskforce.name} Avatar
  1. OMG Task Force

ALF 1.0 FTF — Closed Issues

  • Key: ALF
  • Issues Count: 50
Open Closed All
Issues resolved by a task force and approved by Board

Issues Summary

Key Issue Reported Fixed Disposition Status
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-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-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-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-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

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

  • Key: ALF-50
  • Legacy Issue Number: 3286
  • Status: closed  
  • Source: NIST ( Mr. 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

Problem with parameters of CollectionFunctions::removeAll

  • Key: ALF-46
  • Legacy Issue Number: 16591
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. 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 ( Dr. 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

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

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: Adaptive ( Mr. 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: Adaptive ( Mr. 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

Messaging action language examples

  • Key: ALF-42
  • Legacy Issue Number: 4925
  • Status: closed  
  • Source: International Business Machines ( Mr. 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 ( Mr. 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 ( Mr. 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 ( Mr. 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 ( Mr. 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 ( Mr. 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 ( Mr. 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 ( Mr. 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 ( Mr. 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 ( Mr. 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 ( Mr. 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 ( Mr. 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 ( Mr. 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 ( Mr. 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 ( Mr. 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 ( Mr. 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 ( Mr. 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 ( Mr. 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 ( Mr. 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 ( Mr. 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 ( Mr. 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 ( Mr. 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 ( Mr. 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 ( Mr. 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 ( Mr. 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 ( Mr. 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 ( Mr. 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 ( Mr. 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 ( Mr. 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 ( Mr. 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 ( Mr. 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 ( Mr. 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 ( Mr. 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 ( Mr. 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 ( Mr. 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 ( Mr. 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 ( Mr. 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