Вот черт! Это же и есть буквальный ответ на исходный вопрос! Действительно, так я еще не пробовал... Попробовал, действительно можно. Единственно, - UC-диаграмма вроде как "засоряется". Поэтому попытаюсь еще разобраться с "но IMHO лучше стереотипировать и комментировать.", но это уже следующий вопрос ...
Действительно, можно это сделать на отдельной диаграмме, чтоб не засорять ни UC, ни Class-диаграм. А может для подобной цели еще и какой-н специальный тип(подтип?) диаграммы предусмотрен, или просто оптимален?

Я так полагаю, что ответ автором найден? Если да, предлагаю дискуссию прекратить в данной теме. А если нужно обсудить тонкие моменты UML то, либо ищите имеющуюся тему (их предостаточно), либо создавайте новую коли лень искать или таковой темы на ваш взгляд нет.

Я получил исчерпывающий ответ на свой исходный вопрос (в №14 от AlexTheRaven), и еще много больше, за что всем огромное спасибо. Однако, если говорить только о части ответа, буквально относящейся к исходному вопросу, то ответ оказался обескураживающим и, мне кажется, весьма показательным. Я предполагал что-то подобное (в моем сообщении №12, абзац 4), но реальность превзошла мои ожидания. То, о чем я спрашивал, уже сейчас (прошло всего часов 10, не то что 2 года), представляется мне настолько очевидным, что я просто не представляю, сам себе не верю, что искал и не мог найти этот ответ … наверное много дольше месяца… Я знаю, если не изложу это сейчас, по самой свежей памяти, то уже через пару дней, при обращении ко мне с подобным вопросом, очень вероятно, буду недоумевать точно так же, как Gologen и другие, чего же хочет спрашивающий (даже говорить стыдно). Как мог бы выглядеть ответ на мой исходный вопрос, если бы не существовал эффект вытеснения самых элементарных фактов из сознательной памяти в почти бессознательную: "1. Язык UML не регламентирует отображение семантических (понятийных) связей между сущностями (элементами) диаграмм различных типов, оставляя способ их констатации в документации, при необходимости, в произвольной, на усмотрение автора, форме; 2. В Sparx возможность документирования подобных связей поддерживается очень просто: на любую диаграмму можно физически перетащить любые объекты из дерева модели, и связать их явно одним из доступных в данной диаграмме видом связи (линии и стрелочки в тулзе диаграмм). Данная возможность является чисто сервисной – ответственность за смысл или бессмысленность подобного решения всецело возлагается на автора и его компетенцию; 3. Мне адекватность прямого связывания ВИ и Классов, в частности, представляется весьма сомнительным.", – что-то в этом роде (на 100% в точности содержания не уверен)… и весь разговор был бы много короче. Все…
Да, топик можно закрыть (я должен заблокировать тему? - не нашел в хелпе).

Да, топик можно закрыть (я должен заблокировать тему? - не нашел в хелпе).

Блокировать не надо, мало ли какие вопросы, связанные с темой возникнут.

Выводы, которые Вы сделали, в частности 1, кажутся мне спорными. Но не так важно.

Реализация связи и прослеживаемости одних элементов UML через другие, сильно зависит от инструмента.

Sparx EA предлагает свою модель, возможно далеко не идеальную и не сразу понятную.

Еще раз перечислим способы, чтобы добиться того, о чем спрашивают в топике.

В дереве проекта мы создаем в разных пакетах различные артефакты: элементы, диаграммы и т.п.
На хотелось бы продемонстрировать связь одних артефактов через другие. Связь должна определяться потребностью. В нашем случае мы хотели показать какие классы(класс) реализует ВИ (просто связан с ВИ слишком абстрактно)

1. Создать новый пакет - скажем связей между артефактами и создать новую диаграмму - по сути любую.
На эту диаграмму перетащить как Simple Link соответствующий UC и класс(классы). Связать классы с UC отношением реализации

2. Создать пакет UC realisation, в нем диаграмму реализации. Перетащить на нее UC и создать collaboration. Сделать collaboration композитной (Make Composite). Добавит диаграмму классов, куда из репозитория перетащить классы участники

3. Не делать UC Realisation, а рассматриваем UC сделать композитным и назначить нужную диаграмму (там можно назначить массу диаграмм, права по умолчанию будет открываться одна только)

При этом можно вызвать Вид Иерархии - тогда встав на UC можно проследить все его связи с другими элементами. Можно вызвать More Windows/Relationships и тоже увидеть все виды отношений данного элемента с другими

Да я согласен, что куда как более удобнее было бы так: выделил элемент в его попап меню можно было бы увидеть список связанных диаграмм, элементов и т.п.

Вот кстати: Traceability in Enterprise Architect

1. Создать новый пакет - скажем связей между артефактами и создать новую диаграмму - по сути любую.
На эту диаграмму перетащить как Simple Link соответствующий UC и класс(классы). Связать классы с UC отношением реализации
2. Создать пакет UC realisation, в нем диаграмму реализации. Перетащить на нее UC и создать collaboration. Сделать collaboration композитной (Make Composite). Добавит диаграмму классов, куда из репозитория перетащить классы участники
3. Не делать UC Realisation, а рассматриваем UC сделать композитным и назначить нужную диаграмму (там можно назначить массу диаграмм, права по умолчанию будет открываться одна только)

Эд, этот способ живет, имхо, только в случае когда у тебя 10-20 требований и классов (для учебных проектов сойдет).
Если порядок требований и классов переваливает хотя бы за 100, то на диаграмму их таскать - тоска смертная (проверял на себе).
Для этой цели лучше воспользоваться матрицей отношений.
Там сразу видно все элементы, которые ты хочешь соединить. Связь тоже можно выбрать.
На счет пакетов полностью согласен, удобней работать будет в матрице
 

Для этой цели лучше воспользоваться матрицей отношений.

Ты, конечно, прав

Для этой цели лучше воспользоваться матрицей отношений.

Если не трудно, можно чуть-чуть поподробнее? Это просто компактная форма представления связей между артефактами, насколько я понимаю?
В EA, например, есть такой инструмент?
P.S. Отдельное спасибо Michaj за поднятую тему.

Если не трудно, можно чуть-чуть поподробнее? Это просто компактная форма представления связей между артефактами, насколько я понимаю?
В EA, например, есть такой инструмент?
P.S. Отдельное спасибо Michaj за поднятую тему.

Да, в EA это есть.
View - Relationship Matrix
Далее выбирает типы элементов которые вы хотите связать и пакеты где они находятся.
Выбираете тип связи и просто на матрице отмечаете связи.
Матрицу можно сохранить как профиль и просматривать в ресурсах проекта (View-Resources)

Виталий, можешь подготовить небольшой FAQ с примером, я размещу

Например, можно ли (и нужно ли?) связать элемент "class" Сlass-диаграммы, с элементом "use-case" Use-Case-диаграммы (с помощью чего-то, типа прямой ссылки)?

По стандарту вариант использования может быть соединён связью с классификатором "сабджектом", которым может быть класс. Т. е. у класса могут быть "свои" варианты использования, описывающие способы взаимодействия с его экземплярами. Связь варианта использования с "сабджектом" изображается размещением ВИ внутри рамок его "сабджекта" (например, класса).
[Улечу, пока не пришли линчеватели из веток о том, чем является и чем не является ВИ.]
P. S. VP позволяет довольно много вольностей в соединении ВИ c классами связями разных типов. Попробуйте, будете удивлены. [Почти все, кроме допускаемой стандартом.]

По стандарту вариант использования может быть соединён связью с классификатором "сабджектом", которым может быть класс. Т. е. у класса могут быть "свои" варианты использования, описывающие способы взаимодействия с его экземплярами. Связь варианта использования с "сабджектом" изображается размещением ВИ внутри рамок его "сабджекта" (например, класса).
[Улечу, пока не пришли линчеватели из веток о том, чем является и чем не является ВИ.]
P. S. VP позволяет довольно много вольностей в соединении ВИ c классами связями разных типов. Попробуйте, будете удивлены. [Почти все, кроме допускаемой стандартом.]

Не совсем понятно. А можно проиллюстрировать, то, что написано. А то как-то очень сложно воспринимается.
Уточню. Класс может иметь свои ВИ по отношению к другой структурной части. Правильно? Например, Класс Продажа к Единице продажи, чтобы узнать ее общую стоимость (количество*цену). А класс Единица продажи обращается к Описанию товара, чтобы узнать цену его.  И каждое такое обращение, можно представить как ВИ, т.е. Описание товара будет иметь ВИ "Получить цену", а класс ЕП - "Подсчитать стоимость" - в этом нет ничего удивительного, но , возможно, такой путь слишком затратен, как и описание системы (сложной) через все ее возможные состояния и переходы.
 

Быстрее так, ВИ класса Продажа описывают поведение его экземпляров и экземпляров его частей (Единиц и проч.) при обработке запросов, пришедших извне. Например, со стороны класса Клиент.
Речь не о том, чтобы всю систему описывать до мельчайших винтиков. Джекобсон/Якобсон смог зашить в стандарт изобретённое им (а не авторами методик по работе с требованиями через ВИ) понимание того, что такое ВИ.