Если вы так хотите изучить UML, то вызовы процедур (чтобы вы не закладывали в это понятие) можно смоделировать диаграммой последовательности или диаграммой коммуникации.

Элементом этих диаграмм являются объекты или линии хизни. Объекты обмениваются собщениями. Сообщения сигналы, которые можно моделирвоать и как вызовы процедур.

И мне хотелось бы, чтобы составленную мной диаграмму могли читать другие программисты, чтобы я ее мог показать им, и обсудить предлагаемое мной решение.

Тут такой вопрос: цель в том, чтобы продемонстрировать читателю диаграммы знание UML, или в том, чтобы читатель понял, как это должно работать?
Есть ли уверенность, что другие программисты владеют всеми тонкостями нотаций UML диаграмм? А то ведь можно все формально правильно нарисовать, но окажется, что важные нюансы ускользнули от читателей.
У нас вот программисты слово UML терпеть не могут, говорят "Ты лучше по простому нарисуй и на пальцах объясни".

У нас вот программисты слово UML терпеть не могут, говорят "Ты лучше по простому нарисуй и на пальцах объясни".

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

Тут такой вопрос: цель в том, чтобы продемонстрировать читателю диаграммы знание UML, или в том, чтобы читатель понял, как это должно работать?
Есть ли уверенность, что другие программисты владеют всеми тонкостями нотаций UML диаграмм? А то ведь можно все формально правильно нарисовать, но окажется, что важные нюансы ускользнули от читателей.

В любой области должны быть общие понятия, разделяемые всеми, чтобы иметь возможность понять друг друга, и общаться с друг другом.
Чтобы читатель понял что он читает, он прежде всего должен знать "язык" того, что он собирается читать.
Если вы хотите поговорить с англичанином вы должны знать английский.
UML наиболее распространенный язык для моделирования ПО.

У нас вот программисты слово UML терпеть не могут, говорят "Ты лучше по простому нарисуй и на пальцах объясни".

Язык "простого" у каждого свой.
И нарисовав "по-простому", такие программисты вряд ли друг друга поймут _однозначно_ и _правильно_.
Да, изучение UML - нелегкое дело.
А разве изучение C++ или Java или PHP проще? Если программисты осилили язык программирования, то UML для них - не проблема.
А в компетентности программистов, которые не хотят или не могут изучать UML, я бы усомнился

Если вы так хотите изучить UML, то вызовы процедур (чтобы вы не закладывали в это понятие) можно смоделировать диаграммой последовательности или диаграммой коммуникации.

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

языка моделирования UML, признанного как наиболее удобного языка моделирования

Признанного кем?
google: наиболее удобный язык моделирования

нарисовав "по-простому", такие программисты вряд ли друг друга поймут _однозначно_ и _правильно_.

UML однозначность и "правильность" не обеспечивает.
См. например: http://ru.wikipedia.org/wiki/UML

...
Неточная семантика. ... Неточность описания самого UML одинаково отражается на пользователях и поставщиках инструментов, приводя к несовместимости инструментов из-за уникального трактования спецификаций
...
UML не имеет свойств полноты по Тьюрингу и любой сгенерированный код будет ограничен тем, что может разглядеть или предположить интерпретирующий UML инструмент.
...

представим, что инженер-электронщик в ответ на предсталенную для него принципиальную схему электронного устройства говорит проектировщику: "Ты лучше по простому нарисуй и на пальцах объясни".

Принципиальная схема электронного устройства является, в отличие от диаграмм UML, точной однозначной моделью устройства. Эта схема может быть через интернет загружена в САПРовскую систему любого китайского заводика, и на выходе технологической линии через сутки выползет готовая работающая печатная плата со всеми распянными компонентами. Подключил, и работает (в идеале, если отвлечься от исправления ошибок).
Аналогичные автоматические системы, в которые на вход подается набор UML диаграмм, а на выходе получается программный продукт, на практике оказываются неработоспособными, несмотря на многолетние труды фанатов UML. Именно в силу присущих UML врожденных проблем неполноты и неоднозначности.

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

вы правильно поняли мою задачу

Аналогичные автоматические системы, в которые на вход подается набор UML диаграмм, а на выходе получается программный продукт, на практике оказываются неработоспособными, несмотря на многолетние труды фанатов UML. Именно в силу присущих UML врожденных проблем неполноты и неоднозначности.

На данный исторический момент UML возможно не идеальный язык моделирования,
Кстати мои затруднения выразить на UML вызовы процедур как раз и подтверждают это.
Однако, UML - лучший из того что есть.

Если вы так хотите изучить UML, то вызовы процедур (чтобы вы не закладывали в это понятие) можно смоделировать диаграммой последовательности или диаграммой коммуникации.

Элементом этих диаграмм являются объекты или линии хизни. Объекты обмениваются собщениями. Сообщения сигналы, которые можно моделирвоать и как вызовы процедур.

диаграмма последовательности вообще не подходит для моей задачи - она отображает хронологическую последовательность сообщений,
диаграмма коммуникации тоже не подходит - она отражает взаимодействующие объекты

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

Вопрос в том, какая диаграмма в UML больше всего подходит для отображения связей между методами программы, между методами объектов программы?

В рамках стандарта UML это называется диаграммой объектов. Квадратики (прямоугольники) объекты одного суперкласса - "Метод" с двумя подклассами "Метод программы" и "Метод объекта". Линии - связи одной ассоциации. Стрелки - от вызывающего к вызываемому (вызывающий "знает", кого вызывает, а вызываемый не "знает", кто вызывает).

В рамках стандарта UML это называется диаграммой объектов. Квадратики (прямоугольники) объекты одного суперкласса - "Метод" с двумя подклассами "Метод программы" и "Метод объекта". Линии - связи одной ассоциации. Стрелки - от вызывающего к вызываемому (вызывающий "знает", кого вызывает, а вызываемый не "знает", кто вызывает).

Диаграмма объектов отображает взаимосвязи между объектами в какой-то конкретный момент времени, как будто описываемая система "заморожена".
То есть мне нужно будет изобразить как один метод вызывает другой метод на временном срезе. Это не то что мне нужно.
Мне нужно отобразить вызов не в конкретный момент, а вообще возможность вызова одного метода другим, неважно в какой момент времени и при каких условиях.

По результатам обсуждения я более склоняюсь к диаграмме состояний.
Каждый метод - это состояние моей программы. Переход из одного состояния в другие - будет показывать какие методы могут быть вызваны из текущего метода.
Как вам такое решение?

Каждый метод - это состояние моей программы. Переход из одного состояния в другие - будет показывать какие методы могут быть вызваны из текущего метода.
Как вам такое решение?

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

Надо решить, что является предметом моделирования:
1) процесс выполнения программы - тогда поведенческая диаграмма (может и диаграмма состояний, но лучше - диаграмма деятельности, где вызов будет изображаться узлом вызова деятельности, или старая добрая блок-схема, где вызов будет обозначаться блоком вызова). Правда на таких диаграмме вам не нужны стрелки-переходы и все узлы и блоки, не связанные с вызовами (если не надо отображать условия, при которых происходит вызов или последовательность вызовов или что-нибудь еще);
2) структура программы (исходного текста) - тогда структурная диаграмма (см. ранее).

Предыдущее сообщение от div тоже об этом говорит.