ОПЫТ ИСПОЛЬЗОВАНИЕ ПРЕДИКТИВНЫХ ML-МОДЕЛЕЙ ДЛЯ ОПТИМИЗАЦИИ МОДУЛЬНОЙ КОМПОНОВКИ КОДА

АННОТАЦИЯ

Модульная организация кода в крупных программных проектах оказывает существенное влияние на скорость разработки и стоимость сопровождения программного обеспечения. При инкременте функциональности высокая межмодульная связанность приводит к увеличению количества модифицируемых файлов и росту объема регрессионного тестирования по сравнению с архитектурами с низкой связанностью модулей. В связи с этим задача мониторинга качества модульной декомпозиции функциональности и удержания низкой межмодульной связанности является одной из центральных задач обслуживания программного кода.

В работе рассматривается опыт создания предиктивной модели, устанавливающей функциональную связь между положением единицы кода с идентифицируемой архитектурной ролью и скоростью разработки, выраженной через метрику Lead Time (LT). Предиктивная модель используется для реализации AI-агента в интегрированной среде разработки GIGA IDE, который выполняет рекластеризацию файлов по существующим модулям с целью достижения минимального значения LT.

ABSTRACT

Modular code organization in large software projects has a significant impact on development speed and maintenance costs. During functional increments, high inter-module coupling increases the number of modified files and the volume of regression testing compared to architectures with low coupling. Therefore, monitoring the quality of modular decomposition and maintaining low inter-module coupling is a central task in software maintenance.

This paper presents an experience of developing a predictive model that establishes a functional relationship between the position of a code unit with an identifiable architectural role and development speed measured by the Lead Time (LT) metric. The predictive model is used to implement an AI agent in the GIGA IDE integrated development environment, which performs re-clustering of files across existing modules in order to minimize LT.

Ключевые слова: AI-агенты; предиктивные модели; модульная архитектура ПО; модульная декомпозиция кода; автоматизация рефакторинга; GIGA IDE; Java; Spring; Jakarta.

Keywords: AI agents; predictive models; software modular architecture; modular code clustering; refactoring automation; GIGA IDE; Java; Spring; Jakarta.

Введение

Модульная организация программного кода достаточно давно рассматривается как самостоятельная предметная область, в рамках которой предлагаются различные подходы к процессу модульной декомпозиции [1, 2]. Итоговое модульное решение оказывает существенное влияние как на стоимость эксплуатации программного обеспечения, так и на стоимость и сроки последующего инкремента функциональности этого программного обеспечения.

При разделении (кластеризации) кода на модули возможно параллельное следование нескольким принципам, систематизированным, в частности, в архитектурном обзоре Мартина Фаулера Software Architecture Guide [3]. К таким принципам относятся: разделение прикладного и системного функционала; разделение прикладного функционала различных предметных областей (доменов); группировка прикладного функционала по инсталляционным пакетам; разделение прикладного функционала по слоям прикладной логики; группировка функциональности по пользовательским сценариям.

В архитектурном обзоре Мартина Фаулера [3], а также в работе Juntao Qiu, посвященной модульной декомпозиции React-приложений [4], подчеркивается, что модульная декомпозиция функциональности front-end и back-end частей приложений выполняется различными способами. Это связано как с архитектурными ограничениями со стороны back-end, так и со спецификой пользовательского взаимодействия. В результате для front-end доминирующим подходом является функциональная кластеризация, применяемая при формировании инсталляционных пакетов (bundles). Например, группировка на front-end в бандл всех форм, между которыми существуют прямые переходы; всех форм одного процесса или подпроцесса; всех общих повторно используемых в других модулях компонентов или групп компонентов.

Авторы Pressman [1], Richards [2] и Fowler [3] отмечают, что для back-end частей приложений задача модульной декомпозиции является значительно более комплексной, о чем свидетельствует большое количество предлагаемых архитектурных паттернов, число которых со временем продолжает расти. При этом в статье Мартина Фаулера Monolith First [5] подчеркивается, что существующая практика управления модульной декомпозицией back-end-кода часто оказывается спорной, а заявленные цели архитектурных преобразований, направленных на снижение стоимости эксплуатации и ускорение разработки, достигаются не всегда. Анализ современной стоимости эксплуатации различных архитектурных решений, включая сравнение монолитных и микросервисных подходов, представлен в работе Eleftheria Drosopoulou [6].

Неочевидность выбора правил декомпозиции, а также комбинаторная сложность задачи оставляют значительное пространство для исследований как в области метрик качества модульной декомпозиции [7], так и в области методов оптимизации [8–10]. При этом часть существующих подходов строится без учета феноменологии предметной области, а часть рассматривает код преимущественно как текстовый объект.

Вместе с тем анализ работ, посвященных архитектуре программного обеспечения [1–3], позволяет выделить два устойчивых и широко используемых паттерна модульной декомпозиции back-end-кода. Первый паттерн — горизонтальное деление (horizontal separation), соответствующее слоистой архитектуре (Layered Architecture или Multitier Architecture), для которого характерны раздельная реализация инкремента функциональности на каждом слое, сильная связанность доменов внутри слоя и слабая связанность между слоями. Второй паттерн — вертикальное деление (vertical separation), соответствующее функциональной или сервис-ориентированной архитектуре (Service-oriented Architecture, Microservices Architecture), для которого характерны раздельная реализация инкремента функциональности для каждого домена, слабая связанность доменов и сильная связанность слоев внутри домена либо их редукция.

Важно отметить, что в идеальном случае оба паттерна обеспечивают относительно гибкие возможности по оперативному изменению состава инсталляционных пакетов в зависимости от нагрузки, наличия ресурса DevOps-инженеров, QA-инженеров и предпочтений команды, что позволяет лавировать затратами на эксплуатацию, как указано в [5]. Отход от данных паттернов, как уже отмечалось выше [3], кроме потери гибкости в процессе развертывания, приводит к потерям в скорости разработки. Устойчивость паттернов к модульной декомпозиции вне зависимости от схемы группировки инсталляционного пакета не учитывалась в работах [8–10].

Схемы компоновки в рамках паттернов горизонтального и вертикального деления представлены на рис. 1 ниже с монолитной и сервисной стратегиями формирования инсталляционных пакетов. В определенной степени Layered Architecture также позволяет компоновать отдельные слои в отдельные инсталляционные пакеты, хотя и не столь гибко, как Service-oriented Architecture.

Рисунок 1. Варианты декомпозиции функциональности в рамках Layered Architecture (a, c) и Service-oriented Architecture (b, d) с монолитной и сервисной стратегиями формирования инсталляционных пакетов

Оставляя за скобками вопросы выбора стратегии подготовки инсталляционных пакетов, можно подытожить, что на back-end разделение (кластеризация) кода решается одним из двух способов. Либо горизонтально по слоям (Presentation: API, View и т.д.; Logic: Business layer, Service layer и т.д.; Data: Data access layer, Integration layer и т.д.) с сильной связностью доменов или без их четкого выделения внутри слоя. Либо вертикально по доменам (пользователи, счета и проводки, физические лица, товары и т.д.) с сильной связностью и/или редуцированием слоев.

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

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

Также формулируется следующая гипотеза: любое смещение от сильной связности в сторону ослабления связанности по доменам или слоям приводит к улучшению показателя скорости инкремента функциональности.

Соответствующую зависимость можно представить в виде гипотетической кривой, как показано на рис. 2.

Рисунок 2. Гипотетическая зависимость между фактической модульной архитектурой и значением Lead Time

Целью настоящего исследования является построение предиктивной модели, связывающей характер модульной декомпозиции кода с метрикой Lead Time, с учетом феноменологии разработки программного обеспечения и сформулированных гипотез.

Для достижения поставленной цели в работе решаются следующие задачи:

- разработка предиктивной модели, связывающей модульную компоновку архитектурно значимых типов с Lead Time;

- формализация показателей, которые можно использовать для характеристики близости модульной архитектуры к варианту горизонтальной модуляризации вертикальной модуляризации (индексов слоистости и сервисности);

- экспериментальная проверка гипотез о влиянии модульной декомпозиции на Lead Time;

- апробация модели в виде AI-агента в интегрированной среде разработки.

Методология исследования

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

В качестве объектов исследования рассматривались программные проекты, реализующие слоистую архитектуру либо архитектуру Model–View–Controller. В анализ включались проекты, в которых были явно выделены слои API, Business Logic и Data Access либо Model, View и Control. Допускалось частичное смешивание двух из трех смежных слоев. Анализируемый программный код был реализован на языках Java или Kotlin с использованием фреймворков Spring и/или Jakarta (JavaX), предоставляющих маркирующие аннотации и интерфейсы для определения архитектурных ролей программных компонентов.

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

В качестве основной метрики скорости разработки использовался показатель Lead Time. Под Lead Time понимался интервал времени между моментом создания ветки разработки под конкретную задачу и моментом создания pull request. В расчет включались только завершенные задачи с принятыми pull request, что позволило исключить влияние незавершенных или отклоненных изменений на результаты моделирования.

Предиктивная модель строилась как функция, оценивающая влияние положения архитектурно значимого типа в конкретном модуле на значение Lead Time проекта. Целевая функция формировалась как взвешенная по количеству типов и модулей доля методов архитектурно значимых типов с учетом их архитектурной роли. Для обучения модели использовалась рекуррентная нейронная сеть архитектуры Long Short-Term Memory (LSTM), что обусловлено необходимостью учитывать временные зависимости и накопленный эффект изменений архитектуры на скорость разработки. В результате обучения было достигнуто значение коэффициента детерминации R² = 0,97.

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

Методология исследования также включала проведение what-if анализа, в рамках которого для каждого архитектурно значимого типа оценивалось изменение значения Lead Time при его последовательном перемещении в каждый из существующих модулей проекта. При этом не рассматривались операции создания новых модулей или удаления существующих, что позволяло анализировать влияние исключительно перераспределения типов в рамках заданной модульной структуры.

Разработанная методология обеспечивала воспроизводимость эксперимента и позволяла количественно оценивать влияние различных вариантов модульной декомпозиции кода на показатель Lead Time без внесения изменений в функциональность программного обеспечения.

Результаты и обсуждение

Результаты моделирования представлены на рис. 3 для программных проектов, содержащих от четырех до десяти модулей.

Рисунок 3. Зависимость: a) Lead Time от индекса слоистости; b) Lead Time от индекса сервисности

Полученные результаты подтверждают исходные ожидания, сформулированные при постановке гипотез. Анализ представленных зависимостей показывает, что влияние характера модульной декомпозиции на значение Lead Time носит нелинейный характер. Для проектов, архитектура которых существенно отклоняется от выраженной горизонтальной или выраженной вертикальной модуляризации, наблюдается рост значения Lead Time по сравнению с архитектурами, находящимися вблизи указанных вырожденных состояний.

В частности, минимальные значения Lead Time достигаются в случаях, когда модульная архитектура проекта близка либо к радикально горизонтальному делению по слоям, либо к радикально вертикальному делению по доменам. Это согласуется с выдвинутыми гипотезами о том, что именно данные архитектурные паттерны обеспечивают минимальную межмодульную связанность и, как следствие, более высокую скорость инкремента функциональности.

Для проектов с бессистемной модуляризацией, характеризующихся смешением слоев и доменов без выраженной архитектурной логики, начальные затраты на модульный рефакторинг не приводят к заметному улучшению значения Lead Time. Существенное снижение показателя достигается только после выполнения значительного объема архитектурных преобразований, направленных на приближение архитектуры к одному из устойчивых паттернов. Таким образом, результаты моделирования подтверждают, что частичные и локальные изменения модульной структуры без стратегического выбора архитектурного направления обладают ограниченной эффективностью в рамках рассматриваемой архитектурной модели.

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

Прикладное применение разработанной предиктивной модели реализовано в формате what-if-анализа программного кода проекта. В качестве среды выполнения используется интегрированная среда разработки GIGA IDE. Анализируемый код проверяется на наличие целевых фреймворков и не менее двух модулей, не считая корневого. При несоблюдении указанных условий применение AI-агента не выполняется.

В рамках what-if-анализа для каждого архитектурно значимого типа осуществляется оценка изменения значения Lead Time при его последовательном перемещении в каждый из существующих модулей проекта. Если предполагаемая модификация приводит к улучшению показателя Lead Time выше заданного порогового значения, она предлагается пользователю в виде рекомендации либо выполняется автоматически в зависимости от настроек системы. Создание новых модулей и удаление существующих модулей в рамках анализа не рассматриваются.

Параметры, используемые для настройки поведения предиктивной модели, представлены в табл. 1.

Таблица 1.

Параметры, используемые для настройки поведения предиктивной модели

Все рекомендации, сформированные системой, ранжируются по величине ожидаемого инкремента Lead Time. В итоговый отчет включается только заданное пользователем количество рекомендаций с максимальным улучшением показателя. Дополнительно учитывается признак переноса связанных типов, позволяющий автоматически перемещать архитектурно значимые элементы, на которые ссылаются перемещаемые типы, даже в случае, если они не преодолевают установленный порог значимости.

В отличие от AI-агентов, описанных в работах [14, 15], реализованный плагин функционирует исключительно в пакетном режиме обработки. Это решение обусловлено тем, что перемещение отдельных типов без связанных элементов может негативно влиять на целостность архитектурных решений и ухудшать понимание программного кода разработчиками.

Заключение

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

Показано, что минимальные значения Lead Time достигаются при выраженной горизонтальной либо выраженной вертикальной модуляризации, соответствующей устойчивым архитектурным паттернам. Архитектурные решения, отклоняющиеся от указанных паттернов, приводят к росту межмодульной связанности и увеличению времени разработки, особенно на ранних этапах архитектурных преобразований.

На основе эмпирических данных построена предиктивная модель, позволяющая оценивать влияние положения конкретного архитектурно значимого типа на значение Lead Time проекта. Разработанная модель реализована в виде AI-агента, интегрированного в среду разработки GIGA IDE, и используется для автоматического и полуавтоматического рефакторинга модульной структуры кода без изменения функциональности программного обеспечения.

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

Список литературы:

1. Pressman, R. Software Engineering: A Practitioner’s Approach: European Adaptation; McGraw-Hill: New York, NY, USA, 2000.
2. Richards, Mark (2020). Fundamentals of Software Architecture: An Engineering Approach (1st ed.). O'Reilly Media. ISBN 978-1492043454.
3. Martin Fowler, Software Architecture Guide, 1 Aug 2019 https://martinfowler.com/architecture/
4. Juntao QIU, Modularizing React Applications with Established UI Patterns, 16 February 2023 https://martinfowler.com/articles/modularizing-react-apps.html
5. Martin Fowler, Monolith First, 3 June 2015, https://www.martinfowler.com/bliki/MonolithFirst.html
6. Eleftheria Drosopoulou. Microservices vs Monoliths in 2026: When Each Architecture Wins.  December 24th, 2025 https://www.javacodegeeks.com/2025/12/microservices-vs-monoliths-in-2026-when-each-architecture-wins.html
7. Amarjeet; Chhabra, J.K. An empirical study of the sensitivity of quality indicator for software module clustering. In Proceedings of the 2014 Seventh International Conference on Contemporary Computing (IC3), Noida, India, 7–9 August 2014; IEEE: Piscatway, NJ, USA, 2014; pp. 206–211.
8. Praditwong, K.; Harman, M.; Yao, X. Software Module Clustering as a Multi-Objective Search Problem. IEEE Trans. Softw. Eng. 2011, 37, 264–282.
9. Bahman Arasteh, Amir Seyyedabbasi, Jawad Rasheed,  Adnan M. Abu-Mahfouz. Program Source-Code Re-Modularization Using a Discretized and Modified Sand Cat Swarm Optimization Algorithm. Symmetry 2023, 15(2), 401
10.  Valentina Franzoni, Silvia Tagliente, Alfredo Milani. Generative Models for Source Code: Fine-Tuning Techniques for Structured Pattern Learning. Technologies 2024, 12(11), 219
11.  Слекеничс А.Я. Реализация AI-агентов для разработки ПО объединяющих предиктивные и языковые модели., Universum, № 10 (139), октябрь, 2025, DOI: 10.32743/UniTech.2025.139.10.21091
12.  Sepp Hochreiter; Jürgen Schmidhuber (1997). "Long short-term memory". Neural Computation. 9 (8): 1735–1780. doi:10.1162/neco.1997.9.8.1735. PMID 9377276. S2CID 1915014.
13.  Интегрированная среда разработки GIGA IDE  https://gigaide.ru/
14.  Слекеничс А.Я. Реализация AI-агента для управления объемом логирования в программном обеспечении, Universum, № 11 (140), ноябрь, 2025, DOI: 10.32743/UniTech.2025.140.11.21332
15.  Слекеничс А.Я. Опыт использования предиктивных ML-моделей при автоматизации тестирования ПО., Universum, № 12 (141), декабрь, 2025 г, DOI: 10.32743/UniTech.2025.141.12.21599