Issue 7977: ReduceAction (uml2-rtf) Source: Industrial Internet Consortium (Mr. Stephen J. Mellor, mellor(at)iiconsortium.org) Nature: Uncategorized Issue Severity: Summary: It has come to my attention that the removal of the ReduceAction (fair enough) requires the use of a variable (a very bad idea) to construct an alternative specification. To do something like Reduce(<data expression>, Add) in UML 1.5, you would have to say: - An activity/structure node with variable Sum. - The expansion region takes the collection as input and has no output. In this case, the output collection will have only one element in it. - In the region, edges coming from/going to the inputs/outputs take elements from the input collections and put elements in the output collections. - The region uses CallOperationAction with operation timeofLastCall to get the time and CallBehaviorAction on the (primitive) FunctionBehavior for addition and updates the variable. - After the region is complete, the variable has the sum in it. The 1.5 Action Model included variables so that those who "needed" them could have them. However, the introduction of variables changes the static-single-assignemnt nature of the language and would now require data-flow analysis of a developer model to work out what is happening. Before all we had to do was scan for Variable Actions and reject the developer model so proposed. In other words, those of us in the translation business did not need variables, and we could ignore those models that used them. Now we're stuck. Topic: ReduceAction UML 1.5 had ReduceAction, which repeatedly applied a function pairwise to elements of a collection until only only element is left. It did not constrain order or concurrency of application. It was replaced with ExpansionRegion UML 2, which requires commitment to order and concurrency. Resolution: Corrections to issue description: Revised Text: UML 2 Revision Task Force Disposition: Resolved OMG Issue No: 7977 Document ptc/06-01-01 Page 64 ƒ The filer is explaining how to achieve the effect of UML 1.5 ReduceAction with UML 2 ExpansionRegion. It does not actually work, because each input collection must provide at least two values for each cycle on the contents of the region, whereas ExpansionRegion currently only provides one value per input per cycle. ƒ The last paragraph of the discussion is incorrect. The concurrent mode of ExpansionRegion only allows concurrency, it does not require concurrency. In addition, the outputs of ExpansionRegion are collections, whereas the output of ReduceAction is a single element, calculated from the elements of the input collections. Even if a regular output pin is used instead of an ExpansionNode, the output of the contents of the region (the reducing action) must be returned to the input collection for further processing by the action. ReduceAction was inadvertently omitted from the U2P submission. For backwards compatibility with UML 1.5 it is added below, based on the UML 1.5 ReduceAction. Revised Text: In Actions: At end of Abstract syntax section, after Figure 156, add new figure as follows (adds ReduceAction to CompleteActions): Action (fromBasicActions) Behavior (from BasicBehaviors) InputPin (fromBasicActions) ReduceAction isOrdered : Boolean = false 1 +reducer 1 1 +collection 1 OutputPin (fromBasicActions) 1 +result {subsets input} {subsets output} 1 Action (fromBasicActions) Behavior (from BasicBehaviors) InputPin (fromBasicActions) ReduceAction isOrdered : Boolean = false 1 +reducer 1 1 +collection 1 OutputPin (fromBasicActions) 1 +result {subsets input} {subsets output} 1 UML 2 Revision Task Force Disposition: Resolved OMG Issue No: 7977 Document ptc/06-01-01 Page 65 In Class Descriptions, add entry for ReduceAction, as follows: ReduceAction (from CompleteActions) (CompleteActions) ReduceAction is an action that reduces a collection to a single value by combining the elements of the collection. Generalizations Action (from BasicActions) Description This action takes a collection as input and produces an output by applying a behavior with two inputs pairwise to the elements of the collection. Attributes ƒ isOrdered : Boolean = false Tells whether the order of the input collection should determine the order in which the behavior is applied to its elements. Associations ƒ collection : InputPin [1] The collection to be reduced (subsets Action::input) ƒ reducer : Behavior [1] Behavior that is applied to two elements of the input collection to produce a value that is the same type as elements of the collection. ƒ result : OutputPin [1] Gives the output pin on which the result is put (subsets Action::output). Constraints [1] The type of the input must be a collection. [2] The type of the output must be compatible with the type of the output of the reducer behavior. [3] The reducer behavior must have two input parameters and one output parameter, of types compatible with the types of elements of the input collection. Semantics The behavior is invoked repeatedly on pairs of elements in the input collection. Each time it is invoked, it produces one output that is put back in an intermediate version of the collection. This repeats until the collection is reduced to a single value, which is the output of the action. If isOrdered is false, the order in which the behavior is applied to pairs of values is indeterminate. This will not affect the result of the action if the behavior is commutative and associative, see below. If separate invocations of the behavior affect each other, for example, through side-effects, the result of the actions may be unpredictable, however. If the reducing behavior is not commutative and associative, as with matrix multiplication, the order of the elements in the collection will affect the result of the behavior and the action. In this case, isOrdered should be set to true, so the behavior will be applied to adjacent pairs according to the collection order. The result of each invocation of the behavior replaces the two values taken as input in the same position in the order as the two values. If isOrdered = false, the reducer behavior should be commutative and associative so it will produce the same reduced value regardless of which two elements are paired at each invocation. For example, addition is commutative because because a + b = b + a. It is also associative because ((a + b) + c) = (a + (b + c)). Commutativity and associativity are not required, but the result will be indeterminate if isOrdered = false. Notation None. Examples ReduceAction can be used to reduce a list of numbers to the sum of the numbers. It would have one input pin for a collection of numbers, one result pin for a number, and an addition function as the reducer behavior. For example, suppose the input collection has four integers: (2, 7, 5, -3). The result of applying the reduce action to this collection with an addition function is 11. This can be computed in a number of ways, for example, ( ( (2+7) + 5) + -3), (2 + (7 + (5 + -3))), ((2 + 7) + (5 + -3)). Rationale The purpose of ReduceAction is to specify the transformation of a collection to a single value by pairwise application of a behavior, without necessarily committing to the order in which the pairs are chosen. Changes from UML 1.5 ReduceAction replaces ReduceAction in UML 1.5. It has the same functionality, except it takes one collection instead of multiple as input, and produces one result instead of multiple. The effect of multiple input collections can be achieved in UML 2 with an input that is a collection of collections, where the nested collections are created by taking one element from each of the multiple collection inputs to the UML 1.5 ReduceAction. Actions taken: December 14, 2004: received issue August 23, 2006: closed issue Discussion: End of Annotations:===== ubject: Variables Date: Tue, 14 Dec 2004 14:12:56 -0800 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Variables Thread-Index: AcTiKg+cGkI/fODuRImwfviFQQ2VqQ== From: "Mellor, Stephen" To: "Juergen Boldt" Cc: , "Hagstrom, Erick" X-OriginalArrivalTime: 14 Dec 2004 22:08:37.0924 (UTC) FILETIME=[7648DE40:01C4E229] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id iBEMBD1A029072 Please make this an issue against UML 2. It has come to my attention that the removal of the ReduceAction (fair enough) requires the use of a variable (a very bad idea) to construct an alternative specification. To do something like Reduce(, Add) in UML 1.5, you would have to say: - An activity/structure node with variable Sum. - The expansion region takes the collection as input and has no output. In this case, the output collection will have only one element in it. - In the region, edges coming from/going to the inputs/outputs take elements from the input collections and put elements in the output collections. - The region uses CallOperationAction with operation timeofLastCall to get the time and CallBehaviorAction on the (primitive) FunctionBehavior for addition and updates the variable. - After the region is complete, the variable has the sum in it. The 1.5 Action Model included variables so that those who "needed" them could have them. However, the introduction of variables changes the static-single-assignemnt nature of the language and would now require data-flow analysis of a developer model to work out what is happening. Before all we had to do was scan for Variable Actions and reject the developer model so proposed. In other words, those of us in the translation business did not need variables, and we could ignore those models that used them. Now we're stuck. Not good. Reply-To: From: "Conrad Bock" To: Cc: "Stephen Mellor" Subject: ReduceAction Date: Thu, 30 Dec 2004 14:32:56 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Juergen, Could you add this text to UML 2 RTF Issue 7977: Variables. Would be helpful to change the subject line to "ReduceAction", if possible. Thanks, Conrad Topic: ReduceAction UML 1.5 had ReduceAction, which repeatedly applied a function pairwise to elements of a collection until only only element is left. It did not constrain order or concurrency of application. It was replaced with ExpansionRegion UML 2, which requires commitment to order and Reply-To: From: "Conrad Bock" To: "Branislav Selic" , Subject: RE: Draft ballot 11 Date: Tue, 1 Nov 2005 14:44:38 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Hi Bran, Comments on draft ballot 11. Conrad - Issue 7977: ReduceAction The figure is missing after the third line in the revised text. See attachment. In the Revised Text, under Semantics: Second paragraph: Replace the second and third sentences with "This will not affect the result of the action if the behavior is symmetric and associative, see below." In the sentence beginning "If the reducing behavior is not symmetric", after "symmetric" add "and associative". Replace third paragraph with: If isOrdered = false, the reducer behavior should be symmetric and associative so it will produce the same reduced value regardless of which two elements are paired at each invocation. For example, addition is symmetric because because a + b = b + a. It is also associative because ((a + b) + c) = (a + (b + c)). Symmetry and associativity are not required, but the result will be indeterminate if isOrdered = false. and add it to the end of the second paragraph. I made the above text changes in the attachment. - Issue 8250: Section: 12.3.33 In the discussion, third line, at end of line, there are two footnote numbers, which should be double-quotes. - Issue 8462: UML 2 Super / General / invalid subset rule too strict The discussion begins "The UML2 specification current couples navigability and property ownership as described in section 6.5.2.", which is incorrect. - Issue 8500: mustIsolate: In Discussion, last sentence, before "points", insert "filer". - Issue 8679: token In Discussion, second line, at end, replace "possible" with "possibly". In Revised text, third line, after "replace", replace the two occurences of "edges" with "node". - Issue 8932: UML Superstructure / Actions / incorrect form for subsetting There's one "specialized from" that is not a subset: SendObjectAction.request. It should be "(redefines InvocationAction:argument)". BTW, ActivityPartition has an entry for activity that shouldn't be there. - Issue 8963: UML2 Navigability Impact on Tools Navigability applies to n-ary (n > 2) associations (see Description and Semantics of Association) , whereas the proposed text limits it to binary. It also says that navigation proceeds from the instance at the navigable end, and this could easily be misinterpreted as navigating in the wrong direction, because the navigable end appears in the diagram at the target end. Suggested rewording: Navigability means instances participating in links at runtime (instances of an association) can be accessed efficiently from instances participating in links at the other ends of the association. The precise mechanism by which such access is achieved is implementation specific. If an end is not navigable, access from the other ends may or may not be possible, and if it is, might not be efficient. Note that tools operating on UML models are not prevented from navigating associations from nonnavigable ends. - Issue 9096: UML 2.1 Implementation Issue In the new figure, shouldn't ValuePin have the name of the source package in it? It isn't defining an increment of ValuePin. - Issue 9097: UML 2.1 Implementation Issue In the new figure, shouldn't ValuePin have the name of the source package in it? It isn't defining an increment of ValuePin. In the new figure, there is a minus sign before the association end "value". Is that intended? - Issue 9103: UML 2.1 Implementation Issue - Issue 9107: UML 2.1 Implementation Issue Probably should clarify that the first figure in each of these is from the resolution of Issue 8867 (OpaqueAction). Reply-To: From: "Conrad Bock" To: "Branislav Selic" , Subject: RE: Draft ballot 11 Date: Tue, 1 Nov 2005 14:44:38 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Hi Bran, Comments on draft ballot 11. Conrad - Issue 7977: ReduceAction The figure is missing after the third line in the revised text. See attachment. In the Revised Text, under Semantics: Second paragraph: Replace the second and third sentences with "This will not affect the result of the action if the behavior is symmetric and associative, see below." In the sentence beginning "If the reducing behavior is not symmetric", after "symmetric" add "and associative". Replace third paragraph with: If isOrdered = false, the reducer behavior should be symmetric and associative so it will produce the same reduced value regardless of which two elements are paired at each invocation. For example, addition is symmetric because because a + b = b + a. It is also associative because ((a + b) + c) = (a + (b + c)). Symmetry and associativity are not required, but the result will be indeterminate if isOrdered = false. and add it to the end of the second paragraph. I made the above text changes in the attachment. - Issue 8250: Section: 12.3.33 In the discussion, third line, at end of line, there are two footnote numbers, which should be double-quotes. - Issue 8462: UML 2 Super / General / invalid subset rule too strict The discussion begins "The UML2 specification current couples navigability and property ownership as described in section 6.5.2.", which is incorrect. - Issue 8500: mustIsolate: In Discussion, last sentence, before "points", insert "filer". - Issue 8679: token In Discussion, second line, at end, replace "possible" with "possibly". In Revised text, third line, after "replace", replace the two occurences of "edges" with "node". - Issue 8932: UML Superstructure / Actions / incorrect form for subsetting There's one "specialized from" that is not a subset: SendObjectAction.request. It should be "(redefines InvocationAction:argument)". BTW, ActivityPartition has an entry for activity that shouldn't be there. - Issue 8963: UML2 Navigability Impact on Tools Navigability applies to n-ary (n > 2) associations (see Description and Semantics of Association) , whereas the proposed text limits it to binary. It also says that navigation proceeds from the instance at the navigable end, and this could easily be misinterpreted as navigating in the wrong direction, because the navigable end appears in the diagram at the target end. Suggested rewording: Navigability means instances participating in links at runtime (instances of an association) can be accessed efficiently from instances participating in links at the other ends of the association. The precise mechanism by which such access is achieved is implementation specific. If an end is not navigable, access from the other ends may or may not be possible, and if it is, might not be efficient. Note that tools operating on UML models are not prevented from navigating associations from nonnavigable ends. - Issue 9096: UML 2.1 Implementation Issue In the new figure, shouldn't ValuePin have the name of the source package in it? It isn't defining an increment of ValuePin. - Issue 9097: UML 2.1 Implementation Issue In the new figure, shouldn't ValuePin have the name of the source package in it? It isn't defining an increment of ValuePin. In the new figure, there is a minus sign before the association end "value". Is that intended? - Issue 9103: UML 2.1 Implementation Issue - Issue 9107: UML 2.1 Implementation Issue Probably should clarify that the first figure in each of these is from the resolution of Issue 8867 (OpaqueAction). -- stephen