Gonzalo Génova (firstname.lastname@example.org)
Thu, 25 Jan 2001 13:05:25 +0100
I answer to many of you in this single message. Gonzalo Daniel Jackson wrote: > 2. it's phenomenologically spurious (see chapter on "designations" in: M. Jackson, Requirements and Specifications, Addison Wesley 1995). we won't want an abstract model to make distinctions that we can't make in the real world. for example, if the parent association is a set of links, we'll have to explain what the difference is between Alice being Bob's parent under link L1, and Alice being Bob's parent under link L2. > 5. what would it mean to have two distinct links that link the same objects? this might sometimes be useful, but then you should just construct a link object specially. in the general case, it will be tedious and obscure to have to rule this out. I think the example given later by Perdita Stevens about Edge and Node answers this. === Guy Genilloud wrote: > I am not (yet) on the p-uml mailing list, so please keep me posted in follow-ups to this discussion. I'm afraid you have already lost some messages. You can access the whole list at (http://www.cs.york.ac.uk/puml/puml-list-archive/). === Arend Rensink wrote: > Here you suggest that links are sometimes explicitly manipulated, i.e. should somehow be considered "first class citizens" (to take a term from programming language design). That would be a good reason to have link identities, but in what context does this occur? Certainly not on the implementation level (shudder)! Well, maybe we have to manipulate a link explicitly when we create or delete it. We could say we already have the object's operations to achieve this, but I see a conceptual problem. An ordinary attribute may be get or set through an operation of the object that owns it, right. But who is the owner of a link? In a restaurant reservation system, if I create a link between John and table A17, should I invoke John.reserveTable(A17) or A17.reserveCustomer(John)? Are these two operation invocations equivalent? Should I have instead Reservation.create(John, A17)? === Perdita Stevens wrote: > So, sometimes we want associations to be classifier-like and sometimes we don't. But we have association classes, for when we really want associations to be classifiers, and it's a notion that already needs some attention. Couldn't we use this to square our circle? We'd say something like: an association is just a set of tuples. An association class _induces_ an association, but actually it's more than just an association. It is a thing which can give you its instances in two ways. If you ask for its set of instances as an association, you get a set of tuples. If you as for its set of instances as a class, you get its objects, which have tuples but also identity and whatever else you want. There is a function from objects of an association class to links of the induced association, but it need not be a bijection. This may solve many of my problems, I will reflect on it. > Maybe, then, we'd say we don't need generalisation of associations, we just have generalisation of association classes....?) The generalization of associations has always puzzled me... > I have an unfinished paper sitting around on associations in UML, maybe others do too. Is anyone interested in getting together as a group and writing the definitive paper? I am surely interested in your paper, since my own interest area lies on semantics of associations. > Incidentally I had been thinking 1.4beta was more consistent than it is. In fact: 2-20 says a Link "is a tuple of Instances drawn from the corresponding Classifiers" This suggests me this idea: in a concrete model, a link is an instance of an association (say, John-A17 is instance of Reservation). But, in general, every link is an instance of the metaclass Link; that is, every link in a UML model is an object an therefore has an identity... (btw, this could be said of every element in a UML model, as every element is an instance of metaclass ModelElement). === Joaquin Miller wrote: > R: There is a relationship between these objects, or between these Classes (i.e. between members (read: instances) of these classes). C: There is a connection between these objects, or between instances of these Classes, whereby one (or more) can communicate with the other(s). R is Perdita's Static; C her Dynamic. I think this is the same distinction you made last July, in response to my "Link as instance, tuple, path" contribution, isn't it?: "Often (very often) in practice two concepts are conflated: relations (associations as sets of tuples) and references (associations as sets of paths). This practice is codified in UML: the UML association is specified to be a relation (a set of links as tuple); the UML link is specified to be an instances of a UML association (and so to be a tuple); yet, the UML link is specified to be used to represent both a tuple (that is the tuple of the mathematical theory of relations) and a path (often called a reference)." In my own ongoing research I phrase it as the data structure approach vs. the interaction or communication structure approach. === Stuart Kent wrote: > It may also be worth spreading the net wider. Objects tend to communicate by issuing and listening for events nowadays. How should we abstract out those connectiosn in our diagrams? A very interesting question, but as far as I know it does not affect the core of the discussion. In the UML, a message is directed to an object in the same way, be it an ordinary operation invocation or an event sendig: using a communication path. Whether this path is a link or not, that is what we are discussing. I quote: "Signal events and call events involve at least two objects: the object that sends the signal or invokes the operation, and the object to which the event is directed" (User Guide, p. 281). So, in sending a signal you have to specify a concrete receiver. "In some situations, you may want to show one object sending a signal to a set of objects (multicasting) or to any object in the system that might be listening (broadcasting). To model multicasting, you'd show an object sending a signal to a collection containing a set of receivers. To model broadcasting, you'd show an object sending a signal to another object that represents the system as a whole" (p. 282). Then it seems that, in modeling broadcasting as the User Guide suggests, the receiver is not specified. Is this in contradiction with the previous quote? === Kerry Raymond wrote: > Clearly, structural relationships and communication paths are completely different things, and conceptually we should keep them so with their own properties and not attempt some "unified theory" merging two entirely different concepts, just because we draw them the same way. Well, this is preciseley what this discussion deals with. I agree they are different things, and we need some conceptual clarifications. But the confusion does not come exclusively from the way we draw them: it is well rooted in the UML metamodel.