Issue 12912: InstanceSpecifications (uml2-rtf) Source: (, ) Nature: Enhancement Severity: Significant Summary: To better express links with InstanceSpecifications, InstanceSpecification should be able to reference Slots owned by other InstanceSpecifications similar to an Association's memberEnd. Currently, when modelling an object diagram with a link like the one in fig. 7.54 on p.85, the specification is unclear on which of the involved InstanceSpecifications (Don, Josh, assoc) should own which Slots (father, son). Assuming that the involved association ends are ownedAttributes of the respective classes (Person), one would expect the object specifications (Don, Josh) to have Slots for these ends. Similarly one would expect the link InstanceSpecification to somehow reference its ends. Since a Slot can only belong to one InstanceSpecification, this is currently only possible by duplicating Slots and InstanceValues between object and link InstanceSpecifications (at least that is how e.g. Rational does it). This leads to two problems. First there is of course a lot of redundancy and chances for inconsistency. Second, and more importantly, there is no easy way to navigate from an object InstanceSpecification to the "connected" link InstanceSpecifications. On type level, an association can reference member ends that are owned by other classifiers. For the sake of consistency and simplicity, we would suggest something similar on the instance level for the InstanceSpecification-Slot relationship, i.e. a memberSlot referencing Slots owned by other InstanceSpecifications (maybe in a specialized LinkSpecification). I have created some diagrams to better illustrate the problem, albeit for a different example: - The example: http://www.reckord.de/uml/example.png - What it currently looks like on the meta level: http://www.reckord.de/uml/example-metaobjects.png - What it could look like: http://www.reckord.de/uml/example-meta-fixed.png Resolution: Revised Text: Actions taken: October 6, 2008: received issue Discussion: End of Annotations:===== m: webmaster@omg.org Date: 06 Oct 2008 12:27:54 -0400 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Carsten Reckord Company: University of Kassel mailFrom: creckord@uni-kassel.de Notification: Yes Specification: UML Superstructure Section: 7.3.22 FormalNumber: formal/2007-11-02 Version: 2.1.2 RevisionDate: 11/02/2007 Page: 82ff Nature: Enhancement Severity: Significant HTTP User Agent: Opera/9.52 (Windows NT 5.1; U; en) Description To better express links with InstanceSpecifications, InstanceSpecification should be able to reference Slots owned by other InstanceSpecifications similar to an Association's memberEnd. Currently, when modelling an object diagram with a link like the one in fig. 7.54 on p.85, the specification is unclear on which of the involved InstanceSpecifications (Don, Josh, assoc) should own which Slots (father, son). Assuming that the involved association ends are ownedAttributes of the respective classes (Person), one would expect the object specifications (Don, Josh) to have Slots for these ends. Similarly one would expect the link InstanceSpecification to somehow reference its ends. Since a Slot can only belong to one InstanceSpecification, this is currently only possible by duplicating Slots and InstanceValues between object and link InstanceSpecifications (at least that is how e.g. Rational does it). This leads to two problems. First there is of course a lot of redundancy and chances for inconsistency. Second, and more importantly, there is no easy way to navigate from an object InstanceSpecification to the "connected" link InstanceSpecifications. On type level, an association can reference member ends that are owned by other classifiers. For the sake of consistency and simplicity, we would suggest something similar on the instance level for the InstanceSpecification-Slot relationship, i.e. a memberSlot referencing Slots owned by other InstanceSpecifications (maybe in a specialized LinkSpecification). I have created some diagrams to better illustrate the problem, albeit for a different example: - The example: http://www.reckord.de/uml/example.png - What it currently looks like on the meta level: http://www.reckord.de/uml/example-metaobjects.png - What it could look like: http://www.reckord.de/uml/example-meta-fixed.png 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.