Re: Link as instance, tuple, path



Date view Thread view Subject view Author view

Joaquin Miller (miller@joaquin.net)
Wed, 26 Jul 2000 08:49:30 -0700


This is an excellent separation of concerns! You say some things i disagree with or would say differently, you point out one place where i must explain myself and i'd like to propose a separation of what you say according to some viewpoints. I don't have time for that now. But i applaud and second the idea that "the answers [to the problems with associations and links] may be decomposed into three different threads, corresponding to the three headers, link as instance, link as tuple, link as path." In that light, let me simply rephrase what i said: "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)." [Note the difference (in my usage above) between tuple (e.g. the pair (a,b)) and reference (e.g. the path (a -> b) (or, (if you prefer: the end of the path) ).] At 04:18 AM 7/26/2000, Gonzalo Génova wrote: >Dear pUML members, > >Last January there was an interesting discussion promoted by myself, grouped >in two threads, "modeling link creation" and "links & messages". I would >like to take back some of the ideas that arose then, regarding the concept >of link in UML. I group these ideas in three characterizations of link: link >as instance (which is merely formal), link as tuple (which states a fact >without clarifying its meaning), and link as path, that is, knowledge one >object has of another one (which at last tells us what a link is). This >contribution is rather long, so if you prefer the answers may be decomposed >into three different threads, corresponding to the following three headers. > >LINK AS INSTANCE > >"Each link is an instance of an association" (UML v1.3, p.2-100). I say this >statement is merely formal in a similar sense to that expressed by Stuart >Kent: "We can have a mathematical semantics for class diagrams, e.g. based >on relations, which tells us, given an object diagram, whether that object >diagram satisfies the class diagram or not." > >However, there seemed to be a tacit agreement that some links are not >instances of associations, although this is a clear principle of UML. As >Rober France states it: "Must a link in a Collaboration Diagram be an >instance of an association in a corresponding Class Diagram? The answer >seems to be no (based on my current understanding of Collaboration >Diagrams), and this is probably desirable if only to reduce clutter in the >Class Diagrams." > >Well, I think we can reconcile both positions, the "official" one and the >"pragmatical" one, by admitting that each link must be an instance of an >association, but you can choose not to show that association in some class >diagrams in your model, especially when the link is stereotyped as ><<parameter>>, <<local>>, <<global>> or <<self>>, because in these cases >there exists an implicit association and you can say it needn't be made >explicit (Jos Warmer: "common practice is to show only <<association>> >associations in a class diagram"). But note that the association exists >although you don't show it, and so the theoretical principle is not broken. > >Robert proposes also to distinguish between persistent and transient >associations: "A high-level design Class Diagram should show only persistent >associations (i.e., associations whose links persist between operation >invocation); thus if an object is passed as a parameter to an operation in >another object I would not show this relationship as an association in the >Class Diagram. Class Diagrams at lower levels of abstraction may show >transient relationships." Well, I don't believe that "persistency" be a good >criterion to decide whether to show or not to show an association in >high-level diagrams. Instead, in Analysis Diagrams (which are higher-level) >I would show those associations, persistent or not, that are essential to >understand the problem; and in Design Diagrams (which are lower-level), I >would add those associations that are needed to implement the solution. This >is probably related in practice with persistency, but they are nevertheless >different concepts. > >LINK AS TUPLE > >"The instances of an association are a set of tuples relating instances of >the classifiers" (UML v1.3, p.2-19). The existence of a given tuple merely >states a fact, that two or more object instances are related, but the >characterization as "tuple" doesn't clarify what the meaning of that fact >is, that is, what is the purpose or utility (in other words, the semantics) >of those objects being related. The meaning of a link will become clear only >with its characterization as path for communication (that the objects know >about each other). That is, the mere constatation of the existence of a link >is semantic-less unless we understand what do we use the link for. Using the >words of Joaquin Miller, "the data content of a link is a tuple"; but the >data content of an entity is insufficient to understand an entity if you >don't know how to use it. > >"A link is a tuple (list) of object references" (UML v1.3, p.3-78). Some of >you think the concept of reference is too low-level. Robert France: "At the >requirements (problem-oriented) level a Class Diagram should be a conceptual >model (as advocated in methods/approaches such as Fusion and Syntropy), >meaning that associations represent conceptual relationships between problem >concepts represented as classes - a semantics as a set of tuples is >appropriate at this level of abstraction; viewing links as references (as >the term is used in programming languages) I think is inappropriate here." >Stuart Kent: "When modeling close to the implementation level we may choose >to interpret links as indicating that an object has a (probably private) >stored reference to another object. This is encoded e.g. by mapping >associations to private attributes when mapping the model to an OOPL." I >agree with you, but I don't understand this other remark by Joaquin Miller: >"Often (very often) in practice two concepts are conflated: relations and >references. This practice is codified in UML: the UML association is >specified to be a relation; UML links are specified to be instances of UML >association; yet, UML links are specified to be used to represent both >tuples of relations and references." What is the difference between a >relation and a tuple of references? > >"An n-ary association is an association among three or more classifiers (a >single classifier may appear more than once). Each instance of the >association is an n-tuple of values from the respective classifier" (UML >v1.3, p.3-73). The view of an association as a set of tuples leads easily to >the consideration of n-ary associations and links within the same conceptual >frame as binary associations and links: an n-ary link is a n-tuple of >objects, as a binary link is a pair of objects. But, as we shall soon see, >there may be some difficulties with the semantics (purpose, utility) of an >n-ary association. > >LINK AS PATH > >"Wherever there is a link between two objects, one object can send a message >to the other object" (UML User Guide, p.209). "A link specifies a path along >which one object can dispatch a message to another (or the same)" (UML User >Guide, p.210). Thus, we use links to enable communication among objects: an >object can communicate with the objects linked to itself, that is, the >objects it "knows about". > >Most of you agree with these sentences. Heinrich Hussmann: "An object can >send a message to any other object it knows about. And a link between object >OB1 and OB2 is the UML representation of the fact that these objects know >about each other." Stuart Kent: "When conceptual modeling we will interpret >a link between two objects as just meaning that they know about each other >in some way." Robert France: "For communication to take place between >objects the sending object must know the identity of the receiving object. >If you interpret a link as one object "having knowledge" (knows the >identity) of the other object (where the direction of the link indicates >which object knows about the other) then a link must exist between objects >for communication to take place (assuming that there are no other mechanisms >other than links for doing this)." As Joaquin Miller also points out, a link >by itself doesn't mean mutual knowledge of the involved objects, unless the >corresponding association be navigable in both directions. > >But Daniel Jackson doesn't agree: "In a conceptual model, a link doesn't >mean the two objects "know about each other". It simply means that there is >a property that holds for the pair. For example, in describing access >control, I might have a set Privilege, and a relation dominates : >Privilege -> Privelege where dominates relates privelege p1 to privelege p2 >if having p1 is at least as good as having p2. Just because ReadWrite >dominates Read doesn't mean that one privilege "knows about" the other." >Well, in this case I don't think we are dealing with a true association, but >rather another kind of relationship, analogous to the precedence >relationship that holds for natural numbers. Just because "number three is >greater than number two", I wouldn't say that "three knows about two", but I >wouldn't claim either that those numbers are associated. Any other opinions? > >Therefore, it seems to me that the semantics of links is intrinsicly tied to >communication. Certainly, the fact that "A is linked to B" is stored as a >tuple somewhere in the system, but the "meaning" of that fact is that "A can >send a message to B", or "A can use B", or "A knows about B", or whatever >you want to express it. Now, communication is always modeled in UML, as far >as I understand, as a binary interaction: one sender sends a message to one >receiver (a broadcasting is truly a set of binary messages). Indeed, the UML >metamodel associates at most one receiver and one sender with a stimulus >(UML v1.3, p.2-86, Figure 2-16 Common Behavior - Instances and Links; >"stimulus" has substituted the "message instance" from v1.1). "A stimulus >reifies a communication between two instances. In the metamodel Stimulus is >a communication, i.e. a Signal sent to an Instance, or an invocation of an >Operation. (…) It has a sender, a receiver, and may have a set of actual >arguments, all being Instances." (UML v1.3, p.2-94). > >So, if we tie together the concepts of message and association, in the sense >that an association instance (a link) is the infrastructure along which >messages are sent, then we can speak only of binary associations and links! >This paradox has the following solutions: > >1. True, there are only binary associations, and n-ary associations are no >more than sets of binary associations with additional constraints. I know >there are some that hold this opinion, but I myself do not. >2. An n-ary link is the infrastructure along which an n-ary message is sent. >An n-ary message would have one sender and n-1 receivers, but contrary to a >broadcasting message, it could not be decomposed in n-1 binary messages. Has >this any sense for you? Or else, an n-ary message would have one sender, n-2 >objects that collaborate in the sending (for example, in the identification >of the receiver, or allowing the sender to send) and one receiver. Too >crazy? The concept of "n-ary message" is no doubt a difficult one, maybe >even an impossible one. >3. An n-ary link allows the sending of binary messages between any two >instances linked. This seems easy, but breaks the idea that the semantics of >links is intrinsicly tied to communication. > >Well, I think it's enough. As I said, if you prefer the answers may be >decomposed into three different threads, corresponding to the three headers, >link as instance, link as tuple, link as path. > >Regards, >Gonzalo > > > >To remove yourself from this list please mail puml-list-request@cs.york.ac.uk >with a message containing the word "unsubscribe". Cordially, 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