Issue 8500: mustIsolate: (uml2-rtf) Source: NIST (Dr. Conrad Bock, conrad.bock(at)nist.gov) Nature: Clarification Severity: Minor Summary: mustIsolate: The wording of UML 2 for StructuredActivityNode.mustIsolate refers to individual nodes instead of all the nodes in the group: If the mustIsolate flag is true for an activity node, then any access to an object by an action within the node must not conflict with access to the object by an action outside the node. A conflict is defined as an attempt to write to the object by one or both of the actions. If such a conflict potentially exists, then no such access by an action outside the node may be interleaved with the execution of any action inside the node. The UML 1.5 wording was better: Because of the concurrent nature of the execution of actions within and across procedures, it can be difficult to guarantee the consistent access and modification of object memory. [Examples snipped] In order to avoid these problems, it is necessary to isolate the effects of a group of actions from the effects of actions outside the group. This is indicated by setting the mustIsolate attribute to "true" on a group action. If a group action is isolated, then any object used by an action within the group cannot be accessed by any action outside the group until the group action as a whole completes. Any concurrent actions that would result in accessing such objects are required to have their execution deferred until the completion of the group action. In the first example above, if the read actions on the temperature and pressure attributes are wrapped in a group action with mustIsolate set to "true", then the temperature and pressure values read are assured to be consistent, since no changes can intervene between the two reads. Similarly, if an isolated group is used for the second action, then the update is assured to be consistent, since no action outside the group can change the list until the update is complete. Note" The term "isolation" is used here in the sense used in traditional transaction terminology. An execution engine may achieve any required isolation using locking mechanisms, or it may simply sequentialize execution to avoid concurrency conflicts. Isolation is different than the property of "atomicity", which is the guarantee that a group of actions either all complete successfully or have no effect at all. Atomicity generally requires a rollback mechanism to prevent committing partial results. This is beyond the scope of what can be guaranteed by the basic action semantics. Resolution: see above Revised Text: In Activities, StructuredActivityNode, Semantics, last paragraph, third sentence, replace “any action inside the node” with “the node”. Actions taken: March 6, 2005: received issue August 23, 2006: closed issue Discussion: The text cited above from UML 1.5 appears in the Description section of UML 2 StructuredActivityNode (except for the example). The last paragraph of Semantics is new to UML 2 and it worded incorrectly in one spot, as the submitter points out. End of Annotations:===== m: webmaster@omg.org Date: 06 Mar 2005 10:22:44 -0500 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Conrad Bock Company: NIST mailFrom: conrad.bock@nist.gov Notification: No Specification: UML 2 Superstructure Section: Activities FormalNumber: ptc/04-10-02 Version: RevisionDate: Page: Nature: Clarification Severity: Minor HTTP User Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322) Description 
 mustIsolate: The wording of UML 2 for StructuredActivityNode.mustIsolate refers to individual nodes instead of all the nodes in the group: If the mustIsolate flag is true for an activity node, then any access to an object by an action within the node must not conflict with access to the object by an action outside the node. A conflict is defined as an attempt to write to the object by one or both of the actions. If such a conflict potentially exists, then no such access by an action outside the node may be interleaved with the execution of any action inside the node. The UML 1.5 wording was better: Because of the concurrent nature of the execution of actions within and across procedures, it can be difficult to guarantee the consistent access and modification of object memory. [Examples snipped] In order to avoid these problems, it is necessary to isolate the effects of a group of actions from the effects of actions outside the group. This is indicated by setting the mustIsolate attribute to "true" on a group action. If a group action is isolated, then any object used by an action within the group cannot be accessed by any action outside the group until the group action as a whole completes. Any concurrent actions that would result in accessing such objects are required to have their execution deferred until the completion of the group action. In the first example above, if the read actions on the temperature and pressure attributes are wrapped in a group action with mustIsolate set to "true", then the temperature and pressure values read are assured to be consistent, since no changes can intervene between the two reads. Similarly, if an isolated group is used for the second action, then the update is assured to be consistent, since no action outside the group can change the list until the update is complete. Note" The term "isolation" is used here in the sense used in traditional transaction terminology. An execution engine may achieve any required isolation using locking mechanisms, or it may simply sequentialize execution to avoid concurrency conflicts. Isolation is different than the property of "atomicity", which is the guarantee that a group of actions either all complete successfully or have no effect at all. Atomicity generally requires a rollback mechanism to prevent committing partial results. This is beyond the scope of what can be guaranteed by the basic action semantics.
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).