Issue 8250: Section: 12.3.33 (uml2-rtf) Source: (, ) Nature: Enhancement Severity: Significant Summary: The order cancellation request example lends itself to enhancement. Fig. 274 could be enhanced if there was drawn a fork from invoice providing multiple edges of "no payment needed" or "make payment" with the "no payment needed" edge directly entering the join. Another fork could also be added after the AcceptPayment activity with one outgoing edge labeled "refund payment" with an edge to an activity "IssueRefund" then an edge going to the join. The explanation would reiterate that a token transfer, once initiated (SendInvoice activity), that is outside of the region is not interruptable. That since the SendInvoice activity is outside the region, no matter when the CancelOrder interrupt activity is issued, the SendInvoice activity is issued. However, corrective activities are needed to be performed before the CloseOrder actvity can be accomplished. This would be to either issue the invoice stating no payment is due or to issue a refund once payment is received. Additionally, wouldn't the CancelOrder activity more likely go to the merge before the CloseOrder activity instead of directly to the Activity Final? Otherwise, logically thinking, some order is out there not closed (just canceled). But then maybe (probably??) I'm missing the point of the example in which case a better explanation of the example needs to be provided. Resolution: Revised Text: Actions taken: February 7, 2005: received issue August 23, 2006: closed issue Discussion: The order cancellation request example could be improved by better analysis, as well as an indication of the activity involved in Cancel Order. It should be kept in mind that Cancel Order is a fairly complex activity, involving process-based “compensation.” Compensation would consist of processes such as requesting return of already-shipped items, refunding payments, closing the order, and terminating the activity. So, most of the improvements suggested in this issue would be handled instead within the Cancel Order activity. Adding the suggested enhancements (or an activity diagram containing the Cancel Order activity would indeed enhance the Process Order activity. However, in doing so, it could detract from the clarity of the example¹s primary propose: clearly illustrate an example of using an InteruptableActivityRegion. Disposition: Closed, no change End of Annotations:===== m: webmaster@omg.org Date: 07 Feb 2005 15:50:37 -0500 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Jane Messenger Company: U. S. Geological Survey mailFrom: jmessenger@usgs.gov Notification: Yes Specification: Superstructure Section: 12.3.33 FormalNumber: ptc/04-10-02 Version: 2.0 Draft Adopted RevisionDate: 10/08/2004 Page: 410 Nature: Enhancement Severity: Significant HTTP User Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Q312461) Description The order cancellation request example lends itself to enhancement. Fig. 274 could be enhanced if there was drawn a fork from invoice providing multiple edges of "no payment needed" or "make payment" with the "no payment needed" edge directly entering the join. Another fork could also be added after the AcceptPayment activity with one outgoing edge labeled "refund payment" with an edge to an activity "IssueRefund" then an edge going to the join. The explanation would reiterate that a token transfer, once initiated (SendInvoice activity), that is outside of the region is not interruptable. That since the SendInvoice activity is outside the region, no matter when the CancelOrder interrupt activity is issued, the SendInvoice activity is issued. However, corrective activities are needed to be performed before the CloseOrder actvity can be accomplished. This would be to either issue the invoice stating no payment is due or to issue a refund once payment is received. Additionally, wouldn't the CancelOrder activity more likely go to the merge before the CloseOrder activity instead of directly to the Activity Final? Otherwise, logically thinking, some order is out there not closed (just canceled). But then maybe (probably??) I'm missing the point of the example in which case a better explanation of the example needs to be provided. 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).