Методология понимания массива объектно-ориентированного кода из 40 файлов?

Согласна. Как выше ответили: начните от базовых классов, придумайте для них определения, своими словами. потом идите по наследованию: для каждого уровня определения отличий, также своими словами. Все это напишите, вместо диаграммы, как оглавление.
Потом анализируйте вызовы, но в обратном направлении: от главной программы вниз. Когда не понятно, как попасть в интересное место, то ставьте контрольную точку, под отладчиком, и гоняйте программу, пока туда не попадете.
Есть полезный инструмент: AVSearch, бесплатный: удобный поиск по текстам, очень помогает, для таких задач.

Разбирать код - единственный вариант.
Вообще, ООП придумали для того, чтобы код был понятнее.

Ну и отвечать на вопросы по коду без кода как-то не интересно...

есть три варианта
1) смирись что программирование это слишком сложно для тебя, займись например выращиванием сельхозпродукции
2)если нет мануала то F8, F11(трассировка)
3) написать заново

Я знаю один верный способ:
1. Берёшь задачу
2. Пишешь её заново.
Это займёт меньше времени и потратит меньше нервов.

Если тебе непонятные переменные, и вообще непонятная объектная модель, значит этого монстра лучше не трогать. Оно работает. Лучше пусть оно работает, чем не работает с костылями.

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

Как-то раз разбирал какую-то библиотеку по шифрованию размером в 2 метра чистых исходников. После вдумчивого курения выяснилось, что там есть 3 класса и уйма наследников от них. После понимания этих трех классов логика всех наследников стала очевидной и библиотека стала ОЧЕНЬ простой и понятной.