Issue 6464: UML 2 Issue: isUnique (uml2-rtf) Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org) Nature: Uncategorized Issue Severity: Summary: PROBLEM STATEMENT "When one or more ends of the association have isUnique=false, it is possible to have several links associating the same set of instances." (Superstructure, p. 81) As Pierre-Alain Muller demonstrated in an informal conversation with Bran Selic during a lunch in San Francisco in the last UML Conference (I also was taking part in that conversation), isUnique must have the same value for all ends in an association. This has implications, for example, for the property strings that can be placed near the association ends ({ordered}, {bag}, {seq}). According to the table in Superstructure, p. 92, if one end is a Set or an OrderedSet, then the opposite end must be a Set or an OrderedSet, too; and if one end is a Bag or a Sequence, then the opposite end must be a Bag or a Sequence, too. PROPOSED SOLUTION Explain this in the Spec. Resolution: This topic is discussed in detail in DraganMilicev’s paper at http://afrodita.rcub.bg.ac.rs/ dmilicev/pubs/mdd/ trumlassoc.zip. In the paper he proposes that the collection that provides the value of a property that is an association end is derived from the links that instantiate the association as modified by the isUnique marking. So, even if there are two links targeting an instance in the extent of the association, if the property is marked as unique then there will only be one instance in the collection. This interpretation allows there to be associations with mixed unique/nonunique ends. After discussion the FTF thinks that this interpretation is in fact the intended interpretation of the current spec, and should be clarified as such. Milicev also points out that AssociationClasses make the identity of links visible in the semantics, and in contrast to what the spec currently suggests, it is possible to have multiple instances of an AssociationClass that associate the same set of end instances, regardless of the uniqueness marking of the ends. This is clarified in the current resolution. Milicev proposes adding an isUnique property to AssociationClass to give the power to rule out such multiple instances. Adding such a property is outside the scope of UML 2.5. This resolution also clarifies that property subsetting applies to property values coerced to sets. Currently nonunique B could be marked as subsetting unique A. If B contains the same value twice and A contains it once, then that should be legal, even though the size of the value of B is larger than that of A. The resolution also accounts for the use of qualifiers, makes some improvements to the definition and use of the term “cardinality”, and corrects the semantics of CreateLinkAction to correspond to the clarified definition. This also resolves issue 5977. Revised Text: In clause 7.5.3, replace the sentence: The multiplicity is a constraint on the number of values that may validly occur in that set. by: The size of that collection is called its cardinality. The multiplicity is a constraint on the cardinality, which must be not less than the lower bound and not greater than the upper bound. In clause 11.5.3, replace the following paragraph: For an Association with N memberEnds, choose any N-1 ends and associate specific instances with those ends. Then the collection of links of the Association that refer to these specific instances will identify a collection of instances at the other end. The multiplicity of the other end constrains the size of this collection. If the other end is marked as isOrdered, this collection will be ordered. If the other end is marked as isUnique, this collection is a set; otherwise, it allows duplicate elements. Replace it with: For an Association with N memberEnds, choose any N-1 ends. Let the Property that constitutes the other end be called oep, so that the Classifiers at the chosen N-1 ends are the context for oep (see 9.5.3). Associate specific instances with the context ends. Then the collection of links of the Association that refer to these specific instances will identify a set of instances at oep. The value represented by oep (see 9.5.3) is a collection calculated from this set as follows: All of the instances in the set occur in the collection, and nothing else does. If oep is marked as unique, each instance will occur in the collection just once, regardless of how many links connect to it. If oep is marked as nonunique, each instance will occur in the collection once for each link that connects to it. If oep is marked as ordered, the collection will be ordered in accordance with the ordering information in the links. The cardinality of this collection is its size. The multiplicity of oep constrains this cardinality, or in the case of qualified associations, the size of the collection partition that may be associated with a qualifier value. In 11.5.3, the semantics of AssociationClasses, replace this: NOTE. When one or more ends of the AssociationClass have isUnique=false, it is possible to have several instances associating the same set of instances of the end Classes. By this: NOTE. Even when all ends of the AssociationClass have isUnique=true, it is possible to have several instances associating the same set of instances of the end Classes. In the semantics of Property 9.5.3, replace this: A Property may be marked as the subset of another subsettedProperty. In this case, the collection of values denoted by the subsetting property in some context shall be included in (or the same as) the collection of values denoted by the subsettedProperty in the same context. By this: A Property may be marked as the subset of another subsettedProperty. In this case, calculate a set by eliminating duplicates from the collection of values denoted by the subsetting property in some context. Then that set shall be included in (or the same as) a set calculated by eliminating duplicates from the collection of values denoted by the subsettedProperty in the same context. In the semantics of Association, replace this paragraph: Subsetting represents the familiar set-theoretic concept. It applies to the collections represented by Association ends, not to the Association itself. It means that the subsetting Association end represents a collection that is either equal to or a proper subset of the collection that it is subsetting. Subsetting is a relationship in the domain of extensional semantics. By this: Subsetting of association ends has the meaning specified for Property (see 9.5.3). And replace this sentence: Semantically this implies that the collections representing the ends of the specializing association are subsets of the corresponding collections representing the ends of the specialized association; this fact of subsetting may or may not be explicitly declared in a model. By this: Semantically this implies that sets calculated by eliminating duplicates from the collections representing the ends of the specializing association are subsets of the corresponding sets calculated by eliminating duplicates from collections representing the ends of the specialized association; this fact of subsetting may or may not be explicitly declared in a model. In clause 16.6.3, semantics of CreateLinkAction, replace this sentence: The cardinality of an end is equal to the number of links with objects participating in the other ends that are the same as those participating in those other ends in the new link, and with qualifier values on all ends the same as the new link, if any. By the following: The cardinality of an end is defined in 11.5.3. Use the omg-property style correctly throughout these substitutions. Actions taken: November 7, 2003: received issue February 18, 2005: moved from infrastructure February 20, 2015: closed issue Discussion: Disposition: Deferred to UML 2.4 RTF End of Annotations:===== ubject: Fw: UML 2 Issue: isUnique X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Fri, 7 Nov 2003 08:31:01 -0500 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 11/07/2003 08:31:08, Serialize complete at 11/07/2003 08:31:08 Issue raised by Gonzalo Genova. 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 ----- Forwarded by Branislav Selic/Ottawa/IBM on 11/07/2003 07:49 AM ----- Gonzalo Genova 11/06/2003 01:34 PM To: "'issues@omg.org'" , Branislav Selic/Ottawa/IBM@IBMCA, "'pa.muller@uha.fr'" cc: "Juan Llorens (inf)" , "J.Miguel Fuentes Torres" Subject: UML 2 Issue: isUnique This issue refers to UML 2.0 Infrastructure Specification (ptc/03-09-15) and UML 2.0 Superstructure Specification (ptc/03-08-02). PROBLEM STATEMENT "When one or more ends of the association have isUnique=false, it is possible to have several links associating the same set of instances." (Superstructure, p. 81) As Pierre-Alain Muller demonstrated in an informal conversation with Bran Selic during a lunch in San Francisco in the last UML Conference (I also was taking part in that conversation), isUnique must have the same value for all ends in an association. This has implications, for example, for the property strings that can be placed near the association ends ({ordered}, {bag}, {seq}). According to the table in Superstructure, p. 92, if one end is a Set or an OrderedSet, then the opposite end must be a Set or an OrderedSet, too; and if one end is a Bag or a Sequence, then the opposite end must be a Bag or a Sequence, too. PROPOSED SOLUTION Explain this in the Spec. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:from:date:x-google-sender-auth :message-id:subject:to:content-type; bh=lpVDABfu1IGbqUcXg5pt/Ph60ESmxCAwPKfmLpdvfaA=; b=v6V2sqQd+4wQFE7cEMb5IduptsUmjSOc7MF1ST4RW1RAhgwutKCiCJGq1DPj8nfW6O gAMEwcUvCyQJMfJflbAbFlS5TijrrWUhpNhl7FhxPlH34ExPgcWkTQaFHqkQqXGmMKP+ P6R7iXOPNQe+iaTw9zRn2jYy9MLH3l4k5sEgXTtN/5irMA26aRN0Vx45pPIszkmBAF3D IiE5/WRI++0xp8E4dXKPTR8wVu1p/0omFkpp9PXEqRAuxG8QeHlYJLSYCevo3Y/0K+aH 4c+pxJ2LNEFLR2br5tey5a91c/SOj93NDE/kPr6xYhwFP41fvmDueb12HEBC8hVjw9dq jz3Q== X-Received: by 10.52.95.39 with SMTP id dh7mr1704004vdb.26.1367947414766; Tue, 07 May 2013 10:23:34 -0700 (PDT) Sender: bran.selic@gmail.com From: Bran Selic Date: Tue, 7 May 2013 13:22:54 -0400 X-Google-Sender-Auth: OqHt-18XXvvl_Oh3oSRwTVEw5SE Subject: Resolution 6464 - doubts To: "uml25-ftf@omg.org" X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAA== X-Brightmail-Tracker: AAAAAA== Although I had agreed with the submitter of the issue at the time, I've had doubts about whether or not "isUnique" necessarily has to apply to both ends of an association. The doubt is prompted by the so-called "Milicev interpretation" of links. Namely, in his excellent book on UML, Miliceve provides one possible interpretation of links in which a bidirectional link can be interpreted as representing two mappings: one from an instance of class A to one or more instances of class B (depending on multiplicity), representing one end of the association, while the other end is represented by a mapping going in the opposite direction, from class B to class A. In that interpretation, it is possible for the "isUnique" property to be different for the two ends. If you read the text of the spec (but excluding fUML), there is, as far as I can tell, nothing that prevents this interpretation, which, in my view is not an unreasonable one -- even though I personally never thought of a link that way when I first encountered the concept. So, I would prefer this issue to be discussed further before we decide on the resolution, especially since I know of at least one tool that has adopted this interpretation. Bran X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=XMMJF2RE c=1 sm=1 tr=0 a=eW53zEZrsyElcQ0NK1QpqA==:117 a=eW53zEZrsyElcQ0NK1QpqA==:17 a=0Bzu9jTXAAAA:8 a=0MobcR2tXA8A:10 a=8nJEP1OIZ-IA:10 a=YYzpnO7rAAAA:8 a=GLk8ytPYtoUA:10 a=pGLkceISAAAA:8 a=oCcaPWc0AAAA:8 a=UEsl2iB30DY3RVxiJ4QA:9 a=Ov5kao9bMN50j8-C:21 a=wPNLvfGTeEIA:10 a=_W_S_7VecoQA:10 Date: Tue, 07 May 2013 18:37:25 +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: Resolution 6464 - doubts X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAA== X-Brightmail-Tracker: AAAAAA== Hi Ecore (and I think EMOF too) have independent isUnique. Regards Ed Willink On 07/05/2013 18:22, Bran Selic wrote: Although I had agreed with the submitter of the issue at the time, I've had doubts about whether or not "isUnique" necessarily has to apply to both ends of an association. The doubt is prompted by the so-called "Milicev interpretation" of links. Namely, in his excellent book on UML, Miliceve provides one possible interpretation of links in which a bidirectional link can be interpreted as representing two mappings: one from an instance of class A to one or more instances of class B (depending on multiplicity), representing one end of the association, while the other end is represented by a mapping going in the opposite direction, from class B to class A. In that interpretation, it is possible for the "isUnique" property to be different for the two ends. If you read the text of the spec (but excluding fUML), there is, as far as I can tell, nothing that prevents this interpretation, which, in my view is not an unreasonable one -- even though I personally never thought of a link that way when I first encountered the concept. So, I would prefer this issue to be discussed further before we decide on the resolution, especially since I know of at least one tool that has adopted this interpretation. Bran No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3272 / Virus Database: 3162/6306 - Release Date: 05/07/13 From: Steve Cook To: Bran Selic , "uml25-ftf@omg.org" Subject: RE: Resolution 6464 - doubts Thread-Topic: Resolution 6464 - doubts Thread-Index: AQHOS0eCbIyk0bODQUqereLJw60VqZj6FCLA Date: Tue, 7 May 2013 19:29:14 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: 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:(189002)(199002)(46102001)(74366001)(56776001)(65816001)(79102001)(81542001)(76482001)(54316002)(20776003)(4396001)(63696002)(80022001)(50986001)(47976001)(51856001)(77982001)(49866001)(47736001)(74876001)(15202345002)(53806001)(81342001)(74662001)(74502001)(47446002)(16236675002)(69226001)(54356001)(74706001)(31966008)(71186001)(59766001)(55846006)(16406001)(56816002)(6806003)(512954002)(33656001);DIR:OUT;SFP:;SCL:1;SRVR:BN1AFFO11HUB012;H:TK5EX14HUBC101.redmond.corp.microsoft.com;RD:InfoDomainNonexistent;MX:1;A:1;LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0839D067E7 X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAR15Gpo= X-Brightmail-Tracker: AAAAAA== What I understand Milicev to be saying is that regardless of how many links actually connect to an instance, if that end of the association is marked as unique, then the instance only appears once in the result. I.e., the .uniqueness. refers to the way that the set of connected instances is derived from the links, rather than to the links themselves. This is, I think, clearly ruled out by the following text in 11.5.3: For an Association with N memberEnds, choose any N-1 ends and associate specific instances with those ends. Then the collection of links of the Association that refer to these specific instances will identify a collection of instances at the other end. The multiplicity of the other end constrains the size of this collection. If the other end is marked as isOrdered, this collection will be ordered. If the other end is marked as isUnique, this collection is a set; otherwise, it allows duplicate elements. If we were to adopt Milicev.s semantics, we.d need to clearly distinguish between the collection of instances represented by the value of the property, vs the underlying links. It would also affect the definition of multiplicity. Currently, multiplicity constrains the number of links, not the number of objects in the collection; and with Milicev.s interpretation there could be (say) 2 links and one object. Adopting Milicev.s semantics would be a major and disruptive change. However, if we were to permit Milicev to conform to the abstract syntax but not the semantics, then we.d need to not have the constraint. In which case we.d need some words to admit this possibility. I am open to this as a way forward. Maybe we can discuss next week. -- Steve From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: 07 May 2013 18:23 To: uml25-ftf@omg.org Subject: Resolution 6464 - doubts Although I had agreed with the submitter of the issue at the time, I've had doubts about whether or not "isUnique" necessarily has to apply to both ends of an association. The doubt is prompted by the so-called "Milicev interpretation" of links. Namely, in his excellent book on UML, Miliceve provides one possible interpretation of links in which a bidirectional link can be interpreted as representing two mappings: one from an instance of class A to one or more instances of class B (depending on multiplicity), representing one end of the association, while the other end is represented by a mapping going in the opposite direction, from class B to class A. In that interpretation, it is possible for the "isUnique" property to be different for the two ends. If you read the text of the spec (but excluding fUML), there is, as far as I can tell, nothing that prevents this interpretation, which, in my view is not an unreasonable one -- even though I personally never thought of a link that way when I first encountered the concept. So, I would prefer this issue to be discussed further before we decide on the resolution, especially since I know of at least one tool that has adopted this interpretation. Bran DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=ZgE+Bb0mDp6hOCxANkVMtZ9GJ478a8gQpWaRAR+HMmA=; b=UoDNwzx3fF6UZvY6RfSjTGo7sRmMX8cJNDmI9gPEPws5xtxjJenfofs6wb6y0RRfkU oe+XBvtYzJjTdHQ+Or/hMjRMZS6Gk4HOTO6cpMGLCTP7QLda9JC2BkJROks180faMhWU 0b5sBQDnj7U4GZpxvRH6Rz6ZXOfeMhrn0u0W+v+xPgOFHbeuUC6BsWDNM0JqR+oE6r5F UWsiWHEH7OVKBqKqbFbH/6doK2xL9pMlsQPUmaoIBWpCpvcoHLEefxNKDU6lKLqrO4GT uDRX2wYT//zRu/qIfqYyX/okNelBYYLE4LKOhq7cXWHEdlvxEY9TidTVGwXtcpcZoa4A 152g== X-Received: by 10.220.100.138 with SMTP id y10mr3658450vcn.51.1367998736273; Wed, 08 May 2013 00:38:56 -0700 (PDT) Sender: bran.selic@gmail.com From: Bran Selic Date: Wed, 8 May 2013 03:38:15 -0400 X-Google-Sender-Auth: KaZsK6cdro88r5oa9wh_UIjyVvI Subject: Re: Resolution 6464 - doubts To: Steve Cook Cc: "uml25-ftf@omg.org" X-Virus-Scanned: amavisd-new at omg.org On Tue, May 7, 2013 at 3:29 PM, Steve Cook wrote: What I understand Milicev to be saying is that regardless of how many links actually connect to an instance, if that end of the association is marked as unique, then the instance only appears once in the result. I.e., the .uniqueness. refers to the way that the set of connected instances is derived from the links, rather than to the links themselves. [bvs] I am not sure that this is how I view it. My understanding is that it means that a link can be interpreted as two mappings in complementary directions, rather than as a unique entity. Reducing this to one possible realization, we can imagine that each end is realized by a reference or pointer, each with its own properties. Hence, the fact that a mapping (pointer) in one direction is unique, does not necessarily imply that the complementary mapping has to be unique as well. This is, I think, clearly ruled out by the following text in 11.5.3: For an Association with N memberEnds, choose any N-1 ends and associate specific instances with those ends. Then the collection of links of the Association that refer to these specific instances will identify a collection of instances at the other end. The multiplicity of the other end constrains the size of this collection. If the other end is marked as isOrdered, this collection will be ordered. If the other end is marked as isUnique, this collection is a set; otherwise, it allows duplicate elements. [bvs] I fail to see how this rules out the possibility above, since it only discusses the meaning of one end. It seems to me that the key lies in whether a link is treated as an atomic unit or as a pair of mappings (for binary associations, but this can be generalized). The latter, of course, is how a link could be realized in an OO implementation (as in Ecore). To be clear, I do not think it is a question of one or the other, but whether we support both. [bvs] It would be good to discuss this -- I'll try to make the next telecon, although due to travel I am not sure I will be able to make it. Cheers...Bran From: Steve Cook To: Bran Selic CC: "uml25-ftf@omg.org" Subject: RE: Resolution 6464 - doubts Thread-Topic: Resolution 6464 - doubts Thread-Index: AQHOS0eCbIyk0bODQUqereLJw60VqZj6FCLAgADTToCAAAlMYA== Date: Wed, 8 May 2013 08:25:23 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: 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:(189002)(199002)(377454002)(24454002)(20776003)(4396001)(47736001)(16406001)(6806003)(56816002)(56776001)(50986001)(47976001)(33656001)(54316002)(8558605002)(77982001)(79102001)(49866001)(55846006)(74366001)(63696002)(15202345002)(16236675002)(80022001)(74876001)(69226001)(74706001)(44976003)(53806001)(46102001)(47446002)(31966008)(71186001)(512954002)(74502001)(81342001)(51856001)(74662001)(81542001)(59766001)(54356001)(65816001)(76482001);DIR:OUT;SFP:;SCL:1;SRVR:BL2FFO11HUB025;H:TK5EX14MLTC102.redmond.corp.microsoft.com;RD:InfoDomainNonexistent;MX:1;A:1;LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 084080FC15 X-Virus-Scanned: amavisd-new at omg.org Bran His paper explaining all of this in detail is available online at http://afrodita.rcub.bg.ac.rs/~dmilicev/pubs/mdd/trumlassoc.zip. -- Steve From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: 08 May 2013 08:38 To: Steve Cook Cc: uml25-ftf@omg.org Subject: Re: Resolution 6464 - doubts On Tue, May 7, 2013 at 3:29 PM, Steve Cook wrote: What I understand Milicev to be saying is that regardless of how many links actually connect to an instance, if that end of the association is marked as unique, then the instance only appears once in the result. I.e., the .uniqueness. refers to the way that the set of connected instances is derived from the links, rather than to the links themselves. [bvs] I am not sure that this is how I view it. My understanding is that it means that a link can be interpreted as two mappings in complementary directions, rather than as a unique entity. Reducing this to one possible realization, we can imagine that each end is realized by a reference or pointer, each with its own properties. Hence, the fact that a mapping (pointer) in one direction is unique, does not necessarily imply that the complementary mapping has to be unique as well. This is, I think, clearly ruled out by the following text in 11.5.3: For an Association with N memberEnds, choose any N-1 ends and associate specific instances with those ends. Then the collection of links of the Association that refer to these specific instances will identify a collection of instances at the other end. The multiplicity of the other end constrains the size of this collection. If the other end is marked as isOrdered, this collection will be ordered. If the other end is marked as isUnique, this collection is a set; otherwise, it allows duplicate elements. [bvs] I fail to see how this rules out the possibility above, since it only discusses the meaning of one end. It seems to me that the key lies in whether a link is treated as an atomic unit or as a pair of mappings (for binary associations, but this can be generalized). The latter, of course, is how a link could be realized in an OO implementation (as in Ecore). To be clear, I do not think it is a question of one or the other, but whether we support both. [bvs] It would be good to discuss this -- I'll try to make the next telecon, although due to travel I am not sure I will be able to make it. Cheers...Bran From: Steve Cook To: Bran Selic , "uml25-ftf@omg.org" Subject: RE: Resolution 6464 - doubts Thread-Topic: Resolution 6464 - doubts Thread-Index: AQHOS0eCbIyk0bODQUqereLJw60VqZj6FCLAgADTToCAAAlMYIAAEiNQ Date: Wed, 8 May 2013 09:30:37 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: 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)(189002)(199002)(377454002)(79102001)(74502001)(8558605002)(54356001)(51856001)(53806001)(55846006)(65816001)(33656001)(56776001)(44976003)(47446002)(74662001)(31966008)(6806003)(80022001)(76482001)(20776003)(54316002)(81542001)(63696002)(77982001)(16236675002)(512954002)(46102001)(15202345002)(74876001)(69226001)(47736001)(50986001)(4396001)(47976001)(49866001)(81342001)(74706001)(16406001)(59766001)(56816002)(71186001)(74366001);DIR:OUT;SFP:;SCL:1;SRVR:BL2FFO11HUB024;H:TK5EX14MLTC104.redmond.corp.microsoft.com;RD:InfoDomainNonexistent;MX:1;A:1;LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 084080FC15 X-Virus-Scanned: amavisd-new at omg.org Having now read through this paper, Milicev makes some excellent points and so I would like to withdraw the proposed resolution 6464 (and its duplicate 5977). I am somewhat persuaded to clarify the spec using his approach, and I would like other people to read this paper so we can discuss it. The essence of it is the exact meaning of the phrase .will identify a collection. in the text I quoted earlier. With the .restrictive. interpretation, the collection of links directly determines the collection of instances. With the .intentional. interpretation, the collection of instances is further constrained by the uniqueness marking, so even if there are duplicate links there may still be a single instance. The compelling example for me is figure 3(b) and the accompanying text, where he points out that a container that composes a bag of elements is essentially impossible under the .restrictive. interpretation . any element that is contained more than once will violate the maximum 1 multiplicity on composition. This seems like a showstopper to me. Thanks -- Steve From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 08 May 2013 09:25 To: Bran Selic Cc: uml25-ftf@omg.org Subject: RE: Resolution 6464 - doubts Bran His paper explaining all of this in detail is available online at http://afrodita.rcub.bg.ac.rs/~dmilicev/pubs/mdd/trumlassoc.zip. -- Steve From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: 08 May 2013 08:38 To: Steve Cook Cc: uml25-ftf@omg.org Subject: Re: Resolution 6464 - doubts On Tue, May 7, 2013 at 3:29 PM, Steve Cook wrote: What I understand Milicev to be saying is that regardless of how many links actually connect to an instance, if that end of the association is marked as unique, then the instance only appears once in the result. I.e., the .uniqueness. refers to the way that the set of connected instances is derived from the links, rather than to the links themselves. [bvs] I am not sure that this is how I view it. My understanding is that it means that a link can be interpreted as two mappings in complementary directions, rather than as a unique entity. Reducing this to one possible realization, we can imagine that each end is realized by a reference or pointer, each with its own properties. Hence, the fact that a mapping (pointer) in one direction is unique, does not necessarily imply that the complementary mapping has to be unique as well. This is, I think, clearly ruled out by the following text in 11.5.3: For an Association with N memberEnds, choose any N-1 ends and associate specific instances with those ends. Then the collection of links of the Association that refer to these specific instances will identify a collection of instances at the other end. The multiplicity of the other end constrains the size of this collection. If the other end is marked as isOrdered, this collection will be ordered. If the other end is marked as isUnique, this collection is a set; otherwise, it allows duplicate elements. [bvs] I fail to see how this rules out the possibility above, since it only discusses the meaning of one end. It seems to me that the key lies in whether a link is treated as an atomic unit or as a pair of mappings (for binary associations, but this can be generalized). The latter, of course, is how a link could be realized in an OO implementation (as in Ecore). To be clear, I do not think it is a question of one or the other, but whether we support both. [bvs] It would be good to discuss this -- I'll try to make the next telecon, although due to travel I am not sure I will be able to make it. Cheers...Bran X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=XMMJF2RE c=1 sm=1 tr=0 a=eW53zEZrsyElcQ0NK1QpqA==:117 a=eW53zEZrsyElcQ0NK1QpqA==:17 a=0Bzu9jTXAAAA:8 a=0MobcR2tXA8A:10 a=8nJEP1OIZ-IA:10 a=YYzpnO7rAAAA:8 a=GLk8ytPYtoUA:10 a=yMhMjlubAAAA:8 a=KHpXyVWLAAAA:8 a=HNVTiTzpAAAA:8 a=pGLkceISAAAA:8 a=oCcaPWc0AAAA:8 a=VXWOgDI2fhq5jWA4v30A:9 a=rPd522YhiFvWuy4J:21 a=wPNLvfGTeEIA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=6UIaq3Bcl8oA:10 a=_W_S_7VecoQA:10 a=frz4AuCg-hUA:10 a=tXsnliwV7b4A:10 a=-AOE9ft50oIA:10 a=WP4_USCxRkkA:10 a=MSl-tDqOz04A:10 Date: Wed, 08 May 2013 21:00:55 +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: Resolution 6464 - doubts X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAR15Gpo= X-Brightmail-Tracker: AAAAAA== Hi I was convinced by Milicev's paper initially. I then took a shot at implementing Fig 2 with EMF, raised a Bugzilla and had to think instead. I now don't like the idea, the additional power seems to be dangerous and cute and the 'extra' expressive power is easily supported by asSet(). The routes example ================= R1: "Balkans Tour" { Belgrade, Sarajevo, Athens, Rhodes, Istanbul, Sofia, Bucharest, Belgrade} Route::city[*] {nonunique, ordered} -- no problem here City::route[*] {unique, ordered} -- problem here since Belgrade is on R1 twice. It seems to me that City::route could be declared as nonunique eliminating the problem then if the intentional interpretation is required the access performs b.route->asSet(). The difference between the two interpretations is as to whether the ->asSet() is implicitly 'performed' by UML, or explicitly by the user. If the user really wants the intentional projection they can define the derived property distinctRoutes as route->asSet(). It would seem that a practical implementation would maintain City::route as nonunique, so behind the scenes an efficient implementation just chooses whether it is the UML unique specification, a derived property or user code that activates the cache of the set projection. The container example ==================== Is the use of unique multiplicity one containment powerful or dangerous? The nice feature is that it avoids the need to write the constraint on a multi-container that "parent->asSet()->size() <= 1". The bad feature is that it breaks other 'invariants' such as context Object inv ConsistentContainment: self.parent->size() = Container.allInstances()->select(element = self)->size() If the example was of something less critical than containment, it might be more convincing. I think breaking obvious 'invariants' is a poor trade-off for 'expressive' power. So I have to conclude that the intentional interpretation is dangerously cute. Regards Ed Willink On 08/05/2013 10:30, Steve Cook wrote: Having now read through this paper, Milicev makes some excellent points and so I would like to withdraw the proposed resolution 6464 (and its duplicate 5977). I am somewhat persuaded to clarify the spec using his approach, and I would like other people to read this paper so we can discuss it. The essence of it is the exact meaning of the phrase .will identify a collection. in the text I quoted earlier. With the .restrictive. interpretation, the collection of links directly determines the collection of instances. With the .intentional. interpretation, the collection of instances is further constrained by the uniqueness marking, so even if there are duplicate links there may still be a single instance. The compelling example for me is figure 3(b) and the accompanying text, where he points out that a container that composes a bag of elements is essentially impossible under the .restrictive. interpretation . any element that is contained more than once will violate the maximum 1 multiplicity on composition. This seems like a showstopper to me. Thanks -- Steve From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 08 May 2013 09:25 To: Bran Selic Cc: uml25-ftf@omg.org Subject: RE: Resolution 6464 - doubts Bran His paper explaining all of this in detail is available online at http://afrodita.rcub.bg.ac.rs/~dmilicev/pubs/mdd/trumlassoc.zip. -- Steve From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: 08 May 2013 08:38 To: Steve Cook Cc: uml25-ftf@omg.org Subject: Re: Resolution 6464 - doubts On Tue, May 7, 2013 at 3:29 PM, Steve Cook wrote: What I understand Milicev to be saying is that regardless of how many links actually connect to an instance, if that end of the association is marked as unique, then the instance only appears once in the result. I.e., the .uniqueness. refers to the way that the set of connected instances is derived from the links, rather than to the links themselves. [bvs] I am not sure that this is how I view it. My understanding is that it means that a link can be interpreted as two mappings in complementary directions, rather than as a unique entity. Reducing this to one possible realization, we can imagine that each end is realized by a reference or pointer, each with its own properties. Hence, the fact that a mapping (pointer) in one direction is unique, does not necessarily imply that the complementary mapping has to be unique as well. This is, I think, clearly ruled out by the following text in 11.5.3: For an Association with N memberEnds, choose any N-1 ends and associate specific instances with those ends. Then the collection of links of the Association that refer to these specific instances will identify a collection of instances at the other end. The multiplicity of the other end constrains the size of this collection. If the other end is marked as isOrdered, this collection will be ordered. If the other end is marked as isUnique, this collection is a set; otherwise, it allows duplicate elements. [bvs] I fail to see how this rules out the possibility above, since it only discusses the meaning of one end. It seems to me that the key lies in whether a link is treated as an atomic unit or as a pair of mappings (for binary associations, but this can be generalized). The latter, of course, is how a link could be realized in an OO implementation (as in Ecore). To be clear, I do not think it is a question of one or the other, but whether we support both. [bvs] It would be good to discuss this -- I'll try to make the next telecon, although due to travel I am not sure I will be able to make it. Cheers...Bran No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3272 / Virus Database: 3162/6307 - Release Date: 05/07/13 From: Steve Cook To: Ed Willink , "uml25-ftf@omg.org" Subject: RE: AW: Resolution 6464 - doubts Thread-Topic: AW: Resolution 6464 - doubts Thread-Index: AQHOS0eCbIyk0bODQUqereLJw60VqZj6FCLAgADTToCAAAlMYIAAEiNQgAC0EYCAACA6AIAAg1OAgAA20zA= Date: Thu, 9 May 2013 09:24:58 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.18.101] X-Forefront-Antispam-Report: CIP:131.107.125.37;CTRY:US;IPV:CAL;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(52034003)(24454002)(377454002)(479174002)(199002)(189002)(15974865001)(76482001)(55846006)(74366001)(54356001)(53806001)(80022001)(74706001)(47736001)(47976001)(81542001)(33656001)(81342001)(71186001)(49866001)(44976003)(20776003)(512954002)(16601075002)(69226001)(47446002)(74502001)(31966008)(16236675002)(15202345002)(8558605002)(79102001)(50986001)(74876001)(4396001)(74662001)(56816002)(16406001)(59766001)(46102001)(6806003)(51856001)(77982001)(65816001)(56776001)(54316002)(63696002);DIR:OUT;SFP:;SCL:1;SRVR:BL2FFO11HUB015;H:TK5EX14HUBC101.redmond.corp.microsoft.com;RD:InfoDomainNonexistent;A:1;MX:1;LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 08417837C5 X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAR15Gpo= X-Brightmail-Tracker: AAAAAA== Let.s just be clear that if we don.t adopt Milicev.s idea, the implications are that we need to constrain UML models so that if any end of an association is nonUnique, then all other ends of that association must be nonunique and have multiplicity upper bound > 1. This renders Milicev.s work .non-compliant., both semantically and syntactically, and more than likely invalidates many existing models. Ed, as regards this so-called .obvious. constraint about which you are arguing, it makes no sense to me. The ->size() operation would work on the collection resulting from whichever semantics are in operation. As Axel says, the constraint (were it to be formulated correctly) is satisfied either way. I do not agree with your argument, or that Milicev.s interpretation is anything like .dangerously cute.. Perhaps there is a way through here. Most models (e.g. the UML metamodel) actually mark all ends as unique (the default). The issue only arises when ends are marked as nonunique. If we introduce Milicev.s semantics as a way of explaining what it means to have a non-unique end amongst unique ends, then we don.t need to invalidate any models, we can have a clear and unambiguous semantics, and Milicev.s work can comply with it. Thanks -- Steve From: Ed Willink [mailto:ed@willink.me.uk] Sent: 09 May 2013 06:46 To: uml25-ftf@omg.org Subject: Re: AW: Resolution 6464 - doubts Hi Axel Oops. Yes element is a collection so element = self is functionally stupid but not semantically illegal. Your element->includes(self) has a projection and so gives the intentional semantics I meant context Object inv ConsistentRestrictiveContainment: self.parent->size() = Container.allInstances().element->select(e | e = self)->size() [which is short for Container.allInstances()->collect(c | c.element->select(e | e = self))->size()] the difference is that the intentional semantics has the projection context Object inv ConsistentIntentionalContainment: self.parent->size() = Container.allInstances().element->asSet()->select(e | e = self)->size() Regards Ed Willink On 08/05/2013 22:56, Axel Scheithauer wrote: Hi, I might be wrong, but shouldn.t the .obvious. constraint look like this: context Object inv ConsistentContainment: self.parent->size() = Container.allInstances()->select(element->includes(self))->size() Since element is a collection, element=self is not possible. (By the way, in the original figure, .parent. is called .container.) I think this constraint is fulfilled, even with the .intentional. interpretation. Regards Axel Von: Ed Willink [mailto:ed@willink.me.uk] Gesendet: Mittwoch, 8. Mai 2013 22:01 An: uml25-ftf@omg.org Betreff: Re: Resolution 6464 - doubts Hi I was convinced by Milicev's paper initially. I then took a shot at implementing Fig 2 with EMF, raised a Bugzilla and had to think instead. I now don't like the idea, the additional power seems to be dangerous and cute and the 'extra' expressive power is easily supported by asSet(). The routes example ================= R1: "Balkans Tour" { Belgrade, Sarajevo, Athens, Rhodes, Istanbul, Sofia, Bucharest, Belgrade} Route::city[*] {nonunique, ordered} -- no problem here City::route[*] {unique, ordered} -- problem here since Belgrade is on R1 twice. It seems to me that City::route could be declared as nonunique eliminating the problem then if the intentional interpretation is required the access performs b.route->asSet(). The difference between the two interpretations is as to whether the ->asSet() is implicitly 'performed' by UML, or explicitly by the user. If the user really wants the intentional projection they can define the derived property distinctRoutes as route->asSet(). It would seem that a practical implementation would maintain City::route as nonunique, so behind the scenes an efficient implementation just chooses whether it is the UML unique specification, a derived property or user code that activates the cache of the set projection. The container example ==================== Is the use of unique multiplicity one containment powerful or dangerous? The nice feature is that it avoids the need to write the constraint on a multi-container that "parent->asSet()->size() <= 1". The bad feature is that it breaks other 'invariants' such as context Object inv ConsistentContainment: self.parent->size() = Container.allInstances()->select(element = self)->size() If the example was of something less critical than containment, it might be more convincing. I think breaking obvious 'invariants' is a poor trade-off for 'expressive' power. So I have to conclude that the intentional interpretation is dangerously cute. Regards Ed Willink On 08/05/2013 10:30, Steve Cook wrote: Having now read through this paper, Milicev makes some excellent points and so I would like to withdraw the proposed resolution 6464 (and its duplicate 5977). I am somewhat persuaded to clarify the spec using his approach, and I would like other people to read this paper so we can discuss it. The essence of it is the exact meaning of the phrase .will identify a collection. in the text I quoted earlier. With the .restrictive. interpretation, the collection of links directly determines the collection of instances. With the .intentional. interpretation, the collection of instances is further constrained by the uniqueness marking, so even if there are duplicate links there may still be a single instance. The compelling example for me is figure 3(b) and the accompanying text, where he points out that a container that composes a bag of elements is essentially impossible under the .restrictive. interpretation . any element that is contained more than once will violate the maximum 1 multiplicity on composition. This seems like a showstopper to me. Thanks -- Steve From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 08 May 2013 09:25 To: Bran Selic Cc: uml25-ftf@omg.org Subject: RE: Resolution 6464 - doubts Bran His paper explaining all of this in detail is available online at http://afrodita.rcub.bg.ac.rs/~dmilicev/pubs/mdd/trumlassoc.zip. -- Steve From: bran.selic@gmail.com[mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: 08 May 2013 08:38 To: Steve Cook Cc: uml25-ftf@omg.org Subject: Re: Resolution 6464 - doubts On Tue, May 7, 2013 at 3:29 PM, Steve Cook wrote: What I understand Milicev to be saying is that regardless of how many links actually connect to an instance, if that end of the association is marked as unique, then the instance only appears once in the result. I.e., the .uniqueness. refers to the way that the set of connected instances is derived from the links, rather than to the links themselves. [bvs] I am not sure that this is how I view it. My understanding is that it means that a link can be interpreted as two mappings in complementary directions, rather than as a unique entity. Reducing this to one possible realization, we can imagine that each end is realized by a reference or pointer, each with its own properties. Hence, the fact that a mapping (pointer) in one direction is unique, does not necessarily imply that the complementary mapping has to be unique as well. This is, I think, clearly ruled out by the following text in 11.5.3: For an Association with N memberEnds, choose any N-1 ends and associate specific instances with those ends. Then the collection of links of the Association that refer to these specific instances will identify a collection of instances at the other end. The multiplicity of the other end constrains the size of this collection. If the other end is marked as isOrdered, this collection will be ordered. If the other end is marked as isUnique, this collection is a set; otherwise, it allows duplicate elements. [bvs] I fail to see how this rules out the possibility above, since it only discusses the meaning of one end. It seems to me that the key lies in whether a link is treated as an atomic unit or as a pair of mappings (for binary associations, but this can be generalized). The latter, of course, is how a link could be realized in an OO implementation (as in Ecore). To be clear, I do not think it is a question of one or the other, but whether we support both. [bvs] It would be good to discuss this -- I'll try to make the next telecon, although due to travel I am not sure I will be able to make it. Cheers...Bran No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3272 / Virus Database: 3162/6307 - Release Date: 05/07/13 No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3272 / Virus Database: 3162/6308 - Release Date: 05/08/13 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=VVvQjBrEMcMA:10 a=8nJEP1OIZ-IA:10 a=YYzpnO7rAAAA:8 a=5LlPfTAAGf4A:10 a=yMhMjlubAAAA:8 a=KHpXyVWLAAAA:8 a=HNVTiTzpAAAA:8 a=pGLkceISAAAA:8 a=oCcaPWc0AAAA:8 a=DEfF15jzu-UE8fXiHTUA:9 a=AiEra0-Rpm9r0Cr_:21 a=d5_8c1xyvRk4x7zo:21 a=o5DC1hS0pPhCo-fX:21 a=wPNLvfGTeEIA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=6UIaq3Bcl8oA:10 a=_W_S_7VecoQA:10 a=frz4AuCg-hUA:10 a=tXsnliwV7b4A:10 a=WP4_USCxRkkA:10 a=-AOE9ft50oIA:10 a=MSl-tDqOz04A:10 Date: Thu, 09 May 2013 12:52:50 +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: AW: Resolution 6464 - doubts X-Virus-Scanned: amavisd-new at omg.org Hi Steve Being "dangeously cute" is much less offensive that being broken, so maybe it's necessary. But if the UML specification currently has an ambiguity allowing either interpretation A or B, where interpretation A is widely assumed, is it correct to resolve the ambiguity by taking interpretation B? Whichever unambiguous interpretation is adopted will cause a compatibility problem for someone. If hybrid unique/nonunique associations are respecified according to the restrictive interpretation, old models accidentally using hybrids become explicitly invalid. Old models using intentional semantics become explicitly invalid. If hybrid unique/nonunique associations are respecified according to the intentional interpretation, old models accidentally using hybrids remain semantically valid but may start to behave differently as tooling evolves. Old models using intentional semantics become implicitly valid. [The intentional semantics is presumably not often required. It can easily be expressed using an asSet() somewhere.] I much prefer to to explicitly diagnose old models as broken than silently change their semantics. It is an inevitable consequence of tool evolution that checking steadily improves and so hidden user mistakes are exposed by new tooling. With the OCL in UML 2.5 so much improved and extended, users must expect latent bugs to be exposed. Tool vendors may need to offer a capability to configure warning suppression. ---- My 'obvious' constraint may be a chicken and egg example. Approach containment from two directions: The number of usages of a parent by self: self.parent->size() is equal to The number of usages of self as a child: Container.allInstances().element->select(e | e = self)->size() While writing the above, my first choice of English phrasing was "equal to the number of Containers for which self is a child" which gives the intentional semantics. ======= I'm uncomfortable with, but not violently opposed to the intentional semantics. Regards Ed Willink On 09/05/2013 10:24, Steve Cook wrote: Let.s just be clear that if we don.t adopt Milicev.s idea, the implications are that we need to constrain UML models so that if any end of an association is nonUnique, then all other ends of that association must be nonunique and have multiplicity upper bound > 1. This renders Milicev.s work .non-compliant., both semantically and syntactically, and more than likely invalidates many existing models. Ed, as regards this so-called .obvious. constraint about which you are arguing, it makes no sense to me. The ->size() operation would work on the collection resulting from whichever semantics are in operation. As Axel says, the constraint (were it to be formulated correctly) is satisfied either way. I do not agree with your argument, or that Milicev.s interpretation is anything like .dangerously cute.. Perhaps there is a way through here. Most models (e.g. the UML metamodel) actually mark all ends as unique (the default). The issue only arises when ends are marked as nonunique. If we introduce Milicev.s semantics as a way of explaining what it means to have a non-unique end amongst unique ends, then we don.t need to invalidate any models, we can have a clear and unambiguous semantics, and Milicev.s work can comply with it. Thanks -- Steve From: Ed Willink [mailto:ed@willink.me.uk] Sent: 09 May 2013 06:46 To: uml25-ftf@omg.org Subject: Re: AW: Resolution 6464 - doubts Hi Axel Oops. Yes element is a collection so element = self is functionally stupid but not semantically illegal. Your element->includes(self) has a projection and so gives the intentional semantics I meant context Object inv ConsistentRestrictiveContainment: self.parent->size() = Container.allInstances().element->select(e | e = self)->size() [which is short for Container.allInstances()->collect(c | c.element->select(e | e = self))->size()] the difference is that the intentional semantics has the projection context Object inv ConsistentIntentionalContainment: self.parent->size() = Container.allInstances().element->asSet()->select(e | e = self)->size() Regards Ed Willink On 08/05/2013 22:56, Axel Scheithauer wrote: Hi, I might be wrong, but shouldn.t the .obvious. constraint look like this: context Object inv ConsistentContainment: self.parent->size() = Container.allInstances()->select(element->includes(self))->size() Since element is a collection, element=self is not possible. (By the way, in the original figure, .parent. is called .container.) I think this constraint is fulfilled, even with the .intentional. interpretation. Regards Axel Von: Ed Willink [mailto:ed@willink.me.uk] Gesendet: Mittwoch, 8. Mai 2013 22:01 An: uml25-ftf@omg.org Betreff: Re: Resolution 6464 - doubts Hi I was convinced by Milicev's paper initially. I then took a shot at implementing Fig 2 with EMF, raised a Bugzilla and had to think instead. I now don't like the idea, the additional power seems to be dangerous and cute and the 'extra' expressive power is easily supported by asSet(). The routes example ================= R1: "Balkans Tour" { Belgrade, Sarajevo, Athens, Rhodes, Istanbul, Sofia, Bucharest, Belgrade} Route::city[*] {nonunique, ordered} -- no problem here City::route[*] {unique, ordered} -- problem here since Belgrade is on R1 twice. It seems to me that City::route could be declared as nonunique eliminating the problem then if the intentional interpretation is required the access performs b.route->asSet(). The difference between the two interpretations is as to whether the ->asSet() is implicitly 'performed' by UML, or explicitly by the user. If the user really wants the intentional projection they can define the derived property distinctRoutes as route->asSet(). It would seem that a practical implementation would maintain City::route as nonunique, so behind the scenes an efficient implementation just chooses whether it is the UML unique specification, a derived property or user code that activates the cache of the set projection. The container example ==================== Is the use of unique multiplicity one containment powerful or dangerous? The nice feature is that it avoids the need to write the constraint on a multi-container that "parent->asSet()->size() <= 1". The bad feature is that it breaks other 'invariants' such as context Object inv ConsistentContainment: self.parent->size() = Container.allInstances()->select(element = self)->size() If the example was of something less critical than containment, it might be more convincing. I think breaking obvious 'invariants' is a poor trade-off for 'expressive' power. So I have to conclude that the intentional interpretation is dangerously cute. Regards Ed Willink On 08/05/2013 10:30, Steve Cook wrote: Having now read through this paper, Milicev makes some excellent points and so I would like to withdraw the proposed resolution 6464 (and its duplicate 5977). I am somewhat persuaded to clarify the spec using his approach, and I would like other people to read this paper so we can discuss it. The essence of it is the exact meaning of the phrase .will identify a collection. in the text I quoted earlier. With the .restrictive. interpretation, the collection of links directly determines the collection of instances. With the .intentional. interpretation, the collection of instances is further constrained by the uniqueness marking, so even if there are duplicate links there may still be a single instance. The compelling example for me is figure 3(b) and the accompanying text, where he points out that a container that composes a bag of elements is essentially impossible under the .restrictive. interpretation . any element that is contained more than once will violate the maximum 1 multiplicity on composition. This seems like a showstopper to me. Thanks -- Steve From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 08 May 2013 09:25 To: Bran Selic Cc: uml25-ftf@omg.org Subject: RE: Resolution 6464 - doubts Bran His paper explaining all of this in detail is available online at http://afrodita.rcub.bg.ac.rs/~dmilicev/pubs/mdd/trumlassoc.zip. -- Steve From: bran.selic@gmail.com[mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: 08 May 2013 08:38 To: Steve Cook Cc: uml25-ftf@omg.org Subject: Re: Resolution 6464 - doubts On Tue, May 7, 2013 at 3:29 PM, Steve Cook wrote: What I understand Milicev to be saying is that regardless of how many links actually connect to an instance, if that end of the association is marked as unique, then the instance only appears once in the result. I.e., the .uniqueness. refers to the way that the set of connected instances is derived from the links, rather than to the links themselves. [bvs] I am not sure that this is how I view it. My understanding is that it means that a link can be interpreted as two mappings in complementary directions, rather than as a unique entity. Reducing this to one possible realization, we can imagine that each end is realized by a reference or pointer, each with its own properties. Hence, the fact that a mapping (pointer) in one direction is unique, does not necessarily imply that the complementary mapping has to be unique as well. This is, I think, clearly ruled out by the following text in 11.5.3: For an Association with N memberEnds, choose any N-1 ends and associate specific instances with those ends. Then the collection of links of the Association that refer to these specific instances will identify a collection of instances at the other end. The multiplicity of the other end constrains the size of this collection. If the other end is marked as isOrdered, this collection will be ordered. If the other end is marked as isUnique, this collection is a set; otherwise, it allows duplicate elements. [bvs] I fail to see how this rules out the possibility above, since it only discusses the meaning of one end. It seems to me that the key lies in whether a link is treated as an atomic unit or as a pair of mappings (for binary associations, but this can be generalized). The latter, of course, is how a link could be realized in an OO implementation (as in Ecore). To be clear, I do not think it is a question of one or the other, but whether we support both. [bvs] It would be good to discuss this -- I'll try to make the next telecon, although due to travel I am not sure I will be able to make it. Cheers...Bran No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3272 / Virus Database: 3162/6307 - Release Date: 05/07/13 No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3272 / Virus Database: 3162/6308 - Release Date: 05/08/13 No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3272 / Virus Database: 3162/6309 - Release Date: 05/08/13 From: Axel Scheithauer To: Ed Willink , "uml25-ftf@omg.org" Subject: AW: Resolution 6464 - doubts Thread-Topic: Resolution 6464 - doubts Thread-Index: AQHOS0h+avoFLV2O00qOwGMzmF+e8Jj5+jgAgADLr4CAAA0sgIAAEjmAgACwG4CAADpXAA== Date: Wed, 8 May 2013 21:56:16 +0000 Accept-Language: de-DE, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [80.171.161.1] X-XWALL-BCKS: auto X-Virus-Scanned: amavisd-new at omg.org Hi, I might be wrong, but shouldn.t the .obvious. constraint look like this: context Object inv ConsistentContainment: self.parent->size() = Container.allInstances()->select(element->includes(self))->size() Since element is a collection, element=self is not possible. (By the way, in the original figure, .parent. is called .container.) I think this constraint is fulfilled, even with the .intentional. interpretation. Regards Axel Von: Ed Willink [mailto:ed@willink.me.uk] Gesendet: Mittwoch, 8. Mai 2013 22:01 An: uml25-ftf@omg.org Betreff: Re: Resolution 6464 - doubts Hi I was convinced by Milicev's paper initially. I then took a shot at implementing Fig 2 with EMF, raised a Bugzilla and had to think instead. I now don't like the idea, the additional power seems to be dangerous and cute and the 'extra' expressive power is easily supported by asSet(). The routes example ================= R1: "Balkans Tour" { Belgrade, Sarajevo, Athens, Rhodes, Istanbul, Sofia, Bucharest, Belgrade} Route::city[*] {nonunique, ordered} -- no problem here City::route[*] {unique, ordered} -- problem here since Belgrade is on R1 twice. It seems to me that City::route could be declared as nonunique eliminating the problem then if the intentional interpretation is required the access performs b.route->asSet(). The difference between the two interpretations is as to whether the ->asSet() is implicitly 'performed' by UML, or explicitly by the user. If the user really wants the intentional projection they can define the derived property distinctRoutes as route->asSet(). It would seem that a practical implementation would maintain City::route as nonunique, so behind the scenes an efficient implementation just chooses whether it is the UML unique specification, a derived property or user code that activates the cache of the set projection. The container example ==================== Is the use of unique multiplicity one containment powerful or dangerous? The nice feature is that it avoids the need to write the constraint on a multi-container that "parent->asSet()->size() <= 1". The bad feature is that it breaks other 'invariants' such as context Object inv ConsistentContainment: self.parent->size() = Container.allInstances()->select(element = self)->size() If the example was of something less critical than containment, it might be more convincing. I think breaking obvious 'invariants' is a poor trade-off for 'expressive' power. So I have to conclude that the intentional interpretation is dangerously cute. Regards Ed Willink On 08/05/2013 10:30, Steve Cook wrote: Having now read through this paper, Milicev makes some excellent points and so I would like to withdraw the proposed resolution 6464 (and its duplicate 5977). I am somewhat persuaded to clarify the spec using his approach, and I would like other people to read this paper so we can discuss it. The essence of it is the exact meaning of the phrase .will identify a collection. in the text I quoted earlier. With the .restrictive. interpretation, the collection of links directly determines the collection of instances. With the .intentional. interpretation, the collection of instances is further constrained by the uniqueness marking, so even if there are duplicate links there may still be a single instance. The compelling example for me is figure 3(b) and the accompanying text, where he points out that a container that composes a bag of elements is essentially impossible under the .restrictive. interpretation . any element that is contained more than once will violate the maximum 1 multiplicity on composition. This seems like a showstopper to me. Thanks -- Steve From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 08 May 2013 09:25 To: Bran Selic Cc: uml25-ftf@omg.org Subject: RE: Resolution 6464 - doubts Bran His paper explaining all of this in detail is available online at http://afrodita.rcub.bg.ac.rs/~dmilicev/pubs/mdd/trumlassoc.zip. -- Steve From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: 08 May 2013 08:38 To: Steve Cook Cc: uml25-ftf@omg.org Subject: Re: Resolution 6464 - doubts On Tue, May 7, 2013 at 3:29 PM, Steve Cook wrote: What I understand Milicev to be saying is that regardless of how many links actually connect to an instance, if that end of the association is marked as unique, then the instance only appears once in the result. I.e., the .uniqueness. refers to the way that the set of connected instances is derived from the links, rather than to the links themselves. [bvs] I am not sure that this is how I view it. My understanding is that it means that a link can be interpreted as two mappings in complementary directions, rather than as a unique entity. Reducing this to one possible realization, we can imagine that each end is realized by a reference or pointer, each with its own properties. Hence, the fact that a mapping (pointer) in one direction is unique, does not necessarily imply that the complementary mapping has to be unique as well. This is, I think, clearly ruled out by the following text in 11.5.3: For an Association with N memberEnds, choose any N-1 ends and associate specific instances with those ends. Then the collection of links of the Association that refer to these specific instances will identify a collection of instances at the other end. The multiplicity of the other end constrains the size of this collection. If the other end is marked as isOrdered, this collection will be ordered. If the other end is marked as isUnique, this collection is a set; otherwise, it allows duplicate elements. [bvs] I fail to see how this rules out the possibility above, since it only discusses the meaning of one end. It seems to me that the key lies in whether a link is treated as an atomic unit or as a pair of mappings (for binary associations, but this can be generalized). The latter, of course, is how a link could be realized in an OO implementation (as in Ecore). To be clear, I do not think it is a question of one or the other, but whether we support both. [bvs] It would be good to discuss this -- I'll try to make the next telecon, although due to travel I am not sure I will be able to make it. Cheers...Bran No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3272 / Virus Database: 3162/6307 - Release Date: 05/07/13 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=VVvQjBrEMcMA:10 a=8nJEP1OIZ-IA:10 a=YYzpnO7rAAAA:8 a=5LlPfTAAGf4A:10 a=KHpXyVWLAAAA:8 a=yMhMjlubAAAA:8 a=HNVTiTzpAAAA:8 a=pGLkceISAAAA:8 a=oCcaPWc0AAAA:8 a=i_jXT76nryqf5mvQCsgA:9 a=nJFTJeLyy2uuR1N1:21 a=NNGNBGQ7TdFFgBqZ:21 a=ixvU7ZB8YobU22li:21 a=wPNLvfGTeEIA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=_W_S_7VecoQA:10 a=frz4AuCg-hUA:10 a=tXsnliwV7b4A:10 a=WP4_USCxRkkA:10 a=-AOE9ft50oIA:10 a=MSl-tDqOz04A:10 Date: Thu, 09 May 2013 06:46:17 +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: AW: Resolution 6464 - doubts X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAR15Gpo= X-Brightmail-Tracker: AAAAAA== Hi Axel Oops. Yes element is a collection so element = self is functionally stupid but not semantically illegal. Your element->includes(self) has a projection and so gives the intentional semantics I meant context Object inv ConsistentRestrictiveContainment: self.parent->size() = Container.allInstances().element->select(e | e = self)->size() [which is short for Container.allInstances()->collect(c | c.element->select(e | e = self))->size()] the difference is that the intentional semantics has the projection context Object inv ConsistentIntentionalContainment: self.parent->size() = Container.allInstances().element->asSet()->select(e | e = self)->size() Regards Ed Willink On 08/05/2013 22:56, Axel Scheithauer wrote: Hi, I might be wrong, but shouldn.t the .obvious. constraint look like this: context Object inv ConsistentContainment: self.parent->size() = Container.allInstances()->select(element->includes(self))->size() Since element is a collection, element=self is not possible. (By the way, in the original figure, .parent. is called .container.) I think this constraint is fulfilled, even with the .intentional. interpretation. Regards Axel Von: Ed Willink [mailto:ed@willink.me.uk] Gesendet: Mittwoch, 8. Mai 2013 22:01 An: uml25-ftf@omg.org Betreff: Re: Resolution 6464 - doubts Hi I was convinced by Milicev's paper initially. I then took a shot at implementing Fig 2 with EMF, raised a Bugzilla and had to think instead. I now don't like the idea, the additional power seems to be dangerous and cute and the 'extra' expressive power is easily supported by asSet(). The routes example ================= R1: "Balkans Tour" { Belgrade, Sarajevo, Athens, Rhodes, Istanbul, Sofia, Bucharest, Belgrade} Route::city[*] {nonunique, ordered} -- no problem here City::route[*] {unique, ordered} -- problem here since Belgrade is on R1 twice. It seems to me that City::route could be declared as nonunique eliminating the problem then if the intentional interpretation is required the access performs b.route->asSet(). The difference between the two interpretations is as to whether the ->asSet() is implicitly 'performed' by UML, or explicitly by the user. If the user really wants the intentional projection they can define the derived property distinctRoutes as route->asSet(). It would seem that a practical implementation would maintain City::route as nonunique, so behind the scenes an efficient implementation just chooses whether it is the UML unique specification, a derived property or user code that activates the cache of the set projection. The container example ==================== Is the use of unique multiplicity one containment powerful or dangerous? The nice feature is that it avoids the need to write the constraint on a multi-container that "parent->asSet()->size() <= 1". The bad feature is that it breaks other 'invariants' such as context Object inv ConsistentContainment: self.parent->size() = Container.allInstances()->select(element = self)->size() If the example was of something less critical than containment, it might be more convincing. I think breaking obvious 'invariants' is a poor trade-off for 'expressive' power. So I have to conclude that the intentional interpretation is dangerously cute. Regards Ed Willink On 08/05/2013 10:30, Steve Cook wrote: Having now read through this paper, Milicev makes some excellent points and so I would like to withdraw the proposed resolution 6464 (and its duplicate 5977). I am somewhat persuaded to clarify the spec using his approach, and I would like other people to read this paper so we can discuss it. The essence of it is the exact meaning of the phrase .will identify a collection. in the text I quoted earlier. With the .restrictive. interpretation, the collection of links directly determines the collection of instances. With the .intentional. interpretation, the collection of instances is further constrained by the uniqueness marking, so even if there are duplicate links there may still be a single instance. The compelling example for me is figure 3(b) and the accompanying text, where he points out that a container that composes a bag of elements is essentially impossible under the .restrictive. interpretation . any element that is contained more than once will violate the maximum 1 multiplicity on composition. This seems like a showstopper to me. Thanks -- Steve From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 08 May 2013 09:25 To: Bran Selic Cc: uml25-ftf@omg.org Subject: RE: Resolution 6464 - doubts Bran His paper explaining all of this in detail is available online at http://afrodita.rcub.bg.ac.rs/~dmilicev/pubs/mdd/trumlassoc.zip. -- Steve From: bran.selic@gmail.com[mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: 08 May 2013 08:38 To: Steve Cook Cc: uml25-ftf@omg.org Subject: Re: Resolution 6464 - doubts On Tue, May 7, 2013 at 3:29 PM, Steve Cook wrote: What I understand Milicev to be saying is that regardless of how many links actually connect to an instance, if that end of the association is marked as unique, then the instance only appears once in the result. I.e., the .uniqueness. refers to the way that the set of connected instances is derived from the links, rather than to the links themselves. [bvs] I am not sure that this is how I view it. My understanding is that it means that a link can be interpreted as two mappings in complementary directions, rather than as a unique entity. Reducing this to one possible realization, we can imagine that each end is realized by a reference or pointer, each with its own properties. Hence, the fact that a mapping (pointer) in one direction is unique, does not necessarily imply that the complementary mapping has to be unique as well. This is, I think, clearly ruled out by the following text in 11.5.3: For an Association with N memberEnds, choose any N-1 ends and associate specific instances with those ends. Then the collection of links of the Association that refer to these specific instances will identify a collection of instances at the other end. The multiplicity of the other end constrains the size of this collection. If the other end is marked as isOrdered, this collection will be ordered. If the other end is marked as isUnique, this collection is a set; otherwise, it allows duplicate elements. [bvs] I fail to see how this rules out the possibility above, since it only discusses the meaning of one end. It seems to me that the key lies in whether a link is treated as an atomic unit or as a pair of mappings (for binary associations, but this can be generalized). The latter, of course, is how a link could be realized in an OO implementation (as in Ecore). To be clear, I do not think it is a question of one or the other, but whether we support both. [bvs] It would be good to discuss this -- I'll try to make the next telecon, although due to travel I am not sure I will be able to make it. Cheers...Bran No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3272 / Virus Database: 3162/6307 - Release Date: 05/07/13 No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3272 / Virus Database: 3162/6308 - Release Date: 05/08/13 From: Steve Cook To: Ed Willink , "uml25-ftf@omg.org" Subject: RE: AW: Resolution 6464 - doubts Thread-Topic: AW: Resolution 6464 - doubts Thread-Index: AQHOS0eCbIyk0bODQUqereLJw60VqZj6FCLAgADTToCAAAlMYIAAEiNQgAC0EYCAACA6AIAAg1OAgAA20zCAAC+WAIAACHXQ Date: Thu, 9 May 2013 13:13:09 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.18.101] X-Forefront-Antispam-Report: CIP:131.107.125.37;CTRY:US;IPV:CAL;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(52034003)(51444003)(199002)(189002)(24454002)(479174002)(377454002)(47736001)(71186001)(16601075002)(77982001)(49866001)(15202345002)(74366001)(512954002)(74706001)(47976001)(50986001)(81342001)(16236675002)(81542001)(33656001)(46102001)(6806003)(74876001)(80022001)(4396001)(54356001)(53806001)(44976003)(16406001)(65816001)(76482001)(56816002)(47446002)(56776001)(55846006)(74502001)(54316002)(8558605002)(79102001)(31966008)(74662001)(63696002)(20776003)(69226001)(59766001)(51856001)(15974865001);DIR:OUT;SFP:;SCL:1;SRVR:BL2FFO11HUB031;H:TK5EX14HUBC101.redmond.corp.microsoft.com;RD:InfoDomainNonexistent;A:1;MX:1;LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 08417837C5 X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAR15Gpo= X-Brightmail-Tracker: AAAAAA== Ed Please see my interspersed comments. -- Steve From: Ed Willink [mailto:ed@willink.me.uk] Sent: 09 May 2013 12:53 To: uml25-ftf@omg.org Subject: Re: AW: Resolution 6464 - doubts Hi Steve Being "dangeously cute" is much less offensive that being broken, so maybe it's necessary. But if the UML specification currently has an ambiguity allowing either interpretation A or B, where interpretation A is widely assumed, It is extremely unlikely that interpretation A is widely assumed, especially by anybody who happened to create a hybrid association. If they were assuming interpretation A, they were intentionally creating an invalid model. It is much more likely that users assumed that hybrid associations had a valid semantics, since they were never warned of the opposite. is it correct to resolve the ambiguity by taking interpretation B? Whichever unambiguous interpretation is adopted will cause a compatibility problem for someone. If hybrid unique/nonunique associations are respecified according to the restrictive interpretation, old models accidentally using hybrids become explicitly invalid. They were always invalid. Old models using intentional semantics become explicitly invalid. Indeed. This is bad. If hybrid unique/nonunique associations are respecified according to the intentional interpretation, old models accidentally using hybrids remain semantically valid but may start to behave differently as tooling evolves. The old models were never valid, so could not .remain semantically valid.. There never was a valid behaviour that they could have had. Old models using intentional semantics become implicitly valid. No, they become explicitly valid. The spec will tell them what the models mean. This is good. [The intentional semantics is presumably not often required. It is only ever required for a hybrid association. It can easily be expressed using an asSet() somewhere.] Not so. The particular case where the intentional semantics adds value that asSet() cannot offer is a nonunique composition. In that case, the restrictive semantics would require a multiplicity of more than 1 at the container end, which prohibits the use of nonunique composition altogether. I think that would be a surprise to many users of UML. I much prefer to to explicitly diagnose old models as broken than silently change their semantics. It is an inevitable consequence of tool evolution that checking steadily improves and so hidden user mistakes are exposed by new tooling. With the OCL in UML 2.5 so much improved and extended, users must expect latent bugs to be exposed. Tool vendors may need to offer a capability to configure warning suppression. Nobody is .silently changing any semantics.. The only change would be that models that were previously silently invalid become valid. Presumably the creators of those models had something in mind, however vaguely, when they created a hybrid association. That thing they had in mind is likely to be the intentional semantics (*). I am unaware of any competing valid semantics for hybrid associations. ---- My 'obvious' constraint may be a chicken and egg example. Approach containment from two directions: The number of usages of a parent by self: self.parent->size() is equal to The number of usages of self as a child: Container.allInstances().element->select(e | e = self)->size() While writing the above, my first choice of English phrasing was "equal to the number of Containers for which self is a child" which gives the intentional semantics. Indeed. Which is further justification for (*) above. Of course if you have different semantics then you can find some different equations. But there is nothing .obvious. about this formulation with .usages.. It is just restating the question. ======= I'm uncomfortable with, but not violently opposed to the intentional semantics. Regards Ed Willink On 09/05/2013 10:24, Steve Cook wrote: Let.s just be clear that if we don.t adopt Milicev.s idea, the implications are that we need to constrain UML models so that if any end of an association is nonUnique, then all other ends of that association must be nonunique and have multiplicity upper bound > 1. This renders Milicev.s work .non-compliant., both semantically and syntactically, and more than likely invalidates many existing models. Ed, as regards this so-called .obvious. constraint about which you are arguing, it makes no sense to me. The ->size() operation would work on the collection resulting from whichever semantics are in operation. As Axel says, the constraint (were it to be formulated correctly) is satisfied either way. I do not agree with your argument, or that Milicev.s interpretation is anything like .dangerously cute.. Perhaps there is a way through here. Most models (e.g. the UML metamodel) actually mark all ends as unique (the default). The issue only arises when ends are marked as nonunique. If we introduce Milicev.s semantics as a way of explaining what it means to have a non-unique end amongst unique ends, then we don.t need to invalidate any models, we can have a clear and unambiguous semantics, and Milicev.s work can comply with it. Thanks -- Steve From: Ed Willink [mailto:ed@willink.me.uk] Sent: 09 May 2013 06:46 To: uml25-ftf@omg.org Subject: Re: AW: Resolution 6464 - doubts Hi Axel Oops. Yes element is a collection so element = self is functionally stupid but not semantically illegal. Your element->includes(self) has a projection and so gives the intentional semantics I meant context Object inv ConsistentRestrictiveContainment: self.parent->size() = Container.allInstances().element->select(e | e = self)->size() [which is short for Container.allInstances()->collect(c | c.element->select(e | e = self))->size()] the difference is that the intentional semantics has the projection context Object inv ConsistentIntentionalContainment: self.parent->size() = Container.allInstances().element->asSet()->select(e | e = self)->size() Regards Ed Willink On 08/05/2013 22:56, Axel Scheithauer wrote: Hi, I might be wrong, but shouldn.t the .obvious. constraint look like this: context Object inv ConsistentContainment: self.parent->size() = Container.allInstances()->select(element->includes(self))->size() Since element is a collection, element=self is not possible. (By the way, in the original figure, .parent. is called .container.) I think this constraint is fulfilled, even with the .intentional. interpretation. Regards Axel Von: Ed Willink [mailto:ed@willink.me.uk] Gesendet: Mittwoch, 8. Mai 2013 22:01 An: uml25-ftf@omg.org Betreff: Re: Resolution 6464 - doubts Hi I was convinced by Milicev's paper initially. I then took a shot at implementing Fig 2 with EMF, raised a Bugzilla and had to think instead. I now don't like the idea, the additional power seems to be dangerous and cute and the 'extra' expressive power is easily supported by asSet(). The routes example ================= R1: "Balkans Tour" { Belgrade, Sarajevo, Athens, Rhodes, Istanbul, Sofia, Bucharest, Belgrade} Route::city[*] {nonunique, ordered} -- no problem here City::route[*] {unique, ordered} -- problem here since Belgrade is on R1 twice. It seems to me that City::route could be declared as nonunique eliminating the problem then if the intentional interpretation is required the access performs b.route->asSet(). The difference between the two interpretations is as to whether the ->asSet() is implicitly 'performed' by UML, or explicitly by the user. If the user really wants the intentional projection they can define the derived property distinctRoutes as route->asSet(). It would seem that a practical implementation would maintain City::route as nonunique, so behind the scenes an efficient implementation just chooses whether it is the UML unique specification, a derived property or user code that activates the cache of the set projection. The container example ==================== Is the use of unique multiplicity one containment powerful or dangerous? The nice feature is that it avoids the need to write the constraint on a multi-container that "parent->asSet()->size() <= 1". The bad feature is that it breaks other 'invariants' such as context Object inv ConsistentContainment: self.parent->size() = Container.allInstances()->select(element = self)->size() If the example was of something less critical than containment, it might be more convincing. I think breaking obvious 'invariants' is a poor trade-off for 'expressive' power. So I have to conclude that the intentional interpretation is dangerously cute. Regards Ed Willink On 08/05/2013 10:30, Steve Cook wrote: Having now read through this paper, Milicev makes some excellent points and so I would like to withdraw the proposed resolution 6464 (and its duplicate 5977). I am somewhat persuaded to clarify the spec using his approach, and I would like other people to read this paper so we can discuss it. The essence of it is the exact meaning of the phrase .will identify a collection. in the text I quoted earlier. With the .restrictive. interpretation, the collection of links directly determines the collection of instances. With the .intentional. interpretation, the collection of instances is further constrained by the uniqueness marking, so even if there are duplicate links there may still be a single instance. The compelling example for me is figure 3(b) and the accompanying text, where he points out that a container that composes a bag of elements is essentially impossible under the .restrictive. interpretation . any element that is contained more than once will violate the maximum 1 multiplicity on composition. This seems like a showstopper to me. Thanks -- Steve From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 08 May 2013 09:25 To: Bran Selic Cc: uml25-ftf@omg.org Subject: RE: Resolution 6464 - doubts Bran His paper explaining all of this in detail is available online at http://afrodita.rcub.bg.ac.rs/~dmilicev/pubs/mdd/trumlassoc.zip. -- Steve From: bran.selic@gmail.com[mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: 08 May 2013 08:38 To: Steve Cook Cc: uml25-ftf@omg.org Subject: Re: Resolution 6464 - doubts On Tue, May 7, 2013 at 3:29 PM, Steve Cook wrote: What I understand Milicev to be saying is that regardless of how many links actually connect to an instance, if that end of the association is marked as unique, then the instance only appears once in the result. I.e., the .uniqueness. refers to the way that the set of connected instances is derived from the links, rather than to the links themselves. [bvs] I am not sure that this is how I view it. My understanding is that it means that a link can be interpreted as two mappings in complementary directions, rather than as a unique entity. Reducing this to one possible realization, we can imagine that each end is realized by a reference or pointer, each with its own properties. Hence, the fact that a mapping (pointer) in one direction is unique, does not necessarily imply that the complementary mapping has to be unique as well. This is, I think, clearly ruled out by the following text in 11.5.3: For an Association with N memberEnds, choose any N-1 ends and associate specific instances with those ends. Then the collection of links of the Association that refer to these specific instances will identify a collection of instances at the other end. The multiplicity of the other end constrains the size of this collection. If the other end is marked as isOrdered, this collection will be ordered. If the other end is marked as isUnique, this collection is a set; otherwise, it allows duplicate elements. [bvs] I fail to see how this rules out the possibility above, since it only discusses the meaning of one end. It seems to me that the key lies in whether a link is treated as an atomic unit or as a pair of mappings (for binary associations, but this can be generalized). The latter, of course, is how a link could be realized in an OO implementation (as in Ecore). To be clear, I do not think it is a question of one or the other, but whether we support both. [bvs] It would be good to discuss this -- I'll try to make the next telecon, although due to travel I am not sure I will be able to make it. Cheers...Bran No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3272 / Virus Database: 3162/6307 - Release Date: 05/07/13 No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3272 / Virus Database: 3162/6308 - Release Date: 05/08/13 No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3272 / Virus Database: 3162/6309 - Release Date: 05/08/13