RE: Sets and bags / Identity of a link



Date view Thread view Subject view Author view

Guy Genilloud (guy.genilloud@fsarch.com)
Wed, 24 Jan 2001 20:38:39 -0500


Arend, Thanks for your reply. Note that I am not quite interested in the translation of associations into a mathematical construct or another. I just want the constraint introduced by the 'set of tuples" idea to be removed, from the core of UML 2.0. UML will become a family of languages, and I am asking for not arbitrarily excluding many people. I want a big UML family, with many friends and few ennemies :-) I was asked an example, and this is the true purpose of this reply. Plus, I have one question for you. See below. > -----Original Message----- > From: Arend Rensink [mailto:rensink@cs.utwente.nl] > Sent: Wednesday, January 24, 2001 5:18 AM > To: puml-list@cs.york.ac.uk > Cc: 'Guy Genilloud'; Juan Llorens; J.Miguel Fuentes Torres > Subject: Re: Sets and bags / Identity of a link > ... > Gonzalo Génova wrote: ... > > Unfortunately, the UML standard states that > > each tuple may appear at most once in an association. > > That seems clear enough. The UML chooses 2a. Or does it? An > association end may be marked "ordered"; then we get interpretation 3d >(sic!). Here is my question to you: how does the constraint of only one tuple in a set disappear when we specify that an association may be ordered? I would naively think, from ordinary language, that a an ordered association is a specilization of an association: adding constraints to it. I thought that qualified associations removed the set of tuples constraint, but I looked at the definition of qualifier and saw that this was not the case. > > Guy Genilloud wrote: ... > > Seems to me you're too late. The deed is done. Well, I am not too late for UML 2.0. And if UML contradicts itself in this matter as you point out, then this constradiction ought to be resolved, one way or the other... > > > 1- Reverse engineering: the impossibility to model in a > > class diagram some object implementations. If two objects can have > > an unbounded number of links between them, the set of tuples > > pre-constraint makes that situation impossible to represent in > > a class diagram in a natural way (that is, without introducing a > > third object class, that has no object instances)... > > I'd like an example here. Anyway, your argument is against > option 2a/3a, but not necessarily in favour of 1. I mean that most if not all OO programming languages allow an object to have several links of the same kind to a same other object. There is not going to be a static type error, and not even a dynamic error. So why should UML systematically impose a constraint that OO languages do not impose? For example, let's the case of an object sending notifications to subscriber objects. If an object wants to have n times the same notification, why not allow this in UML? Speaking of reverse engineering, if an implementation allows an object to have n links, n being possibly unknown before runtime, then how do you model this in a class diagram. The solution is of course to have multiple associations with different names... But there is no mechanism in UML to generate a series of associations. You'll only have as many links as you draw associations, and that's it. > > > 2- Not always inforceable. If you are implementing a CORBA object, how do > > you make sure that you never get two links to a same object (remember that a > > CORBA object may have several different identifiers, that may not be > > compared for equality). > > An interesting point. I suspect you could model this by > making the CORBA object identifier, which obviously is NOT the same as the > actual object identity, a class in its own right, with an association to > the real object. > Exit problem. Two points: -- I think that what you are asking of "CORBA modellers" is not acceptable, and without good reasons. And CORBA is an OMG standard... -- It is a common mistake to say that objects have "an identity". Objects have identity, not an identity. Meaning that an object represents itself and not any other object (consider the definition of identity in a dictionary). And that all there is to it. The notion that an object has one secret globally unique number (erroneously named "identity") to support this requirement is just an implementation choice or an accident. Another implementation choice (that of CORBA) is to have each object have possibly several globally unique numbers (the CORBA object identifiers). Regards Guy Genilloud


Date view Thread view Subject view Author view