Issue 18684: Forked association notation ill-formed (uml25-ftf) Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov) Nature: Revision Severity: Significant Summary: Description: Figure 11.34 (Composite aggregation sharing a source segment) shows three association lines sharing one end (window), implying the end is owned by three classes, which isn't possible. Even if the three classes redefine window using the same name, the "shared" end would actually be separate elements in the model, though they would appear notationally the same. If this is the intention, redefinition of window should be added to the figure, and the text should explain that the "shared" graphical elements refer to three underlying model elements, (Annex B should be updated also). The notation wasn't in 2.4.1 that I can find. Resolution: Revised Text: Actions taken: April 24, 2013: received issue Discussion: End of Annotations:===== te: Wed, 24 Apr 2013 10:33:30 -0400 From: webmaster@omg.org Date: 24 Apr 2013 09:06:42 -0400 To: Subject: Issue/Bug Report X-Brightmail-Tracker: AAAAAA== X-Brightmail-Tracker: AAAAAA== ******************************************************************************* Name: Conrad Bock Employer: NIST mailFrom: conrad.bock@nist.gov Terms_Agreement: I agree Specification: UML 2.5 Beta Section: 11.5.4 FormalNumber: ptc/2012-10-24 Version: Beta Doc_Year: 2012 Doc_Month: October Doc_Day: 01 Page: Title: Forked association notation ill-formed Nature: Revision Severity: Significant CODE: 3TMw8 B1: Report Issue Description: Figure 11.34 (Composite aggregation sharing a source segment) shows three association lines sharing one end (window), implying the end is owned by three classes, which isn't possible. Even if the three classes redefine window using the same name, the "shared" end would actually be separate elements in the model, though they would appear notationally the same. If this is the intention, redefinition of window should be added to the figure, and the text should explain that the "shared" graphical elements refer to three underlying model elements, (Annex B should be updated also). The notation wasn't in 2.4.1 that I can find. From: Steve Cook To: "uml25-ftf@omg.org" , Conrad Bock Subject: RE: issue 18684 -- UML 2.5 FTF issue Thread-Topic: issue 18684 -- UML 2.5 FTF issue Thread-Index: AQHOQPywdpRvGP5t8ka15+tNeivVkZjlfSTg Date: Wed, 24 Apr 2013 15:30:55 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.18.105] X-Forefront-Antispam-Report: CIP:131.107.125.37;CTRY:US;IPV:CAL;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(50944002)(199002)(189002)(5403001)(48214006)(20776003)(63696002)(564824004)(49866001)(50986001)(47976001)(16406001)(4396001)(69226001)(47736001)(6806003)(16236675002)(71186001)(74662001)(512874001)(31966008)(54356001)(74502001)(33656001)(65816001)(81342001)(76482001)(53806001)(56816002)(15974865001)(56776001)(15202345002)(79102001)(44976003)(81542001)(55846006)(54316002)(80022001)(46102001)(77982001)(51856001)(59766001)(47446002)(74366001);DIR:OUT;SFP:;SCL:1;SRVR:BY2FFO11HUB032;H:TK5EX14MLTC103.redmond.corp.microsoft.com;RD:InfoDomainNonexistent;A:1;MX:1;LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0826B2F01B X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAR15Gmw= X-Brightmail-Tracker: AAAAAA== Conrad The purpose of that figure is to exemplify the following statement that you will find in UML 2.4.1: .If there are two or more aggregations to the same aggregate, they may be drawn as a tree by merging the aggregation ends into a single segment. Any adornments on that single segment apply to all of the aggregation ends.. The same paragraph appears in 2.5 clause 11.5.4. Immediately above figure 11.34 it says .Figure 11.34 shows the same model using the notational option of sharing the same source segment between multiple compositions. The multiplicity and name adornments on the shared end apply to all of the compositions.. I don.t know what you mean by .redefinition of window should be added to the figure.. -- Steve From: Juergen Boldt [mailto:juergen@omg.org] Sent: 24 April 2013 15:57 To: issues@omg.org; uml25-ftf@omg.org Subject: issue 18684 -- UML 2.5 FTF issue From: "Bock, Conrad" To: Juergen Boldt Date: Wed, 24 Apr 2013 10:33:30 -0400 From: webmaster@omg.org Date: 24 Apr 2013 09:06:42 -0400 To: Subject: Issue/Bug Report X-Brightmail-Tracker: AAAAAA== X-Brightmail-Tracker: AAAAAA== ******************************************************************************* Name: Conrad Bock Employer: NIST mailFrom: conrad.bock@nist.gov Terms_Agreement: I agree Specification: UML 2.5 Beta Section: 11.5.4 FormalNumber: ptc/2012-10-24 Version: Beta Doc_Year: 2012 Doc_Month: October Doc_Day: 01 Page: Title: Forked association notation ill-formed Nature: Revision Severity: Significant CODE: 3TMw8 B1: Report Issue Description: Figure 11.34 (Composite aggregation sharing a source segment) shows three association lines sharing one end (window), implying the end is owned by three classes, which isn't possible. Even if the three classes redefine window using the same name, the "shared" end would actually be separate elements in the model, though they would appear notationally the same. If this is the intention, redefinition of window should be added to the figure, and the text should explain that the "shared" graphical elements refer to three underlying model elements, (Annex B should be updated also). The notation wasn't in 2.4.1 that I can find. Juergen Boldt Director, Member Services 109 Highland Ave Needham, MA 02494 USA Tel: 781 444 0404 x 132 fax: 781 444 0320 www.omg.org [] From: "Bock, Conrad" To: "uml25-ftf@omg.org" Date: Wed, 24 Apr 2013 13:17:42 -0400 Subject: RE: issue 18684 -- UML 2.5 FTF issue Thread-Topic: issue 18684 -- UML 2.5 FTF issue Thread-Index: AQHOQPywdpRvGP5t8ka15+tNeivVkZjlfSTggAAfdyA= Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from base64 to 8bit by amethyst.omg.org id r3OHHptH015558 X-Brightmail-Tracker: AAAAAA== X-Brightmail-Tracker: AAAAAA== Content-Transfer-Encoding: 8bit Steve, > The purpose of that figure is to exemplify the following statement > that you will find in UML 2.4.1: "If there are two or more > aggregations to the same aggregate, they may be drawn as a tree by > merging the aggregation ends into a single segment. Any adornments on > that single segment apply to all of the aggregation ends." The same > paragraph appears in 2.5 clause 11.5.4. Thanks, I didn't see that. My comments apply to 2.4.1 also then. > Immediately above figure 11.34 it says "Figure 11.34 shows the same > model using the notational option of sharing the same source segment > between multiple compositions. The multiplicity and name adornments > on the shared end apply to all of the compositions." The notation gives the impression that "window" is the same property for all the associations, even (as the text explains) this is not the case. For example, structural feature actions operating on one of the properties will not work on the other two, but the figure gives the impression that it will. > I don't know what you mean by "redefinition of window should be added > to the figure". I guess that doesn't completely address the problem above, since the redefining properties will all be different also, but if the three window properties redefine the same general property, then it is at least justifiable to show them all as one graphical element, and actions can refer to the single general property to operate on all the associations. Conrad From: "Bock, Conrad" To: Juergen Boldt Date: Wed, 24 Apr 2013 10:33:30 -0400 From: webmaster@omg.org Date: 24 Apr 2013 09:06:42 -0400 To: Subject: Issue/Bug Report X-Brightmail-Tracker: AAAAAA== X-Brightmail-Tracker: AAAAAA== ******************************************************************************* Name: Conrad Bock Employer: NIST mailFrom: conrad.bock@nist.gov Terms_Agreement: I agree Specification: UML 2.5 Beta Section: 11.5.4 FormalNumber: ptc/2012-10-24 Version: Beta Doc_Year: 2012 Doc_Month: October Doc_Day: 01 Page: Title: Forked association notation ill-formed Nature: Revision Severity: Significant CODE: 3TMw8 B1: Report Issue Description: Figure 11.34 (Composite aggregation sharing a source segment) shows three association lines sharing one end (window), implying the end is owned by three classes, which isn't possible. Even if the three classes redefine window using the same name, the "shared" end would actually be separate elements in the model, though they would appear notationally the same. If this is the intention, redefinition of window should be added to the figure, and the text should explain that the "shared" graphical elements refer to three underlying model elements, (Annex B should be updated also). The notation wasn't in 2.4.1 that I can find. From: Steve Cook To: "Bock, Conrad" , "uml25-ftf@omg.org" Subject: RE: issue 18684 -- UML 2.5 FTF issue Thread-Topic: issue 18684 -- UML 2.5 FTF issue Thread-Index: AQHOQPywdpRvGP5t8ka15+tNeivVkZjlfSTggAAfdyCAAPngIA== Date: Thu, 25 Apr 2013 08:23:00 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.18.100] X-Forefront-Antispam-Report: CIP:131.107.125.37;CTRY:US;IPV:CAL;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(50944002)(164054002)(5403001)(13464002)(189002)(199002)(56816002)(47776003)(51856001)(23676002)(65816001)(76482001)(56776001)(54316002)(16796002)(74502001)(47446002)(16406001)(20776003)(31966008)(74662001)(47976001)(46102001)(80022001)(44976003)(69226001)(53806001)(59766001)(77982001)(49866001)(79102001)(4396001)(55846006)(6806003)(81542001)(81342001)(54356001)(50986001)(33656001)(74366001)(63696002)(50466002)(47736001);DIR:OUT;SFP:;SCL:1;SRVR:BL2FFO11HUB023;H:TK5EX14HUBC102.redmond.corp.microsoft.com;RD:InfoDomainNonexistent;MX:1;A:1;LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0827D7ACB9 X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from base64 to 8bit by amethyst.omg.org id r3P8ORxU023264 X-Brightmail-Tracker: AAAAAR15Qr0= X-Brightmail-Tracker: AAAAAA== Content-Transfer-Encoding: 8bit Conrad This notation dates from UML 1 or before. It appears in the three amigos' 1998 UML user guide. Quoting from UML 1.1 spec: " If there are two or more aggregations to the same aggregate, they may be drawn as a tree by merging the aggregation ends into a single segment. This requires that all of the adornments on the aggregation ends be consistent. This is purely a presentation option; there are no additional semantics to it". So I don't really think we can remove this notational option from the spec. Perhaps we need to reword it. It strikes me that the original UML 1.1 wording is a significant improvement on its successors. I don't think this notation necessarily means that all the meta-properties at the aggregation end are the same: e.g. if there is no name on the diagram, presumably the names of the actual properties could be different in the model. A topic for next week's call, I think. -- Steve -----Original Message----- From: Bock, Conrad [mailto:conrad.bock@nist.gov] Sent: 24 April 2013 18:18 To: uml25-ftf@omg.org Subject: RE: issue 18684 -- UML 2.5 FTF issue Steve, > The purpose of that figure is to exemplify the following statement > that you will find in UML 2.4.1: "If there are two or more > aggregations to the same aggregate, they may be drawn as a tree by > merging the aggregation ends into a single segment. Any adornments on > that single segment apply to all of the aggregation ends." The same > paragraph appears in 2.5 clause 11.5.4. Thanks, I didn't see that. My comments apply to 2.4.1 also then. > Immediately above figure 11.34 it says "Figure 11.34 shows the same > model using the notational option of sharing the same source segment > between multiple compositions. The multiplicity and name adornments > on the shared end apply to all of the compositions." The notation gives the impression that "window" is the same property for all the associations, even (as the text explains) this is not the case. For example, structural feature actions operating on one of the properties will not work on the other two, but the figure gives the impression that it will. > I don't know what you mean by "redefinition of window should be added > to the figure". I guess that doesn't completely address the problem above, since the redefining properties will all be different also, but if the three window properties redefine the same general property, then it is at least justifiable to show them all as one graphical element, and actions can refer to the single general property to operate on all the associations. Conrad From: "Bock, Conrad" To: Juergen Boldt Date: Wed, 24 Apr 2013 10:33:30 -0400 From: webmaster@omg.org Date: 24 Apr 2013 09:06:42 -0400 To: Subject: Issue/Bug Report X-Brightmail-Tracker: AAAAAA== X-Brightmail-Tracker: AAAAAA== ******************************************************************************* Name: Conrad Bock Employer: NIST mailFrom: conrad.bock@nist.gov Terms_Agreement: I agree Specification: UML 2.5 Beta Section: 11.5.4 FormalNumber: ptc/2012-10-24 Version: Beta Doc_Year: 2012 Doc_Month: October Doc_Day: 01 Page: Title: Forked association notation ill-formed Nature: Revision Severity: Significant CODE: 3TMw8 B1: Report Issue Description: Figure 11.34 (Composite aggregation sharing a source segment) shows three association lines sharing one end (window), implying the end is owned by three classes, which isn't possible. Even if the three classes redefine window using the same name, the "shared" end would actually be separate elements in the model, though they would appear notationally the same. If this is the intention, redefinition of window should be added to the figure, and the text should explain that the "shared" graphical elements refer to three underlying model elements, (Annex B should be updated also). The notation wasn't in 2.4.1 that I can find. From: "Bock, Conrad" To: "uml25-ftf@omg.org" Date: Thu, 16 May 2013 09:52:33 -0400 Subject: Re: [UML 2.5 FTF] Ballot 5 -- Preview 3, 18684, inconsistent defaults Thread-Topic: Re: [UML 2.5 FTF] Ballot 5 -- Preview 3, 18684, inconsistent defaults Thread-Index: Ac5SPHaySYheKoJVTHGpa6K791N2qg== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAA== X-Brightmail-Tracker: AAAAAA== UMLers, The resolution for 18684 (Forked association notation) changes the default multiplicity for properties shown as association ends to something different than is currently assumed in the UML spec for properties shown in compartments (the spec convention is that no multiplicity shown in> property compartment defaults to [1]). Steve doesn't think this is worth discussing anymore (see below). What do others think of this? I don't think it's good to have different defaults in different contexts. I think it's best to leave the absence of multiplicity for associations to be left up to modeler conventions. Conrad -----Original Message----- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Tuesday, May 14, 2013 9:52 AM To: Bock, Conrad; uml25-ftf@omg.org Subject: RE: [UML 2.5 FTF] Ballot 5 -- Preview 3 -- PLEASE READ [snip] > - 18684 : Forked association notation ill-formed > > If the note on default multiplicity is going to be changed for > associations, it ought to be similarly noted for properties in > compartments. But the UML spec assumes no multiplicity shown in > property compartment defaults to [1]. I think it's best to leave > the absence of multiplicity for associations to be left up to > modeler conventions. > > The relationship between Figures 11.33 and 11.34 would be clearer > if the window property appeared in Figure 11.3. In particular, it > would make the current sentence above Figure 11.34 (that the > underlying models are the same) more obvious. Changing "same" to > "similar" is very confusing. It's an example, so they can be the > same for clarity in this example. > > At the end of the sentence added by the revised text above Figure > 11.34, it would help to add ", because the properties are separate > in the model even though they have the same name and are notated > with the same segment in Figure 11.34". > > In my view this resolution is good enough and enough time has been spent on it. No change. I don't agree, it introduces inconsistencies. I had let you know that I wouldn't be at the telecon when it was on the agenda. It would have been more efficient to wait to the next week. I'd like to discuss at the next telecon. I do not consider this to be high enough priority to discuss any more. I wish this to go to the FTF for a vote as it is. From: Steve Cook To: "Bock, Conrad" , "uml25-ftf@omg.org" Subject: RE: [UML 2.5 FTF] Ballot 5 -- Preview 3, 18684, inconsistent defaults Thread-Topic: [UML 2.5 FTF] Ballot 5 -- Preview 3, 18684, inconsistent defaults Thread-Index: Ac5SPHaySYheKoJVTHGpa6K791N2qgAAsudg Date: Thu, 16 May 2013 14:20:17 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.18.103] X-Forefront-Antispam-Report: CIP:131.107.125.37;CTRY:US;IPV:CAL;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(51704005)(189002)(199002)(377454002)(13464003)(74876001)(54316002)(76482001)(50466002)(46102001)(65816001)(56816002)(81342001)(23726002)(51856001)(69226001)(47776003)(55846006)(74662001)(63696002)(74706001)(53806001)(20776003)(33656001)(74366001)(6806003)(77982001)(49866001)(46406003)(47976001)(80022001)(16406001)(54356001)(79102001)(4396001)(59766001)(50986001)(47446002)(81542001)(74502001)(56776001)(31966008)(47736001);DIR:OUT;SFP:;SCL:1;SRVR:BN1BFFO11HUB021;H:TK5EX14HUBC107.redmond.corp.microsoft.com;RD:InfoDomainNonexistent;MX:1;A:1;LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0848C1A6AA X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id r4GEKggK032745 X-Brightmail-Tracker: AAAAAA== X-Brightmail-Tracker: AAAAAA== Conrad I do not believe that the resolution changes any default. It simply clarifies the current situation for association ends, for which there is no assumed multiplicity default. I don't know what you mean by "left up to modeler conventions", but if it means what I think it ought to mean, then that is what the current resolution is intended to accomplish. -- Steve -----Original Message----- From: Bock, Conrad [mailto:conrad.bock@nist.gov] Sent: 16 May 2013 14:53 To: uml25-ftf@omg.org Subject: Re: [UML 2.5 FTF] Ballot 5 -- Preview 3, 18684, inconsistent defaults UMLers, The resolution for 18684 (Forked association notation) changes the default multiplicity for properties shown as association ends to something different than is currently assumed in the UML spec for properties shown in compartments (the spec convention is that no multiplicity shown in> property compartment defaults to [1]). Steve doesn't think this is worth discussing anymore (see below). What do others think of this? I don't think it's good to have different defaults in different contexts. I think it's best to leave the absence of multiplicity for associations to be left up to modeler conventions. Conrad -----Original Message----- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Tuesday, May 14, 2013 9:52 AM To: Bock, Conrad; uml25-ftf@omg.org Subject: RE: [UML 2.5 FTF] Ballot 5 -- Preview 3 -- PLEASE READ [snip] > - 18684 : Forked association notation ill-formed > > If the note on default multiplicity is going to be changed for > associations, it ought to be similarly noted for properties in > compartments. But the UML spec assumes no multiplicity shown in > property compartment defaults to [1]. I think it's best to leave > the absence of multiplicity for associations to be left up to > modeler conventions. > > The relationship between Figures 11.33 and 11.34 would be clearer > if the window property appeared in Figure 11.3. In particular, it > would make the current sentence above Figure 11.34 (that the > underlying models are the same) more obvious. Changing "same" to > "similar" is very confusing. It's an example, so they can be the > same for clarity in this example. > > At the end of the sentence added by the revised text above Figure > 11.34, it would help to add ", because the properties are separate > in the model even though they have the same name and are notated > with the same segment in Figure 11.34". > > In my view this resolution is good enough and enough time has been spent on it. No change. I don't agree, it introduces inconsistencies. I had let you know that I wouldn't be at the telecon when it was on the agenda. It would have been more efficient to wait to the next week. I'd like to discuss at the next telecon. I do not consider this to be high enough priority to discuss any more. I wish this to go to the FTF for a vote as it is. From: "BERNARD, Yves" To: "Bock, Conrad" , "uml25-ftf@omg.org" Date: Thu, 16 May 2013 17:03:49 +0200 Subject: RE: [UML 2.5 FTF] Ballot 5 -- Preview 3, 18684, inconsistent defaults Thread-Topic: [UML 2.5 FTF] Ballot 5 -- Preview 3, 18684, inconsistent defaults Thread-Index: Ac5SPHaySYheKoJVTHGpa6K791N2qgAAT7mQ Accept-Language: fr-FR, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id r4GF3vdQ008751 X-Brightmail-Tracker: AAAAAR15Qr0= X-Brightmail-Tracker: AAAAAA== According to the rules applicable to this FTF, changing such a convention is acceptable if the change is "safe". That is: it shall not lead to an incorrect interpretation of the diagram (e.g. a counter sense). If the meaning of a missing multiplicity was actually left under the responsibility of the modeler it would be an issue since there is no standard way to specify the choice made but it is not what the proposed resolution says: "NOTE. If no multiplicity is shown on the diagram, no conclusion may be drawn about the multiplicity in the model." So, to me, the proposed change is "safe" and thus acceptable. Yves -----Original Message----- From: Bock, Conrad [mailto:conrad.bock@nist.gov] Sent: jeudi 16 mai 2013 15:53 To: uml25-ftf@omg.org Subject: Re: [UML 2.5 FTF] Ballot 5 -- Preview 3, 18684, inconsistent defaults UMLers, The resolution for 18684 (Forked association notation) changes the default multiplicity for properties shown as association ends to something different than is currently assumed in the UML spec for properties shown in compartments (the spec convention is that no multiplicity shown in> property compartment defaults to [1]). Steve doesn't think this is worth discussing anymore (see below). What do others think of this? I don't think it's good to have different defaults in different contexts. I think it's best to leave the absence of multiplicity for associations to be left up to modeler conventions. Conrad -----Original Message----- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Tuesday, May 14, 2013 9:52 AM To: Bock, Conrad; uml25-ftf@omg.org Subject: RE: [UML 2.5 FTF] Ballot 5 -- Preview 3 -- PLEASE READ [snip] > - 18684 : Forked association notation ill-formed > > If the note on default multiplicity is going to be changed for > associations, it ought to be similarly noted for properties in > compartments. But the UML spec assumes no multiplicity shown in > property compartment defaults to [1]. I think it's best to leave > the absence of multiplicity for associations to be left up to > modeler conventions. > > The relationship between Figures 11.33 and 11.34 would be clearer > if the window property appeared in Figure 11.3. In particular, it > would make the current sentence above Figure 11.34 (that the > underlying models are the same) more obvious. Changing "same" to > "similar" is very confusing. It's an example, so they can be the > same for clarity in this example. > > At the end of the sentence added by the revised text above Figure > 11.34, it would help to add ", because the properties are separate > in the model even though they have the same name and are notated > with the same segment in Figure 11.34". > > In my view this resolution is good enough and enough time has been spent on it. No change. I don't agree, it introduces inconsistencies. I had let you know that I wouldn't be at the telecon when it was on the agenda. It would have been more efficient to wait to the next week. I'd like to discuss at the next telecon. I do not consider this to be high enough priority to discuss any more. I wish this to go to the FTF for a vote as it is. This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. X-Virus-Scanned: OK From: Ed Seidewitz To: "Wendland, Marc-Florian" CC: "uml25-ftf@omg.org" Subject: RE: I posted draft resolutions for Clause 17 Issues for Ballot 6 Thread-Topic: I posted draft resolutions for Clause 17 Issues for Ballot 6 Thread-Index: AQHOUZkj9wM68mfvHUS3dDvzNklWKpkHomdQgAAGm3CAAIYBAP//uhLAgABepYD//612QA== Date: Thu, 16 May 2013 15:49:03 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [71.178.82.93] X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id r4GFn6TF017355 X-Brightmail-Tracker: AAAAAR16Wag= X-Brightmail-Tracker: AAAAAA== Marc-Florian -- The ways in which a BehavioredClassifier can "conform to the contract of the Interface" are kept pretty loose in the UML spec. For instance, it is possible for attributes in the Interface to be "realized" by getter and setter operations in the BehavioredClassifier. It is not the case that the BehavioredClassifier has to have identical features to those of the Interface(s) it realizes. Plus, UML defines the machinery for inheritance only for Generalization, not InterfaceRealization -- the BehavioredClassifier must have the necessary features to realize the Interface as its own members, it cannot "inherit" them from the Interface. As with many areas of UML, it can certainly be questioned whether this is the best way to do things. But it is the way it is. -- Ed -----Original Message----- From: Wendland, Marc-Florian [mailto:marc-florian.wendland@fokus.fraunhofer.de] Sent: Thursday, May 16, 2013 11:39 AM To: Ed Seidewitz Cc: uml25-ftf@omg.org Subject: AW: I posted draft resolutions for Clause 17 Issues for Ballot 6 Hi Ed, I see. I did not know this is required for BehavioredClassifiers and I really do not understand why this is mandatory. It disallows high-level modeling and leads to redundant information in the model. All information are available without these features being present in the BehavioredClassifier. Even for code generation, the implemented features in the BehavioredClassifier could be derived. Maybe I overlook some aspects, though... Regards, Marc-Florian > -----Ursprühe Nachricht----- > Von: Ed Seidewitz [mailto:eseidewitz@ivarjacobson.com] > Gesendet: Donnerstag, 16. Mai 2013 17:17 > An: Wendland, Marc-Florian > Cc: uml25-ftf@omg.org > Betreff: RE: I posted draft resolutions for Clause 17 Issues for > Ballot 6 > > Marc-Florian -- > > Actually, InterfaceRealization does not allow Actors to "define" > Operations and Receptions. InterfaceRealization requires that the > realizing BehavioredClassifier own features that "conform to the > contract specified by the Interface". Features are not "inherited" from an Interface. > > The problem is that Actor has no ownership associations for attributes > or operations. As a BehavioredClassifier, it can own Behaviors, but > the Classifier::feature and attribute properties are derived unions > which remain empty unless subsetted. Thus, there is really no way for > an Actor to legally realize and Interface, unless that Interface simply has no features. > > There are a number of open issues related to this, including: 8893, > 10780, 12942, 13134, 13948, 14875, 15162, 17366. > > -- Ed > > -----Original Message----- > From: Wendland, Marc-Florian [mailto:marc- > florian.wendland@fokus.fraunhofer.de] > Sent: Thursday, May 16, 2013 10:11 AM > To: Steve Cook; Tom Rutt; uml25-ftf@omg.org > Subject: AW: I posted draft resolutions for Clause 17 Issues for > Ballot 6 > > Hi Steven, > > I totally agree with you. Just a comment to your statement: > > > It is true that an Actor may not have Operations or Signals. But, > > according to existing practice, it is false that this means that > > their lifelines may not participate in Messages. > > Nevertheless, Actors may for sure define Operations or Receptions via > InterfaceRealization. They are, in fact, ordinary BehavioredClassifiers. > > I agree that the issue can be closed - actually I argued for this > several months ago. > > Regards, > Marc-Florian > > > -----Ursprühe Nachricht----- > > Von: Steve Cook [mailto:Steve.Cook@microsoft.com] > > Gesendet: Donnerstag, 16. Mai 2013 13:22 > > An: Tom Rutt; uml25-ftf@omg.org > > Betreff: RE: I posted draft resolutions for Clause 17 Issues for > > Ballot 6 > > > > I just checked and RSA allows you to type a lifeline by an Actor, > > and to create messages to/from Actors. Our UML tool does too. > > > > I think a key point here is that clause 17 is ambivalent about > > whether a Message may have an empty signature. According to the > > multiplicity and > the > > constraints, it may. And some of the text substantiates this: "If the > Message > > has a signature ...." > > > > But other parts of the text do not: "The signature of a Message > > refers to either an Operation or a Signal." > > > > It is true that an Actor may not have Operations or Signals. But, > > according to existing practice, it is false that this means that > > their lifelines may not participate in Messages. > > > > -- Steve > > > > -----Original Message----- > > From: Steve Cook [mailto:Steve.Cook@microsoft.com] > > Sent: 16 May 2013 11:54 > > To: Tom Rutt; uml25-ftf@omg.org > > Subject: RE: I posted draft resolutions for Clause 17 Issues for > > Ballot 6 > > > > Tom > > > > I think the resolution for 11068 is wrong. A Lifeline can represent > > a Property that is typed by an Actor. The issue as raised is > > incorrect > > - an Actor is indeed a kind of Type. The issue should be closed, but > > not for > the reason given. > > > > Using Lifelines to represent Actors is a very common user scenario > > and as far as I know is supported by many tools, even to the extent > > of having stick-man headers for the lifeline. This is allowed by > > the following > wording in 17.3.4: > > > > "The Lifeline head has a shape that is based on the classifier for > > the part that this lifeline represents. Often the head is a white > > rectangle containing the name." > > > > Thanks > > -- Steve > > > > -----Original Message----- > > From: Tom Rutt [mailto:tom@coastin.com] > > Sent: 15 May 2013 19:21 > > To: uml25-ftf@omg.org > > Subject: I posted draft resolutions for Clause 17 Issues for Ballot > > 6 > > > > I posted draft resolutions for some more Clause 17 issues for Ballot 6. > > > > > > > > Tom Rutt > > > > -- > > ---------------------------------------------------- > > Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com > > Tel: +1 732 801 5744 Fax: +1 732 774 5133 X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=Wq0Sb7vv c=1 sm=1 tr=0 a=eW53zEZrsyElcQ0NK1QpqA==:117 a=eW53zEZrsyElcQ0NK1QpqA==:17 a=0Bzu9jTXAAAA:8 a=0MobcR2tXA8A:10 a=Ynoq8V6NOrEA:10 a=8nJEP1OIZ-IA:10 a=YYzpnO7rAAAA:8 a=jfIYF3b_Rj0A:10 a=yMhMjlubAAAA:8 a=KHpXyVWLAAAA:8 a=oCcaPWc0AAAA:8 a=4kDmai7qMBmMpHOvlE0A:9 a=wPNLvfGTeEIA:10 a=-AOE9ft50oIA:10 a=WP4_USCxRkkA:10 Date: Thu, 16 May 2013 17:14:18 +0100 From: Ed Willink User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 To: "Bock, Conrad" CC: "uml25-ftf@omg.org" Subject: Re: [UML 2.5 FTF] Ballot 5 -- Preview 3, 18684, inconsistent defaults X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAA== X-Brightmail-Tracker: AAAAAA== Hi Conrad, Steve Conrad: I'm afraid that I cannot understand your point of view at all. Steve: I don't find the clarification very helpful. IMHO there is no formal support for modeller discretion over unspecified multiplicities. The MultiplicityElement::upperBound/lowerBound constraints impose a unity default. The wording clearly defines the merged tree as a short form of the explicit long form. The short form must be a consistent merge so the same adornment is replicated between short and long forms. Therefore an unadorned merge in the short form is a replicated lack of adornment on the long form, and each then defaults to unity. So in so far as clarification is needed, I feel it should say, "Note that unadorned association ends default to unity, unique, unordered multiplicity." Regards Ed Willink On 16/05/2013 14:52, Bock, Conrad wrote: UMLers, The resolution for 18684 (Forked association notation) changes the default multiplicity for properties shown as association ends to something different than is currently assumed in the UML spec for properties shown in compartments (the spec convention is that no multiplicity shown in> property compartment defaults to [1]). Steve doesn't think this is worth discussing anymore (see below). What do others think of this? I don't think it's good to have different defaults in different contexts. I think it's best to leave the absence of multiplicity for associations to be left up to modeler conventions. Conrad -----Original Message----- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Tuesday, May 14, 2013 9:52 AM To: Bock, Conrad; uml25-ftf@omg.org Subject: RE: [UML 2.5 FTF] Ballot 5 -- Preview 3 -- PLEASE READ [snip] - 18684 : Forked association notation ill-formed > > If the note on default multiplicity is going to be changed for > associations, it ought to be similarly noted for properties in > compartments. But the UML spec assumes no multiplicity shown in > property compartment defaults to [1]. I think it's best to leave > the absence of multiplicity for associations to be left up to > modeler conventions. > > The relationship between Figures 11.33 and 11.34 would be clearer > if the window property appeared in Figure 11.3. In particular, it > would make the current sentence above Figure 11.34 (that the > underlying models are the same) more obvious. Changing "same" to > "similar" is very confusing. It's an example, so they can be the > same for clarity in this example. > > At the end of the sentence added by the revised text above Figure > 11.34, it would help to add ", because the properties are separate > in the model even though they have the same name and are notated > with the same segment in Figure 11.34". > > In my view this resolution is good enough and enough time has been spent on it. No change. I don't agree, it introduces inconsistencies. I had let you know that I wouldn't be at the telecon when it was on the agenda. It would have been more efficient to wait to the next week. I'd like to discuss at the next telecon. I do not consider this to be high enough priority to discuss any more. I wish this to go to the FTF for a vote as it is. ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3336 / Virus Database: 3162/6327 - Release Date: 05/15/13 From: Steve Cook To: Ed Willink , "uml25-ftf@omg.org" Subject: RE: [UML 2.5 FTF] Ballot 5 -- Preview 3, 18684, inconsistent defaults Thread-Topic: [UML 2.5 FTF] Ballot 5 -- Preview 3, 18684, inconsistent defaults Thread-Index: Ac5SPHaySYheKoJVTHGpa6K791N2qgAE/PsAAAEz8xAAAW/3AAAoouaA Date: Fri, 17 May 2013 13:01:05 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.166.18.102] X-Forefront-Antispam-Report: CIP:131.107.125.37;CTRY:US;IPV:CAL;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(24454002)(13464003)(199002)(189002)(51704005)(377454002)(479174002)(76482001)(63696002)(49866001)(54356001)(77982001)(56816002)(50986001)(55846006)(67866001)(54316002)(44976003)(80022001)(74706001)(6806003)(51856001)(74876001)(74366001)(512954002)(33656001)(16236675002)(47736001)(66926002)(53806001)(74662001)(79102001)(17760045001)(47976001)(15974865001)(16406001)(59766001)(81542001)(56776001)(47446002)(81342001)(46102001)(31966008)(4396001)(65816001)(71186001)(74502001)(20776003)(16601075002)(69226001)(15202345002);DIR:OUT;SFP:;SCL:1;SRVR:BL2FFO11HUB028;H:TK5EX14HUBC104.redmond.corp.microsoft.com;RD:InfoDomainNonexistent;A:1;MX:1;LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 08497C3D99 X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAh3FFAodxOez X-Brightmail-Tracker: AAAAAA== I really don't want to prolong this conversation, but a few points need to be made. 1. Nothing is being changed here, contrary to what is being claimed. There never was a version of UML 2 in which the absence of a multiplicity notation on an association end determined the value. 2. The BNF for Property, which is used in compartments, explicitly says " is the multiplicity of the Property. If this term is omitted, it implies a multiplicity of 1 (exactly one)." 3. Existing tools allow you to make diagrams of associations which show no multiplicity on the ends, even when the multiplicity is not 1. Here is one made with RSA: So this resolution does not change defaults nor does it break tools. -- Steve -----Original Message----- From: Ed Willink [mailto:ed@willink.me.uk] Sent: 16 May 2013 18:30 To: uml25-ftf@omg.org Subject: Re: [UML 2.5 FTF] Ballot 5 -- Preview 3, 18684, inconsistent defaults Hi Steve Yes but rather subtle. Absence of an explicit value in the merge of all partial models (views) triggers the default. Alternate partial models may indeed have very divergent but consistent values. So perhaps an even better clarification is: "Note that unadorned association ends that are not specified elsewhere default to unity, unique, unordered multiplicity." Regards Ed Willink On 16/05/2013 17:53, Steve Cook wrote: > Ed > > The default you are referring to describes the initial value in the > model, > > > "If there is a defaultValue specified for a Property, this default is evaluated when an instance of the Property is created in the absence of a specific setting for the Property or a constraint in the model that requires the Property to have a specific value." > > This is unrelated to the relationship between the model and diagram. If an element does not appear on the diagram it does not imply that the value is default. > > -- Steve > > -----Original Message----- > From: Ed Willink [mailto:ed@willink.me.uk] > Sent: 16 May 2013 17:14 > To: Bock, Conrad > Cc: uml25-ftf@omg.org > Subject: Re: [UML 2.5 FTF] Ballot 5 -- Preview 3, 18684, inconsistent > defaults > > Hi Conrad, Steve > > Conrad: I'm afraid that I cannot understand your point of view at all. > > Steve: I don't find the clarification very helpful. > > IMHO there is no formal support for modeller discretion over > unspecified multiplicities. The > MultiplicityElement::upperBound/lowerBound > constraints impose a unity default. > > The wording clearly defines the merged tree as a short form of the explicit long form. The short form must be a consistent merge so the same adornment is replicated between short and long forms. Therefore an unadorned merge in the short form is a replicated lack of adornment on the long form, and each then defaults to unity. > > So in so far as clarification is needed, I feel it should say, "Note that unadorned association ends default to unity, unique, unordered multiplicity." > > Regards > > Ed Willink > > On 16/05/2013 14:52, Bock, Conrad wrote: >> UMLers, >> >> The resolution for 18684 (Forked association notation) changes the >> default multiplicity for properties shown as association ends to >> something different than is currently assumed in the UML spec for >> properties shown in compartments (the spec convention is that no >> multiplicity shown in> property compartment defaults to [1]). Steve >> doesn't think this is worth discussing anymore (see below). >> >> What do others think of this? I don't think it's good to have >> different defaults in different contexts. I think it's best to leave >> the absence of multiplicity for associations to be left up to modeler conventions. >> >> Conrad >> >> >> -----Original Message----- >> From: Steve Cook [mailto:Steve.Cook@microsoft.com] >> Sent: Tuesday, May 14, 2013 9:52 AM >> To: Bock, Conrad; uml25-ftf@omg.org >> Subject: RE: [UML 2.5 FTF] Ballot 5 -- Preview 3 -- PLEASE READ >> >> [snip] >> >>> - 18684 : Forked association notation ill-formed >> > >> > If the note on default multiplicity is going to be changed for >> > associations, it ought to be similarly noted for properties in >> > compartments. But the UML spec assumes no multiplicity shown in >> > property compartment defaults to [1]. I think it's best to leave >> > the absence of multiplicity for associations to be left up to >> > modeler conventions. >> > >> > The relationship between Figures 11.33 and 11.34 would be clearer >> > if the window property appeared in Figure 11.3. In particular, it >> > would make the current sentence above Figure 11.34 (that the >> > underlying models are the same) more obvious. Changing "same" to >> > "similar" is very confusing. It's an example, so they can be the >> > same for clarity in this example. >> > >> > At the end of the sentence added by the revised text above Figure >> > 11.34, it would help to add ", because the properties are separate >> > in the model even though they have the same name and are notated >> > with the same segment in Figure 11.34". >> > >> > In my view this resolution is good enough and enough time >> has been spent on it. No change. >> >> I don't agree, it introduces inconsistencies. I had let you know that I wouldn't be at the telecon when it was on the agenda. It would have been more efficient to wait to the next week. I'd like to discuss at the next telecon. >> >> I do not consider this to be high enough priority to discuss >> any more. I wish this to go to the FTF for a vote as it is. >> >> >> ----- >> No virus found in this message. >> Checked by AVG - www.avg.com >> Version: 2013.0.3336 / Virus Database: 3162/6327 - Release Date: >> 05/15/13 >> >> > > > ----- > No virus found in this message. > Checked by AVG - www.avg.com > Version: 2013.0.3336 / Virus Database: 3162/6329 - Release Date: > 05/16/13 > > > From: Steve Cook To: Ed Willink , "Bock, Conrad" CC: "uml25-ftf@omg.org" Subject: RE: [UML 2.5 FTF] Ballot 5 -- Preview 3, 18684, inconsistent defaults Thread-Topic: [UML 2.5 FTF] Ballot 5 -- Preview 3, 18684, inconsistent defaults Thread-Index: Ac5SPHaySYheKoJVTHGpa6K791N2qgAE/PsAAAEz8xA= Date: Thu, 16 May 2013 16:53:09 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.18.103] X-Forefront-Antispam-Report: CIP:131.107.125.37;CTRY:US;IPV:CAL;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(189002)(377454002)(479174002)(199002)(13464003)(51704005)(24454002)(74876001)(56816002)(6806003)(56776001)(74366001)(74662001)(16406001)(79102001)(59766001)(47446002)(74502001)(69226001)(81542001)(74706001)(47736001)(46102001)(51856001)(4396001)(81342001)(50986001)(44976003)(80022001)(65816001)(31966008)(49866001)(54316002)(76482001)(53806001)(77982001)(63696002)(20776003)(46406003)(47976001)(50466002)(15974865001)(23726002)(33656001)(55846006)(54356001)(47776003);DIR:OUT;SFP:;SCL:1;SRVR:BL2FFO11HUB022;H:TK5EX14HUBC102.redmond.corp.microsoft.com;RD:InfoDomainNonexistent;MX:1;A:1;LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0848C1A6AA X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id r4GGrQYf030384 Ed The default you are referring to describes the initial value in the model, "If there is a defaultValue specified for a Property, this default is evaluated when an instance of the Property is created in the absence of a specific setting for the Property or a constraint in the model that requires the Property to have a specific value." This is unrelated to the relationship between the model and diagram. If an element does not appear on the diagram it does not imply that the value is default. -- Steve -----Original Message----- From: Ed Willink [mailto:ed@willink.me.uk] Sent: 16 May 2013 17:14 To: Bock, Conrad Cc: uml25-ftf@omg.org Subject: Re: [UML 2.5 FTF] Ballot 5 -- Preview 3, 18684, inconsistent defaults Hi Conrad, Steve Conrad: I'm afraid that I cannot understand your point of view at all. Steve: I don't find the clarification very helpful. IMHO there is no formal support for modeller discretion over unspecified multiplicities. The MultiplicityElement::upperBound/lowerBound constraints impose a unity default. The wording clearly defines the merged tree as a short form of the explicit long form. The short form must be a consistent merge so the same adornment is replicated between short and long forms. Therefore an unadorned merge in the short form is a replicated lack of adornment on the long form, and each then defaults to unity. So in so far as clarification is needed, I feel it should say, "Note that unadorned association ends default to unity, unique, unordered multiplicity." Regards Ed Willink On 16/05/2013 14:52, Bock, Conrad wrote: > UMLers, > > The resolution for 18684 (Forked association notation) changes the > default multiplicity for properties shown as association ends to > something different than is currently assumed in the UML spec for > properties shown in compartments (the spec convention is that no > multiplicity shown in> property compartment defaults to [1]). Steve > doesn't think this is worth discussing anymore (see below). > > What do others think of this? I don't think it's good to have > different defaults in different contexts. I think it's best to leave > the absence of multiplicity for associations to be left up to modeler conventions. > > Conrad > > > -----Original Message----- > From: Steve Cook [mailto:Steve.Cook@microsoft.com] > Sent: Tuesday, May 14, 2013 9:52 AM > To: Bock, Conrad; uml25-ftf@omg.org > Subject: RE: [UML 2.5 FTF] Ballot 5 -- Preview 3 -- PLEASE READ > > [snip] > >> - 18684 : Forked association notation ill-formed > > > > If the note on default multiplicity is going to be changed for > > associations, it ought to be similarly noted for properties in > > compartments. But the UML spec assumes no multiplicity shown in > > property compartment defaults to [1]. I think it's best to leave > > the absence of multiplicity for associations to be left up to > > modeler conventions. > > > > The relationship between Figures 11.33 and 11.34 would be clearer > > if the window property appeared in Figure 11.3. In particular, it > > would make the current sentence above Figure 11.34 (that the > > underlying models are the same) more obvious. Changing "same" to > > "similar" is very confusing. It's an example, so they can be the > > same for clarity in this example. > > > > At the end of the sentence added by the revised text above Figure > > 11.34, it would help to add ", because the properties are separate > > in the model even though they have the same name and are notated > > with the same segment in Figure 11.34". > > > > In my view this resolution is good enough and enough time > has been spent on it. No change. > > I don't agree, it introduces inconsistencies. I had let you know that I wouldn't be at the telecon when it was on the agenda. It would have been more efficient to wait to the next week. I'd like to discuss at the next telecon. > > I do not consider this to be high enough priority to discuss > any more. I wish this to go to the FTF for a vote as it is. > > > ----- > No virus found in this message. > Checked by AVG - www.avg.com > Version: 2013.0.3336 / Virus Database: 3162/6327 - Release Date: > 05/15/13 > > From: "Bock, Conrad" To: "uml25-ftf@omg.org" Date: Thu, 16 May 2013 13:18:16 -0400 Subject: RE: [UML 2.5 FTF] Ballot 5 -- Preview 3, 18684, inconsistent defaults Thread-Topic: [UML 2.5 FTF] Ballot 5 -- Preview 3, 18684, inconsistent defaults Thread-Index: Ac5SUHPmy8uAfFcSRKa3Y2on9/vl9wACLrpw Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Virus-Scanned: amavisd-new at omg.org Ed, > So in so far as clarification is needed, I feel it should say, "Note > that unadorned association ends default to unity, unique, unordered > multiplicity." I agree, this would be consistent at with the UML spec properties shown in compartments. Presumably the same should be said about properties in compartments, if it isn't already. Conrad From: "Bock, Conrad" To: "uml25-ftf@omg.org" Date: Thu, 16 May 2013 13:24:37 -0400 Subject: RE: [UML 2.5 FTF] Ballot 5 -- Preview 3, 18684, inconsistent defaults Thread-Topic: [UML 2.5 FTF] Ballot 5 -- Preview 3, 18684, inconsistent defaults Thread-Index: Ac5SPHaySYheKoJVTHGpa6K791N2qgAE/PsAAAEz8xAAAQnhIA== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Virus-Scanned: amavisd-new at omg.org Steve, > The default you are referring to describes the initial value in the model, > This is unrelated to the relationship between the model and diagram. If an > element does not appear on the diagram it does not imply that the value is > default. Yes, but when UML spec doesn't show property multiplicities in compartments they are taken as the same as the default, while the change in 18684 establishes something different for properties shown on associations. It doesn't seem like we should have such context-dependent differences. For example, should the reader make no assumption about the multiplicities of properties in the UML spec when the multiplicity isn't shown in compartments? Conrad X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=Wq0Sb7vv c=1 sm=1 tr=0 a=eW53zEZrsyElcQ0NK1QpqA==:117 a=eW53zEZrsyElcQ0NK1QpqA==:17 a=0Bzu9jTXAAAA:8 a=0MobcR2tXA8A:10 a=Ynoq8V6NOrEA:10 a=8nJEP1OIZ-IA:10 a=YYzpnO7rAAAA:8 a=jfIYF3b_Rj0A:10 a=KHpXyVWLAAAA:8 a=yMhMjlubAAAA:8 a=oCcaPWc0AAAA:8 a=RYgGa77Wdy420N01UE4A:9 a=XrvTeji25Xs5uWV2:21 a=Dy7qhwsFrp4JMXrX:21 a=wPNLvfGTeEIA:10 a=WP4_USCxRkkA:10 a=-AOE9ft50oIA:10 Date: Thu, 16 May 2013 18:29:54 +0100 From: Ed Willink User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 To: "uml25-ftf@omg.org" Subject: Re: [UML 2.5 FTF] Ballot 5 -- Preview 3, 18684, inconsistent defaults X-Virus-Scanned: amavisd-new at omg.org Hi Steve Yes but rather subtle. Absence of an explicit value in the merge of all partial models (views) triggers the default. Alternate partial models may indeed have very divergent but consistent values. So perhaps an even better clarification is: "Note that unadorned association ends that are not specified elsewhere default to unity, unique, unordered multiplicity." Regards Ed Willink On 16/05/2013 17:53, Steve Cook wrote: Ed The default you are referring to describes the initial value in the model, "If there is a defaultValue specified for a Property, this default is evaluated when an instance of the Property is created in the absence of a specific setting for the Property or a constraint in the model that requires the Property to have a specific value." This is unrelated to the relationship between the model and diagram. If an element does not appear on the diagram it does not imply that the value is default. -- Steve -----Original Message----- From: Ed Willink [mailto:ed@willink.me.uk] Sent: 16 May 2013 17:14 To: Bock, Conrad Cc: uml25-ftf@omg.org Subject: Re: [UML 2.5 FTF] Ballot 5 -- Preview 3, 18684, inconsistent defaults Hi Conrad, Steve Conrad: I'm afraid that I cannot understand your point of view at all. Steve: I don't find the clarification very helpful. IMHO there is no formal support for modeller discretion over unspecified multiplicities. The MultiplicityElement::upperBound/lowerBound constraints impose a unity default. The wording clearly defines the merged tree as a short form of the explicit long form. The short form must be a consistent merge so the same adornment is replicated between short and long forms. Therefore an unadorned merge in the short form is a replicated lack of adornment on the long form, and each then defaults to unity. So in so far as clarification is needed, I feel it should say, "Note that unadorned association ends default to unity, unique, unordered multiplicity." Regards Ed Willink On 16/05/2013 14:52, Bock, Conrad wrote: UMLers, The resolution for 18684 (Forked association notation) changes the default multiplicity for properties shown as association ends to something different than is currently assumed in the UML spec for properties shown in compartments (the spec convention is that no multiplicity shown in> property compartment defaults to [1]). Steve doesn't think this is worth discussing anymore (see below). What do others think of this? I don't think it's good to have different defaults in different contexts. I think it's best to leave the absence of multiplicity for associations to be left up to modeler conventions. Conrad -----Original Message----- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Tuesday, May 14, 2013 9:52 AM To: Bock, Conrad; uml25-ftf@omg.org Subject: RE: [UML 2.5 FTF] Ballot 5 -- Preview 3 -- PLEASE READ [snip] - 18684 : Forked association notation ill-formed > > If the note on default multiplicity is going to be changed for > associations, it ought to be similarly noted for properties in > compartments. But the UML spec assumes no multiplicity shown in > property compartment defaults to [1]. I think it's best to leave > the absence of multiplicity for associations to be left up to > modeler conventions. > > The relationship between Figures 11.33 and 11.34 would be clearer > if the window property appeared in Figure 11.3. In particular, it > would make the current sentence above Figure 11.34 (that the > underlying models are the same) more obvious. Changing "same" to > "similar" is very confusing. It's an example, so they can be the > same for clarity in this example. > > At the end of the sentence added by the revised text above Figure > 11.34, it would help to add ", because the properties are separate > in the model even though they have the same name and are notated > with the same segment in Figure 11.34". > > In my view this resolution is good enough and enough time has been spent on it. No change. I don't agree, it introduces inconsistencies. I had let you know that I wouldn't be at the telecon when it was on the agenda. It would have been more efficient to wait to the next week. I'd like to discuss at the next telecon. I do not consider this to be high enough priority to discuss any more. I wish this to go to the FTF for a vote as it is. ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3336 / Virus Database: 3162/6327 - Release Date: 05/15/13 ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3336 / Virus Database: 3162/6329 - Release Date: 05/16/13