Re: Sets and bags / Identity of a link



Date view Thread view Subject view Author view

Joaquin Miller (miller@joaquin.net)
Wed, 24 Jan 2001 09:44:01 -0500


This discussion just keeps getting better. This is the deepest yet. Another way to look at this is that we have two radically different concepts: 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. Perdita, it is with great respect and great trepidation that i say you have fallen into the UML habit of hacking. I feel we need to try to completely and cleanly separate the idea (R) we got from entity-relationship diagrams (and before that, from the ancient philosophers) from the idea (C) that one object is connected to another. And do that without reference to UML. Then work on UML. Separating the two ideas with the association class is a hack. Perhaps that is all we can sell to the UML 2.0 submitters. But let's at least try to separate the two concepts cleanly, find a way to express the two concepts in a variant of UML, and try to sell that to the submitters. ....... Notice, everyone, that the link is, by most UML readers, read as an instance of a type of architectural connector, what ODP calls a direct binding. That's the second concept (C) i mention above. At 01:41 PM 1/24/2001 +0000, Perdita Stevens wrote: >[First, apologies for the hasty nature of this mail. I'm away, but >this topic is one that interests me too much for me to stay out of >it.] > >I like Arend's classification, it helps. But like all good >classifications it oversimplifies :-) (Also something went wrong with >the numbering: I will assume that 2b which wasn't actually defined was > >2b. An association is a bag of object tuples.) > >I don't really like this, it just seems neither one thing nor t'other: >OK, compromise is the core of UML, but for a moment let's step back... > >I think _one_ of the root causes of UML's ambiguity is that there is a >confusion between static and dynamic associations. What do we want to >*use* associations for? > >Static: I want associations to tell me something about the structure >of the associated classes. If you want the presence of an association >between two classes to model the existence in one class of an >attribute whose type is the other class, then you tend to view >associations as almost-classifiers. > >Dynamic: I want associations to tell me something about the dynamics of my >system. An association between A and B means simply that an object of one >of the classes may send a message to an object of the other, then it is >more natural to view the (identity-free) links as primitive with the >association seen as a relation. > >The complication arises of course because we want both, at different >times. Rumbaugh is on record as preferring static, but UML as it is >leans towards dynamic, without ever quite committing itself. I don't >want to claim that the static/dynamic distinction is identical with >any considered so far, but I think it is helpful as a way of >understanding the worldviews that arise. > >Consider the following example. We have class Edge with an association >called connects to a class Node and we put multiplicity 2 on the Node >end. Now, does a system in which an Edge sometimes connects a Node to >itself match the model? In UML1.4beta (for concreteness, I don't think >this is new) the answer is clear: NO! And the connection is that if >you forbid links to have identities (that is, you regard an >association as a relation), then this is natural (not inevitable) In >UML1.4beta 2-24: > >multiplicity When placed on a target end, specifies the number of >target instances that may be associated with a single source instance >across the given Association. > >If an edge e connects n to itself, there is only one target instance, >viz n. We fail the definition. > >Suppose you follow UML, but you intended not to forbid this situation. >You have a problem: you can write 1..2 instead, but that doesn't >capture the fact that edges have two ends. You're going to end up >writing two association source and target, probably. Not too bad in >this case, but arguably clumsy. > >There are also implications for what generalization of association >should mean... > >Despite these problems, on the whole I usually prefer to take a >dynamic view and to regard associations as sets of tuples, but there >are cases (e.g modelling product line architectures, I found recently) >where the static view is more useful. > >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. >Maybe, then, we'd say we don't need generalisation of associations, we >just have generalisation of association classes....?) > >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? > >Perdita > >PS My use case paper, which I mentioned some time ago, was accepted by >FASE and the updated version is on my webpage. I'd still very much >welcome comments, to feed into a more finished long version some time. >*Especially* if you know about related work please point me at it -- >however much you think I should already know about it... I've already >found one embarrassing omission and there may be more. >-- >Dr. Perdita Stevens >Division of Informatics, University of Edinburgh >www.dcs.ed.ac.uk/home/pxs Fax: +44 131 667 7209 > > > >To remove yourself from this list please mail puml-list-request@cs.york.ac.uk >with a message containing the word "unsubscribe". Cordially, Joaquin ................................................ Joaquin Miller Chief Architect Financial Systems Architects mailto:joaquin@acm.org San Francisco phone: +1 (510) 336-2545 fax: +1 (510) 336-2546 PGP Fingerprint: CA23 6BCA ACAB 6006 E3C3 0E79 2122 94B4 E5FD 42C3


Date view Thread view Subject view Author view