Issue 6354: Association end names and part types (uml2-superstructure-ftf) Source: International Business Machines (Dr. Bruce Powel Douglass, bruce.douglass(at)us.ibm.com) Nature: Revision Severity: Significant Summary: In the notation of composite structure, are association end names allowed to be presented on connectors? If so, how are they distinguished from port type? Resolution: Revised Text: Actions taken: October 20, 2003: received issue March 9, 2005: closed issue Discussion: The issue probably refers to connector end names. No restrictions are given on the adornment of connector ends. There could, in fact, be a difficulty to distinguish visually whether a given text is the name of a port or the name of the connector end. (Note: the difficulty is not with port type, but with port; the notation for port type has no confusion due to the preceding colon.) In practice, this confusion will not arise as typically connector ends would not be named unless they do not connect via ports. Otherwise, proximity has to be used to differentiate (e.g., the name of the port could be written inside the part or class symbol. Note that there is no difficulty differentiating in the metamodel or a tool implementing the metamodel. The difficulty is merely one of parsing a graphical document. The small likelihood of a problem does not warrant a special notation. Disposition: Closed, no change End of Annotations:===== me: SysML Company: SysML Partners mailFrom: bpd@ilogix.com Nature: Revision Severity: Significant Subject: Association end names and part types In the notation of composite structure, are association end names allowed to be presented on connectors? If so, how are they distinguished from port type? Subject: RE: Ballot 7 (official version -- please vote on this!) Date: Mon, 16 Feb 2004 04:23:12 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Ballot 7 (official version -- please vote on this!) Thread-Index: AcPrcBWp1nNUlAD9ThyUgPjB9KCZQAI96bfA From: "Pete Rivett" To: "Branislav Selic" , X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i1G9BBrh028937 Adaptive votes YES to all the proposed resolutions, except 6310 and 6354 to which it votes NO. While I agree 6310 should be 'closed no change' the resolution text below is not only technically incorrect about where kernel is defined, but does not make sense as English, and formal resolutions should not be a statement of belief: "Well, Kernel is defined in the infrastructure, and construct is build in the superstructure. So I believe it is the way around : the opposite." The resolution to Issue 6354, about notation ambiguity, although it states that 'typically' the specific problem won't arise (I don't know how we can judge 'typical' for a new notation), in effect includes the claim that ambiguous diagrams are not a problem since tools and the metamodel will know the difference: "The difficulty is merely one of parsing a graphical document." This is what I object to: for most people UML is *only* about a notation for communicating designs, and the 'graphical document' is all they see: so it's poor humans who will be 'parsing' the diagrams and trying to work out what's going on. We should not forget this. Especially for a new UML addition which people will initially be unfamiliar with. For future reference 6350 is borderline: the resolution makes no attempt to state where the changes need to be made - is it just to the diagram on which the issue was raised? "The multiplicity of the end at CollaborationOccurrence should be changed to "0..1". Note that the resolutions to 6014, 6016, 6022, 6023 (referring to 'as specialized'), while correct now, will not be correct if we adopt the consensus for package merge which will remove all these nasty specializations. I suggest that we hold off voting on any similar issues until the package merge solution has been formally resolved. -------- I know we're supposed to raise problems at the draft stage. But in this case 23 new issues were added in draft 2 with only 7 hours between the draft and the issued ballot. This might be good for perceived FTF productivity but not for resolution quality IMHO. (I missed reading the resolution text for 6310 in 1st draft I admit since I could see from reading the issue that it would be 'closed no change'). Pete Pete Rivett (mailto:pete.rivett@adaptive.com) Consulting Architect, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com ________________________________ From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Wednesday, February 04, 2004 4:37 PM To: uml2-superstructure-ftf@omg.org Cc: mu2i-ftf@omg.org; ocl2-ftf@omg.org Subject: Ballot 7 (official version -- please vote on this!) OK, after a bit of to and fro, here is the official version of ballot 7 for voting purposes. It has a total of 36 proposed issue resolutions (not 38 as I had promised). I have excluded from it all items that have even a whiff of contention -- but it is still your responsibility to look at each proposed resolution and decide if you agree with it. Remember, once we have voted on an issue, there is no going back, so please make sure you do this right. The official ballot opens in 26 minutes and goes on for two weeks. During that time, you can change your vote. After that you cannot. Thanks, Bran Selic Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph. (613) 591-7915 fax (613) 599-3912 e-mail: bselic@ca.ibm.com To: "Pete Rivett" Cc: uml2-superstructure-ftf@omg.org Subject: RE: Ballot 7 (official version -- please vote on this!) X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Mon, 16 Feb 2004 08:00:07 -0500 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 02/16/2004 08:02:18, Serialize complete at 02/16/2004 08:02:18 Pete, Regarding the resolution to issue 6354: Your objection is one of principle, but sometimes general principles need to be re-evaluated in concrete situations -- otherwise we suffer from the problem of overgeneralization. In this case, we are very much in a position to judge what is "typical" since the notation is not new (as you state) but one that has been used for over 15 years in various forms. I can assure you that not once has anyone asked for the capability to name a connector end, since there is no need ever to reference it. The fact that a connector end is a named element is only a consequence of the old problem of overgeneralziation. This whole problem is artificial and I do hope you will reconsider your vote. Regards, Bran "Pete Rivett" 02/16/2004 04:23 AM To: Branislav Selic/Ottawa/IBM@IBMCA, cc: Subject: RE: Ballot 7 (official version -- please vote on this!) Adaptive votes YES to all the proposed resolutions, except 6310 and 6354 to which it votes NO. While I agree 6310 should be 'closed no change' the resolution text below is not only technically incorrect about where kernel is defined, but does not make sense as English, and formal resolutions should not be a statement of belief: "Well, Kernel is defined in the infrastructure, and construct is build in the superstructure. So I believe it is the way around : the opposite." The resolution to Issue 6354, about notation ambiguity, although it states that 'typically' the specific problem won't arise (I don't know how we can judge 'typical' for a new notation), in effect includes the claim that ambiguous diagrams are not a problem since tools and the metamodel will know the difference: "The difficulty is merely one of parsing a graphical document." This is what I object to: for most people UML is *only* about a notation for communicating designs, and the 'graphical document' is all they see: so it's poor humans who will be 'parsing' the diagrams and trying to work out what's going on. We should not forget this. Especially for a new UML addition which people will initially be unfamiliar with. For future reference 6350 is borderline: the resolution makes no attempt to state where the changes need to be made - is it just to the diagram on which the issue was raised? "The multiplicity of the end at CollaborationOccurrence should be changed to "0..1". Note that the resolutions to 6014, 6016, 6022, 6023 (referring to 'as specialized'), while correct now, will not be correct if we adopt the consensus for package merge which will remove all these nasty specializations. I suggest that we hold off voting on any similar issues until the package merge solution has been formally resolved. -------- I know we're supposed to raise problems at the draft stage. But in this case 23 new issues were added in draft 2 with only 7 hours between the draft and the issued ballot. This might be good for perceived FTF productivity but not for resolution quality IMHO. (I missed reading the resolution text for 6310 in 1st draft I admit since I could see from reading the issue that it would be 'closed no change'). Pete Pete Rivett (mailto:pete.rivett@adaptive.com) Consulting Architect, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com ________________________________ From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Wednesday, February 04, 2004 4:37 PM To: uml2-superstructure-ftf@omg.org Cc: mu2i-ftf@omg.org; ocl2-ftf@omg.org Subject: Ballot 7 (official version -- please vote on this!) OK, after a bit of to and fro, here is the official version of ballot 7 for voting purposes. It has a total of 36 proposed issue resolutions (not 38 as I had promised). I have excluded from it all items that have even a whiff of contention -- but it is still your responsibility to look at each proposed resolution and decide if you agree with it. Remember, once we have voted on an issue, there is no going back, so please make sure you do this right. The official ballot opens in 26 minutes and goes on for two weeks. During that time, you can change your vote. After that you cannot. Thanks, Bran Selic Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph. (613) 591-7915 fax (613) 599-3912 e-mail: bselic@ca.ibm.com Subject: RE: Ballot 7 (official version -- please vote on this!) - revote Date: Tue, 17 Feb 2004 03:31:39 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Ballot 7 (official version -- please vote on this!) - revote Thread-Index: AcP0jdQXohWOa+znTVi1BfuVijFNnwAoPEZg From: "Pete Rivett" To: "Branislav Selic" Cc: Adaptive changes its vote on Issue 6354 to YES (votes on all other resolutions remain the same: YES except for 6310). Bran's reasonable argument and experience prevailed over some of the unreasonable (IMHO) comments in the resolution. Should we take the constraint/OCL option for addressing overgeneralization, I look forward to constraining connector ends to be un-named! Regards Pete Pete Rivett (mailto:pete.rivett@adaptive.com) Consulting Architect, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Monday, February 16, 2004 7:00 AM To: Pete Rivett Cc: uml2-superstructure-ftf@omg.org Subject: RE: Ballot 7 (official version -- please vote on this!) Pete, Regarding the resolution to issue 6354: Your objection is one of principle, but sometimes general principles need to be re-evaluated in concrete situations -- otherwise we suffer from the problem of overgeneralization. In this case, we are very much in a position to judge what is "typical" since the notation is not new (as you state) but one that has been used for over 15 years in various forms. I can assure you that not once has anyone asked for the capability to name a connector end, since there is no need ever to reference it. The fact that a connector end is a named element is only a consequence of the old problem of overgeneralziation. This whole problem is artificial and I do hope you will reconsider your vote. Regards, Bran "Pete Rivett" 02/16/2004 04:23 AM To: Branislav Selic/Ottawa/IBM@IBMCA, cc: Subject: RE: Ballot 7 (official version -- please vote on this!) Adaptive votes YES to all the proposed resolutions, except 6310 and 6354 to which it votes NO. While I agree 6310 should be 'closed no change' the resolution text below is not only technically incorrect about where kernel is defined, but does not make sense as English, and formal resolutions should not be a statement of belief: "Well, Kernel is defined in the infrastructure, and construct is build in the superstructure. So I believe it is the way around : the opposite." The resolution to Issue 6354, about notation ambiguity, although it states that 'typically' the specific problem won't arise (I don't know how we can judge 'typical' for a new notation), in effect includes the claim that ambiguous diagrams are not a problem since tools and the metamodel will know the difference: "The difficulty is merely one of parsing a graphical document." This is what I object to: for most people UML is *only* about a notation for communicating designs, and the 'graphical document' is all they see: so it's poor humans who will be 'parsing' the diagrams and trying to work out what's going on. We should not forget this. Especially for a new UML addition which people will initially be unfamiliar with. For future reference 6350 is borderline: the resolution makes no attempt to state where the changes need to be made - is it just to the diagram on which the issue was raised? "The multiplicity of the end at CollaborationOccurrence should be changed to "0..1". Note that the resolutions to 6014, 6016, 6022, 6023 (referring to 'as specialized'), while correct now, will not be correct if we adopt the consensus for package merge which will remove all these nasty specializations. I suggest that we hold off voting on any similar issues until the package merge solution has been formally resolved. -------- I know we're supposed to raise problems at the draft stage. But in this case 23 new issues were added in draft 2 with only 7 hours between the draft and the issued ballot. This might be good for perceived FTF productivity but not for resolution quality IMHO. (I missed reading the resolution text for 6310 in 1st draft I admit since I could see from reading the issue that it would be 'closed no change'). Pete Pete Rivett (mailto:pete.rivett@adaptive.com) Consulting Architect, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com ________________________________ From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Wednesday, February 04, 2004 4:37 PM To: uml2-superstructure-ftf@omg.org Cc: mu2i-ftf@omg.org; ocl2-ftf@omg.org Subject: Ballot 7 (official version -- please vote on this!) OK, after a bit of to and fro, here is the official version of ballot 7 for voting purposes. It has a total of 36 proposed issue resolutions (not 38 as I had promised). I have excluded from it all items that have even a whiff of contention -- but it is still your responsibility to look at each proposed resolution and decide if you agree with it. Remember, once we have voted on an issue, there is no going back, so please make sure you do this right. The official ballot opens in 26 minutes and goes on for two weeks. During that time, you can change your vote. After that you cannot. Thanks, Bran Selic Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph. (613) 591-7915 fax (613) 599-3912 e-mail: bselic@ca.ibm.com