Issue 15383: fUML 1.0 beta3 document (ad/2010-03-14), Subclause 10.4.6.2 (fuml-rtf) Source: Ivar Jacobson International AB (Mr. Ed Seidewitz, eseidewitz(at)ivarjacobson.com) Nature: Uncategorized Issue Severity: Summary: In the fUML 1.0 beta3 document (ad/2010-03-14), Subclause 10.4.6.2, it states that: The empty-output-parameter-node relation ensures executions of expansion region action (the xac variable) transfer values from an output parameter node of the executions of the constructed activity (xcall) to the corresponding output pin of the expansion region (op). It assumes output pin multiplicity upper (opmax) is one or unlimited. This does not put null tokens in output pins when output parameter nodes are empty, as in UML. The final sentence is no longer consistent with the fUML operational semantics given in the execution model, which was updated by the resolution of Issue 14550 to offer a null token from an output pin if it holds no values when it fires. Resolution: 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. Revised Text: None Disposition: Deferred Revised Text: Actions taken: July 27, 2010: received issue January 7, 2013: deferred Discussion: End of Annotations:===== ubject: RE: fUML: The "no token" semantics of null & empty collections is quite problematic Date: Tue, 27 Jul 2010 15:59:05 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: fUML: The "no token" semantics of null & empty collections is quite problematic thread-index: AcstvELpjD9K2t1oSfudcojZD6K1JgACNuQw From: "Ed Seidewitz" To: "Juergen Boldt" Cc: , "Conrad Bock" , "Stephen Mellor" , "Bran Selic" , "Rouquette, Nicolas F (316A)" Juergen . I think the only issue is the following: In the fUML 1.0 beta3 document (ad/2010-03-14), Subclause 10.4.6.2, it states that: The empty-output-parameter-node relation ensures executions of expansion region action (the xac variable) transfer values from an output parameter node of the executions of the constructed activity (xcall) to the corresponding output pin of the expansion region (op). It assumes output pin multiplicity upper (opmax) is one or unlimited. This does not put null tokens in output pins when output parameter nodes are empty, as in UML. The final sentence is no longer consistent with the fUML operational semantics given in the execution model, which was updated by the resolution of Issue 14550 to offer a null token from an output pin if it holds no values when it fires. -- Ed -------------------------------------------------------------------------------- From: Juergen Boldt [mailto:juergen@omg.org] Sent: Tuesday, July 27, 2010 2:47 PM To: Ed Seidewitz; Rouquette, Nicolas F (316A) Cc: issues@omg.org; Conrad Bock; Stephen Mellor; Bran Selic Subject: RE: fUML: The "no token" semantics of null & empty collections is quite problematic issue? -Juergen At 12:29 PM 7/26/2010, Ed Seidewitz wrote: Nicolas . You have a notation .In 8.5.4.1., but don.t actually include any update for that section. I reread the section, and it seems fine to me. On 10.4.6.2, you are right that this was missed in the resolution to 14550. This should be required as a new issue. (And the Roman page numbers starting on page 230 seem to be some sort of weird artifact from the generation of PDF from OpenOffice. It is not that way in the original OpenOffice file. Hopefully this can be fixed in the production of the formal spec document.) However, I do not believe you are correct on your comments on Annex A. Note that a null token does not represent a value. Rather it specifically represents the situation of there being no values on an object node. This is now clear in UML 2.3, and fUML now reflects this (so there is no longer any inconsistency with basic UML semantics in this regard, as there was with UML 2.2). The sections in Annex A that you quote consistently refer to .no values., which is still correct after the resolution to 14550. Nothing .maps to. a null token. A null token is simply what is offered by an object node when it has .no values.. (Indeed, nothing .maps to. any kind of token . tokens are a semantic mechanism for moving values in an activity graph and are not explicitly represented at all in any UML surface syntax.) So, in Annex A, .null. still maps to .no value.. This just represents basic UML semantics . there is simply no such thing as a .null pointer. in UML (which I actually think is a good thing). Nevertheless, in the Java mapping it is still not allowed to use null for a list type. That is because this would not have the same semantics in Java (where null actually is a null pointer, not an empty list) as in UML, and the goal of the Java mapping in Annex A is to only allow code that has the same effective meaning whether it is executed as Java or it is mapped to UML. -- Ed -------------------------------------------------------------------------------- From: Rouquette, Nicolas F (316A) [ mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Monday, July 26, 2010 4:13 AM To: Ed Seidewitz Cc: issues@omg.org; Conrad Bock; Stephen Mellor; Bran Selic Subject: Re: fUML: The "no token" semantics of null & empty collections is quite problematic Thanks Ed for the reply. The fUML resolution for 14550 is incomplete in that the current fUML 1.0 beta3 document (ad/2010-03-14) needs to be updated in a few places to reflect the change where empty collections result in a null token being offered instead of none. I've added in bold & "[...]" indications where the current document needs to be updated to reflect the resolution to 14550. In 8.5.4.1: In clause 10.4.6.2 page ccxcviii (why are the pages numbered in roman numerals?): The empty-output-parameter-node relation ensures executions of expansion region action (the xac variable) transfer values from an outut parameter node of the executions of the constructed activity (xcall) to the corresponding output pin of the expansion region (op). It assumes output pin multiplicity upper (opmax) is one or unlimited. This does not put null tokens in output pins when output parameter nodes are empty, as in UML [this seems wrong] A.4.3 Null: A null value may not be used for a list type [This is clearly wrong now]. A null value maps to a value specification action for a literal null. The result output pin of the value specification action becomes the result pin of the mapping. All class types in Java allow .null. values. Such types map to types with .optional. multiplicity [0..1] in UML (see Subclause A.1). Java .null. is used to represent the case of .no value. (0 cardinality) allowed by this multiplicity. A value specification for a literal null places no values on its output pin when it executes, corresponding to the 0 cardinality case. [This is clearly wrong now]. A.4.8 Testing For Equality Neither expression may evaluate to null (for testing for null, see Subclause A). [If a Null maps to a null token, then it seems that it is possible to test for equality of possibly-null expressions.] A.5.4 Empty List A value specification for a literal null places no values on its output pin when it executes, corresponding to the 0 cardinality case of the multiplicity [*]. [This is clearly wrong now.] - Nicolas. On Jul 25, 2010, at 11:51 PM, Ed Seidewitz wrote: Nicolas -- The resolution to Issue 9863, incorporated into UML 2.3, clarified the semantics of null tokens in the case of reading empty collections. The clarified semantics were incorporated into fUML as part of the resolution of Issue 14550. In fUML, as finalized, an object node (such as a pin) always offers a null token if it fires when it holds no tokens. Thus, for example, if a read link action completes successfully but reads no links, it will offer a null token to downstream nodes, while it will offer nothing if it does not fire or does not complete.\ Your example models had some errors that prevented them from executing correctly. In the case of the activity NoLinks, the input pin for the call action .count B.s. had the multiplicity *. Unfortunately, MagicDraw stores this in its mdxml file in a non-standard way as .*..*.. When directly executing from an mdxml file, one must use .0..*. instead. In the case of EmptyExtent and NullTest, the input pin had no multiplicity specified at all (which violates the well-formedness of the model). Again, the multiplicity should be 0..*. When these errors are corrected, the activities all execute correctly. Given below are the event traces for them using the latest open source fUML Reference Implementation plugin for MagicDraw (v0.4.0). In all cases, .true. is returned from the output pin of the activity. [event] Execute activity=NoLinks [event] Fire activity=NoLinks action=create A [event] Fire activity=NoLinks action=get B's [event] Fire activity=NoLinks action=count B's [event] Fire activity=NoLinks action=Zero [event] Fire activity=NoLinks action=IsZero? [event] Output activity=NoLinks parameter=noLinks value=true [execute] output parameter 'noLinks' has 1 value(s) [execute] value [0] = true [plugin] execution complete [event] Execute activity=EmptyExtent [event] Fire activity=EmptyExtent action=Get A's [event] Fire activity=EmptyExtent action=ListSize [event] Fire activity=EmptyExtent action=Zero [event] Fire activity=EmptyExtent action=IsZero? [event] Output activity=EmptyExtent parameter=isEmpty value=true [execute] output parameter 'isEmpty' has 1 value(s) [execute] value [0] = true [plugin] execution complete [event] Execute activity=NullTest [event] Fire activity=NullTest action=null A [event] Fire activity=NullTest action=ListSize [event] Fire activity=NullTest action=Zero [event] Fire activity=NullTest action=IsZero? [event] Output activity=NullTest parameter=isNull value=true [execute] output parameter 'isNull' has 1 value(s) [execute] value [0] = true [plugin] execution complete -- Ed -----Original Message----- From: Rouquette, Nicolas F (316A) [ mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Sunday, July 25, 2010 6:31 PM To: issues@omg.org Cc: Ed Seidewitz; Conrad Bock; Stephen Mellor; Bran Selic Subject: fUML: The "no token" semantics of null & empty collections is quite problematic Although the topic of empty collections has been discussed extensively in the fUML RTF, there choice for representing a collection of values as a set of tokens for a multi-valued pin turns out to be quite problematic. 1) No distinction between a null scalar value (A.4.3) vs. an empty collection (A.5.4) Both are value specifications actions for a literal null. In both cases, the action produces no output tokens. In both case, there is a loss of type information because there's nothing to distinguish between 3 alternatives: - the action completed and the result would be a null scalar value if it were written Java (A.4.3) - the action completed and the result would be an empty collection if it were written in Java (A.5.4) - the action has not completed 2) ListSize does not work for an empty list (A.5.6) When the list is empty, no token will be offered on the input pin for the ListSize() behavior, which never executes. (See the NullTest in the attached example) This behavior means that testing for null as specified in A.4.10 does not work when the value is actually null! 3) Because of (1) and (2), it is impossible to test whether a collection of links is empty (i.e. the result of ReadLinkAction). 4) Because of (1) and (2), it is impossible to test whether a collection of instances is empty (i.e., the result of ReadExtentAction). These problems have serious consequences for Alf (ad/2010-02-01) because Alf expects fUML-based behaviors for several operations involving collections that may be empty; see Table 8.1, 8.2, 8.3 Attached is a test case in MagicDraw 16.8 to illustrate the avove problems (see NullTest, NoLinks, EmptyExtent). Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org