Issue 8077: Properties on Association for end objects (uml2-rtf) Source: Deere & Company (Mr. Roger Burkhart, burkhartrogerm(at)johndeere.com) Nature: Revision Severity: Significant Summary: The memberEnd/ownedEnd/NavigableOwnedEnd properties of Association represent the navigations from one end object to other end objects along the association. There are no properties available for navigating from an instance of an association (link) to the end objects. This has a number of negative effects: - The model cannot represent structured associations properly, because association classes that are also structured classifiers cannot have connectors to end objects, because the end objects cannot be reached with StructuredClassifier.role (see constraint 3 on Connector). - An InstanceSpecification for link can use memberEnd properties of association as properties of the link, even though these properties are ownedAttribute of the end classes, rather than the association. This is due to the loose definition of Classifier.allFeatures. - A special action is needed to retrieve (the end objects of links (ReadLinkObjectEndAction), rather than (using the action for attribute values ReadStructuralFeatureAction. The metamodel should have an association for properties that have the end objects of link objects as values. Resolution: Revised Text: Actions taken: January 5, 2005: received issue Discussion: Disposition: Deferred to UML 2.4 RTF End of Annotations:===== m: webmaster@omg.org Date: 05 Jan 2005 12:46:46 -0500 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Roger Brukhart Company: Deere & Company mailFrom: BurkhartRogerM@JohnDeere.com Notification: No Specification: UML 2 Superstructure Section: Classes FormalNumber: ptc/04-10-02 Version: 2 RevisionDate: 04-10-02 Page: n Nature: Revision Severity: Significant HTTP User Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322) Description Properties on Association for end objects: The memberEnd/ownedEnd/NavigableOwnedEnd properties of Association represent the navigations from one end object to other end objects along the association. There are no properties available for navigating from an instance of an association (link) to the end objects. This has a number of negative effects: - The model cannot represent structured associations properly, because association classes that are also structured classifiers cannot have connectors to end objects, because the end objects cannot be reached with StructuredClassifier.role (see constraint 3 on Connector). - An InstanceSpecification for link can use memberEnd properties of association as properties of the link, even though these properties are ownedAttribute of the end classes, rather than the association. This is due to the loose definition of Classifier.allFeatures. - A special action is needed to retrieve (the end objects of links (ReadLinkObjectEndAction), rather than (using the action for attribute values ReadStructuralFeatureAction. The metamodel should have an association for properties that have the end objects of link objects as values. X-YMail-OSG: Vrd1BvQVM1mWTxJemCy9_JThvddTsID2T4AnMrgtFvQEy6SRuHTLXSiQBaF5_czvEg-- Reply-To: From: "Thomas Weigert" To: "'Nerijus Jankevicius'" , "'Tim Weilkiens'" , Cc: "'Branislav Selic'" , "'Pete Rivett'" Subject: RE: updated resolutions for UML 2.2 Date: Fri, 31 Aug 2007 21:20:04 -0500 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Acfr32xEUYI+MSCISnigJyjbz2KUlwAXpAug Regarding issue 8077, 9961, 9962 The proposed resolution violates the original strategy of the instance metamodel which explicitly and purposefully removed "Link" as a metaclass together with the convolutions that surrounded it. We should not reintroduce these concepts we have worked hard to get rid of. Issues 8077 and issue 9961 do not appear correct. Cheers, Th. > -----Original Message----- > From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] > Sent: Friday, August 31, 2007 9:42 AM > To: Tim Weilkiens; uml2-rtf@omg.org > Cc: Branislav Selic; Pete Rivett > Subject: Re: updated resolutions for UML 2.2 To: "Nerijus Jankevicius" Cc: "Pete Rivett" , uml2-rtf@omg.org Subject: Re: updated resolutions for UML 2.2 X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Branislav Selic Date: Tue, 4 Sep 2007 08:26:44 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 7.0.2HF446 | March 16, 2007) at 09/04/2007 08:26:44, Serialize complete at 09/04/2007 08:26:44 Thank you very much, Nerijus, for taking the initiative to propose resolutions to these issues. I've already commented a bit on some of the proposed resolutions, but here is my complete list of comments to each of your resolutions. I believe that we will need more discussions on these issues in the next few weeks. ====================================================================== Issue 11240: Indeed there seems to be redundancy between TemplateParameter::default and ClassifierTemplateParameter::defaultClassifier, but there are numerous examples of this in the spec. It allows polymorphism, so that software dealing with TemplateParameters in general can ignore which type of specialization is in question. Redefinition would prevent that capability. What is the motivation behind this issue and resolution? Is it implementation optimization, metamodel consistency, or something else? What effect will this have on users and existing models, if any? Issue 11244: Same comment as 11240 Issue 11243: Seems OK, except that the text needs to be fixed a bit to ensure correct English usage; here is a suggestion (italics are words that I changed from your original): . constrainingClassifier : Classifier [0..*] The classifiers that constrain the argument that can be used for the parameter. If the allowSubstitutable attribute is true, then any classifier that is compatible with any of these constraining classifiers can be substituted; otherwise, it must be either one of these classifiers or their respective subclasses. If this property is empty, there are no constraints on the classifier that can be used as an argument. Issue 11239: Agreed. The statement should read: "make ValueSpecification::duration and ValueSpecification::timeExpression composites" Issue 10591: The issue seems quite valid, but is ValueSpecification (instead of Action) general enough? We need Oystein to comment on the thinking behind this one. I believe that the intent was to point to an action instance that had the necessary values specified; if so, it is a rather vague and indirect way to specify arguments. Issue 10820: I think that the real problem here is that the semantics of ports providing/requiring multiple interfaces are highly ambiguous. A much better solution to this problem is to limit the number to at most one required and/or provided interface per port. This will remove the ambiguity in both the connection and the semantics of ports. This issue needs to be addressed in depth. Issue 9003: Agreed, but we need to understand the impact of this on implementations on users and existing tools. Issue 9834: Although this proposal sounds reasonable, it should be clear that this is merely an optimization intended to make the jobs of tool builders easier; it is transparent to UML modelers. Therefore, a change like this should be assessed in terms of its impact on existing models and tools. For example, if the impact is backward compatibility issues between models of different versions or to bulking up of models due to additional data per model element, then I dont think it is worth the effort. I am also concerned with the possibility of introducing additional semantic conflicts between the current definition of these elements and the new generalization. How can we be confident that such conflicts will not be created? Unless we have reassurances of this type, it seems to me that this is more trouble than it's worth. Issues 8077, 9961, 9962: These too look like optimizations that are really only of benefit to tool builders, and not necessarily all of them. Modeler's can create links in their model currently and are not overly concerned with whether the repository names the result Link or InstanceSpecification. This may not be worth the disruption that it introduces. Issue 10819: I have already commented on this one. I agree that there are problems here that need to be resolved; but, as I said, I think that this is a key architectural issue that should be addressed in a systematic manner, rather than as some kind of local fix. Issue 10821: I agree that something needs to be done about this. However, I have concerns that the proposed resolution is too loose, since it allows any element to be named as a reference. It would be nice if this could be tightened in some way. I think we need to discuss this one further. ====================================================================== Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Nerijus Jankevicius" 08/24/2007 11:22 AM To cc Branislav Selic/Ottawa/IBM@IBMCA, "Pete Rivett" Subject updated resolutions for UML 2.2 Hello, See attached updated list of resolutions of some important UML 2.1.1 issues. Some issues requires quite important metamodel changes, so please start discussions on that. Any feedback is welcome. Thanks in advance, -- Nerijus Jankevicius Senior System Analyst No Magic Lithuanian Development Center[attachment "resolutions of UML2.2 issues.doc" deleted by Branislav Selic/Ottawa/IBM] Subject: RE: Some additional potential resolutions for Ballot 7 Date: Wed, 27 May 2009 11:09:55 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Some additional potential resolutions for Ballot 7 Thread-Index: AcneZNb+vOmYTcQTRSajnByJdsEUzwAcdHtQAAERKrA= From: "Ed Seidewitz" To: Cc: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id n4RFBPAQ001476 Conrad -- I went back and forth on this myself. Nicolas had it marked as a duplicate, and my first reaction was similar to yours. However, after re-reading 8077 (the issue number should really be 8077, not 8007) a couple of times, I realized that the key point was "There are no properties available for navigating from an instance of an association (link) to the end objects." The rest of the issue is mostly describing the negative consequences of this. Issue 12912 also addresses this: "Similarly one would expect the link InstanceSpecification to somehow reference its ends." I agree that 8077 is more narrow than 12912 (other than 8077 proposing ReadLinkObjectEndAction, which already exists. But I believe that this means that resolving 12912 will also resolve 8077. Specifically, 8077 proposes "The metamodel should have an association for properties that have the end objects of link objects as values." Similarly, 12912 proposes InstanceSpecification allow "a memberSlot [parallel to Association::memberEnd] referencing Slots owned by other InstanceSpecifications". But the actual resolution is really up to the RTF in the end, of course. So, on the whole, I agree with Nicolas that 8077 is a duplicate, and 12912 is the one we want to resolve. It doesn't seem worth it to me to keep both open. However, if you still don't agree -- or if others on the RTF agree with you -- it is probably not critical to put this one on Ballot 7. -- Ed > -----Original Message----- > From: Conrad Bock [mailto:conrad.bock@nist.gov] > Sent: Wednesday, May 27, 2009 10:29 AM > To: uml2-rtf@omg.org > Subject: RE: Some additional potential resolutions for Ballot 7 > > Ed, > > One comment below. > > Conrad > > - Issue 8007 (Properties on Association for end object) > > This doesn't appear to be a duplicate of 12912, at least not > enough to address the concerns of 8007. 8007 also proposes a > narrow solution regarding instance specs, rather than the general > problem of properties on association classes for navigating from > links. > DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=oz3i+toC3w4opSh1JmX4GtkB9OyyRadlIMaHfdlEsdc=; b=cwUsoqEENnXKIH8iEPvZ84WifEVTEDkBTkVtqTOOfg3PuajSzOF2ucs7x4mbl3x62f o9qvqBM8H0uHY826/1JWwZ7swnQFdnU9zCfWFdvyYG6pKItDMzjBj4CVqzFas2fpyYXb Yn2TlxqmzrkmPDIx/1XgLoBcdC2SXHLsy0pqk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=o6sVw75lBKF5F+s/+xB9QNl/y5Mz55CUPbA92o+l9qDOXtVAAbUKPe8FJ5iKjtPhZr 2HFaIfnwT9vY+Djxy8HWrdk30Nd9mDWuSt5olcMisa5phvL4tqZMtC1YE28Cieh0CPQ1 83MMN0bR1zBA5LZGbpPvx3ZH4S9lnebMUqp6U= Date: Wed, 27 May 2009 15:40:03 -0400 Subject: Re: Some additional potential resolutions for Ballot 7 From: Bran Selic To: Ed Seidewitz Cc: conrad.bock@nist.gov, uml2-rtf@omg.org I suggest that this discussion be included in the resolution proposal -- whenever it is submitted. Bran On Wed, May 27, 2009 at 1:04 PM, Ed Seidewitz wrote: Conrad -- I think you may be misreading 8077 (or maybe I am!). I don't think it has to do with associations, as such, but with instances of associations (links), as indicated by the quote I gave from it. This is the same thing that 12912 is dealing with. But, since we are down to the wire with Ballot 7, we can take it off for now and work this out for the next ballot. -- Ed > -----Original Message----- > From: Conrad Bock [mailto:conrad.bock@nist.gov] > Sent: Wednesday, May 27, 2009 11:46 AM > To: uml2-rtf@omg.org > Subject: RE: Some additional potential resolutions for Ballot 7 > > Ed, > > > I went back and forth on this myself. Nicolas had it marked as a > > duplicate, and my first reaction was similar to yours. > > This is a good reason not to include it in ballot 7. > > > However, after re-reading 8077 (the issue number should really be > > 8077, not 8007) a couple of times, I realized that the key point was > > "There are no properties available for navigating from an instance > > of an association (link) to the end objects." The rest of the issue > > is mostly describing the negative consequences of this. > > > > Issue c also addresses this: "Similarly one would expect the link > > InstanceSpecification to somehow reference its ends." I agree that > > 8077 is more narrow than 12912 (other than 8077 proposing > > ReadLinkObjectEndAction, which already exists. But I believe that > > this means that resolving 12912 will also resolve 8077. > > > > Specifically, 8077 proposes "The metamodel should have an > > association for properties that have the end objects of link objects > > as values." Similarly, 12912 proposes InstanceSpecification allow > > "a memberSlot [parallel to Association::memberEnd] referencing Slots > > owned by other InstanceSpecifications". > > Thanks for showing the similarities, but this is in proposed solutions, > rather than in the issues identified. 8007 as an issue is concerned > with associations, 12912 with instance specs. It might be the same > solution addresses both, but I'd rather close them together when we know > for sure. > > Conrad >