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