1С СППР Система Проектирования Прикладных Решений

СППР можно представить как граф зависимостей между требованиями, процессами, метаданными, ролями, задачами, тестами и документацией. Есть теория "классический анализ потока данных (data-flow analysis)", где на основе которой делают разбор программ на узлы (функция, модуль кода, поле, выражение и т.п.) Например заводят формулу типа XM​=FM​(XN1​​,…,XNk​​) Здесь FM​ — правило, которое говорит: «если аргументы имеют такие типы, какой тип получится у этого выражения/вызова/метода?" Типы представляют как элементы решётки типов. В частности, на этой основе строят AST-дерево кода. Тут основная борьба состоит в том, что теория обещает, что вы можете описать код с помощью решётки типов и после какого-то числа итераций достигается неподвижная точка, где весь ваш код как бы описан. Но практика говорит что рекурсии в коде, стоимость каждой итерации пересчёта типов, ресурсы памяти компьютера могут сделать детальное описание невозможным и придётся делать огрубление описания связей графа (решётки). Так вот, вопрос в том, можно ли эту теорию применить к проектированию ПО, в частности на СППР (там же тоже будет граф связей, решётки типов)? Это касается, в частности, тех, кто пытается связать проектирование отражённое в СППР (требования, функции, роли и т.п.) с конфигурациями 1С (включая перестройку описаний в СППР от diff`ов конфигураций). По сути в СППР строится некая решётка (граф) и есть потребность её постоянно переписывать из-за изменений в требованиях заказчика и в коде.