Issue 15120: Activity vs Action completion (uml2-rtf) Source: (, ) Nature: Uncategorized Issue Severity: Summary: "In both UML activities and UML statecharts it is sometimes necessary to recognize when some behavior (activity or state-based, respectively) has completed. However, in models without an explicit final node or final state respectively, it is not always clear when this condition is achieved Resolution: Revised Text: Actions taken: March 4, 2010: received issue Discussion: End of Annotations:===== ubject: Activity vs Action completion Date: Thu, 4 Mar 2010 14:46:15 +0100 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Activity vs Action completion Thread-Index: Acq7oQ9P95sRAlK+TpOf26T/jhhqig== From: "BERNARD, Yves" To: X-OriginalArrivalTime: 04 Mar 2010 13:46:16.0804 (UTC) FILETIME=[101E7240:01CABBA1] The specification is not clear on how the completion of an Activity is related to the completion of the action it owns. Have a look on the diagram below. This very simple Activity has no ActivityFinalNode and only one action with no outgoing flow. Imagine that a synchronous CallBehaviorAction is used to invoke that simple activity, what should happen when this call will be executed? a) The action A is executed and the call hang b) The action A is executed and the call return c) It.s a semantic variation point / undefined behaviour Thanks, Yves The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. Subject: RE: Activity vs Action completion Date: Thu, 4 Mar 2010 09:19:51 -0500 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Activity vs Action completion thread-index: Acq7oQ9P95sRAlK+TpOf26T/jhhqigAA1AFg From: "Ed Seidewitz" To: "BERNARD, Yves" Cc: Yves . I agree with you that the spec is not entirely clear on the completion of activities. This actually is made precise in the fUML semantics, but I am not sure that the current fUML completion semantics completely captures the intended completion semantics in the superstructure spec, exactly because those are not clearly laid out. This will need to be resolved in the fUML RTF after finalization, since we need to first clear up the semantics in the superstructure spec (perhaps as part of the UML 2.5 submission process) before formalizing it in fUML. That said, I do think that it is clear what happens in the simple case that your give. When the activity begins execution, a single control token is offered from the initial node to Action A. The execution of Action A then proceeds according to the semantic rules specified in Subclause 12.3.2 of the spec (which have themselves been clarified in UML 2.3). First, when the action accepts the control token it is .removed from the original source. (the initial node) and consumed by the action. Since this satisfies all the prerequisites for the action, it fires and, when completed, .offers any object tokens that have been placed on its output pins and control tokens on all its outgoing control flows.and terminates.. Since Action A has no output pins or outgoing control flows, it terminates without offering any new tokens. Thus, when Action A is completed, there are no tokens on any of the nodes of the activity. In this case, it is clear than the activity execution is completed, and a synchronous call will return normally. No final node is needed. (If you added a final node, with a control flow from Action A, then, on completion of Action A, a control token would be offered to and then consumed by the final node, leading to the same result.) -- Ed -------------------------------------------------------------------------------- From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Thursday, March 04, 2010 8:46 AM To: uml2-rtf@omg.org Subject: Activity vs Action completion The specification is not clear on how the completion of an Activity is related to the completion of the action it owns. Have a look on the diagram below. This very simple Activity has no ActivityFinalNode and only one action with no outgoing flow. Imagine that a synchronous CallBehaviorAction is used to invoke that simple activity, what should happen when this call will be executed? a) The action A is executed and the call hang b) The action A is executed and the call return c) It.s a semantic variation point / undefined behaviour Thanks, Yves The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. Subject: RE: Activity vs Action completion Date: Thu, 4 Mar 2010 17:22:26 +0100 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Activity vs Action completion Thread-Index: Acq7oQ9P95sRAlK+TpOf26T/jhhqigAA1AFgAAPoHOA= From: "BERNARD, Yves" To: X-OriginalArrivalTime: 04 Mar 2010 16:22:27.0601 (UTC) FILETIME=[E18C9810:01CABBB6] Ed, Thanks for your interest. A first point is to clearly state what proposition is true: 1. An Activity ends when it contains no more token of any kind. 2. An Activity ends when none of its action is executing. ðf (1) is true then some activities might never end (eg. With datastoere and no ActivityFinalNode) ðf (2) is true then some activity with streaming or optional input parameters might end .prematurely. (in case of starvation) Another point is to clarify how tokens are managed because the specification (UML v2.3) does not seem consistent to me: · p319: .When a node begins execution, tokens are accepted from some or all of its input edges and a token is placed on the node. When a node completes execution, a token is removed from the node and tokens are offered to some or all of its output edges. => Except ActivityGroups, anything in an activity is either a node or an edge. Then this statement suggests that between the instant a node completes its execution and the instant the next node starts its owns, the token resides on the edge. · In the same sub clause, p320: .Edges have rules about when a token may be taken from the source node and moved to the target node. A token traverses an edge when it satisfies the rules for target node, edge, and source node all at once. This means a source node can only offer tokens to the outgoing edges, rather than force them along the edge, because the tokens may be rejected by the edge or the target node on the other side. [...] Since multiple edges can leave the same node, the same token can be offered to multiple targets.. => What seems indicates that tokens can only traverse edges but never .reside. on them. Then, and to be consistent with the previous statement, the control token corresponding to the execution of an action should be destroy if not immediately accepted by another node. For sure, this is not a desirable behaviour! Putting these all together, I came to the conclusion that the rule that would provide the expected behaviour would be the following: · When an action ends its execution the control token remains in the node while it has not been accepted through an outgoing edge or destroyed In that case, the answer to my simple Activity example should be (a): the call hangs. Yves De : Ed Seidewitz [mailto:ed-s@modeldriven.com] Envoyé jeudi 4 mars 2010 15:20 À: BERNARD, Yves Cc : uml2-rtf@omg.org Objet : RE: Activity vs Action completion Yves . I agree with you that the spec is not entirely clear on the completion of activities. This actually is made precise in the fUML semantics, but I am not sure that the current fUML completion semantics completely captures the intended completion semantics in the superstructure spec, exactly because those are not clearly laid out. This will need to be resolved in the fUML RTF after finalization, since we need to first clear up the semantics in the superstructure spec (perhaps as part of the UML 2.5 submission process) before formalizing it in fUML. That said, I do think that it is clear what happens in the simple case that your give. When the activity begins execution, a single control token is offered from the initial node to Action A. The execution of Action A then proceeds according to the semantic rules specified in Subclause 12.3.2 of the spec (which have themselves been clarified in UML 2.3). First, when the action accepts the control token it is .removed from the original source. (the initial node) and consumed by the action. Since this satisfies all the prerequisites for the action, it fires and, when completed, .offers any object tokens that have been placed on its output pins and control tokens on all its outgoing control flows.and terminates.. Since Action A has no output pins or outgoing control flows, it terminates without offering any new tokens. Thus, when Action A is completed, there are no tokens on any of the nodes of the activity. In this case, it is clear than the activity execution is completed, and a synchronous call will return normally. No final node is needed. (If you added a final node, with a control flow from Action A, then, on completion of Action A, a control token would be offered to and then consumed by the final node, leading to the same result.) -- Ed -------------------------------------------------------------------------------- From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Thursday, March 04, 2010 8:46 AM To: uml2-rtf@omg.org Subject: Activity vs Action completion The specification is not clear on how the completion of an Activity is related to the completion of the action it owns. Have a look on the diagram below. This very simple Activity has no ActivityFinalNode and only one action with no outgoing flow. Imagine that a synchronous CallBehaviorAction is used to invoke that simple activity, what should happen when this call will be executed? a) The action A is executed and the call hang b) The action A is executed and the call return c) It.s a semantic variation point / undefined behaviour Thanks, Yves The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type; bh=GX3CXjpe1KFKUkxncG/TCyiIymZoAwXFkvk4D2eJrZ4=; b=qbRxNucDMs6CQvvEEkX8J9pyN8HMJnoj273ve3Rm3XS1j9hLTOuINS/4mE0zftg+Yz +dF5ekswBx+by9uLJgb9o+PU+5Hik/1rrm/ZjO8p2snSjicoL2/bjllcZTHnFXbV2SHk K2XW6knh8Qg+c2hE19JZZ3EO2KUegHFWxYAWI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=CsVgxBEoO6hJwLb67MlNM5TCM2hopjm1YcTDJ+vR/9PrXrTAda9lIWDXCyCbJ/3+8g TEytYyFxfTXx5941FJ0lisbC685taSgFnY9j/wsspoUAFzgoNyVOd7dYoM9d5nwsaYiY rRBN+Zb3bGR23oY4fzcvwBKNSA7H38DW0/fC0= Sender: bran.selic@gmail.com From: Bran Selic Date: Thu, 4 Mar 2010 11:51:44 -0500 X-Google-Sender-Auth: 72e40c742deb7a2a Subject: Re: Activity vs Action completion To: "BERNARD, Yves" Cc: uml2-rtf@omg.org A similar problem also occurs in statecharts, where the concept of a completion transition depends on some type of explicit completion specification (what about the case where one orthogonal region has a final state but not its parallel peers?). In my view, we should simplify things by stating that the only valid completion is the case where there is an explicit final state/action. The only exception to this rule, of course, is the case where the state is a simple state, which completes when all of its entry and do activities are completed (this is already stated as such in the spec). Trying to figure out what represents "implicit" completion in the myriad of other possible situations is too complex. In other words, those who are worried about completion should include an explicit completion element in their models. It's not asking too much and it simplifies the spec significantly. Cheers...Bran On Thu, Mar 4, 2010 at 8:46 AM, BERNARD, Yves wrote: The specification is not clear on how the completion of an Activity is related to the completion of the action it owns. Have a look on the diagram below. This very simple Activity has no ActivityFinalNode and only one action with no outgoing flow. Imagine that a synchronous CallBehaviorAction is used to invoke that simple activity, what should happen when this call will be executed? a) The action A is executed and the call hang b) The action A is executed and the call return c) It.s a semantic variation point / undefined behaviour Thanks, Yves The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. Content-Type: image/bmp; name="ole0.bmp" X-Attachment-Id: 0.1 ole02.bmp Subject: RE: Activity vs Action completion Date: Thu, 4 Mar 2010 12:41:21 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Activity vs Action completion thread-index: Acq7uxP+M4KL3eMrRCS0KeuAoAJA5gAAFXbAAAFbC0A= From: "Ed Seidewitz" To: "BERNARD, Yves" , Yves . On: .Another (but related) point is: how to explicitly specify a .never ending. situation in an Activity graph? It can be useful where, for instance, you want that under some specific conditions an activity goes to and stays in a .wait state. where nothing happen until it is .killed. or interrupted in some way?. This can actually be done in a number of ways. One easy way is to simply have the activity simply wait at an accept event action. One of the triggers can be an event that, when detected, causes the activity to terminate, while another trigger might cause it to actually do something useful, and then return to its wait state. Alternatively, if you want the activity to perform some ongoing activity until it is killed, you can put that activity inside a continuous loop. Then you can have a concurrent accept event action in the activity that is triggered by the .kill. event (maybe the reception of some signal), such that, when the accept event action fires, it passes a control token to a final node and terminates the activity. You can also get fancier about just terminating part of the behavior of the activity or allowing for graceful clean-up before termination by using interruptible regions. -- Ed Subject: RE: Activity vs Action completion Date: Thu, 4 Mar 2010 11:59:18 -0500 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Activity vs Action completion thread-index: Acq7oQ9P95sRAlK+TpOf26T/jhhqigAA1AFgAAPoHOAAAXC/YA== From: "Ed Seidewitz" To: "BERNARD, Yves" Cc: Yves . See comments in-line below. -------------------------------------------------------------------------------- From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Thursday, March 04, 2010 11:22 AM To: uml2-rtf@omg.org Subject: RE: Activity vs Action completion Ed, Thanks for your interest. A first point is to clearly state what proposition is true: 1. An Activity ends when it contains no more token of any kind. 2. An Activity ends when none of its action is executing. ð If (1) is true then some activities might never end (eg. With datastoere and no ActivityFinalNode) ð If (2) is true then some activity with streaming or optional input parameters might end .prematurely. (in case of starvation) [EVS] I believe that (1) was what was intended in the Superstructure spec for activity completion semantics, though I can.t really find a clear general statement of it. On the other hand, (2) is what is currently formally specified for fUML (though fUML does not include streaming, so that is not an issue for it right now). Another point is to clarify how tokens are managed because the specification (UML v2.3) does not seem consistent to me: · p319: .When a node begins execution, tokens are accepted from some or all of its input edges and a token is placed on the node. When a node completes execution, a token is removed from the node and tokens are offered to some or all of its output edges. => Except ActivityGroups, anything in an activity is either a node or an edge. Then this statement suggests that between the instant a node completes its execution and the instant the next node starts its owns, the token resides on the edge. [EVS] The phrase .a token is accepted from and edge. is really shorthand for .an offer for a token is accepted via an edge from the (direct or indirect) source of that edge.. Tokens never reside on edges, they can only reside at nodes. Tokens move from node to node when offers for them are accepted. · In the same sub clause, p320: .Edges have rules about when a token may be taken from the source node and moved to the target node. A token traverses an edge when it satisfies the rules for target node, edge, and source node all at once. This means a source node can only offer tokens to the outgoing edges, rather than force them along the edge, because the tokens may be rejected by the edge or the target node on the other side. [...] Since multiple edges can leave the same node, the same token can be offered to multiple targets.. => What seems indicates that tokens can only traverse edges but never .reside. on them. Then, and to be consistent with the previous statement, the control token corresponding to the execution of an action should be destroy if not immediately accepted by another node. For sure, this is not a desirable behaviour! [EVS] This is correct: tokens can only traverse edges, but never reside on them. But the control token corresponding to an action is NOT destroyed if it is not immediately accepted by another node. This means that, if one action has a control flow to another action, and the first action completes but the second action never accepts the control token from the first (perhaps because it has another control dependency that is not satisfied), then, under semantic (1) above, it would seem that the containing activity would hang without ever returning. I agree that this behaviour is undesirable, which is one of the reasons that, until things are better clarified, the fUML semantics are (2). By the way, even though the spec talks all over the place about tokens .traversing edges., it is really only the offer that traverses the edges, possibly passing through one or more control nodes on its way. When an offer for a token is accepted, the token actually .jumps. from its source to its destination without .moving. along the intermediate edges. This is important in so much that it means that, for example, conditions on decision nodes are only evaluated on offers and are not re-evaluated when an offer is accepted. But most of the time it is sufficient to talk as if it was the token that actually .traversed. the edge. Putting these all together, I came to the conclusion that the rule that would provide the expected behaviour would be the following: · When an action ends its execution the control token remains in the node while it has not been accepted through an outgoing edge or destroyed In that case, the answer to my simple Activity example should be (a): the call hangs. [EVS] In your simple activity example, Action A has no outgoing control flows. Therefore, it never offers ANY outgoing control tokens. And the incoming control token to the action is consumed (destroyed) when the action executes. Thus, when the action completes, there are no tokens left and the activity completes execution without problem, as I noted in my previous response. Yves De : Ed Seidewitz [mailto:ed-s@modeldriven.com] Envoyé jeudi 4 mars 2010 15:20 À: BERNARD, Yves Cc : uml2-rtf@omg.org Objet : RE: Activity vs Action completion Yves . I agree with you that the spec is not entirely clear on the completion of activities. This actually is made precise in the fUML semantics, but I am not sure that the current fUML completion semantics completely captures the intended completion semantics in the superstructure spec, exactly because those are not clearly laid out. This will need to be resolved in the fUML RTF after finalization, since we need to first clear up the semantics in the superstructure spec (perhaps as part of the UML 2.5 submission process) before formalizing it in fUML. That said, I do think that it is clear what happens in the simple case that your give. When the activity begins execution, a single control token is offered from the initial node to Action A. The execution of Action A then proceeds according to the semantic rules specified in Subclause 12.3.2 of the spec (which have themselves been clarified in UML 2.3). First, when the action accepts the control token it is .removed from the original source. (the initial node) and consumed by the action. Since this satisfies all the prerequisites for the action, it fires and, when completed, .offers any object tokens that have been placed on its output pins and control tokens on all its outgoing control flows.and terminates.. Since Action A has no output pins or outgoing control flows, it terminates without offering any new tokens. Thus, when Action A is completed, there are no tokens on any of the nodes of the activity. In this case, it is clear than the activity execution is completed, and a synchronous call will return normally. No final node is needed. (If you added a final node, with a control flow from Action A, then, on completion of Action A, a control token would be offered to and then consumed by the final node, leading to the same result.) -- Ed -------------------------------------------------------------------------------- From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Thursday, March 04, 2010 8:46 AM To: uml2-rtf@omg.org Subject: Activity vs Action completion The specification is not clear on how the completion of an Activity is related to the completion of the action it owns. Have a look on the diagram below. This very simple Activity has no ActivityFinalNode and only one action with no outgoing flow. Imagine that a synchronous CallBehaviorAction is used to invoke that simple activity, what should happen when this call will be executed? a) The action A is executed and the call hang b) The action A is executed and the call return c) It.s a semantic variation point / undefined behaviour Thanks, Yves The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. Subject: RE: Activity vs Action completion Date: Thu, 4 Mar 2010 18:03:45 +0100 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Activity vs Action completion Thread-Index: Acq7uxP+M4KL3eMrRCS0KeuAoAJA5gAAFXbA From: "BERNARD, Yves" To: X-OriginalArrivalTime: 04 Mar 2010 17:03:45.0788 (UTC) FILETIME=[A6A9EBC0:01CABBBC] I.m in favour of an explicit final statement, too. Another (but related) point is: how to explicitly specify a .never ending. situation in an Activity graph? It can be useful where, for instance, you want that under some specific conditions an activity goes to and stays in a .wait state. where nothing happen until it is .killed. or interrupted in some way? Thanks, Yves De : bran.selic@gmail.com [mailto:bran.selic@gmail.com] De la part de Bran Selic Envoyé jeudi 4 mars 2010 17:52 À: BERNARD, Yves Cc : uml2-rtf@omg.org Objet : Re: Activity vs Action completion A similar problem also occurs in statecharts, where the concept of a completion transition depends on some type of explicit completion specification (what about the case where one orthogonal region has a final state but not its parallel peers?). In my view, we should simplify things by stating that the only valid completion is the case where there is an explicit final state/action. The only exception to this rule, of course, is the case where the state is a simple state, which completes when all of its entry and do activities are completed (this is already stated as such in the spec). Trying to figure out what represents "implicit" completion in the myriad of other possible situations is too complex. In other words, those who are worried about completion should include an explicit completion element in their models. It's not asking too much and it simplifies the spec significantly. Cheers...Bran On Thu, Mar 4, 2010 at 8:46 AM, BERNARD, Yves wrote: The specification is not clear on how the completion of an Activity is related to the completion of the action it owns. Have a look on the diagram below. This very simple Activity has no ActivityFinalNode and only one action with no outgoing flow. Imagine that a synchronous CallBehaviorAction is used to invoke that simple activity, what should happen when this call will be executed? a) The action A is executed and the call hang b) The action A is executed and the call return c) It.s a semantic variation point / undefined behaviour Thanks, Yves The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type; bh=5pEKCA9WGPbBdNnp8TfnTdrOK5omTerhRXXgMcPTVOM=; b=k1rnU2/ex1YFtPML0us/O+MSpviyRYRIgcQ9BuN7vJ8YdqqyfiBJiGoYmqHM6T4Klo Cs9P7YZpwcpc1Rt+I21ctJT2CV21RhNFz9oUHkoKUbU3ySmYL+1DdPTib0c0kO6haGG6 PIYNSPuEpCv9S8lujbWJqeqUwb2j+fogBgWBo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=AsF2nRgMIEWI74QA9c35QVpWWtoTi8xn2d2K8MMUfls/igapZXDX+fC/w/yUCobXHT fo/3UqXS01jPnM8Lwl+PXhOGGFxyVAL+6TTuM0RKUdS/PtC2aWHGb7qT7ky6j1njMH0u +WWzmPjXFSp95gzpayVncHtqsecWyRuE4Z9D0= Sender: bran.selic@gmail.com From: Bran Selic Date: Thu, 4 Mar 2010 15:11:22 -0500 X-Google-Sender-Auth: 8c99ffa981ed0e28 Subject: Re: Activity vs Action completion To: Ed Seidewitz Cc: Juergen Boldt , uml2-rtf@omg.org Ed, Conrad may be able to answer the question for the case of activities, but, as I pointed out, the problem still remains in statecharts. In either case, however, the spec is quite unclear on this point, so there is definitely an issue here. Juergen, here is a proposed formulation: "In both UML activities and UML statecharts it is sometimes necessary to recognize when some behavior (activity or state-based, respectively) has completed. However, in models without an explicit final node or final state respectively, it is not always clear when this condition is achieved." Cheers...Bran On Thu, Mar 4, 2010 at 2:28 PM, Ed Seidewitz wrote: Juergen . I would personally prefer to have some discussion with Conrad Bock about this before formulating an issue. If it turns out to just be a matter of clarifying the way this is documented in the spec, then it can probably be handled best in the UML 2.5 spec simplification submission, and an issue is not really important. But if Yves would like to see this documented as an issue, that would be OK, too. -- Ed -------------------------------------------------------------------------------- From: Juergen Boldt [mailto:juergen@omg.org] Sent: Thursday, March 04, 2010 2:23 PM To: BERNARD, Yves; uml2-rtf@omg.org Subject: Re: Activity vs Action completion issue? -Juergen At 08:46 AM 3/4/2010, BERNARD, Yves wrote: The specification is not clear on how the completion of an Activity is related to the completion of the action it owns. Have a look on the diagram below. This very simple Activity has no ActivityFinalNode and only one action with no outgoing flow. Imagine that a synchronous CallBehaviorAction is used to invoke that simple activity, what should happen when this call will be executed? a) The action A is executed and the call hang b) The action A is executed and the call return c) It.s a semantic variation point / undefined behaviour Thanks, Yves The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. 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 Subject: RE: Activity vs Action completion Date: Thu, 4 Mar 2010 15:21:57 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Activity vs Action completion thread-index: Acq71vJBiWrVh+m4RUONhCiPJ6w34wAAL84w From: "Ed Seidewitz" To: "Bran Selic" Cc: "Juergen Boldt" , Bran . It is really not clear to me that both state machines and activities should be covered in a single issue like you proposed. The underlying semantics of state machines and activities are now quite different and, while they may each have a similar issue on the semantics of completion, I would rather see these issues stated separately and in more detail, in terms of the specific semantics of each. And I would also like to think more about what the underlying issues really are, semantically, before formally submitting them formally. (Separately the issues also, pragmatically, makes them easier to categorize, assign and resolve in the RTF.) However, you are perfectly within your rights, of course, to submit whatever issue you think is appropriate. -- Ed -------------------------------------------------------------------------------- From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: Thursday, March 04, 2010 3:11 PM To: Ed Seidewitz Cc: Juergen Boldt; uml2-rtf@omg.org Subject: Re: Activity vs Action completion Ed, Conrad may be able to answer the question for the case of activities, but, as I pointed out, the problem still remains in statecharts. In either case, however, the spec is quite unclear on this point, so there is definitely an issue here. Juergen, here is a proposed formulation: "In both UML activities and UML statecharts it is sometimes necessary to recognize when some behavior (activity or state-based, respectively) has completed. However, in models without an explicit final node or final state respectively, it is not always clear when this condition is achieved." Cheers...Bran On Thu, Mar 4, 2010 at 2:28 PM, Ed Seidewitz wrote: Juergen . I would personally prefer to have some discussion with Conrad Bock about this before formulating an issue. If it turns out to just be a matter of clarifying the way this is documented in the spec, then it can probably be handled best in the UML 2.5 spec simplification submission, and an issue is not really important. But if Yves would like to see this documented as an issue, that would be OK, too. -- Ed -------------------------------------------------------------------------------- From: Juergen Boldt [mailto:juergen@omg.org] Sent: Thursday, March 04, 2010 2:23 PM To: BERNARD, Yves; uml2-rtf@omg.org Subject: Re: Activity vs Action completion issue? -Juergen At 08:46 AM 3/4/2010, BERNARD, Yves wrote: The specification is not clear on how the completion of an Activity is related to the completion of the action it owns. Have a look on the diagram below. This very simple Activity has no ActivityFinalNode and only one action with no outgoing flow. Imagine that a synchronous CallBehaviorAction is used to invoke that simple activity, what should happen when this call will be executed? a) The action A is executed and the call hang b) The action A is executed and the call return c) It.s a semantic variation point / undefined behaviour Thanks, Yves The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. 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 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type; bh=j7NdkEwGxhGeGKZBV6gLDUAFZpaT9EKrZEnqxHNQTo4=; b=N49dtAZXsq34Q3irCaY8fBo38GKQqcoWtGS4xqwmuEBaE0wARI7Li30KDES/MuoOU1 M6/5AMkg1bOuIChVlGZca3xglfvk8VBTHN3RrlgrmW79Yb5NzuX+sB51ks+mJs+TK8AC sljgFxS0kfCzz356v6O68+h3HUKWliTNfuzcQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=UWRzwk3p9zY0gkR1MwWfIM+c+SQOBgrCG/FrOyvlh9STD7INL2MW146qu8k8M1c1aQ JKNIW8EgQIcAVoebkM6YaLfZ0y8jXiK2plaMzPv7McqsksJ5S4rHQxJtbS3np6ivP0SY zWFjd+MYBwmfC96J5bQdwmMX/baFC1gssQHeA= Sender: bran.selic@gmail.com From: Bran Selic Date: Thu, 4 Mar 2010 15:31:34 -0500 X-Google-Sender-Auth: cb171c21bf49986b Subject: Re: Activity vs Action completion To: Ed Seidewitz Cc: Juergen Boldt , uml2-rtf@omg.org Yes, I thought of that as well. However, I do believe that the issue is actually a cross-behavior one, since the concept is one of "behavior completion" whether or not the behavior is nested in an activity or a statechart. (Perhaps my formulation could have been clearer on that point.) Cheers...Bran On Thu, Mar 4, 2010 at 3:21 PM, Ed Seidewitz wrote: Bran . It is really not clear to me that both state machines and activities should be covered in a single issue like you proposed. The underlying semantics of state machines and activities are now quite different and, while they may each have a similar issue on the semantics of completion, I would rather see these issues stated separately and in more detail, in terms of the specific semantics of each. And I would also like to think more about what the underlying issues really are, semantically, before formally submitting them formally. (Separately the issues also, pragmatically, makes them easier to categorize, assign and resolve in the RTF.) However, you are perfectly within your rights, of course, to submit whatever issue you think is appropriate. -- Ed -------------------------------------------------------------------------------- From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: Thursday, March 04, 2010 3:11 PM To: Ed Seidewitz Cc: Juergen Boldt; uml2-rtf@omg.org Subject: Re: Activity vs Action completion Ed, Conrad may be able to answer the question for the case of activities, but, as I pointed out, the problem still remains in statecharts. In either case, however, the spec is quite unclear on this point, so there is definitely an issue here. Juergen, here is a proposed formulation: "In both UML activities and UML statecharts it is sometimes necessary to recognize when some behavior (activity or state-based, respectively) has completed. However, in models without an explicit final node or final state respectively, it is not always clear when this condition is achieved." Cheers...Bran On Thu, Mar 4, 2010 at 2:28 PM, Ed Seidewitz wrote: Juergen . I would personally prefer to have some discussion with Conrad Bock about this before formulating an issue. If it turns out to just be a matter of clarifying the way this is documented in the spec, then it can probably be handled best in the UML 2.5 spec simplification submission, and an issue is not really important. But if Yves would like to see this documented as an issue, that would be OK, too. -- Ed -------------------------------------------------------------------------------- From: Juergen Boldt [mailto:juergen@omg.org] Sent: Thursday, March 04, 2010 2:23 PM To: BERNARD, Yves; uml2-rtf@omg.org Subject: Re: Activity vs Action completion issue? -Juergen At 08:46 AM 3/4/2010, BERNARD, Yves wrote: The specification is not clear on how the completion of an Activity is related to the completion of the action it owns. Have a look on the diagram below. This very simple Activity has no ActivityFinalNode and only one action with no outgoing flow. Imagine that a synchronous CallBehaviorAction is used to invoke that simple activity, what should happen when this call will be executed? a) The action A is executed and the call hang b) The action A is executed and the call return c) It.s a semantic variation point / undefined behaviour Thanks, Yves The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. 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 Subject: RE: Activity vs Action completion Date: Thu, 4 Mar 2010 17:22:26 +0100 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Activity vs Action completion Thread-Index: Acq7oQ9P95sRAlK+TpOf26T/jhhqigAA1AFgAAPoHOA= From: "BERNARD, Yves" To: X-OriginalArrivalTime: 04 Mar 2010 16:22:27.0601 (UTC) FILETIME=[E18C9810:01CABBB6] Ed, Thanks for your interest. A first point is to clearly state what proposition is true: 1. An Activity ends when it contains no more token of any kind. 2. An Activity ends when none of its action is executing. ðf (1) is true then some activities might never end (eg. With datastoere and no ActivityFinalNode) ðf (2) is true then some activity with streaming or optional input parameters might end .prematurely. (in case of starvation) Another point is to clarify how tokens are managed because the specification (UML v2.3) does not seem consistent to me: · p319: .When a node begins execution, tokens are accepted from some or all of its input edges and a token is placed on the node. When a node completes execution, a token is removed from the node and tokens are offered to some or all of its output edges. => Except ActivityGroups, anything in an activity is either a node or an edge. Then this statement suggests that between the instant a node completes its execution and the instant the next node starts its owns, the token resides on the edge. · In the same sub clause, p320: .Edges have rules about when a token may be taken from the source node and moved to the target node. A token traverses an edge when it satisfies the rules for target node, edge, and source node all at once. This means a source node can only offer tokens to the outgoing edges, rather than force them along the edge, because the tokens may be rejected by the edge or the target node on the other side. [...] Since multiple edges can leave the same node, the same token can be offered to multiple targets.. => What seems indicates that tokens can only traverse edges but never .reside. on them. Then, and to be consistent with the previous statement, the control token corresponding to the execution of an action should be destroy if not immediately accepted by another node. For sure, this is not a desirable behaviour! Putting these all together, I came to the conclusion that the rule that would provide the expected behaviour would be the following: · When an action ends its execution the control token remains in the node while it has not been accepted through an outgoing edge or destroyed In that case, the answer to my simple Activity example should be (a): the call hangs. Yves De : Ed Seidewitz [mailto:ed-s@modeldriven.com] Envoyé jeudi 4 mars 2010 15:20 À: BERNARD, Yves Cc : uml2-rtf@omg.org Objet : RE: Activity vs Action completion Yves . I agree with you that the spec is not entirely clear on the completion of activities. This actually is made precise in the fUML semantics, but I am not sure that the current fUML completion semantics completely captures the intended completion semantics in the superstructure spec, exactly because those are not clearly laid out. This will need to be resolved in the fUML RTF after finalization, since we need to first clear up the semantics in the superstructure spec (perhaps as part of the UML 2.5 submission process) before formalizing it in fUML. That said, I do think that it is clear what happens in the simple case that your give. When the activity begins execution, a single control token is offered from the initial node to Action A. The execution of Action A then proceeds according to the semantic rules specified in Subclause 12.3.2 of the spec (which have themselves been clarified in UML 2.3). First, when the action accepts the control token it is .removed from the original source. (the initial node) and consumed by the action. Since this satisfies all the prerequisites for the action, it fires and, when completed, .offers any object tokens that have been placed on its output pins and control tokens on all its outgoing control flows.and terminates.. Since Action A has no output pins or outgoing control flows, it terminates without offering any new tokens. Thus, when Action A is completed, there are no tokens on any of the nodes of the activity. In this case, it is clear than the activity execution is completed, and a synchronous call will return normally. No final node is needed. (If you added a final node, with a control flow from Action A, then, on completion of Action A, a control token would be offered to and then consumed by the final node, leading to the same result.) -- Ed -------------------------------------------------------------------------------- From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Thursday, March 04, 2010 8:46 AM To: uml2-rtf@omg.org Subject: Activity vs Action completion The specification is not clear on how the completion of an Activity is related to the completion of the action it owns. Have a look on the diagram below. This very simple Activity has no ActivityFinalNode and only one action with no outgoing flow. Imagine that a synchronous CallBehaviorAction is used to invoke that simple activity, what should happen when this call will be executed? a) The action A is executed and the call hang b) The action A is executed and the call return c) It.s a semantic variation point / undefined behaviour Thanks, Yves The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. Subject: RE: Activity vs Action completion X-KeepSent: AFC2F25E:D1376E0A-C22576DD:003D1FBB; type=4; name=$KeepSent To: "BERNARD, Yves" Cc: "Ed Seidewitz" , "Juergen Boldt" , "Bran Selic" , uml2-rtf@omg.org X-Mailer: Lotus Notes Release 8.5 HF58 February 06, 2009 From: Eran Gery Date: Fri, 5 Mar 2010 13:26:26 +0200 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 8.5|December 05, 2008) at 05/03/2010 13:27:44 X-MIME-Autoconverted: from base64 to 8bit by amethyst.omg.org id o25BJpLY025922 Yes - but as to the issue "when a statemachine completes" it is very explicit in the spec. All topmost regions must reach a final state. So a statemachine can reach a "dead end" configuration, but still considered active. I agree with Bran that this might not be intuitive to users, and in that sense if we could find a proper analogous definition to "all tokens are consumed" certain users may prefer this. However since SMs are not token based, it would be more superficial to define a "dead configuration" in a statemachine as a completion state. What I would add to a statemachine is something like "activity final" which is a node that terminates the machine regardless of where it is and how many regions are there. Eran Eran Gery IBM Distinguished Engineer IBM Rational Systems Platform From: "BERNARD, Yves" To: "Bran Selic" , "Ed Seidewitz" Cc: "Juergen Boldt" , Date: 03/05/2010 01:07 PM Subject: RE: Activity vs Action completion Indeed. Even if state machine and activity have now distinct semantics they are used together in mixed way to describe a behavior and they have side effects on one another: state machines can start and kill activities which can trigger transitions by generating events but also through their completion. Yves De : bran.selic@gmail.com [mailto:bran.selic@gmail.com] De la part de Bran Selic Envoyé : jeudi 4 mars 2010 21:32 Ã : Ed Seidewitz Cc : Juergen Boldt; uml2-rtf@omg.org Objet : Re: Activity vs Action completion Yes, I thought of that as well. However, I do believe that the issue is actually a cross-behavior one, since the concept is one of "behavior completion" whether or not the behavior is nested in an activity or a statechart. (Perhaps my formulation could have been clearer on that point.) Cheers...Bran On Thu, Mar 4, 2010 at 3:21 PM, Ed Seidewitz wrote: Bran ­ It is really not clear to me that both state machines and activities should be covered in a single issue like you proposed. The underlying semantics of state machines and activities are now quite different and, while they may each have a similar issue on the semantics of completion, I would rather see these issues stated separately and in more detail, in terms of the specific semantics of each. And I would also like to think more about what the underlying issues really are, semantically, before formally submitting them formally. (Separately the issues also, pragmatically, makes them easier to categorize, assign and resolve in the RTF.) However, you are perfectly within your rights, of course, to submit whatever issue you think is appropriate. -- Ed From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: Thursday, March 04, 2010 3:11 PM To: Ed Seidewitz Cc: Juergen Boldt; uml2-rtf@omg.org Subject: Re: Activity vs Action completion Ed, Conrad may be able to answer the question for the case of activities, but, as I pointed out, the problem still remains in statecharts. In either case, however, the spec is quite unclear on this point, so there is definitely an issue here. Juergen, here is a proposed formulation: "In both UML activities and UML statecharts it is sometimes necessary to recognize when some behavior (activity or state-based, respectively) has completed. However, in models without an explicit final node or final state respectively, it is not always clear when this condition is achieved." Cheers...Bran On Thu, Mar 4, 2010 at 2:28 PM, Ed Seidewitz wrote: Juergen ­ I would personally prefer to have some discussion with Conrad Bock about this before formulating an issue. If it turns out to just be a matter of clarifying the way this is documented in the spec, then it can probably be handled best in the UML 2.5 spec simplification submission, and an issue is not really important. But if Yves would like to see this documented as an issue, that would be OK, too. -- Ed From: Juergen Boldt [mailto:juergen@omg.org] Sent: Thursday, March 04, 2010 2:23 PM To: BERNARD, Yves; uml2-rtf@omg.org Subject: Re: Activity vs Action completion issue? -Juergen At 08:46 AM 3/4/2010, BERNARD, Yves wrote: The specification is not clear on how the completion of an Activity is related to the completion of the action it owns. Have a look on the diagram below. Erreur ! Nom du fichier non spécifié. This very simple Activity has no ActivityFinalNode and only one action with no outgoing flow. Imagine that a synchronous CallBehaviorAction is used to invoke that simple activity, what should happen when this call will be executed? a) The action A is executed and the call hang b) The action A is executed and the call return c) Itâs a semantic variation point / undefined behaviour Thanks, Yves The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. 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 Erreur ! Nom du fichier non spécifié. This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free.