UML: как представить косвенные вызовы операций в диаграмме последовательности?

Question

Рассмотрим следующие классы:

Я хотел бы представить на диаграмме последовательности тот факт, что экземпляр A сначала перемещается по b конец ассоциации для достижения экземпляра B, затем переходит через его ассоциацию c для достижения экземпляра C, затем вызывает операцию foo().

Как я могу представить это на диаграмме последовательности?Афаик, навигация от одного объекта к другому - , а не сообщение, и поэтому не может быть представлена ​​стрелкой, не так ли?Тогда как я могу показать, как экземпляр C обнаруживается экземпляром A?

Пока что моя единственная идея - записать a.b.c в имя линии жизни экземпляра C, но я знаю, что это очень вероятноневерно:

---

РЕДАКТИРОВАТЬ (28/11): Не думаю, что этот вопрос является дубликатомиз этого существующего вопроса , так как здесь меня интересует представление на диаграмме последовательности, как объект смог получить доступ к другому объекту, а не как объект был получен в результате вызова / сообщения метода.

---

РЕДАКТИРОВАТЬ (снова 28/11): Я понял, что описанный мной случай неверен, как на самом деле Взаимодействие (т.е. последовательностьили схема связи) должна содержаться в классификаторе и отображать только линии жизни элементов, доступных через свойства классификатора .Таким образом, с моей текущей диаграммой классов на самом деле невозможно представить как экземпляр A, так и экземпляр C, поскольку нет ни одного кандидата Classifier , ссылающегося на оба, которые можно было бы использовать для содержания диаграммы последовательности.

Другими словами, afaik, с предложенной диаграммой классов я не могу иметь диаграмму последовательности, представляющую A и C, и я могу представлять только либо A и B, либо B и C.

Answer 1

На вашей диаграмме вы использовали обозначение ассоциации атрибутов: +b означает, что b является открытым атрибутом A, который имеет класс B, и аналогичным образом c является открытым атрибутомB.Таким образом, запись a.b.c:C может быть действительной.

Однако я не уверен на 100%, действительно ли это UML.Стандарт предусматривает имя элемента, а не выражение, которое определяет элемент.Это позволяет квалифицированное имя, но в пространстве имен не в классификаторе.Необязательный селектор, который возможен для имени, также не предназначен для обхода нескольких отношений.

Поэтому лучшим подходом, безусловно, было бы дать простое имя вашей второй линии жизни (например, x или оставить его анонимным).) и добавьте ограничение , которое объясняет, как оно определяется (например, { x = a.b.c }. В ограничениях, будь то на OCL, Java или естественном языке, вам разрешено делать такие видыдоступ к общедоступным атрибутам.

Теперь это может быть нежелательно с точки зрения проектирования ОО: использование таких открытых членов создает сильную связь и не обеспечивает надлежащей инкапсуляции . Поэтому я бы использовалнекоторый получатель.

Результат будет выглядеть следующим образом:

Обратите внимание, что если вам не нравится предположение о том, что bизвестно, вы можете заменить иллюстративный комментарий реальным ограничением, точно так, как я объяснил выше.

Answer 2

Ну, вариантов не так много.Как видите, ничего не стоит делать, поскольку вы нарушаете парадигму сокрытия информации.