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

Ну как же... я в теме объяснил свою задачу.
Может быть не очень точно. Тогда сформулирую задачу еще раз:

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

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

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

Наверное, больше подходит - структура программы.
Тогда получается что для каждого отображаемого метода нужно сделать отдельный класс. А правильно ли это будет с точки зрения семантики UML?

Для каждого метода - отдельный ОБЪЕКТ. Все эти объекты одного КЛАССА - "Метод".
Для каждого вызова - отдельную СВЯЗЬ. Все эти связи одна АССОЦИАЦИЯ.

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

Вы писали "Нужно к UML-модели модифицируемой программы добавить новую диаграмму."

Можно существующие диаграммы посмотреть?

Тогда сформулирую задачу еще раз:

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

ИМХО вы путаете задачу со способом ее решения.

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

Далее, нарисовать диаграмму "в стандарте UML" является одним из возможных способов решения этой задачи. Выбор способа за вами - как вам удобнее.
Лично мне было бы удобнее, на порядок быстрее и нагляднее, просто видеть список имен методов, которые ее вызывают. Хотя бы потому, что из текста удобно копировать имена методов в форму Search для поиска их в исходниках.
Ну а современные средства разработки софта, типа Visal Studio, позволяют делать это парой щелчков мыши. Удивительно, что у вас используется такая древняя среда разработки, в которой нет способа стандартно решить эту задачу.

У меня был вынужденный длительный перерыв.
Возвращаюсь к обсуждению темы.

Для каждого метода - отдельный ОБЪЕКТ. Все эти объекты одного КЛАССА - "Метод".
Для каждого вызова - отдельную СВЯЗЬ. Все эти связи одна АССОЦИАЦИЯ.

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

Пока разбирался с этим вопросом много прочитал об UML. В том числе и его критики.
В какой-то мере эта критика справедлива, как показывает наше обсуждение.
С одной стороны: "UML (англ. Unified Modeling Language — унифицированный язык моделирования) — язык графического описания для объектного моделирования в области разработки программного обеспечения" (википедия)
А с другой стороны, вопрос связей методов в программе - это вопрос именно из области программного обеспечения, и на него мы не можем дать четкого и однозначного ответа, что подтверждает критику UML.

[из википедии]

Критика

Несмотря на то, что UML - достаточно широко распространённый и используемый стандарт, его часто критикуют из-за следующих недостатков:

    Избыточность языка. UML часто критикуется, как неоправданно большой и сложный. Он включает много избыточных или практически неиспользуемых диаграмм и конструкций. Чаще это можно услышать в отношении UML 2.0, чем UML 1.0, так как более новые ревизии включают больше «разработанных-комитетом» компромиссов.

    Неточная семантика. Так как UML определён комбинацией себя (абстрактный синтаксис), OCL (языком описания ограничений — формальной проверки правильности) и Английского (подробная семантика), то он лишен скованности присущей языкам, точно определённым техниками формального описания. В некоторых случаях абстрактный синтаксис UML, OCL и Английский противоречат друг другу, в других случаях они неполные. Неточность описания самого UML одинаково отражается на пользователях и поставщиках инструментов, приводя к несовместимости инструментов из-за уникального трактования спецификаций.

С "третьей" стороны следует признать, что альтернатив UML нету

ИМХО вы путаете задачу со способом ее решения.

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

Далее, нарисовать диаграмму "в стандарте UML" является одним из возможных способов решения этой задачи. Выбор способа за вами - как вам удобнее.
Лично мне было бы удобнее, на порядок быстрее и нагляднее, просто видеть список имен методов, которые ее вызывают. Хотя бы потому, что из текста удобно копировать имена методов в форму Search для поиска их в исходниках.
Ну а современные средства разработки софта, типа Visal Studio, позволяют делать это парой щелчков мыши. Удивительно, что у вас используется такая древняя среда разработки, в которой нет способа стандартно решить эту задачу.

Нет, я не путаю задачу с решением.

Скажем так.
Задача-максимум - это как вы правильно заметили:

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

Задача-минимум (или по вашему - решение задачи-максимум):

нарисовать диаграмму "в стандарте UML"

Т.е. нарисовать диаграмму связей методов в программе.
Да, решить задачу-максимум можно разными способами. Например, как вы предлагаете, списком методов.
Однако, мы (участники проекта) уже решили как ее будем решать, т.е. выбрали способ решения: при помощи диаграммы на UML.
И именно этот вопрос я задал в этой теме.

Кстати, список не поможет.
Как вы при помощи списка отследите и зафиксируете, что метод А вызывает метод Б не напрямую, а косвенно, через цепочку вызовов промежуточных методов С, Д, Е?
А на диаграмме это все прекрасно видно

Можно существующие диаграммы посмотреть?

А что это даст?
Вся модель огромная, какие-то кусочки вам особого смысла не раскроют: чтобы понять смысл - это нужно о-очень много времени.
На наших диаграммах также как и на других присутствуют квадратики и стрелочки.
Например, я приложил диаграмму - это кусочек предметной области самого верхнего уровня.

Я боюсь, что начиная обсуждать мои диаграммы, мы уйдем в сторону от построения новой интересующей меня диаграммы.

сообщение устарело

Мы делаем так..
Полная версия http://edu.reqcenter.pro/?p=3450

P.S. Картинка по ссылке вставилась без уменьшения. Как ее уменьшить?

а на чем вы это делаете?
в смысле какое программное средство используете?

сообщение устарело

Конкретно эта картинка из 3SL Cradle.

Полная связка по этому проекту:
MS Project - 3SL Cradle - PhpStorm + yii -Github
Управление проектом -  управление требованиями и проектными данными, разработка моделей - разработка +фреймворк разработки, поддерживающий MVC - управление версиями

Связка впечатляет.
В MS Project сам работаю, а вот про другие средства не слышал

Инженеры Гугла, создавшие собственный инструмент для анализа зависимостей в сложных приложениях, не придерживаются стандартов UML: «Projects are modeled as generic dependency graphs, with many different node and relation types. For example, the Java module uses 6 different node types and 24 different relations»
http://google-opensource.blogspot.ru/2008/09/depan-dependency-analysis-tool.html
http://code.google.com/p/google-depan/
https://developers.google.com/java-dev-tools/codepro/doc/features/dependencies/dependencies

Тоже повод задуматься о компетентности этих инженеров?

Тоже повод задуматься о компетентности этих инженеров?

Я ни в чьей компетентности не сомневался.

…
А в компетентности программистов, которые не хотят или не могут изучать UML, я бы усомнился
…

я об этой фразе