UML 通信图中涉及的对象之间的关系

Question

In short

In an UML communication diagram, the objects that interact with each other are visually connected with lines along which sequenced messages can circulate in both directions. Lines between objects usually represent links, ie instances of an association. But objects can exchange message even if they are not associated (eg if one object is passed as parameter or return to the other).

I wish to represent such a message exchange between objects that are not associated. But I would like to disambiguate and clarify that there is no direct association between the involved objects. Do the UML specs allow to express this without creating user-defined stereotypes?

Moreover do the current UML specifications define somewhere a term for the relation between objects in a communication diagram that interact ? And is it possible to further specify in the diagram how the communicating objects know about each other?

More research done before asking the question

I am currently re-reading " The UML User Guide, 2nd edition " by Grady Booch, James Rumbaugh and Ivar Jacobson, a great book that explains the UML specifications in reader-friendly plaintext. It's the updated UML 2 edition of the book and I could map back to the UML 2.5.1 specifications most of their claims.

In chapter 16 on interactions however, they explain that objects communicate along links:

A link specifies a path along which one object can dispatch a message to another (or the same) object. (...) If you need to be more precise about how that path exists, you can adorn the appropriate end of the link with one of the following constraints:

• association: (...) object is visible by association
• self: (...) object is visible because it is the dispatcher of the operation
• global: (...) object is visible because it is in an enclosing scope
• local: (...) object is visible because it is in a local scope
• parameter: (...) object is visible because it is a parameter

In chapter 19, they explain for communication diagrams that objects involved in the interaction are shown interlinked:

you render the links that connect these objects as the arcs of this graph. The links may have rolenames to identify them. Finally, you adorn these links with the messages that objects send and receive.

This seemed straightforward. So I looked for the corresponding UML 2.5.1 specifications:

• Links are solely defined as instances of associations.
• For communication diagrams, there is no mention at all in section 17.9 of links nor communication channels. Figure 17.26 shows interlinked objects (ie lifelines), but the lines linking the objects AND the arrows representing the messages along this line seem both to be graphically defined as "messages". This seems very ambiguous to me.
• Moreover I have not found any reference to constraints, keywords or pre-defined stereotypes that could describe how the objects know about each other in a particular diagram and that could justify a communication channel between them.
• I could find «association» , «local» , «global» , «parameter» (with the same meaning as above) defined as stereotypes in the obsolete UML 1.4 specification, but no longer in the current specs.

Hence my question.

Answer 1

The specification doesn't say this explicitely, but I think this is the definition of link used:

Two objects are said to be linked, when they can interact with each other.

There are several places in the specification that talk about links. The most general one I found in 11.2.3.3

Each link may be realized by something as simple as a pointer or by something as complex as a network connection, and may represent the possibility of instances being able to communicate because their identities are known by virtue of being passed in as parameters, held in variables or slots, or even because the communicating instances are the same instance.

From this I derived my simple definition.

So, I disagree, links are not "solely defined as instances of associations" . This misunderstanding probably stems from the fact, that specifying links with InstanceSpecifications is only possible for Associations: Each InstanceSpecification that wants to have slots for the linked InstanceSpecifications must have an Association as Classifier. But - links can be there even if they are not specified. And they can be specified by other model elements.

These other link specifying model elements include connectors in composite structure diagrams or messages in interaction diagrams or attributes and parameters in class diagrams.

Communication diagrams are just a way to show an interaction. They have the same underlying metamodel instances as a sequence diagram. Therefore, even though there are lines in between the lifelines, there is no corresponding model element. They are just there to have a place for attaching the message symbols (see Table 17.4 Graphic Paths Included in Communications Diagrams).

It is possible for a message to reference a connector. So, you can view the line in the communication diagram as a visual representation of this connector. However, it is not necessary to model the connector explicitely. There are tools that will require a connector, but in the specification the connector is optional.

As you say, there are no stereotypes to describe how objects know each other. You would need to define your own. However, there are other possibilities: A Lifeline represents a connectable element, which can either be a parameter or an attribute (or a variable, but nobody uses them). By looking at the represented attribute, you can find out, whether it is a global or local attribute and whether it is an association end.

Having said that, there is a catch. Officially all represented elements must belong directly or indirectly to the context class of the interaction (same_classifier constraint in 17.12.17.5). In most cases I encounter, this context is just the system. This means, all attributes must be global. I had a long conversation with the author of this section, and found out, that the idea was, that an interaction should belong to a collaboration and the connection to the system is via CollaborationUses and roleBindings. This is the reason, why MagicDraw automatically creates a Collaboration for each Interaction.

This adds another level of indirection, which solves, as we know ;-) all problems in computer science. Fortunately, most tools don't enforce this rule, so we are free to let our lifelines represent attributes and parameters of real components of our systems.