Issue 6223: UML 2 Super/pg.395/multiple meaning of exception (uml2-superstructure-ftf) Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org) Nature: Uncategorized Issue Severity: Summary: pg. 395: Multiple meanings of exception (signal, stack mechanism). The use of exception to be a kind of signal was a mistake in UML1 that goes against all practice. We have now defined it (in the action semantics) to be a proper synchronous nonlinear control mechanism, as in all programming languages. Eliminate all references to it as a kind of signal, otherwise much confusion will ensue. Resolution: see above Revised Text: Actions taken: September 7, 2003: received issue March 8, 2005: closed issue Discussion: The submitter is correct in pointing out that UML 2.0 added a powerful exception handling mechanism. In general, an exception is any object, not necessarily a signal instance. However, if there are still remnants of the original mechanisms left in the text accidentally, these should be adjusted appropriately: In the glossary, p.8, change the first sentence to: “An object typically used to indicate fault situations.” On p.376, Figure 316 “Extensions to behavioral features and signal”, delete the symbol for Signal. Have the association BehavioralFeature.raisedException go to Classifier. Move Signal.ownedAttribute and the attached Property to Figure 315. On p.376, Figure 315 “Reception”, add Signal.ownedAttribute, as currently shown in Figure 316. On p.382, class BehavioralFeature, change type of association raisedException to Classifier. Change the text to “The classifier that the behavioral feature…”. On p.395, delete the last sentence in the Semantics section for class Signal. End of Annotations:===== To: issues@omg.org Subject: UML 2 Super/pg.395/multiple meaning of exception X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 From: Branislav Selic Date: Sun, 7 Sep 2003 09:58:46 -0400 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 09/07/2003 09:58:49, Serialize complete at 09/07/2003 09:58:49 pg. 395: Multiple meanings of exception (signal, stack mechanism). The use of exception to be a kind of signal was a mistake in UML1 that goes against all practice. We have now defined it (in the action semantics) to be a proper synchronous nonlinear control mechanism, as in all programming languages. Eliminate all references to it as a kind of signal, otherwise much confusion will ensue. Bran Selic IBM Software Group -- Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph. (613) 591-7915 fax (613) 599-3912 e-mail: bselic@ca.ibm.com OMG Issue No: 6223 Title: UML 2 Super/pg.395/multiple meaning of exception Source: International Business Machines (Mr. Bran Selic, bselic@ca.ibm.com) Summary: pg. 395: Multiple meanings of exception (signal, stack mechanism). The use of exception to be a kind of signal was a mistake in UML1 that goes against all practice. We have now defined it (in the action semantics) to be a proper synchronous nonlinear control mechanism, as in all programming languages. Eliminate all references to it as a kind of signal, otherwise much confusion will ensue. Discussion: The submitter is correct in pointing out that UML 2.0 added a powerful exception handling mechanism. In general, an exception is any object, not necessarily a signal instance. However, if there are still remnants of the original mechanisms left in the text accidentally, these should be adjusted appropriately: In the glossary, p.8, change the first sentence to: .An object typically used to indicate fault situations.. On p.376, Figure 316 .Extensions to behavioral features and signal., delete the symbol for Signal. Have the association BehavioralFeature.raisedException go to Classifier. Move Signal.ownedAttribute and the attached Property to Figure 315. On p.376, Figure 315 .Reception., add Signal.ownedAttribute, as currently shown in Figure 316. On p.382, class BehavioralFeature, change type of association raisedException to Classifier. Change the text to .The classifier that the behavioral feature... On p.395, delete the last sentence in the Semantics section for class Signal. Disposition: Resolved OMG Issue No: 6223 Title: UML 2 Super/pg.395/multiple meaning of exception Source: International Business Machines (Mr. Bran Selic, bselic@ca.ibm.com) Summary: pg. 395: Multiple meanings of exception (signal, stack mechanism). The use of exception to be a kind of signal was a mistake in UML1 that goes against all practice. We have now defined it (in the action semantics) to be a proper synchronous nonlinear control mechanism, as in all programming languages. Eliminate all references to it as a kind of signal, otherwise much confusion will ensue. Discussion: The submitter is correct in pointing out that UML 2.0 added a powerful exception handling mechanism. In general, an exception is any object, not necessarily a signal instance. However, if there are still remnants of the original mechanisms left in the text accidentally, these should be adjusted appropriately: In the glossary, p.8, change the first sentence to: .An object typically used to indicate fault situations.. On p.376, Figure 316 .Extensions to behavioral features and signal., delete the symbol for Signal. Have the association BehavioralFeature.raisedException go to Classifier. Move Signal.ownedAttribute and the attached Property to Figure 315. On p.376, Figure 315 .Reception., add Signal.ownedAttribute, as currently shown in Figure 316. On p.382, class BehavioralFeature, change type of association raisedException to Classifier. Change the text to .The classifier that the behavioral feature... On p.395, delete the last sentence in the Semantics section for class Signal. From: "Moore, Alan" To: "'Eran Gery'" , "'Branislav Selic'" Cc: uml2-superstructure-ftf@omg.org Subject: RE: 4 statemachine resolutions for ballot 12 (11?) Date: Wed, 7 Apr 2004 08:59:42 +0100 X-Mailer: Internet Mail Service (5.5.2653.19) Hi Eran, Sorry but I'm not convinced - for example in the discussion you state: "Therefore, the answer to Alan's question is that all the graphical segments connecting action and trigger nodes map to a single transition" and then in a later section you state: "Therefore figure 395 consists of 4 transitions: from idle to the choice symbol, each of the branches of the choice through the junction symbol, and a transition from the junction to the busy state." I can't see how these two statements can be reconciled. What would convince me is a repository model for figure 395. Alan. -----Original Message----- From: Eran Gery [mailto:erang@ilogix.co.il] Sent: 06 April 2004 17:58 To: 'Moore, Alan'; 'Branislav Selic' Cc: uml2-superstructure-ftf@omg.org Subject: RE: 4 statemachine resolutions for ballot 12 (11?) Alan, The junction and choice symbols are NOT actions. They are pseudo state instances of the state machine. The source for the confusion is that this is an overloaded notation from activities. However none of these shared symbols is mapped to the semantics the same way in state machines. I added a paragraph at the end clarifying this. With this additional paragraph, I am convinced that your issue is now clarified. Yes, there is a subtlety regarding maping several transition symbols to the same transition, but I believe it is clarified in various places now to a reasonable degree. Eran p.s. Bran - a new candidate for Ballot 12... -----Original Message----- From: Moore, Alan [mailto:AlanM@artisansw.com] Sent: Tue, April 06, 2004 11:24 AM To: 'Eran Gery'; 'Branislav Selic' Cc: uml2-superstructure-ftf@omg.org; Guus Ramackers (E-mail) Subject: RE: 4 statemachine resolutions for ballot 12 (11?) Hi Eran, I have problems with your explanation as it relates to Fig 395. Most obvious is that you don't mention the junction and choice symbols - they can't be part of the action sequence and yet they are not activities in their own right, so what are they? The status of figure 395 is also dubious IMO because the only interpretation of the arrow symbols according to the Graphic Paths table is a transition, so the figure includes symbols that have an undefined interpretation according to the definition in the Diagrams section (15.4), which I assume is where everyone will look for an interpretation. Alan. -----Original Message----- From: Eran Gery [mailto:erang@ilogix.co.il] Sent: 04 April 2004 14:36 To: Moore, Alan; 'Branislav Selic' Cc: uml2-superstructure-ftf@omg.org; Guus Ramackers (E-mail) Subject: RE: 4 statemachine resolutions for ballot 12 (11?) Alan - I have further refined the text to address your comments. There were indeed several places where we used terms that could have been misleading. As to the multiple triggers issue - I have basically modifid the text such that the trigger/guard expression is denoted within the "signal receipt" symbol similar to the way it is denoted in regular (non "action-oriented" transitions). Therefore, it does not impose any additional constraint comparing to the "regular" notation. So I have essentially delagated the multiple trigger issue to the textual notation which is not part of this section. However, looking at that, this whole issue of denoting multiple triggers seems lacking/inconsistent and "deserves" another issue, which also involves common behaviors. Eran p.s. Bran - this is the current candidate to include in ballot 12 -----Original Message----- From: Moore, Alan [mailto:AlanM@artisansw.com] Sent: Sun, April 04, 2004 1:33 PM To: 'Eran Gery'; 'Branislav Selic'; Guus Ramackers (E-mail) Cc: uml2-superstructure-ftf@omg.org Subject: RE: 4 statemachine resolutions for ballot 12 (11?) Hi Eran, I have modified the document with some comments on my issue. Alan. -----Original Message----- From: Eran Gery [mailto:erang@ilogix.co.il] Sent: 30 March 2004 15:06 To: 'Branislav Selic'; Guus Ramackers (E-mail) Cc: uml2-superstructure-ftf@omg.org Subject: 4 statemachine resolutions for ballot 12 (11?) Bran/Guus Attached is a resolution prposal for 4 statemachine issues I originally intended for ballot 11, but since none of them is trivial, I thought at this point they better be submitted for discussion for ballot 12. However I'm fine submitting them to 11 if you find appropriate and/or nobody objects. Thanks, Eran From: "Moore, Alan" To: "'Eran Gery'" , "'Branislav Selic'" Cc: uml2-superstructure-ftf@omg.org Subject: RE: 4 statemachine resolutions for ballot 12 (11?) Date: Wed, 7 Apr 2004 09:05:51 +0100 X-Mailer: Internet Mail Service (5.5.2653.19) By which I mean a model showing the repository instances corresponding to figure 395. Alan. -----Original Message----- From: Moore, Alan [mailto:AlanM@artisansw.com] Sent: 07 April 2004 09:00 To: 'Eran Gery'; 'Branislav Selic' Cc: uml2-superstructure-ftf@omg.org Subject: RE: 4 statemachine resolutions for ballot 12 (11?) Hi Eran, Sorry but I'm not convinced - for example in the discussion you state: "Therefore, the answer to Alan's question is that all the graphical segments connecting action and trigger nodes map to a single transition" and then in a later section you state: "Therefore figure 395 consists of 4 transitions: from idle to the choice symbol, each of the branches of the choice through the junction symbol, and a transition from the junction to the busy state." I can't see how these two statements can be reconciled. What would convince me is a repository model for figure 395. Alan. -----Original Message----- From: Eran Gery [mailto:erang@ilogix.co.il] Sent: 06 April 2004 17:58 To: 'Moore, Alan'; 'Branislav Selic' Cc: uml2-superstructure-ftf@omg.org Subject: RE: 4 statemachine resolutions for ballot 12 (11?) Alan, The junction and choice symbols are NOT actions. They are pseudo state instances of the state machine. The source for the confusion is that this is an overloaded notation from activities. However none of these shared symbols is mapped to the semantics the same way in state machines. I added a paragraph at the end clarifying this. With this additional paragraph, I am convinced that your issue is now clarified. Yes, there is a subtlety regarding maping several transition symbols to the same transition, but I believe it is clarified in various places now to a reasonable degree. Eran p.s. Bran - a new candidate for Ballot 12... -----Original Message----- From: Moore, Alan [mailto:AlanM@artisansw.com] Sent: Tue, April 06, 2004 11:24 AM To: 'Eran Gery'; 'Branislav Selic' Cc: uml2-superstructure-ftf@omg.org; Guus Ramackers (E-mail) Subject: RE: 4 statemachine resolutions for ballot 12 (11?) Hi Eran, I have problems with your explanation as it relates to Fig 395. Most obvious is that you don't mention the junction and choice symbols - they can't be part of the action sequence and yet they are not activities in their own right, so what are they? The status of figure 395 is also dubious IMO because the only interpretation of the arrow symbols according to the Graphic Paths table is a transition, so the figure includes symbols that have an undefined interpretation according to the definition in the Diagrams section (15.4), which I assume is where everyone will look for an interpretation. Alan. -----Original Message----- From: Eran Gery [mailto:erang@ilogix.co.il] Sent: 04 April 2004 14:36 To: Moore, Alan; 'Branislav Selic' Cc: uml2-superstructure-ftf@omg.org; Guus Ramackers (E-mail) Subject: RE: 4 statemachine resolutions for ballot 12 (11?) Alan - I have further refined the text to address your comments. There were indeed several places where we used terms that could have been misleading. As to the multiple triggers issue - I have basically modifid the text such that the trigger/guard expression is denoted within the "signal receipt" symbol similar to the way it is denoted in regular (non "action-oriented" transitions). Therefore, it does not impose any additional constraint comparing to the "regular" notation. So I have essentially delagated the multiple trigger issue to the textual notation which is not part of this section. However, looking at that, this whole issue of denoting multiple triggers seems lacking/inconsistent and "deserves" another issue, which also involves common behaviors. Eran p.s. Bran - this is the current candidate to include in ballot 12 -----Original Message----- From: Moore, Alan [mailto:AlanM@artisansw.com] Sent: Sun, April 04, 2004 1:33 PM To: 'Eran Gery'; 'Branislav Selic'; Guus Ramackers (E-mail) Cc: uml2-superstructure-ftf@omg.org Subject: RE: 4 statemachine resolutions for ballot 12 (11?) Hi Eran, I have modified the document with some comments on my issue. Alan. -----Original Message----- From: Eran Gery [mailto:erang@ilogix.co.il] Sent: 30 March 2004 15:06 To: 'Branislav Selic'; Guus Ramackers (E-mail) Cc: uml2-superstructure-ftf@omg.org Subject: 4 statemachine resolutions for ballot 12 (11?) Bran/Guus Attached is a resolution prposal for 4 statemachine issues I originally intended for ballot 11, but since none of them is trivial, I thought at this point they better be submitted for discussion for ballot 12. However I'm fine submitting them to 11 if you find appropriate and/or nobody objects. Thanks, Eran From: "Moore, Alan" To: "'Thomas Weigert'" , uml2ftf Cc: bselic@ca.ibm.com Subject: RE: ,cb,,cs, Proposals for ballot 12 (April 14) Date: Wed, 7 Apr 2004 09:13:30 +0100 X-Mailer: Internet Mail Service (5.5.2653.19) OK. So I want to check a couple of points: 1. Is it possible for a behaviour port to have a required interface - yes, in fact it's shown on Figure 111 in the spec. 2. In the example quoted below, class C with behaviour port BP and part P, connected by connector chan. In the scenario you describe P sends a message , say m, to BP, which is forwarded to C. If the behavioural feature related to m is specified by interface I1, is the scenario you describe affected if BP requires I1, rather than provides I1? From what I can see, within the scope of the example there is no difference. Alan. -----Original Message----- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: 06 April 2004 13:21 To: Moore, Alan; 'Thomas Weigert'; uml2ftf Cc: bselic@ca.ibm.com Subject: RE: ,cb,,cs, Proposals for ballot 12 (April 14) Actually, in both examples we are dealing with provided interfaces, don't we? A behavior port is just like any other port with respect to its interfaces. But you are raising an interesting enhancement suggestion: Should the behavior port have its interfaces derived from the classifier it is a port on, if it has not been given explicit interfaces? In other words, if we omit the type of the behavior port, should we say that in that case it derives its interfaces from the classifier it is the behavior port of? This appears to be a convenient shortcut, albeit I am not sure how often these situations actually arise (probably most of the time we would limit the interfaces offered at the behavior port?). Bran, do you have any intuitions governing the above? Thanks, Th. > -----Original Message----- > From: Moore, Alan [mailto:AlanM@artisansw.com] > Sent: Tuesday, April 06, 2004 7:06 AM > To: 'Thomas Weigert'; uml2ftf > Cc: bselic@ca.ibm.com > Subject: RE: ,cb,,cs, Proposals for ballot 12 (April 14) > > > Interesting and I can see that it has a meaning and a use. I have a > supplementary question - does the behaviour port of C, let's call > it BP, in > case 1, have to have a required interface, because P requires features of > BP, or a provided interface because C offers features via BP? > > I assume the latter(provided), although if BP was not a behaviour > port then > it would be the former (required) - this seems a little odd - imagine if > chan was connected to BP via a port, P.P1, rather than directly > to P - would > the nature of P.P1s interface (required/provided) be affected by > whether BP > was a behaviour port or not? > > Alan. > > -----Original Message----- > From: Thomas Weigert [mailto:thomas.weigert@motorola.com] > Sent: 06 April 2004 12:14 > To: Moore, Alan; 'Thomas Weigert'; uml2ftf > Cc: bselic@ca.ibm.com > Subject: RE: ,cb,,cs, Proposals for ballot 12 (April 14) > > > Alan, > > I am sorry but I don't quite follow your question. Let me try > again: In the > situation below, let's call the connector between P and the > behavior port of > C "chan". If a message is sent from P along chan, it will be handled by C, > not forwarded to anywhere else even if there are other connectors to that > behavior port. > > Further imagine two parts Q1:C and Q2:D and a connector chan2 > between Q2 and > the behavior port of Q2 (remember that C is the type of Q1). Any > communication send along chan2 from Q2 will be handled by the > instance of C > that plays the part Q1, rather than by the instance that plays the part of > P. > > Hope this helps, Th. > > > -----Original Message----- > > From: Moore, Alan [mailto:AlanM@artisansw.com] > > Sent: Tuesday, April 06, 2004 3:04 AM > > To: 'Thomas Weigert'; uml2ftf > > Cc: bselic@ca.ibm.com > > Subject: RE: ,cb,,cs, Proposals for ballot 12 (April 14) > > > > > > Thomas, > > > > On 6669, I'm confused by your discussion, the text in the spec says: > > > > "Any invocation of a behavioral feature targeted at a behavior > > port will be > > handled by the instance of the owning classifier itself, rather > > than by any > > instances that this classifier may contain." > > > > and yet the example you quote: > > > > "Consider the situation where a part P of Classifier C is connected to a > > behavior port of C." > > > > seems to violate this because it implies that an invocation > targeted at a > > behaviour port of C is targeted at an instance, playing part P, > > contained in > > C. > > > > The only conclusion I can draw is that P may be connected to > the behaviour > > port of C but may not handle any invocations sent to that port. Can you > > clarify please? > > > > As an aside could you also clarify whether behaviour ports can > > have required > > interfaces? > > > > Alan. > > > > -----Original Message----- > > From: Thomas Weigert [mailto:thomas.weigert@motorola.com] > > Sent: 06 April 2004 05:28 > > To: uml2ftf > > Cc: bselic@ca.ibm.com > > Subject: RE: ,cb,,cs, Proposals for ballot 12 (April 14) > > > > > > Dear all, > > > > please find attached another installment of issue resolutions for both > > topics. > > > > Th. > > > > > -----Original Message----- > > > From: Thomas Weigert [mailto:Thomas.Weigert@motorola.com] > > > Sent: Tuesday, March 30, 2004 11:45 PM > > > To: uml2ftf > > > Cc: bselic@ca.ibm.com > > > Subject: ,cb,,cs, Proposals for ballot 12 (April 14) > > > > > > > > > Dear all, > > > > > > please find attached some proposed issue resolution from common > > > behavior and > > > composite structures. > > > > > > All the best, Th. > > > To: "Moore, Alan" Cc: "'Thomas Weigert'" , uml2ftf Subject: RE: ,cb,,cs, Proposals for ballot 12 (April 14) X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Wed, 7 Apr 2004 05:26:23 -0400 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 04/07/2004 05:26:25, Serialize complete at 04/07/2004 05:26:25 Alan, I am really not sure what the problem is. Here is the situation that you are talking about: If P sends a message m via chan to BP, and i1 (a provided interface of behavior port BP) is an operation or reception of i1, then that operation will be handled by the corresponding method of C. So far so good. If we remove i1 from BP, then message m will not be handled by BP because BP does not implement interface i1. So, clearly, it makes a difference. I don't see why you think it makes no difference? Can you please clarify? Cheers, Bran "Moore, Alan" 04/07/2004 04:13 AM To "'Thomas Weigert'" , uml2ftf cc Branislav Selic/Ottawa/IBM@IBMCA Subject RE: ,cb,,cs, Proposals for ballot 12 (April 14) OK. So I want to check a couple of points: 1. Is it possible for a behaviour port to have a required interface - yes, in fact it's shown on Figure 111 in the spec. 2. In the example quoted below, class C with behaviour port BP and part P, connected by connector chan. In the scenario you describe P sends a message , say m, to BP, which is forwarded to C. If the behavioural feature related to m is specified by interface I1, is the scenario you describe affected if BP requires I1, rather than provides I1? From what I can see, within the scope of the example there is no difference. Alan. -----Original Message----- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: 06 April 2004 13:21 To: Moore, Alan; 'Thomas Weigert'; uml2ftf Cc: bselic@ca.ibm.com Subject: RE: ,cb,,cs, Proposals for ballot 12 (April 14) Actually, in both examples we are dealing with provided interfaces, don't we? A behavior port is just like any other port with respect to its interfaces. But you are raising an interesting enhancement suggestion: Should the behavior port have its interfaces derived from the classifier it is a port on, if it has not been given explicit interfaces? In other words, if we omit the type of the behavior port, should we say that in that case it derives its interfaces from the classifier it is the behavior port of? This appears to be a convenient shortcut, albeit I am not sure how often these situations actually arise (probably most of the time we would limit the interfaces offered at the behavior port?). Bran, do you have any intuitions governing the above? Thanks, Th. > -----Original Message----- > From: Moore, Alan [mailto:AlanM@artisansw.com] > Sent: Tuesday, April 06, 2004 7:06 AM > To: 'Thomas Weigert'; uml2ftf > Cc: bselic@ca.ibm.com > Subject: RE: ,cb,,cs, Proposals for ballot 12 (April 14) > > > Interesting and I can see that it has a meaning and a use. I have a > supplementary question - does the behaviour port of C, let's call > it BP, in > case 1, have to have a required interface, because P requires features of > BP, or a provided interface because C offers features via BP? > > I assume the latter(provided), although if BP was not a behaviour > port then > it would be the former (required) - this seems a little odd - imagine if > chan was connected to BP via a port, P.P1, rather than directly > to P - would > the nature of P.P1s interface (required/provided) be affected by > whether BP > was a behaviour port or not? > > Alan. > > -----Original Message----- > From: Thomas Weigert [mailto:thomas.weigert@motorola.com] > Sent: 06 April 2004 12:14 > To: Moore, Alan; 'Thomas Weigert'; uml2ftf > Cc: bselic@ca.ibm.com > Subject: RE: ,cb,,cs, Proposals for ballot 12 (April 14) > > > Alan, > > I am sorry but I don't quite follow your question. Let me try > again: In the > situation below, let's call the connector between P and the > behavior port of > C "chan". If a message is sent from P along chan, it will be handled by C, > not forwarded to anywhere else even if there are other connectors to that > behavior port. > > Further imagine two parts Q1:C and Q2:D and a connector chan2 > between Q2 and > the behavior port of Q2 (remember that C is the type of Q1). Any > communication send along chan2 from Q2 will be handled by the > instance of C > that plays the part Q1, rather than by the instance that plays the part of > P. > > Hope this helps, Th. > > > -----Original Message----- > > From: Moore, Alan [mailto:AlanM@artisansw.com] > > Sent: Tuesday, April 06, 2004 3:04 AM > > To: 'Thomas Weigert'; uml2ftf > > Cc: bselic@ca.ibm.com > > Subject: RE: ,cb,,cs, Proposals for ballot 12 (April 14) > > > > > > Thomas, > > > > On 6669, I'm confused by your discussion, the text in the spec says: > > > > "Any invocation of a behavioral feature targeted at a behavior > > port will be > > handled by the instance of the owning classifier itself, rather > > than by any > > instances that this classifier may contain." > > > > and yet the example you quote: > > > > "Consider the situation where a part P of Classifier C is connected to a > > behavior port of C." > > > > seems to violate this because it implies that an invocation > targeted at a > > behaviour port of C is targeted at an instance, playing part P, > > contained in > > C. > > > > The only conclusion I can draw is that P may be connected to > the behaviour > > port of C but may not handle any invocations sent to that port. Can you > > clarify please? > > > > As an aside could you also clarify whether behaviour ports can > > have required > > interfaces? > > > > Alan. > > > > -----Original Message----- > > From: Thomas Weigert [mailto:thomas.weigert@motorola.com] > > Sent: 06 April 2004 05:28 > > To: uml2ftf > > Cc: bselic@ca.ibm.com > > Subject: RE: ,cb,,cs, Proposals for ballot 12 (April 14) > > > > > > Dear all, > > > > please find attached another installment of issue resolutions for both > > topics. > > > > Th. > > > > > -----Original Message----- > > > From: Thomas Weigert [mailto:Thomas.Weigert@motorola.com] > > > Sent: Tuesday, March 30, 2004 11:45 PM > > > To: uml2ftf > > > Cc: bselic@ca.ibm.com > > > Subject: ,cb,,cs, Proposals for ballot 12 (April 14) > > > > > > > > > Dear all, > > > > > > please find attached some proposed issue resolution from common > > > behavior and > > > composite structures. > > > > > > All the best, Th. > > > From: "Eran Gery" To: "'Moore, Alan'" , "'Branislav Selic'" Cc: Subject: RE: 4 statemachine resolutions for ballot 12 (11?) Date: Wed, 7 Apr 2004 12:45:34 +0300 X-Mailer: Microsoft Outlook CWS, Build 9.0.6604 (9.0.2911.0) Importance: Normal Alan - I do not see the issue and any contradiction between the two statements. Once you pass the bridge that the decision and junction are pseudo states and not actions,everything is fine. This is also explained in the text. Therefore the statement "all the graphical segments connecting action and trigger nodes map to a single transition" does not relate to choice and junction, only to the 3 trigger/action symbols mentioned in the paragraph. This is why it perfectly matches the interpretation of figure 395, where each one of the path from the choice to the junction map to a single transition (without a trigger), and the segment incoming the choice and leaving the junction are also transitions. Here are the instances of the metamodel in 395, I skipped some of the action/trigger instances and focused on the states/pseudo states/transition instances. idle: state instance t_req: a transition instance with a signal trigger "req", source: idle; target: choice1 choice1: a choice pseudo state instance t_minor: a transition instance with a guard [id<=10] and two activities: send minor and minorReq=id source: choice1; target: junction1 t_major: a transition instance with a guard [id>10] and two activities: send major and majorReq=id source: choice1; target: junction1 t_busy: a transition instance with no trigger/guard/action. source: junction1 target: busy busy: state instance Hope this clarifies this... Eran -----Original Message----- From: Moore, Alan [mailto:AlanM@artisansw.com] Sent: Wed, April 07, 2004 11:00 AM To: 'Eran Gery'; 'Branislav Selic' Cc: uml2-superstructure-ftf@omg.org Subject: RE: 4 statemachine resolutions for ballot 12 (11?) Hi Eran, Sorry but I'm not convinced - for example in the discussion you state: "Therefore, the answer to Alan's question is that all the graphical segments connecting action and trigger nodes map to a single transition" and then in a later section you state: "Therefore figure 395 consists of 4 transitions: from idle to the choice symbol, each of the branches of the choice through the junction symbol, and a transition from the junction to the busy state." I can't see how these two statements can be reconciled. What would convince me is a repository model for figure 395. Alan. -----Original Message----- From: Eran Gery [mailto:erang@ilogix.co.il] Sent: 06 April 2004 17:58 To: 'Moore, Alan'; 'Branislav Selic' Cc: uml2-superstructure-ftf@omg.org Subject: RE: 4 statemachine resolutions for ballot 12 (11?) Alan, The junction and choice symbols are NOT actions. They are pseudo state instances of the state machine. The source for the confusion is that this is an overloaded notation from activities. However none of these shared symbols is mapped to the semantics the same way in state machines. I added a paragraph at the end clarifying this. With this additional paragraph, I am convinced that your issue is now clarified. Yes, there is a subtlety regarding maping several transition symbols to the same transition, but I believe it is clarified in various places now to a reasonable degree. Eran p.s. Bran - a new candidate for Ballot 12... -----Original Message----- From: Moore, Alan [mailto:AlanM@artisansw.com] Sent: Tue, April 06, 2004 11:24 AM To: 'Eran Gery'; 'Branislav Selic' Cc: uml2-superstructure-ftf@omg.org; Guus Ramackers (E-mail) Subject: RE: 4 statemachine resolutions for ballot 12 (11?) Hi Eran, I have problems with your explanation as it relates to Fig 395. Most obvious is that you don't mention the junction and choice symbols - they can't be part of the action sequence and yet they are not activities in their own right, so what are they? The status of figure 395 is also dubious IMO because the only interpretation of the arrow symbols according to the Graphic Paths table is a transition, so the figure includes symbols that have an undefined interpretation according to the definition in the Diagrams section (15.4), which I assume is where everyone will look for an interpretation. Alan. -----Original Message----- From: Eran Gery [mailto:erang@ilogix.co.il] Sent: 04 April 2004 14:36 To: Moore, Alan; 'Branislav Selic' Cc: uml2-superstructure-ftf@omg.org; Guus Ramackers (E-mail) Subject: RE: 4 statemachine resolutions for ballot 12 (11?) Alan - I have further refined the text to address your comments. There were indeed several places where we used terms that could have been misleading. As to the multiple triggers issue - I have basically modifid the text such that the trigger/guard expression is denoted within the "signal receipt" symbol similar to the way it is denoted in regular (non "action-oriented" transitions). Therefore, it does not impose any additional constraint comparing to the "regular" notation. So I have essentially delagated the multiple trigger issue to the textual notation which is not part of this section. However, looking at that, this whole issue of denoting multiple triggers seems lacking/inconsistent and "deserves" another issue, which also involves common behaviors. Eran p.s. Bran - this is the current candidate to include in ballot 12 -----Original Message----- From: Moore, Alan [mailto:AlanM@artisansw.com] Sent: Sun, April 04, 2004 1:33 PM To: 'Eran Gery'; 'Branislav Selic'; Guus Ramackers (E-mail) Cc: uml2-superstructure-ftf@omg.org Subject: RE: 4 statemachine resolutions for ballot 12 (11?) Hi Eran, I have modified the document with some comments on my issue. Alan. -----Original Message----- From: Eran Gery [mailto:erang@ilogix.co.il] Sent: 30 March 2004 15:06 To: 'Branislav Selic'; Guus Ramackers (E-mail) Cc: uml2-superstructure-ftf@omg.org Subject: 4 statemachine resolutions for ballot 12 (11?) Bran/Guus Attached is a resolution prposal for 4 statemachine issues I originally intended for ballot 11, but since none of them is trivial, I thought at this point they better be submitted for discussion for ballot 12. However I'm fine submitting them to 11 if you find appropriate and/or nobody objects. Thanks, Eran From: "Moore, Alan" To: "'Eran Gery'" , "'Branislav Selic'" Cc: uml2-superstructure-ftf@omg.org Subject: RE: 4 statemachine resolutions for ballot 12 (11?) Date: Wed, 7 Apr 2004 12:13:57 +0100 X-Mailer: Internet Mail Service (5.5.2653.19) Eran, I understand now - and I can see that my initial interpretation was very different hence my confusion (I thought that the whole figure represented one transition). One last point, on fig 395 should the line segment from Idle to Req(id) have an arrow on it? Alan. -----Original Message----- From: Eran Gery [mailto:erang@ilogix.co.il] Sent: 07 April 2004 10:46 To: 'Moore, Alan'; 'Branislav Selic' Cc: uml2-superstructure-ftf@omg.org Subject: RE: 4 statemachine resolutions for ballot 12 (11?) Alan - I do not see the issue and any contradiction between the two statements. Once you pass the bridge that the decision and junction are pseudo states and not actions,everything is fine. This is also explained in the text. Therefore the statement "all the graphical segments connecting action and trigger nodes map to a single transition" does not relate to choice and junction, only to the 3 trigger/action symbols mentioned in the paragraph. This is why it perfectly matches the interpretation of figure 395, where each one of the path from the choice to the junction map to a single transition (without a trigger), and the segment incoming the choice and leaving the junction are also transitions. Here are the instances of the metamodel in 395, I skipped some of the action/trigger instances and focused on the states/pseudo states/transition instances. idle: state instance t_req: a transition instance with a signal trigger "req", source: idle; target: choice1 choice1: a choice pseudo state instance t_minor: a transition instance with a guard [id<=10] and two activities: send minor and minorReq=id source: choice1; target: junction1 t_major: a transition instance with a guard [id>10] and two activities: send major and majorReq=id source: choice1; target: junction1 t_busy: a transition instance with no trigger/guard/action. source: junction1 target: busy busy: state instance Hope this clarifies this... Eran -----Original Message----- From: Moore, Alan [mailto:AlanM@artisansw.com] Sent: Wed, April 07, 2004 11:00 AM To: 'Eran Gery'; 'Branislav Selic' Cc: uml2-superstructure-ftf@omg.org Subject: RE: 4 statemachine resolutions for ballot 12 (11?) Hi Eran, Sorry but I'm not convinced - for example in the discussion you state: "Therefore, the answer to Alan's question is that all the graphical segments connecting action and trigger nodes map to a single transition" and then in a later section you state: "Therefore figure 395 consists of 4 transitions: from idle to the choice symbol, each of the branches of the choice through the junction symbol, and a transition from the junction to the busy state." I can't see how these two statements can be reconciled. What would convince me is a repository model for figure 395. Alan. -----Original Message----- From: Eran Gery [mailto:erang@ilogix.co.il] Sent: 06 April 2004 17:58 To: 'Moore, Alan'; 'Branislav Selic' Cc: uml2-superstructure-ftf@omg.org Subject: RE: 4 statemachine resolutions for ballot 12 (11?) Alan, The junction and choice symbols are NOT actions. They are pseudo state instances of the state machine. The source for the confusion is that this is an overloaded notation from activities. However none of these shared symbols is mapped to the semantics the same way in state machines. I added a paragraph at the end clarifying this. With this additional paragraph, I am convinced that your issue is now clarified. Yes, there is a subtlety regarding maping several transition symbols to the same transition, but I believe it is clarified in various places now to a reasonable degree. Eran p.s. Bran - a new candidate for Ballot 12... -----Original Message----- From: Moore, Alan [mailto:AlanM@artisansw.com] Sent: Tue, April 06, 2004 11:24 AM To: 'Eran Gery'; 'Branislav Selic' Cc: uml2-superstructure-ftf@omg.org; Guus Ramackers (E-mail) Subject: RE: 4 statemachine resolutions for ballot 12 (11?) Hi Eran, I have problems with your explanation as it relates to Fig 395. Most obvious is that you don't mention the junction and choice symbols - they can't be part of the action sequence and yet they are not activities in their own right, so what are they? The status of figure 395 is also dubious IMO because the only interpretation of the arrow symbols according to the Graphic Paths table is a transition, so the figure includes symbols that have an undefined interpretation according to the definition in the Diagrams section (15.4), which I assume is where everyone will look for an interpretation. Alan. -----Original Message----- From: Eran Gery [mailto:erang@ilogix.co.il] Sent: 04 April 2004 14:36 To: Moore, Alan; 'Branislav Selic' Cc: uml2-superstructure-ftf@omg.org; Guus Ramackers (E-mail) Subject: RE: 4 statemachine resolutions for ballot 12 (11?) Alan - I have further refined the text to address your comments. There were indeed several places where we used terms that could have been misleading. As to the multiple triggers issue - I have basically modifid the text such that the trigger/guard expression is denoted within the "signal receipt" symbol similar to the way it is denoted in regular (non "action-oriented" transitions). Therefore, it does not impose any additional constraint comparing to the "regular" notation. So I have essentially delagated the multiple trigger issue to the textual notation which is not part of this section. However, looking at that, this whole issue of denoting multiple triggers seems lacking/inconsistent and "deserves" another issue, which also involves common behaviors. Eran p.s. Bran - this is the current candidate to include in ballot 12 -----Original Message----- From: Moore, Alan [mailto:AlanM@artisansw.com] Sent: Sun, April 04, 2004 1:33 PM To: 'Eran Gery'; 'Branislav Selic'; Guus Ramackers (E-mail) Cc: uml2-superstructure-ftf@omg.org Subject: RE: 4 statemachine resolutions for ballot 12 (11?) Hi Eran, I have modified the document with some comments on my issue. Alan. -----Original Message----- From: Eran Gery [mailto:erang@ilogix.co.il] Sent: 30 March 2004 15:06 To: 'Branislav Selic'; Guus Ramackers (E-mail) Cc: uml2-superstructure-ftf@omg.org Subject: 4 statemachine resolutions for ballot 12 (11?) Bran/Guus Attached is a resolution prposal for 4 statemachine issues I originally intended for ballot 11, but since none of them is trivial, I thought at this point they better be submitted for discussion for ballot 12. However I'm fine submitting them to 11 if you find appropriate and/or nobody objects. Thanks, Eran From: "Moore, Alan" To: "'Branislav Selic'" Cc: "'Thomas Weigert'" , uml2ftf Subject: RE: ,cb,,cs, Proposals for ballot 12 (April 14) Date: Wed, 7 Apr 2004 12:18:32 +0100 X-Mailer: Internet Mail Service (5.5.2653.19) Brean, Thanks for taking the time to draw the picture, which I should have done earlier. This wasn't quite what I meant - what I meant was would there be a difference if the i1 connected to BP was a cup rather than a ball and what would the difference be? Alan. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: 07 April 2004 10:26 To: Moore, Alan Cc: 'Thomas Weigert'; uml2ftf Subject: RE: ,cb,,cs, Proposals for ballot 12 (April 14) Alan, I am really not sure what the problem is. Here is the situation that you are talking about: If P sends a message m via chan to BP, and i1 (a provided interface of behavior port BP) is an operation or reception of i1, then that operation will be handled by the corresponding method of C. So far so good. If we remove i1 from BP, then message m will not be handled by BP because BP does not implement interface i1. So, clearly, it makes a difference. I don't see why you think it makes no difference? Can you please clarify? Cheers, Bran "Moore, Alan" 04/07/2004 04:13 AM To "'Thomas Weigert'" , uml2ftf cc Branislav Selic/Ottawa/IBM@IBMCA Subject RE: ,cb,,cs, Proposals for ballot 12 (April 14) OK. So I want to check a couple of points: 1. Is it possible for a behaviour port to have a required interface - yes, in fact it's shown on Figure 111 in the spec. 2. In the example quoted below, class C with behaviour port BP and part P, connected by connector chan. In the scenario you describe P sends a message , say m, to BP, which is forwarded to C. If the behavioural feature related to m is specified by interface I1, is the scenario you describe affected if BP requires I1, rather than provides I1? From what I can see, within the scope of the example there is no difference. Alan. -----Original Message----- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: 06 April 2004 13:21 To: Moore, Alan; 'Thomas Weigert'; uml2ftf Cc: bselic@ca.ibm.com Subject: RE: ,cb,,cs, Proposals for ballot 12 (April 14) Actually, in both examples we are dealing with provided interfaces, don't we? A behavior port is just like any other port with respect to its interfaces. But you are raising an interesting enhancement suggestion: Should the behavior port have its interfaces derived from the classifier it is a port on, if it has not been given explicit interfaces? In other words, if we omit the type of the behavior port, should we say that in that case it derives its interfaces from the classifier it is the behavior port of? This appears to be a convenient shortcut, albeit I am not sure how often these situations actually arise (probably most of the time we would limit the interfaces offered at the behavior port?). Bran, do you have any intuitions governing the above? Thanks, Th. > -----Original Message----- > From: Moore, Alan [mailto:AlanM@artisansw.com] > Sent: Tuesday, April 06, 2004 7:06 AM > To: 'Thomas Weigert'; uml2ftf > Cc: bselic@ca.ibm.com > Subject: RE: ,cb,,cs, Proposals for ballot 12 (April 14) > > > Interesting and I can see that it has a meaning and a use. I have a > supplementary question - does the behaviour port of C, let's call > it BP, in > case 1, have to have a required interface, because P requires features of > BP, or a provided interface because C offers features via BP? > > I assume the latter(provided), although if BP was not a behaviour > port then > it would be the former (required) - this seems a little odd - imagine if > chan was connected to BP via a port, P.P1, rather than directly > to P - would > the nature of P.P1s interface (required/provided) be affected by > whether BP > was a behaviour port or not? > > Alan. > > -----Original Message----- > From: Thomas Weigert [mailto:thomas.weigert@motorola.com] > Sent: 06 April 2004 12:14 > To: Moore, Alan; 'Thomas Weigert'; uml2ftf > Cc: bselic@ca.ibm.com > Subject: RE: ,cb,,cs, Proposals for ballot 12 (April 14) > > > Alan, > > I am sorry but I don't quite follow your question. Let me try > again: In the > situation below, let's call the connector between P and the > behavior port of > C "chan". If a message is sent from P along chan, it will be handled by C, > not forwarded to anywhere else even if there are other connectors to that > behavior port. > > Further imagine two parts Q1:C and Q2:D and a connector chan2 > between Q2 and > the behavior port of Q2 (remember that C is the type of Q1). Any > communication send along chan2 from Q2 will be handled by the > instance of C > that plays the part Q1, rather than by the instance that plays the part of > P. > > Hope this helps, Th. > > > -----Original Message----- > > From: Moore, Alan [mailto:AlanM@artisansw.com] > > Sent: Tuesday, April 06, 2004 3:04 AM > > To: 'Thomas Weigert'; uml2ftf > > Cc: bselic@ca.ibm.com > > Subject: RE: ,cb,,cs, Proposals for ballot 12 (April 14) > > > > > > Thomas, > > > > On 6669, I'm confused by your discussion, the text in the spec says: > > > > "Any invocation of a behavioral feature targeted at a behavior > > port will be > > handled by the instance of the owning classifier itself, rather > > than by any > > instances that this classifier may contain." > > > > and yet the example you quote: > > > > "Consider the situation where a part P of Classifier C is connected to a > > behavior port of C." > > > > seems to violate this because it implies that an invocation > targeted at a > > behaviour port of C is targeted at an instance, playing part P, > > contained in > > C. > > > > The only conclusion I can draw is that P may be connected to > the behaviour > > port of C but may not handle any invocations sent to that port. Can you > > clarify please? > > > > As an aside could you also clarify whether behaviour ports can > > have required > > interfaces? > > > > Alan. > > > > -----Original Message----- > > From: Thomas Weigert [mailto:thomas.weigert@motorola.com] > > Sent: 06 April 2004 05:28 > > To: uml2ftf > > Cc: bselic@ca.ibm.com > > Subject: RE: ,cb,,cs, Proposals for ballot 12 (April 14) > > > > > > Dear all, > > > > please find attached another installment of issue resolutions for both > > topics. > > > > Th. > > > > > -----Original Message----- > > > From: Thomas Weigert [mailto:Thomas.Weigert@motorola.com] > > > Sent: Tuesday, March 30, 2004 11:45 PM > > > To: uml2ftf > > > Cc: bselic@ca.ibm.com > > > Subject: ,cb,,cs, Proposals for ballot 12 (April 14) > > > > > > > > > Dear all, > > > > > > please find attached some proposed issue resolution from common > > > behavior and > > > composite structures. > > > > > > All the best, Th. > > > ATT65316.gif From: "Eran Gery" To: "'Moore, Alan'" , "'Branislav Selic'" Cc: Subject: RE: 4 statemachine resolutions for ballot 12 (11?) Date: Wed, 7 Apr 2004 14:52:32 +0300 X-Mailer: Microsoft Outlook CWS, Build 9.0.6604 (9.0.2911.0) Importance: Normal Alan - Yes it should. I will add it to the resolution. Thanks for persisting on this... I agree with you this area was lacking and confusing before we started that long journey... Eran -----Original Message----- From: Moore, Alan [mailto:AlanM@artisansw.com] Sent: Wed, April 07, 2004 2:14 PM To: 'Eran Gery'; 'Branislav Selic' Cc: uml2-superstructure-ftf@omg.org Subject: RE: 4 statemachine resolutions for ballot 12 (11?) Eran, I understand now - and I can see that my initial interpretation was very different hence my confusion (I thought that the whole figure represented one transition). One last point, on fig 395 should the line segment from Idle to Req(id) have an arrow on it? Alan. -----Original Message----- From: Eran Gery [mailto:erang@ilogix.co.il] Sent: 07 April 2004 10:46 To: 'Moore, Alan'; 'Branislav Selic' Cc: uml2-superstructure-ftf@omg.org Subject: RE: 4 statemachine resolutions for ballot 12 (11?) Alan - I do not see the issue and any contradiction between the two statements. Once you pass the bridge that the decision and junction are pseudo states and not actions,everything is fine. This is also explained in the text. Therefore the statement "all the graphical segments connecting action and trigger nodes map to a single transition" does not relate to choice and junction, only to the 3 trigger/action symbols mentioned in the paragraph. This is why it perfectly matches the interpretation of figure 395, where each one of the path from the choice to the junction map to a single transition (without a trigger), and the segment incoming the choice and leaving the junction are also transitions. Here are the instances of the metamodel in 395, I skipped some of the action/trigger instances and focused on the states/pseudo states/transition instances. idle: state instance t_req: a transition instance with a signal trigger "req", source: idle; target: choice1 choice1: a choice pseudo state instance t_minor: a transition instance with a guard [id<=10] and two activities: send minor and minorReq=id source: choice1; target: junction1 t_major: a transition instance with a guard [id>10] and two activities: send major and majorReq=id source: choice1; target: junction1 t_busy: a transition instance with no trigger/guard/action. source: junction1 target: busy busy: state instance Hope this clarifies this... Eran -----Original Message----- From: Moore, Alan [mailto:AlanM@artisansw.com] Sent: Wed, April 07, 2004 11:00 AM To: 'Eran Gery'; 'Branislav Selic' Cc: uml2-superstructure-ftf@omg.org Subject: RE: 4 statemachine resolutions for ballot 12 (11?) Hi Eran, Sorry but I'm not convinced - for example in the discussion you state: "Therefore, the answer to Alan's question is that all the graphical segments connecting action and trigger nodes map to a single transition" and then in a later section you state: "Therefore figure 395 consists of 4 transitions: from idle to the choice symbol, each of the branches of the choice through the junction symbol, and a transition from the junction to the busy state." I can't see how these two statements can be reconciled. What would convince me is a repository model for figure 395. Alan. -----Original Message----- From: Eran Gery [mailto:erang@ilogix.co.il] Sent: 06 April 2004 17:58 To: 'Moore, Alan'; 'Branislav Selic' Cc: uml2-superstructure-ftf@omg.org Subject: RE: 4 statemachine resolutions for ballot 12 (11?) Alan, The junction and choice symbols are NOT actions. They are pseudo state instances of the state machine. The source for the confusion is that this is an overloaded notation from activities. However none of these shared symbols is mapped to the semantics the same way in state machines. I added a paragraph at the end clarifying this. With this additional paragraph, I am convinced that your issue is now clarified. Yes, there is a subtlety regarding maping several transition symbols to the same transition, but I believe it is clarified in various places now to a reasonable degree. Eran p.s. Bran - a new candidate for Ballot 12... -----Original Message----- From: Moore, Alan [mailto:AlanM@artisansw.com] Sent: Tue, April 06, 2004 11:24 AM To: 'Eran Gery'; 'Branislav Selic' Cc: uml2-superstructure-ftf@omg.org; Guus Ramackers (E-mail) Subject: RE: 4 statemachine resolutions for ballot 12 (11?) Hi Eran, I have problems with your explanation as it relates to Fig 395. Most obvious is that you don't mention the junction and choice symbols - they can't be part of the action sequence and yet they are not activities in their own right, so what are they? The status of figure 395 is also dubious IMO because the only interpretation of the arrow symbols according to the Graphic Paths table is a transition, so the figure includes symbols that have an undefined interpretation according to the definition in the Diagrams section (15.4), which I assume is where everyone will look for an interpretation. Alan. -----Original Message----- From: Eran Gery [mailto:erang@ilogix.co.il] Sent: 04 April 2004 14:36 To: Moore, Alan; 'Branislav Selic' Cc: uml2-superstructure-ftf@omg.org; Guus Ramackers (E-mail) Subject: RE: 4 statemachine resolutions for ballot 12 (11?) Alan - I have further refined the text to address your comments. There were indeed several places where we used terms that could have been misleading. As to the multiple triggers issue - I have basically modifid the text such that the trigger/guard expression is denoted within the "signal receipt" symbol similar to the way it is denoted in regular (non "action-oriented" transitions). Therefore, it does not impose any additional constraint comparing to the "regular" notation. So I have essentially delagated the multiple trigger issue to the textual notation which is not part of this section. However, looking at that, this whole issue of denoting multiple triggers seems lacking/inconsistent and "deserves" another issue, which also involves common behaviors. Eran p.s. Bran - this is the current candidate to include in ballot 12 -----Original Message----- From: Moore, Alan [mailto:AlanM@artisansw.com] Sent: Sun, April 04, 2004 1:33 PM To: 'Eran Gery'; 'Branislav Selic'; Guus Ramackers (E-mail) Cc: uml2-superstructure-ftf@omg.org Subject: RE: 4 statemachine resolutions for ballot 12 (11?) Hi Eran, I have modified the document with some comments on my issue. Alan. -----Original Message----- From: Eran Gery [mailto:erang@ilogix.co.il] Sent: 30 March 2004 15:06 To: 'Branislav Selic'; Guus Ramackers (E-mail) Cc: uml2-superstructure-ftf@omg.org Subject: 4 statemachine resolutions for ballot 12 (11?) Bran/Guus Attached is a resolution prposal for 4 statemachine issues I originally intended for ballot 11, but since none of them is trivial, I thought at this point they better be submitted for discussion for ballot 12. However I'm fine submitting them to 11 if you find appropriate and/or nobody objects. Thanks, Eran To: "Moore, Alan" Cc: "'Thomas Weigert'" , uml2ftf Subject: RE: ,cb,,cs, Proposals for ballot 12 (April 14) X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Wed, 7 Apr 2004 08:09:16 -0400 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 04/07/2004 08:09:18, Serialize complete at 04/07/2004 08:09:18 The difference would be that an invocation of any operation or signal from P would fail, since BP does not offer any features. Bran "Moore, Alan" 04/07/2004 07:18 AM To Branislav Selic/Ottawa/IBM@IBMCA cc "'Thomas Weigert'" , uml2ftf Subject RE: ,cb,,cs, Proposals for ballot 12 (April 14) Brean, Thanks for taking the time to draw the picture, which I should have done earlier. This wasn't quite what I meant - what I meant was would there be a difference if the i1 connected to BP was a cup rather than a ball and what would the difference be? Alan. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: 07 April 2004 10:26 To: Moore, Alan Cc: 'Thomas Weigert'; uml2ftf Subject: RE: ,cb,,cs, Proposals for ballot 12 (April 14) Alan, I am really not sure what the problem is. Here is the situation that you are talking about: If P sends a message m via chan to BP, and i1 (a provided interface of behavior port BP) is an operation or reception of i1, then that operation will be handled by the corresponding method of C. So far so good. If we remove i1 from BP, then message m will not be handled by BP because BP does not implement interface i1. So, clearly, it makes a difference. I don't see why you think it makes no difference? Can you please clarify? Cheers, Bran "Moore, Alan" 04/07/2004 04:13 AM To "'Thomas Weigert'" , uml2ftf cc Branislav Selic/Ottawa/IBM@IBMCA Subject RE: ,cb,,cs, Proposals for ballot 12 (April 14) OK. So I want to check a couple of points: 1. Is it possible for a behaviour port to have a required interface - yes, in fact it's shown on Figure 111 in the spec. 2. In the example quoted below, class C with behaviour port BP and part P, connected by connector chan. In the scenario you describe P sends a message , say m, to BP, which is forwarded to C. If the behavioural feature related to m is specified by interface I1, is the scenario you describe affected if BP requires I1, rather than provides I1? From what I can see, within the scope of the example there is no difference. Alan. -----Original Message----- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: 06 April 2004 13:21 To: Moore, Alan; 'Thomas Weigert'; uml2ftf Cc: bselic@ca.ibm.com Subject: RE: ,cb,,cs, Proposals for ballot 12 (April 14) Actually, in both examples we are dealing with provided interfaces, don't we? A behavior port is just like any other port with respect to its interfaces. But you are raising an interesting enhancement suggestion: Should the behavior port have its interfaces derived from the classifier it is a port on, if it has not been given explicit interfaces? In other words, if we omit the type of the behavior port, should we say that in that case it derives its interfaces from the classifier it is the behavior port of? This appears to be a convenient shortcut, albeit I am not sure how often these situations actually arise (probably most of the time we would limit the interfaces offered at the behavior port?). Bran, do you have any intuitions governing the above? Thanks, Th. > -----Original Message----- > From: Moore, Alan [mailto:AlanM@artisansw.com] > Sent: Tuesday, April 06, 2004 7:06 AM > To: 'Thomas Weigert'; uml2ftf > Cc: bselic@ca.ibm.com > Subject: RE: ,cb,,cs, Proposals for ballot 12 (April 14) > > > Interesting and I can see that it has a meaning and a use. I have a > supplementary question - does the behaviour port of C, let's call > it BP, in > case 1, have to have a required interface, because P requires features of > BP, or a provided interface because C offers features via BP? > > I assume the latter(provided), although if BP was not a behaviour > port then > it would be the former (required) - this seems a little odd - imagine if > chan was connected to BP via a port, P.P1, rather than directly > to P - would > the nature of P.P1s interface (required/provided) be affected by > whether BP > was a behaviour port or not? > > Alan. > > -----Original Message----- > From: Thomas Weigert [mailto:thomas.weigert@motorola.com] > Sent: 06 April 2004 12:14 > To: Moore, Alan; 'Thomas Weigert'; uml2ftf > Cc: bselic@ca.ibm.com > Subject: RE: ,cb,,cs, Proposals for ballot 12 (April 14) > > > Alan, > > I am sorry but I don't quite follow your question. Let me try > again: In the > situation below, let's call the connector between P and the > behavior port of > C "chan". If a message is sent from P along chan, it will be handled by C, > not forwarded to anywhere else even if there are other connectors to that > behavior port. > > Further imagine two parts Q1:C and Q2:D and a connector chan2 > between Q2 and > the behavior port of Q2 (remember that C is the type of Q1). Any > communication send along chan2 from Q2 will be handled by the > instance of C > that plays the part Q1, rather than by the instance that plays the part of > P. > > Hope this helps, Th. > > > -----Original Message----- > > From: Moore, Alan [mailto:AlanM@artisansw.com] > > Sent: Tuesday, April 06, 2004 3:04 AM > > To: 'Thomas Weigert'; uml2ftf > > Cc: bselic@ca.ibm.com > > Subject: RE: ,cb,,cs, Proposals for ballot 12 (April 14) > > > > > > Thomas, > > > > On 6669, I'm confused by your discussion, the text in the spec says: > > > > "Any invocation of a behavioral feature targeted at a behavior > > port will be > > handled by the instance of the owning classifier itself, rather > > than by any > > instances that this classifier may contain." > > > > and yet the example you quote: > > > > "Consider the situation where a part P of Classifier C is connected to a > > behavior port of C." > > > > seems to violate this because it implies that an invocation > targeted at a > > behaviour port of C is targeted at an instance, playing part P, > > contained in > > C. > > > > The only conclusion I can draw is that P may be connected to > the behaviour > > port of C but may not handle any invocations sent to that port. Can you > > clarify please? > > > > As an aside could you also clarify whether behaviour ports can > > have required > > interfaces? > > > > Alan. > > > > -----Original Message----- > > From: Thomas Weigert [mailto:thomas.weigert@motorola.com] > > Sent: 06 April 2004 05:28 > > To: uml2ftf > > Cc: bselic@ca.ibm.com > > Subject: RE: ,cb,,cs, Proposals for ballot 12 (April 14) > > > > > > Dear all, > > > > please find attached another installment of issue resolutions for both > > topics. > > > > Th. > > > > > -----Original Message----- > > > From: Thomas Weigert [mailto:Thomas.Weigert@motorola.com] > > > Sent: Tuesday, March 30, 2004 11:45 PM > > > To: uml2ftf > > > Cc: bselic@ca.ibm.com > > > Subject: ,cb,,cs, Proposals for ballot 12 (April 14) > > > > > > > > > Dear all, > > > > > > please find attached some proposed issue resolution from common > > > behavior and > > > composite structures. > > > > > > All the best, Th. > > > [attachment "ATT65316.gif" deleted by Branislav Selic/Ottawa/IBM] From: "Thomas Weigert" To: "Moore, Alan" , "'Branislav Selic'" Cc: "'Thomas Weigert'" , "uml2ftf" Subject: RE: ,cb,,cs, Proposals for ballot 12 (April 14) Date: Wed, 7 Apr 2004 07:09:21 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal If you were to change i1 on BP to a required interface, then you would state that BP would be sending the messages supported by the interface. But you want to receive them at BP, so this does not really make much sense. Th. -----Original Message----- From: Moore, Alan [mailto:AlanM@artisansw.com] Sent: Wednesday, April 07, 2004 6:19 AM To: 'Branislav Selic' Cc: 'Thomas Weigert'; uml2ftf Subject: RE: ,cb,,cs, Proposals for ballot 12 (April 14) Brean, Thanks for taking the time to draw the picture, which I should have done earlier. This wasn't quite what I meant - what I meant was would there be a difference if the i1 connected to BP was a cup rather than a ball and what would the difference be? Alan. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: 07 April 2004 10:26 To: Moore, Alan Cc: 'Thomas Weigert'; uml2ftf Subject: RE: ,cb,,cs, Proposals for ballot 12 (April 14) Alan, I am really not sure what the problem is. Here is the situation that you are talking about: If P sends a message m via chan to BP, and i1 (a provided interface of behavior port BP) is an operation or reception of i1, then that operation will be handled by the corresponding method of C. So far so good. If we remove i1 from BP, then message m will not be handled by BP because BP does not implement interface i1. So, clearly, it makes a difference. I don't see why you think it makes no difference? Can you please clarify? Cheers, Bran "Moore, Alan" 04/07/2004 04:13 AM To "'Thomas Weigert'" , uml2ftf cc Branislav Selic/Ottawa/IBM@IBMCA Subject RE: ,cb,,cs, Proposals for ballot 12 (April 14) OK. So I want to check a couple of points: 1. Is it possible for a behaviour port to have a required interface - yes, in fact it's shown on Figure 111 in the spec. 2. In the example quoted below, class C with behaviour port BP and part P, connected by connector chan. In the scenario you describe P sends a message , say m, to BP, which is forwarded to C. If the behavioural feature related to m is specified by interface I1, is the scenario you describe affected if BP requires I1, rather than provides I1? From what I can see, within the scope of the example there is no difference. Alan. -----Original Message----- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: 06 April 2004 13:21 To: Moore, Alan; 'Thomas Weigert'; uml2ftf Cc: bselic@ca.ibm.com Subject: RE: ,cb,,cs, Proposals for ballot 12 (April 14) Actually, in both examples we are dealing with provided interfaces, don't we? A behavior port is just like any other port with respect to its interfaces. But you are raising an interesting enhancement suggestion: Should the behavior port have its interfaces derived from the classifier it is a port on, if it has not been given explicit interfaces? In other words, if we omit the type of the behavior port, should we say that in that case it derives its interfaces from the classifier it is the behavior port of? This appears to be a convenient shortcut, albeit I am not sure how often these situations actually arise (probably most of the time we would limit the interfaces offered at the behavior port?). Bran, do you have any intuitions governing the above? Thanks, Th. > -----Original Message----- > From: Moore, Alan [mailto:AlanM@artisansw.com] > Sent: Tuesday, April 06, 2004 7:06 AM > To: 'Thomas Weigert'; uml2ftf > Cc: bselic@ca.ibm.com > Subject: RE: ,cb,,cs, Proposals for ballot 12 (April 14) > > > Interesting and I can see that it has a meaning and a use. I have a > supplementary question - does the behaviour port of C, let's call > it BP, in > case 1, have to have a required interface, because P requires features of > BP, or a provided interface because C offers features via BP? > > I assume the latter(provided), although if BP was not a behaviour > port then > it would be the former (required) - this seems a little odd - imagine if > chan was connected to BP via a port, P.P1, rather than directly > to P - would > the nature of P.P1s interface (required/provided) be affected by > whether BP > was a behaviour port or not? > > Alan. > > -----Original Message----- > From: Thomas Weigert [mailto:thomas.weigert@motorola.com] > Sent: 06 April 2004 12:14 > To: Moore, Alan; 'Thomas Weigert'; uml2ftf > Cc: bselic@ca.ibm.com > Subject: RE: ,cb,,cs, Proposals for ballot 12 (April 14) > > > Alan, > > I am sorry but I don't quite follow your question. Let me try > again: In the > situation below, let's call the connector between P and the > behavior port of > C "chan". If a message is sent from P along chan, it will be handled by C, > not forwarded to anywhere else even if there are other connectors to that > behavior port. > > Further imagine two parts Q1:C and Q2:D and a connector chan2 > between Q2 and > the behavior port of Q2 (remember that C is the type of Q1). Any > communication send along chan2 from Q2 will be handled by the > instance of C > that plays the part Q1, rather than by the instance that plays the part of > P. > > Hope this helps, Th. > > > -----Original Message----- > > From: Moore, Alan [mailto:AlanM@artisansw.com] > > Sent: Tuesday, April 06, 2004 3:04 AM > > To: 'Thomas Weigert'; uml2ftf > > Cc: bselic@ca.ibm.com > > Subject: RE: ,cb,,cs, Proposals for ballot 12 (April 14) > > > > > > Thomas, > > > > On 6669, I'm confused by your discussion, the text in the spec says: > > > > "Any invocation of a behavioral feature targeted at a behavior > > port will be > > handled by the instance of the owning classifier itself, rather > > than by any > > instances that this classifier may contain." > > > > and yet the example you quote: > > > > "Consider the situation where a part P of Classifier C is connected to a > > behavior port of C." > > > > seems to violate this because it implies that an invocation > targeted at a > > behaviour port of C is targeted at an instance, playing part P, > > contained in > > C. > > > > The only conclusion I can draw is that P may be connected to > the behaviour > > port of C but may not handle any invocations sent to that port. Can you > > clarify please? > > > > As an aside could you also clarify whether behaviour ports can > > have required > > interfaces? > > > > Alan. > > > > -----Original Message----- > > From: Thomas Weigert [mailto:thomas.weigert@motorola.com] > > Sent: 06 April 2004 05:28 > > To: uml2ftf > > Cc: bselic@ca.ibm.com > > Subject: RE: ,cb,,cs, Proposals for ballot 12 (April 14) > > > > > > Dear all, > > > > please find attached another installment of issue resolutions for both > > topics. > > > > Th. > > > > > -----Original Message----- > > > From: Thomas Weigert [mailto:Thomas.Weigert@motorola.com] > > > Sent: Tuesday, March 30, 2004 11:45 PM > > > To: uml2ftf > > > Cc: bselic@ca.ibm.com > > > Subject: ,cb,,cs, Proposals for ballot 12 (April 14) > > > > > > > > > Dear all, > > > > > > please find attached some proposed issue resolution from common > > > behavior and > > > composite structures. > > > > > > All the best, Th. > > > From: "Moore, Alan" To: "'Thomas Weigert'" , "'Branislav Selic'" Cc: uml2ftf Subject: RE: ,cb,,cs, Proposals for ballot 12 (April 14) Date: Wed, 7 Apr 2004 13:20:06 +0100 X-Mailer: Internet Mail Service (5.5.2653.19) The spec says this for isBehaviour (p168): " Specifies whether requests arriving at this port are sent to the classifier behavior of this classifier (see "BehavioredClassifier (from BasicBehaviors)" on page 383). Such ports are referred to as behavior port. Any invocation of a behavioral feature targeted at a behavior port will be handled by the instance of the owning classifier itself, rather than by any instances that this classifier may contain. The default value is false." I assume that it should talk about invocations for behavioural features that the port provides, as distinct from requires - this is a minor point. Another interpretation is that they're sent (i.e. the description above is accurate) but thrown away. Second point is under what circumstances does a required interface on a behaviour port (fig 111) make sense? I can't find anywhere that explains this. Does is act as a normal port? Alan. -----Original Message----- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: 07 April 2004 13:09 To: Moore, Alan; 'Branislav Selic' Cc: 'Thomas Weigert'; uml2ftf Subject: RE: ,cb,,cs, Proposals for ballot 12 (April 14) If you were to change i1 on BP to a required interface, then you would state that BP would be sending the messages supported by the interface. But you want to receive them at BP, so this does not really make much sense. Th. -----Original Message----- From: Moore, Alan [mailto:AlanM@artisansw.com] Sent: Wednesday, April 07, 2004 6:19 AM To: 'Branislav Selic' Cc: 'Thomas Weigert'; uml2ftf Subject: RE: ,cb,,cs, Proposals for ballot 12 (April 14) Brean, Thanks for taking the time to draw the picture, which I should have done earlier. This wasn't quite what I meant - what I meant was would there be a difference if the i1 connected to BP was a cup rather than a ball and what would the difference be? Alan. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: 07 April 2004 10:26 To: Moore, Alan Cc: 'Thomas Weigert'; uml2ftf Subject: RE: ,cb,,cs, Proposals for ballot 12 (April 14) Alan, I am really not sure what the problem is. Here is the situation that you are talking about: If P sends a message m via chan to BP, and i1 (a provided interface of behavior port BP) is an operation or reception of i1, then that operation will be handled by the corresponding method of C. So far so good. If we remove i1 from BP, then message m will not be handled by BP because BP does not implement interface i1. So, clearly, it makes a difference. I don't see why you think it makes no difference? Can you please clarify? Cheers, Bran "Moore, Alan" 04/07/2004 04:13 AM To "'Thomas Weigert'" , uml2ftf cc Branislav Selic/Ottawa/IBM@IBMCA Subject RE: ,cb,,cs, Proposals for ballot 12 (April 14) OK. So I want to check a couple of points: 1. Is it possible for a behaviour port to have a required interface - yes, in fact it's shown on Figure 111 in the spec. 2. In the example quoted below, class C with behaviour port BP and part P, connected by connector chan. In the scenario you describe P sends a message , say m, to BP, which is forwarded to C. If the behavioural feature related to m is specified by interface I1, is the scenario you describe affected if BP requires I1, rather than provides I1? From what I can see, within the scope of the example there is no difference. Alan. -----Original Message----- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: 06 April 2004 13:21 To: Moore, Alan; 'Thomas Weigert'; uml2ftf Cc: bselic@ca.ibm.com Subject: RE: ,cb,,cs, Proposals for ballot 12 (April 14) Actually, in both examples we are dealing with provided interfaces, don't we? A behavior port is just like any other port with respect to its interfaces. But you are raising an interesting enhancement suggestion: Should the behavior port have its interfaces derived from the classifier it is a port on, if it has not been given explicit interfaces? In other words, if we omit the type of the behavior port, should we say that in that case it derives its interfaces from the classifier it is the behavior port of? This appears to be a convenient shortcut, albeit I am not sure how often these situations actually arise (probably most of the time we would limit the interfaces offered at the behavior port?). Bran, do you have any intuitions governing the above? Thanks, Th. > -----Original Message----- > From: Moore, Alan [mailto:AlanM@artisansw.com] > Sent: Tuesday, April 06, 2004 7:06 AM > To: 'Thomas Weigert'; uml2ftf > Cc: bselic@ca.ibm.com > Subject: RE: ,cb,,cs, Proposals for ballot 12 (April 14) > > > Interesting and I can see that it has a meaning and a use. I have a > supplementary question - does the behaviour port of C, let's call > it BP, in > case 1, have to have a required interface, because P requires features of > BP, or a provided interface because C offers features via BP? > > I assume the latter(provided), although if BP was not a behaviour > port then > it would be the former (required) - this seems a little odd - imagine if > chan was connected to BP via a port, P.P1, rather than directly > to P - would > the nature of P.P1s interface (required/provided) be affected by > whether BP > was a behaviour port or not? > > Alan. > > -----Original Message----- > From: Thomas Weigert [mailto:thomas.weigert@motorola.com] > Sent: 06 April 2004 12:14 > To: Moore, Alan; 'Thomas Weigert'; uml2ftf > Cc: bselic@ca.ibm.com > Subject: RE: ,cb,,cs, Proposals for ballot 12 (April 14) > > > Alan, > > I am sorry but I don't quite follow your question. Let me try > again: In the > situation below, let's call the connector between P and the > behavior port of > C "chan". If a message is sent from P along chan, it will be handled by C, > not forwarded to anywhere else even if there are other connectors to that > behavior port. > > Further imagine two parts Q1:C and Q2:D and a connector chan2 > between Q2 and > the behavior port of Q2 (remember that C is the type of Q1). Any > communication send along chan2 from Q2 will be handled by the > instance of C > that plays the part Q1, rather than by the instance that plays the part of > P. > > Hope this helps, Th. > > > -----Original Message----- > > From: Moore, Alan [mailto:AlanM@artisansw.com] > > Sent: Tuesday, April 06, 2004 3:04 AM > > To: 'Thomas Weigert'; uml2ftf > > Cc: bselic@ca.ibm.com > > Subject: RE: ,cb,,cs, Proposals for ballot 12 (April 14) > > > > > > Thomas, > > > > On 6669, I'm confused by your discussion, the text in the spec says: > > > > "Any invocation of a behavioral feature targeted at a behavior > > port will be > > handled by the instance of the owning classifier itself, rather > > than by any > > instances that this classifier may contain." > > > > and yet the example you quote: > > > > "Consider the situation where a part P of Classifier C is connected to a > > behavior port of C." > > > > seems to violate this because it implies that an invocation > targeted at a > > behaviour port of C is targeted at an instance, playing part P, > > contained in > > C. > > > > The only conclusion I can draw is that P may be connected to > the behaviour > > port of C but may not handle any invocations sent to that port. Can you > > clarify please? > > > > As an aside could you also clarify whether behaviour ports can > > have required > > interfaces? > > > > Alan. > > > > -----Original Message----- > > From: Thomas Weigert [mailto:thomas.weigert@motorola.com] > > Sent: 06 April 2004 05:28 > > To: uml2ftf > > Cc: bselic@ca.ibm.com > > Subject: RE: ,cb,,cs, Proposals for ballot 12 (April 14) > > > > > > Dear all, > > > > please find attached another installment of issue resolutions for both > > topics. > > > > Th. > > > > > -----Original Message----- > > > From: Thomas Weigert [mailto:Thomas.Weigert@motorola.com] > > > Sent: Tuesday, March 30, 2004 11:45 PM > > > To: uml2ftf > > > Cc: bselic@ca.ibm.com > > > Subject: ,cb,,cs, Proposals for ballot 12 (April 14) > > > > > > > > > Dear all, > > > > > > please find attached some proposed issue resolution from common > > > behavior and > > > composite structures. > > > > > > All the best, Th. > > > ATT653161.gif From: "Thomas Weigert" To: "Moore, Alan" , "'Thomas Weigert'" , "'Branislav Selic'" Cc: "uml2ftf" Subject: RE: ,cb,,cs, Proposals for ballot 12 (April 14) Date: Wed, 7 Apr 2004 07:55:54 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal Alan, I am so sorry but I just don't understand what your questions are asking. Obviously a behavior port is a port, so everything that is said about port also applies to behavior port, unless stated otherwise. The only difference with behavior ports is regarding the routing when you send to it. Th. -----Original Message----- From: Moore, Alan [mailto:AlanM@artisansw.com] Sent: Wednesday, April 07, 2004 7:20 AM To: 'Thomas Weigert'; 'Branislav Selic' Cc: uml2ftf Subject: RE: ,cb,,cs, Proposals for ballot 12 (April 14) The spec says this for isBehaviour (p168): " Specifies whether requests arriving at this port are sent to the classifier behavior of this classifier (see "BehavioredClassifier (from BasicBehaviors)" on page 383). Such ports are referred to as behavior port. Any invocation of a behavioral feature targeted at a behavior port will be handled by the instance of the owning classifier itself, rather than by any instances that this classifier may contain. The default value is false." I assume that it should talk about invocations for behavioural features that the port provides, as distinct from requires - this is a minor point. Another interpretation is that they're sent (i.e. the description above is accurate) but thrown away. Second point is under what circumstances does a required interface on a behaviour port (fig 111) make sense? I can't find anywhere that explains this. Does is act as a normal port? Alan. -----Original Message----- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: 07 April 2004 13:09 To: Moore, Alan; 'Branislav Selic' Cc: 'Thomas Weigert'; uml2ftf Subject: RE: ,cb,,cs, Proposals for ballot 12 (April 14) If you were to change i1 on BP to a required interface, then you would state that BP would be sending the messages supported by the interface. But you want to receive them at BP, so this does not really make much sense. Th. -----Original Message----- From: Moore, Alan [mailto:AlanM@artisansw.com] Sent: Wednesday, April 07, 2004 6:19 AM To: 'Branislav Selic' Cc: 'Thomas Weigert'; uml2ftf Subject: RE: ,cb,,cs, Proposals for ballot 12 (April 14) Brean, Thanks for taking the time to draw the picture, which I should have done earlier. This wasn't quite what I meant - what I meant was would there be a difference if the i1 connected to BP was a cup rather than a ball and what would the difference be? Alan. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: 07 April 2004 10:26 To: Moore, Alan Cc: 'Thomas Weigert'; uml2ftf Subject: RE: ,cb,,cs, Proposals for ballot 12 (April 14) Alan, I am really not sure what the problem is. Here is the situation that you are talking about: If P sends a message m via chan to BP, and i1 (a provided interface of behavior port BP) is an operation or reception of i1, then that operation will be handled by the corresponding method of C. So far so good. If we remove i1 from BP, then message m will not be handled by BP because BP does not implement interface i1. So, clearly, it makes a difference. I don't see why you think it makes no difference? Can you please clarify? Cheers, Bran "Moore, Alan" 04/07/2004 04:13 AM To "'Thomas Weigert'" , uml2ftf cc Branislav Selic/Ottawa/IBM@IBMCA Subject RE: ,cb,,cs, Proposals for ballot 12 (April 14) OK. So I want to check a couple of points: 1. Is it possible for a behaviour port to have a required interface - yes, in fact it's shown on Figure 111 in the spec. 2. In the example quoted below, class C with behaviour port BP and part P, connected by connector chan. In the scenario you describe P sends a message , say m, to BP, which is forwarded to C. If the behavioural feature related to m is specified by interface I1, is the scenario you describe affected if BP requires I1, rather than provides I1? From what I can see, within the scope of the example there is no difference. Alan. -----Original Message----- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: 06 April 2004 13:21 To: Moore, Alan; 'Thomas Weigert'; uml2ftf Cc: bselic@ca.ibm.com Subject: RE: ,cb,,cs, Proposals for ballot 12 (April 14) Actually, in both examples we are dealing with provided interfaces, don't we? A behavior port is just like any other port with respect to its interfaces. But you are raising an interesting enhancement suggestion: Should the behavior port have its interfaces derived from the classifier it is a port on, if it has not been given explicit interfaces? In other words, if we omit the type of the behavior port, should we say that in that case it derives its interfaces from the classifier it is the behavior port of? This appears to be a convenient shortcut, albeit I am not sure how often these situations actually arise (probably most of the time we would limit the interfaces offered at the behavior port?). Bran, do you have any intuitions governing the above? Thanks, Th. > -----Original Message----- > From: Moore, Alan [mailto:AlanM@artisansw.com] > Sent: Tuesday, April 06, 2004 7:06 AM > To: 'Thomas Weigert'; uml2ftf > Cc: bselic@ca.ibm.com > Subject: RE: ,cb,,cs, Proposals for ballot 12 (April 14) > > > Interesting and I can see that it has a meaning and a use. I have a > supplementary question - does the behaviour port of C, let's call > it BP, in > case 1, have to have a required interface, because P requires features of > BP, or a provided interface because C offers features via BP? > > I assume the latter(provided), although if BP was not a behaviour > port then > it would be the former (required) - this seems a little odd - imagine if > chan was connected to BP via a port, P.P1, rather than directly > to P - would > the nature of P.P1s interface (required/provided) be affected by > whether BP > was a behaviour port or not? > > Alan. > > -----Original Message----- > From: Thomas Weigert [mailto:thomas.weigert@motorola.com] > Sent: 06 April 2004 12:14 > To: Moore, Alan; 'Thomas Weigert'; uml2ftf > Cc: bselic@ca.ibm.com > Subject: RE: ,cb,,cs, Proposals for ballot 12 (April 14) > > > Alan, > > I am sorry but I don't quite follow your question. Let me try > again: In the > situation below, let's call the connector between P and the > behavior port of > C "chan". If a message is sent from P along chan, it will be handled by C, > not forwarded to anywhere else even if there are other connectors to that > behavior port. > > Further imagine two parts Q1:C and Q2:D and a connector chan2 > between Q2 and > the behavior port of Q2 (remember that C is the type of Q1). Any > communication send along chan2 from Q2 will be handled by the > instance of C > that plays the part Q1, rather than by the instance that plays the part of > P. > > Hope this helps, Th. > > > -----Original Message----- > > From: Moore, Alan [mailto:AlanM@artisansw.com] > > Sent: Tuesday, April 06, 2004 3:04 AM > > To: 'Thomas Weigert'; uml2ftf > > Cc: bselic@ca.ibm.com > > Subject: RE: ,cb,,cs, Proposals for ballot 12 (April 14) > > > > > > Thomas, > > > > On 6669, I'm confused by your discussion, the text in the spec says: > > > > "Any invocation of a behavioral feature targeted at a behavior > > port will be > > handled by the instance of the owning classifier itself, rather > > than by any > > instances that this classifier may contain." > > > > and yet the example you quote: > > > > "Consider the situation where a part P of Classifier C is connected to a > > behavior port of C." > > > > seems to violate this because it implies that an invocation > targeted at a > > behaviour port of C is targeted at an instance, playing part P, > > contained in > > C. > > > > The only conclusion I can draw is that P may be connected to > the behaviour > > port of C but may not handle any invocations sent to that port. Can you > > clarify please? > > > > As an aside could you also clarify whether behaviour ports can > > have required > > interfaces? > > > > Alan. > > > > -----Original Message----- > > From: Thomas Weigert [mailto:thomas.weigert@motorola.com] > > Sent: 06 April 2004 05:28 > > To: uml2ftf > > Cc: bselic@ca.ibm.com > > Subject: RE: ,cb,,cs, Proposals for ballot 12 (April 14) > > > > > > Dear all, > > > > please find attached another installment of issue resolutions for both > > topics. > > > > Th. > > > > > -----Original Message----- > > > From: Thomas Weigert [mailto:Thomas.Weigert@motorola.com] > > > Sent: Tuesday, March 30, 2004 11:45 PM > > > To: uml2ftf > > > Cc: bselic@ca.ibm.com > > > Subject: ,cb,,cs, Proposals for ballot 12 (April 14) > > > > > > > > > Dear all, > > > > > > please find attached some proposed issue resolution from common > > > behavior and > > > composite structures. > > > > > > All the best, Th. > > > From: "Moore, Alan" To: "'Thomas Weigert'" , "'Branislav Selic'" Cc: uml2ftf Subject: RE: ,cb,,cs, Proposals for ballot 12 (April 14) Date: Wed, 7 Apr 2004 14:29:58 +0100 X-Mailer: Internet Mail Service (5.5.2653.19) Dear Thomas, Perhaps this question will clarify - In Bran's picture, if BP required rather than provided i1, would P be able to send m along chan? The answer I assume is yes. If the answer is yes then what does BP do with m when it receives it? Alan. -----Original Message----- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: 07 April 2004 13:56 To: Moore, Alan; 'Thomas Weigert'; 'Branislav Selic' Cc: uml2ftf Subject: RE: ,cb,,cs, Proposals for ballot 12 (April 14) Alan, I am so sorry but I just don't understand what your questions are asking. Obviously a behavior port is a port, so everything that is said about port also applies to behavior port, unless stated otherwise. The only difference with behavior ports is regarding the routing when you send to it. Th. -----Original Message----- From: Moore, Alan [mailto:AlanM@artisansw.com] Sent: Wednesday, April 07, 2004 7:20 AM To: 'Thomas Weigert'; 'Branislav Selic' Cc: uml2ftf Subject: RE: ,cb,,cs, Proposals for ballot 12 (April 14) The spec says this for isBehaviour (p168): " Specifies whether requests arriving at this port are sent to the classifier behavior of this classifier (see "BehavioredClassifier (from BasicBehaviors)" on page 383). Such ports are referred to as behavior port. Any invocation of a behavioral feature targeted at a behavior port will be handled by the instance of the owning classifier itself, rather than by any instances that this classifier may contain. The default value is false." I assume that it should talk about invocations for behavioural features that the port provides, as distinct from requires - this is a minor point. Another interpretation is that they're sent (i.e. the description above is accurate) but thrown away. Second point is under what circumstances does a required interface on a behaviour port (fig 111) make sense? I can't find anywhere that explains this. Does is act as a normal port? Alan. -----Original Message----- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: 07 April 2004 13:09 To: Moore, Alan; 'Branislav Selic' Cc: 'Thomas Weigert'; uml2ftf Subject: RE: ,cb,,cs, Proposals for ballot 12 (April 14) If you were to change i1 on BP to a required interface, then you would state that BP would be sending the messages supported by the interface. But you want to receive them at BP, so this does not really make much sense. Th. -----Original Message----- From: Moore, Alan [mailto:AlanM@artisansw.com] Sent: Wednesday, April 07, 2004 6:19 AM To: 'Branislav Selic' Cc: 'Thomas Weigert'; uml2ftf Subject: RE: ,cb,,cs, Proposals for ballot 12 (April 14) Brean, Thanks for taking the time to draw the picture, which I should have done earlier. This wasn't quite what I meant - what I meant was would there be a difference if the i1 connected to BP was a cup rather than a ball and what would the difference be? Alan. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: 07 April 2004 10:26 To: Moore, Alan Cc: 'Thomas Weigert'; uml2ftf Subject: RE: ,cb,,cs, Proposals for ballot 12 (April 14) Alan, I am really not sure what the problem is. Here is the situation that you are talking about: If P sends a message m via chan to BP, and i1 (a provided interface of behavior port BP) is an operation or reception of i1, then that operation will be handled by the corresponding method of C. So far so good. If we remove i1 from BP, then message m will not be handled by BP because BP does not implement interface i1. So, clearly, it makes a difference. I don't see why you think it makes no difference? Can you please clarify? Cheers, Bran "Moore, Alan" 04/07/2004 04:13 AM To "'Thomas Weigert'" , uml2ftf cc Branislav Selic/Ottawa/IBM@IBMCA Subject RE: ,cb,,cs, Proposals for ballot 12 (April 14) OK. So I want to check a couple of points: 1. Is it possible for a behaviour port to have a required interface - yes, in fact it's shown on Figure 111 in the spec. 2. In the example quoted below, class C with behaviour port BP and part P, connected by connector chan. In the scenario you describe P sends a message , say m, to BP, which is forwarded to C. If the behavioural feature related to m is specified by interface I1, is the scenario you describe affected if BP requires I1, rather than provides I1? From what I can see, within the scope of the example there is no difference. Alan. -----Original Message----- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: 06 April 2004 13:21 To: Moore, Alan; 'Thomas Weigert'; uml2ftf Cc: bselic@ca.ibm.com Subject: RE: ,cb,,cs, Proposals for ballot 12 (April 14) Actually, in both examples we are dealing with provided interfaces, don't we? A behavior port is just like any other port with respect to its interfaces. But you are raising an interesting enhancement suggestion: Should the behavior port have its interfaces derived from the classifier it is a port on, if it has not been given explicit interfaces? In other words, if we omit the type of the behavior port, should we say that in that case it derives its interfaces from the classifier it is the behavior port of? This appears to be a convenient shortcut, albeit I am not sure how often these situations actually arise (probably most of the time we would limit the interfaces offered at the behavior port?). Bran, do you have any intuitions governing the above? Thanks, Th. > -----Original Message----- > From: Moore, Alan [mailto:AlanM@artisansw.com] > Sent: Tuesday, April 06, 2004 7:06 AM > To: 'Thomas Weigert'; uml2ftf > Cc: bselic@ca.ibm.com > Subject: RE: ,cb,,cs, Proposals for ballot 12 (April 14) > > > Interesting and I can see that it has a meaning and a use. I have a > supplementary question - does the behaviour port of C, let's call > it BP, in > case 1, have to have a required interface, because P requires features of > BP, or a provided interface because C offers features via BP? > > I assume the latter(provided), although if BP was not a behaviour > port then > it would be the former (required) - this seems a little odd - imagine if > chan was connected to BP via a port, P.P1, rather than directly > to P - would > the nature of P.P1s interface (required/provided) be affected by > whether BP > was a behaviour port or not? > > Alan. > > -----Original Message----- > From: Thomas Weigert [mailto:thomas.weigert@motorola.com] > Sent: 06 April 2004 12:14 > To: Moore, Alan; 'Thomas Weigert'; uml2ftf > Cc: bselic@ca.ibm.com > Subject: RE: ,cb,,cs, Proposals for ballot 12 (April 14) > > > Alan, > > I am sorry but I don't quite follow your question. Let me try > again: In the > situation below, let's call the connector between P and the > behavior port of > C "chan". If a message is sent from P along chan, it will be handled by C, > not forwarded to anywhere else even if there are other connectors to that > behavior port. > > Further imagine two parts Q1:C and Q2:D and a connector chan2 > between Q2 and > the behavior port of Q2 (remember that C is the type of Q1). Any > communication send along chan2 from Q2 will be handled by the > instance of C > that plays the part Q1, rather than by the instance that plays the part of > P. > > Hope this helps, Th. > > > -----Original Message----- > > From: Moore, Alan [mailto:AlanM@artisansw.com] > > Sent: Tuesday, April 06, 2004 3:04 AM > > To: 'Thomas Weigert'; uml2ftf > > Cc: bselic@ca.ibm.com > > Subject: RE: ,cb,,cs, Proposals for ballot 12 (April 14) > > > > > > Thomas, > > > > On 6669, I'm confused by your discussion, the text in the spec says: > > > > "Any invocation of a behavioral feature targeted at a behavior > > port will be > > handled by the instance of the owning classifier itself, rather > > than by any > > instances that this classifier may contain." > > > > and yet the example you quote: > > > > "Consider the situation where a part P of Classifier C is connected to a > > behavior port of C." > > > > seems to violate this because it implies that an invocation > targeted at a > > behaviour port of C is targeted at an instance, playing part P, > > contained in > > C. > > > > The only conclusion I can draw is that P may be connected to > the behaviour > > port of C but may not handle any invocations sent to that port. Can you > > clarify please? > > > > As an aside could you also clarify whether behaviour ports can > > have required > > interfaces? > > > > Alan. > > > > -----Original Message----- > > From: Thomas Weigert [mailto:thomas.weigert@motorola.com] > > Sent: 06 April 2004 05:28 > > To: uml2ftf > > Cc: bselic@ca.ibm.com > > Subject: RE: ,cb,,cs, Proposals for ballot 12 (April 14) > > > > > > Dear all, > > > > please find attached another installment of issue resolutions for both > > topics. > > > > Th. > > > > > -----Original Message----- > > > From: Thomas Weigert [mailto:Thomas.Weigert@motorola.com] > > > Sent: Tuesday, March 30, 2004 11:45 PM > > > To: uml2ftf > > > Cc: bselic@ca.ibm.com > > > Subject: ,cb,,cs, Proposals for ballot 12 (April 14) > > > > > > > > > Dear all, > > > > > > please find attached some proposed issue resolution from common > > > behavior and > > > composite structures. > > > > > > All the best, Th. > > > ATT653162.gif To: "Moore, Alan" Cc: "'Thomas Weigert'" , uml2ftf Subject: RE: ,cb,,cs, Proposals for ballot 12 (April 14) X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Wed, 7 Apr 2004 10:22:20 -0400 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 04/07/2004 10:22:26 Alan, The answer is "no"! P cannot send "m" through "chan" if BP does not provide an interface that features "m". I am not sure what led you to think that the answer was "yes". Bran "Moore, Alan" 04/07/2004 09:29 AM To "'Thomas Weigert'" , Branislav Selic/Ottawa/IBM@IBMCA cc uml2ftf Subject RE: ,cb,,cs, Proposals for ballot 12 (April 14) Dear Thomas, Perhaps this question will clarify - In Bran's picture, if BP required rather than provided i1, would P be able to send m along chan? The answer I assume is yes. If the answer is yes then what does BP do with m when it receives it? Alan. -----Original Message----- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: 07 April 2004 13:56 To: Moore, Alan; 'Thomas Weigert'; 'Branislav Selic' Cc: uml2ftf Subject: RE: ,cb,,cs, Proposals for ballot 12 (April 14) Alan, I am so sorry but I just don't understand what your questions are asking. Obviously a behavior port is a port, so everything that is said about port also applies to behavior port, unless stated otherwise. The only difference with behavior ports is regarding the routing when you send to it. Th. -----Original Message----- From: Moore, Alan [mailto:AlanM@artisansw.com] Sent: Wednesday, April 07, 2004 7:20 AM To: 'Thomas Weigert'; 'Branislav Selic' Cc: uml2ftf Subject: RE: ,cb,,cs, Proposals for ballot 12 (April 14) The spec says this for isBehaviour (p168): " Specifies whether requests arriving at this port are sent to the classifier behavior of this classifier (see "BehavioredClassifier (from BasicBehaviors)" on page 383). Such ports are referred to as behavior port. Any invocation of a behavioral feature targeted at a behavior port will be handled by the instance of the owning classifier itself, rather than by any instances that this classifier may contain. The default value is false." I assume that it should talk about invocations for behavioural features that the port provides, as distinct from requires - this is a minor point. Another interpretation is that they're sent (i.e. the description above is accurate) but thrown away. Second point is under what circumstances does a required interface on a behaviour port (fig 111) make sense? I can't find anywhere that explains this. Does is act as a normal port? Alan. -----Original Message----- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: 07 April 2004 13:09 To: Moore, Alan; 'Branislav Selic' Cc: 'Thomas Weigert'; uml2ftf Subject: RE: ,cb,,cs, Proposals for ballot 12 (April 14) If you were to change i1 on BP to a required interface, then you would state that BP would be sending the messages supported by the interface. But you want to receive them at BP, so this does not really make much sense. Th. -----Original Message----- From: Moore, Alan [mailto:AlanM@artisansw.com] Sent: Wednesday, April 07, 2004 6:19 AM To: 'Branislav Selic' Cc: 'Thomas Weigert'; uml2ftf Subject: RE: ,cb,,cs, Proposals for ballot 12 (April 14) Brean, Thanks for taking the time to draw the picture, which I should have done earlier. This wasn't quite what I meant - what I meant was would there be a difference if the i1 connected to BP was a cup rather than a ball and what would the difference be? Alan. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: 07 April 2004 10:26 To: Moore, Alan Cc: 'Thomas Weigert'; uml2ftf Subject: RE: ,cb,,cs, Proposals for ballot 12 (April 14) Alan, I am really not sure what the problem is. Here is the situation that you are talking about: If P sends a message m via chan to BP, and i1 (a provided interface of behavior port BP) is an operation or reception of i1, then that operation will be handled by the corresponding method of C. So far so good. If we remove i1 from BP, then message m will not be handled by BP because BP does not implement interface i1. So, clearly, it makes a difference. I don't see why you think it makes no difference? Can you please clarify? Cheers, Bran "Moore, Alan" 04/07/2004 04:13 AM To "'Thomas Weigert'" , uml2ftf cc Branislav Selic/Ottawa/IBM@IBMCA Subject RE: ,cb,,cs, Proposals for ballot 12 (April 14) OK. So I want to check a couple of points: 1. Is it possible for a behaviour port to have a required interface - yes, in fact it's shown on Figure 111 in the spec. 2. In the example quoted below, class C with behaviour port BP and part P, connected by connector chan. In the scenario you describe P sends a message , say m, to BP, which is forwarded to C. If the behavioural feature related to m is specified by interface I1, is the scenario you describe affected if BP requires I1, rather than provides I1? From what I can see, within the scope of the example there is no difference. Alan. -----Original Message----- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: 06 April 2004 13:21 To: Moore, Alan; 'Thomas Weigert'; uml2ftf Cc: bselic@ca.ibm.com Subject: RE: ,cb,,cs, Proposals for ballot 12 (April 14) Actually, in both examples we are dealing with provided interfaces, don't we? A behavior port is just like any other port with respect to its interfaces. But you are raising an interesting enhancement suggestion: Should the behavior port have its interfaces derived from the classifier it is a port on, if it has not been given explicit interfaces? In other words, if we omit the type of the behavior port, should we say that in that case it derives its interfaces from the classifier it is the behavior port of? This appears to be a convenient shortcut, albeit I am not sure how often these situations actually arise (probably most of the time we would limit the interfaces offered at the behavior port?). Bran, do you have any intuitions governing the above? Thanks, Th. > -----Original Message----- > From: Moore, Alan [mailto:AlanM@artisansw.com] > Sent: Tuesday, April 06, 2004 7:06 AM > To: 'Thomas Weigert'; uml2ftf > Cc: bselic@ca.ibm.com > Subject: RE: ,cb,,cs, Proposals for ballot 12 (April 14) > > > Interesting and I can see that it has a meaning and a use. I have a > supplementary question - does the behaviour port of C, let's call > it BP, in > case 1, have to have a required interface, because P requires features of > BP, or a provided interface because C offers features via BP? > > I assume the latter(provided), although if BP was not a behaviour > port then > it would be the former (required) - this seems a little odd - imagine if > chan was connected to BP via a port, P.P1, rather than directly > to P - would > the nature of P.P1s interface (required/provided) be affected by > whether BP > was a behaviour port or not? > > Alan. > > -----Original Message----- > From: Thomas Weigert [mailto:thomas.weigert@motorola.com] > Sent: 06 April 2004 12:14 > To: Moore, Alan; 'Thomas Weigert'; uml2ftf > Cc: bselic@ca.ibm.com > Subject: RE: ,cb,,cs, Proposals for ballot 12 (April 14) > > > Alan, > > I am sorry but I don't quite follow your question. Let me try > again: In the > situation below, let's call the connector between P and the > behavior port of > C "chan". If a message is sent from P along chan, it will be handled by C, > not forwarded to anywhere else even if there are other connectors to that > behavior port. > > Further imagine two parts Q1:C and Q2:D and a connector chan2 > between Q2 and > the behavior port of Q2 (remember that C is the type of Q1). Any > communication send along chan2 from Q2 will be handled by the > instance of C > that plays the part Q1, rather than by the instance that plays the part of > P. > > Hope this helps, Th. > > > -----Original Message----- > > From: Moore, Alan [mailto:AlanM@artisansw.com] > > Sent: Tuesday, April 06, 2004 3:04 AM > > To: 'Thomas Weigert'; uml2ftf > > Cc: bselic@ca.ibm.com > > Subject: RE: ,cb,,cs, Proposals for ballot 12 (April 14) > > > > > > Thomas, > > > > On 6669, I'm confused by your discussion, the text in the spec says: > > > > "Any invocation of a behavioral feature targeted at a behavior > > port will be > > handled by the instance of the owning classifier itself, rather > > than by any > > instances that this classifier may contain." > > > > and yet the example you quote: > > > > "Consider the situation where a part P of Classifier C is connected to a > > behavior port of C." > > > > seems to violate this because it implies that an invocation > targeted at a > > behaviour port of C is targeted at an instance, playing part P, > > contained in > > C. > > > > The only conclusion I can draw is that P may be connected to > the behaviour > > port of C but may not handle any invocations sent to that port. Can you > > clarify please? > > > > As an aside could you also clarify whether behaviour ports can > > have required > > interfaces? > > > > Alan. > > > > -----Original Message----- > > From: Thomas Weigert [mailto:thomas.weigert@motorola.com] > > Sent: 06 April 2004 05:28 > > To: uml2ftf > > Cc: bselic@ca.ibm.com > > Subject: RE: ,cb,,cs, Proposals for ballot 12 (April 14) > > > > > > Dear all, > > > > please find attached another installment of issue resolutions for both > > topics. > > > > Th. > > > > > -----Original Message----- > > > From: Thomas Weigert [mailto:Thomas.Weigert@motorola.com] > > > Sent: Tuesday, March 30, 2004 11:45 PM > > > To: uml2ftf > > > Cc: bselic@ca.ibm.com > > > Subject: ,cb,,cs, Proposals for ballot 12 (April 14) > > > > > > > > > Dear all, > > > > > > please find attached some proposed issue resolution from common > > > behavior and > > > composite structures. > > > > > > All the best, Th. > > > ATT653163.gif From: "Moore, Alan" To: "'Branislav Selic'" Cc: "'Thomas Weigert'" , uml2ftf Subject: RE: ,cb,,cs, Proposals for ballot 12 (April 14) Date: Wed, 7 Apr 2004 15:48:54 +0100 X-Mailer: Internet Mail Service (5.5.2653.19) Something weird happened to your e-mail, so I'm reprising your response here: Alan, The answer is "no"! P cannot send "m" through "chan" if BP does not provide an interface that features "m". I am not sure what led you to think that the answer was "yes". Bran I think that I was confused between the concepts of assembly and delegation connectors as described in chapter 8: "A delegation connector is a connector that links the external contract of a component (as specified by its ports) to the internal realization of that behavior by the component's parts. It represents the forwarding of signals (operation requests and events) : a signal that arrives at a port that has a delegation connector to a part or to another port will be passed on to that target for handling." It seems like the default (assuming a UML without components) is assembly throughout whereas I thought that it was delegation from a composite to its parts (or vice versa) and assembly between parts. Have I got that right? Alan. > -----Original Message----- > From: Branislav Selic [mailto:bselic@ca.ibm.com] > Sent: 07 April 2004 15:22 > To: Moore, Alan > Cc: 'Thomas Weigert'; uml2ftf > Subject: RE: ,cb,,cs, Proposals for ballot 12 (April 14) > > << Message: Untitled Attachment >> << File: ATT65316.gif >> From: "Thomas Weigert" To: "Moore, Alan" , "'Branislav Selic'" Cc: "uml2ftf" Subject: RE: ,cb,,cs, Proposals for ballot 12 (April 14) Date: Wed, 7 Apr 2004 09:51:27 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal UML without components would not have either, as these two special cases of connectors are introduced in the component chapter... Th. > -----Original Message----- > From: Moore, Alan [mailto:AlanM@artisansw.com] > Sent: Wednesday, April 07, 2004 9:49 AM > To: 'Branislav Selic' > Cc: 'Thomas Weigert'; uml2ftf > Subject: RE: ,cb,,cs, Proposals for ballot 12 (April 14) > > > Something weird happened to your e-mail, so I'm reprising your response > here: > Alan, > > The answer is "no"! P cannot send "m" through "chan" if BP does > not provide > an interface that features "m". > > I am not sure what led you to think that the answer was "yes". > > Bran > > I think that I was confused between the concepts of assembly and > delegation > connectors as described in chapter 8: > > "A delegation connector is a connector that links the external > contract of a > component (as specified by its ports) to the internal > realization of that behavior by the component's parts. It represents the > forwarding of signals (operation requests and events) : a > signal that arrives at a port that has a delegation connector to a part or > to another port will be passed on to that target for > handling." > > It seems like the default (assuming a UML without components) is assembly > throughout whereas I thought that it was delegation from a > composite to its > parts (or vice versa) and assembly between parts. Have I got that right? > > Alan. > > > > > -----Original Message----- > > From: Branislav Selic [mailto:bselic@ca.ibm.com] > > Sent: 07 April 2004 15:22 > > To: Moore, Alan > > Cc: 'Thomas Weigert'; uml2ftf > > Subject: RE: ,cb,,cs, Proposals for ballot 12 (April 14) > > > > << Message: Untitled Attachment >> << File: ATT65316.gif >> From: "Moore, Alan" To: "'Thomas Weigert'" , "'Branislav Selic'" Cc: uml2ftf Subject: RE: ,cb,,cs, Proposals for ballot 12 (April 14) Date: Wed, 7 Apr 2004 15:56:50 +0100 X-Mailer: Internet Mail Service (5.5.2653.19) Putting to one side the semantics of connectors without components, which I'm still dubious about, but will have to read more, what about the semantics with components, if chan was a delegation connector? BTW, I assume that if components is included then users have to choose - is there a default? Alan. -----Original Message----- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: 07 April 2004 15:51 To: Moore, Alan; 'Branislav Selic' Cc: uml2ftf Subject: RE: ,cb,,cs, Proposals for ballot 12 (April 14) UML without components would not have either, as these two special cases of connectors are introduced in the component chapter... Th. > -----Original Message----- > From: Moore, Alan [mailto:AlanM@artisansw.com] > Sent: Wednesday, April 07, 2004 9:49 AM > To: 'Branislav Selic' > Cc: 'Thomas Weigert'; uml2ftf > Subject: RE: ,cb,,cs, Proposals for ballot 12 (April 14) > > > Something weird happened to your e-mail, so I'm reprising your response > here: > Alan, > > The answer is "no"! P cannot send "m" through "chan" if BP does > not provide > an interface that features "m". > > I am not sure what led you to think that the answer was "yes". > > Bran > > I think that I was confused between the concepts of assembly and > delegation > connectors as described in chapter 8: > > "A delegation connector is a connector that links the external > contract of a > component (as specified by its ports) to the internal > realization of that behavior by the component's parts. It represents the > forwarding of signals (operation requests and events) : a > signal that arrives at a port that has a delegation connector to a part or > to another port will be passed on to that target for > handling." > > It seems like the default (assuming a UML without components) is assembly > throughout whereas I thought that it was delegation from a > composite to its > parts (or vice versa) and assembly between parts. Have I got that right? > > Alan. > > > > > -----Original Message----- > > From: Branislav Selic [mailto:bselic@ca.ibm.com] > > Sent: 07 April 2004 15:22 > > To: Moore, Alan > > Cc: 'Thomas Weigert'; uml2ftf > > Subject: RE: ,cb,,cs, Proposals for ballot 12 (April 14) > > > > << Message: Untitled Attachment >> << File: ATT65316.gif >> From: "Thomas Weigert" To: "'Branislav Selic'" Cc: "uml2ftf" Subject: RE: ,cb,,cs, Proposals for ballot 12 (April 14) Date: Wed, 7 Apr 2004 10:00:57 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal No, these are just two special cases of connectors that some thought were useful in the component case.... Th. P.S. I'd love to help clear up things but you need to try to express what your questions are clearer... > -----Original Message----- > From: Moore, Alan [mailto:AlanM@artisansw.com] > Sent: Wednesday, April 07, 2004 9:57 AM > To: 'Thomas Weigert'; 'Branislav Selic' > Cc: uml2ftf > Subject: RE: ,cb,,cs, Proposals for ballot 12 (April 14) > > > Putting to one side the semantics of connectors without components, which > I'm still dubious about, but will have to read more, what about the > semantics with components, if chan was a delegation connector? > BTW, I assume > that if components is included then users have to choose - is there a > default? Disposition: Resolved