Link as instance, tuple, path



Date view Thread view Subject view Author view

Gonzalo Génova (ggenova@inf.uc3m.es)
Wed, 26 Jul 2000 13:18:54 +0200


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


Date view Thread view Subject view Author view