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

Decline

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

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

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

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

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

Fixed in adopted spec

Currently, the signature of CollectionFunctions::removeAll is:

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

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

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

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

agreed

I think there is a typo page 184:

Difference

(in seq1: any[*] sequence,

in seq2: any[*] sequence nonunique):

any[*] sequence

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

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

agreed

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

This is a duplicate of Issue 16419.

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

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

agreed

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

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

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

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

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

duplicate of 4924 --close issue

[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'.

see below

Variable to VariableAction association should have multiplicity *

accept

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

decline

TestIdentityAction should have an output

accept

PrimitiveFunction should have a supertype

accept

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?

accept

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

decline

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

accept

Conrad Bock] Add action for starting procedure (StartProcedureAction)

[Jim Rumbaugh] FinishProcedureAction, ReturnFromCallAction.

accept

Multiplicity from Attribute to AttributeAction should be 0..*

accept

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

decline

Make spec reflect package structure.

accept

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

Decline with clarification

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

decline

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

Already supported

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

accept

[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'.

accept

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

accept

[Steve Mellor] Add IsReplaceAll for ReclassifyObjectAction.

accepted

[Conrad Bock] Rename ReadLinkAction to ReadLinksAction?

decline

[Conrad Bock] Rename ClearAssociationAction to ClearLinkAction?

decline

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

Decline

[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'.

accept

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

accept

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

accept

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

Fixed in the adopted spec.

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

Decline

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

accept

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

Accept

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

Accept

[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'.

decline

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

accept

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

decline

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

accept

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

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

References to congruent removed

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

accept

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

decline

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

accept

[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?

decline

[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?

accept

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

this.monitor.getActiveSensor().getReading()

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

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

Here is the current definition for InvocationExpression...

InvocationExpression= InvocationTarget Tuple
InvocationTarget= BehaviorInvocationTarget

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

InvocationExpression= InvocationTarget Tuple

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

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

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

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