UML: how to represent indirect operation calls in a sequence diagram?

Question

Consider the following classes:

I would like to represent in a sequence diagram the fact that an instance of A first navigates through the b association end to reach a B instance, then navigates through its association c to reach a C instance, then calls the operation foo().

How can I represent this in a sequence diagram? Afaik, navigating from one object to an other is not a message, and thus cannot be represented by an arrow, can it? Then how can I show how the C instance is found by the A instance?

My only idea so far is to write a.b.c into the name of the C instance lifeline, but I know that this is very likely incorrect:

---

EDIT (28/11): I don't think that this question is a duplicate of this existing question, as here I am interested in representing in a sequence diagram how an object was able to access another object, and not how an object was obtained as a result of a method call / message.

---

EDIT (28/11 again): I realized that what the case I have described is wrong, as in fact an Interaction (ie. a sequence or communication diagram) has to be contained in a Classifier, and can only show Lifelines of elements accessible through the properties of the Classifier. Thus, with my current class diagram, it is in fact impossible to represent both an instance of A and an instance of C, since there is no candidate Classifier referencing both which could be used to contain the sequence diagram.

In other words, afaik, with the proposed class diagram, I cannot have a sequence diagram representing A and C, and I can only represent either A and B, or B and C.

Answer 1

In your diagram, you have used the association notation of attributes: +b means that b is a public attribute of A that has is of class B, and similarly c is a public attribute of B. So the notation a.b.c:C could be valid.

However, I'm not 100% sure if this is really valid UML. The standard foresees an element name and not an expression that determines the element. It allows qualified name, but in a namespace not in a classifier. The optional selector that is possible on the name is also not designed for traversing multiple relationships.

So a better approach would certainly be to give a simple name to your second lifeline (e.g. x, or keep it anonymous) and add a constraint that explains how it is determined ( e.g. { x = a.b.c }. In constraints, be it in OCL, java or natural language, you are allowed to do these kind of access to public attributes.

Now, this might not be desirable from an OO design perspective: using such public members creates a strong coupling and does not offer proper encapsulation. I'd therefore use some getter.

The result would then look like:

Note that if you don't like the assumption for b being known, you can replace the illustrative comment by a real constraint, exactly the way I explained above.

Answer 2

Well, there are not many options. As you see it's nothing you should do anyway since you're violating the paradigm of information hiding.