Недавно сказал не совсем точно - схемы взаимосвязей типа желаемых Прохоренко и igor, в принципе определил давно. Пример для частного случая можно было найти здесь:http://forum.oberoncore.ru/download/file.php?id=1791. Но нужно сказать вот что.

А. Синтаксис в примере старый, "силуэтно-ограниченный", он не позволяет выразить всё оптимально. Уже давно использую другой, основанный на лио-расширении. Там получается не устремлённая топология, а сетевая в пределе, что не проблема - выводится графит-методом с соответствующей спецификой. Ну и графит-сеть здесь м.б. двумерной, что позволяет на одном уровне расположить те процедуры, которые только вызываются вышестоящими в иерархии реализации и/или сами вызывают нижестоящие (но не друг друга и не на несмежных уровнях при строгой иерархии). Т.е. решается задача:> -- igor в viewtopic.php?p=28837#p28837 писал(а):
> ... чтобы обрести ясность что делает та или иная процедура, и как она используется в самом модуле. ... понять какие из них являются ключевыми, а какие служат лишь для того, чтобы обеспечить реализацию этих ключевых процедур....- т.е. программа представляется как "решётка" из процедур.

Правда, есть одно "но" - зависимости надо прослеживать по "разъёмам", как обычно в ЕСКД-сетях. Решений, чтобы "наглядный рисунок скрывал" ((С)П. Алмазов) как можно меньше, два:* выполнять снятие кросса (разгруппировку его линий на отдельные связи) - при этом пересечения, если они есть, будут явными;
* показывать зависимости над кроссом (например, как в табличных процессорах) - но тоже организованной сетью связей, а не "по кратчайшим", как уРейссав FIELD, что Тышов воспроизвёл.В любом случае получится на плоскости, как у Вирта в "Проекте Оберон" примерно (допустим, на Рис. 2.2, 12.6). Классика она и есть классика...Ну а как в пространстве - возможное решение недавно Дмитрий_ВБ предложил:http://forum.oberoncore.ru/viewtopic.php?p=83913#p83913.
Только подробнее структурно, потому что даются и вызовы, и возвраты.
Расширение позволяет показывать, кроме обычного вызова/возврата, также внешний, порождение/снятие, конструкцию/деструкцию. Знай только символику изобретай...

Б. Выводить-то можно, но вручную... столько надо заполнять для небольшой, в общем-то, программы (какОчередь)... поэтому сделал только, чтобы выработать практичное определение...
А ведь схема-то производная!.. Т.е. делается просто на основании кода в определённой "проекции"... Так что тут просится информатизация составления с последующей автоматизацией...

В. Автоматизировали. И тогда упрёмся в то, что схема всех аспектов взаимодействия процедур будет весьма объёмной. Так что надо реализовать прежде всего составление выборочное.

А вообще штука полезная... получается "графический инспектор кода" в части структур управления. Например, можно быстрее получать ответ на вопрос вида: "Вот я ставлю палец в эту точку <на каком-то маршруте - В.Ж.> и спрашиваю: Какой последовательности событий <при дальнейшем следовании - В.Ж.> я могу ожидать?" ((C)И. Ермаков)
Только в составе продуманной системы представлений кода... ибо есть ещё части структур данных и исполнителя... и нужно системировать. Некоторые замечания здесь:http://forum.oberoncore.ru/viewtopic.php?p=84856#p84856.