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

АННОТАЦИЯ

Программный код, работающий с данными, должен поддерживать единую транзакционную политику с источниками данных (например, базами данных). При этом перед разработчиком остаётся задача оптимизации стоимости эксплуатации. С одной стороны, повышение требований к согласованности данных ведёт к росту эксплуатационных расходов и снижению скорости обработки пользовательских запросов. С другой стороны, снижение требований к согласованности данных в связке «приложение — источник данных» повышает производительность и уменьшает эксплуатационные затраты. Управление транзакционностью на уровне кода требует понимания последовательности вызовов через все слои приложения, что особенно значимо для крупных корпоративных проектов. В работе рассматривается опыт создания предиктивной модели, определяющей функциональную связь между характером расстановки инструкций управления транзакциями и плотностью дефектов (Defect Density) в коде, а также описывается алгоритм применения модели для оптимизации расстановки транзакций для фреймворков JTA и Spring. Модель внедрена в форме отдельного плагина для интегрированной среды разработки GIGA IDE, обеспечивающего автоматическую оптимизацию расстановки инструкций управления транзакциями JTA и Spring.

ABSTRACT

Software code that works with data must share a common transactional policy with data sources such as databases. At the same time, developers face the task of optimizing operational costs. On the one hand, stricter data consistency requirements increase operational costs and reduce the processing speed of user requests. On the other hand, lower data consistency requirements within the “application–data source” pair increase performance and reduce operational costs. Furthermore, managing transactionality at the code level requires understanding the call sequence across all layers of an application, which is especially important for large enterprise projects.

This paper discusses the experience of creating a predictive model that determines a functional relationship between the placement of transaction management instructions and defect density in the code, and proposes an algorithm for applying the model to optimize transaction placement for the JTA and Spring frameworks. The model is implemented as a standalone plugin for the GIGA IDE integrated development environment, enabling automatic optimization of transaction management instructions for JTA and Spring.

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

Keywords: AI agents; predictive models; transaction management; refactoring automation; GIGA IDE; Java; Spring; Jakarta.

Введение

Одной из центральных инженерных задач при проектировании программного обеспечения является обеспечение транзакционности данных. Данное свойство должно поддерживаться не только на уровне источника данных (например, базы данных), но и на уровне бизнес-логики приложения. Современные прикладные системы могут требовать параллельного доступа к нескольким источникам данных, различающимся по степени связанности и/или сцепления. Кроме того, бизнес-логика может накладывать дополнительные ограничения на допустимое время обработки данных и порядок выполнения операций.

Проблема согласования транзакционности на уровне прикладного кода и источников данных рассматривается во множестве работ, включая [1, 2]. При этом исследователи отмечают отсутствие универсального решения: механизмы обеспечения транзакционности предлагают различные способы управления целостностью транзакции, по крайней мере, через регулирование уровня изоляции (isolation) и характера распространения транзакции (propagation). Высокая вариативность возможных архитектурных и инженерных решений обусловлена фундаментальными ограничениями, сформулированными в CAP-теореме [3].

Практическим следствием CAP-теоремы является рост стоимости эксплуатации программного обеспечения при повышении требований к согласованности данных (data consistency). Усиление требований к согласованности неизбежно снижает доступность данных (data availability), что влечёт увеличение затрат на вычислительные ресурсы и инфраструктуру [4].

Так, повышение уровня изоляции транзакций на уровне источника данных приводит к увеличению времени удержания блокировок, росту вероятности взаимных блокировок (deadlock) и снижению степени параллелизма. Аналогично, реализация транзакционности на уровне приложения увеличивает продолжительность блокировки ресурсов источников данных, особенно в ситуациях, когда бизнес-логика задействует несколько источников одновременно: каждый из них остаётся заблокированным до завершения выполнения всех связанных операций. Современные подходы к проектированию программного обеспечения позволяют смещать баланс компромисса C–A–P как на уровне выбора типа источника данных, так и на уровне архитектурной организации приложения. Разработчики могут выбирать между CP-системами, жертвующими доступностью ради обеспечения согласованности, и AP-системами, допускающими снижение согласованности ради повышения доступности [5]. Кроме того, прикладные решения могут быть реализованы на основе микросервисной архитектуры [6], предусматривающей разделение приложений и источников данных по доменам предметной области.

Архитектурная декомпозиция по доменам позволяет снизить связанность на уровне источников данных, перенося ответственность за согласованность на уровень прикладной логики и пользовательских сценариев. Однако подобный подход требует детальной проработки логики управления транзакциями в коде приложения. В экосистеме Java для этого используются декларативные механизмы управления транзакциями, реализованные в рамках спецификации JTA и фреймворка Spring Transaction.

В инженерной практике сформированы эмпирические рекомендации по размещению инструкций управления транзакциями. В рамках слоистой архитектуры (layered architecture или multitier architecture), включая микросервисные решения, транзакционные инструкции, как правило, размещаются на уровне сервисного слоя [7]. Однако на практике границы сервисного слоя могут быть размыты между уровнем контроллера и уровнем доступа к данным. В ряде случаев слой бизнес-логики оказывается минимизированным, например, если приложение выполняет функцию фасада к базе данных, в которой сосредоточена основная логика обработки.

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

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

В отличие от существующих эвристических подходов, ориентированных преимущественно на формальную валидацию транзакционных аннотаций, представляется целесообразным рассмотреть задачу управления расстановкой инструкций управления транзакциями с позиции количественного анализа их влияния на показатели качества программного кода. В качестве интегрального показателя в настоящем исследовании рассматривается плотность дефектов (Defect Density), позволяющая оценивать влияние конфигурации транзакционности на устойчивость и корректность прикладной логики.

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

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

– анализ архитектурных и транзакционных факторов, влияющих на показатели согласованности данных и эксплуатационные характеристики системы;

– формализация параметров программного кода, потенциально влияющих на плотность дефектов при различной конфигурации транзакционности;

– построение многопараметрической предиктивной модели на основе метода Long Short-Term Memory;

– экспериментальная проверка гипотезы о возможности оптимизации состава инструкций управления транзакциями при заданных целевых ограничениях;

– реализация разработанного подхода в виде программного инструмента, интегрированного в среду разработки GIGA IDE.

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

В рамках настоящего исследования прямой эмпирический сбор данных по зависимости «согласованность данных — доступность данных» был заменён анализом косвенной зависимости «согласованность данных — плотность дефектов» (Defect Density, DD). Такой подход основан на предположении о том, что снижение уровня согласованности данных может приводить к росту числа логических и транзакционных нарушений, проявляющихся в виде дефектов прикладного кода. Аналогичный подход к использованию показателя плотности дефектов в качестве интегральной характеристики качества программного обеспечения обсуждался в [11].

Эмпирическая база исследования сформирована на основе собственной выборки Java-проектов, реализованных с использованием фреймворка Spring (Spring Transactional). Для каждого проекта анализировалась конфигурация расстановки инструкций управления транзакциями и рассчитывался показатель Defect Density. Типы исключений при анализе не фильтровались, поскольку инциденты, вызванные нарушением транзакционности данных, могут сопровождаться каскадными ошибками иных типов, что затрудняет их однозначную классификацию и может искажать оценку взаимосвязи.

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

Рисунок 1. Зависимость плотности дефектов от плотности использования инструкций управления транзакциями

Построение графика осуществлялось путём группировки проектов по диапазонам плотности транзакционной разметки и вычисления среднего значения DD для каждой группы. Полученная зависимость использовалась в дальнейшем как эмпирическая основа для формулирования гипотезы о возможности оптимизации состава транзакционных инструкций.

Дополнительно в рамках методологии предусматривалось построение расширенной модели с учётом архитектурной стратификации кода по слоям (API, Business Logic, Data Access), что позволило сформировать отдельные зависимости для различных уровней layered architecture. Результаты данного анализа представлены на рис. 2 и будут использованы при построении прогностической модели.

Рисунок 2. Зависимость показателя DD от доли методов, имеющих инструкции управления транзакциями, для различных слоёв слоистой архитектуры

В целях формализации зависимости между конфигурацией транзакционности и плотностью дефектов был сформирован вектор параметров, характеризующих структуру и сложность прикладного кода. Для ограничения области анализа общий код каждого проекта предварительно редуцировался на основании следующих допущений: код реализует слоистую архитектуру (layered architecture или multitier architecture) вне зависимости от способа доменной декомпозиции (монолитная или микросервисная структура); в коде выделяются слои API, Business Logic и Data Access, при этом допускается частичное смешивание смежных слоёв; анализируемые проекты разработаны на языках Java или Kotlin с использованием фреймворков Spring и/или Jakarta, содержащих маркирующие аннотации для идентификации транзакционных инструкций.

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

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

Для построения прогностической модели применялся метод Long Short-Term Memory (LSTM) [12], позволяющий учитывать нелинейные зависимости между признаками. Обучение модели проводилось на размеченной выборке проектов с известными значениями показателя Defect Density. В качестве метрики качества использовался коэффициент детерминации R², достигший значения 0,98, что свидетельствует о высокой объясняющей способности модели в рамках используемой выборки.

Дополнительно была проведена стратификация данных по архитектурным слоям (API, Business Logic, Data Access), что позволило построить отдельные зависимости показателя DD от доли методов, покрытых инструкциями управления транзакциями, для каждого слоя. Результирующие зависимости представлены на рис. 2.

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

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

В рамках методологии под оптимизацией понимается изменение состава и параметров инструкций управления транзакциями, включая: добавление аннотаций на уровне метода или типа (Jakarta Transactional или Spring Transactional), удаление существующих транзакционных инструкций, а также модификацию параметров аннотаций, управляющих уровнем изоляции (isolation) и характером распространения транзакции (propagation).

Для формализации процедуры принятия решения вводятся два пороговых параметра: TA и TR. Параметр TA определяет минимально допустимое улучшение показателя DD, при котором добавление транзакционной инструкции считается целесообразным. Параметр TR задаёт максимально допустимое ухудшение показателя DD, при котором удаление транзакционной инструкции допускается с точки зрения целевой функции. При этом в рамках модели предполагается выполнение соотношения TA < TR, что обеспечивает асимметричность решений в зависимости от выбранной стратегии оптимизации.

Оценка эффективности каждой потенциальной модификации выполняется в формате what-if-анализа: для каждой альтернативной конфигурации рассчитывается прогнозируемое значение DD до модификации (DDB) и после неё (DDM) с использованием построенной предиктивной модели. Разность между DDB и DDM используется как количественная основа для принятия решения о целесообразности изменения конфигурации транзакционной разметки.

Таким образом, методология исследования объединяет эмпирический анализ зависимости DD от плотности транзакционных инструкций, построение многопараметрической прогностической модели и формализованную процедуру оптимизации, основанную на целевых пороговых значениях.

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

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

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

Анализ зависимостей, представленных на рис. 2, выполненный с учётом стратификации по архитектурным слоям, показывает различную чувствительность показателя DD к изменению плотности транзакционной разметки на уровнях API, Business Logic и Data Access. В частности, при низкой плотности инструкций наибольший эффект с точки зрения снижения DD наблюдается при включении транзакционности на уровнях API и persistence-слоя. Для слоя бизнес-логики зависимость носит более сглаженный характер, что указывает на различную роль слоёв в формировании дефектов, связанных с транзакционностью.

Сопоставление результатов по слоям подтверждает целесообразность дифференцированного подхода к управлению транзакциями в рамках layered architecture. Унифицированная стратегия равномерного покрытия всех слоёв транзакционными инструкциями не обеспечивает оптимального баланса между качеством и эксплуатационными затратами. Напротив, целенаправленная настройка конфигурации транзакционности по слоям позволяет достигать более устойчивых значений показателя DD при контролируемых издержках.

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

Полученные эмпирические зависимости позволили формализовать допустимые варианты изменения состава инструкций управления транзакциями в прикладном коде. В рамках разработанного подхода модификации рассматриваются как управляемые операции, направленные на изменение конфигурации транзакционной разметки с учётом прогнозируемого влияния на показатель Defect Density.

С точки зрения модели, изменение транзакционной конфигурации может осуществляться по трём основным направлениям: добавление транзакционных инструкций, удаление существующих инструкций и изменение параметров аннотаций, определяющих уровень изоляции (isolation) и характер распространения транзакции (propagation). Каждое из указанных действий оценивается через процедуру what-if-анализа, в рамках которой рассчитываются значения DD до предполагаемой модификации (DDB) и после неё (DDM). Разность между этими значениями используется как количественная мера эффективности изменения.

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

Формализация перечисленных вариантов модификации представлена в таблице 1.

Таблица 1.

Варианты модификации кода с точки зрения управления транзакциями

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

Практическое применение разработанной модели потребовало учёта различий в стратегиях эксплуатации программного обеспечения. Как отмечалось во введении, на различных этапах жизненного цикла системы приоритеты могут смещаться в сторону максимизации согласованности данных либо минимизации эксплуатационных затрат. В связи с этим параметры T_A и T_R не являются фиксированными и подлежат настройке в зависимости от целевой функции оптимизации. В рамках реализации подхода были сформированы типовые режимы работы агента, отличающиеся наборами пороговых значений T_A и T_R. При ориентации на максимизацию целостности данных используется более жёсткий порог для добавления транзакционных инструкций и более ограничительный критерий их удаления. При ориентации на снижение эксплуатационных затрат допускается большая гибкость в удалении инструкций при контролируемом росте значения DD. Таким образом обеспечивается управляемый компромисс между качеством и ресурсными издержками. Параметризация режимов может выполняться автоматически на основании выбранной пользователем цели. При этом соблюдается соотношение TA < TR, что позволяет избежать симметричных решений и обеспечить устойчивость конфигурации при последовательных модификациях. Конкретный пример набора режимов и соответствующих пороговых значений представлен в таблице 2.

Таблица 2.

Пример набора режимов работы агента с разным набором порогов

Предложенный механизм параметризации демонстрирует возможность адаптации модели к различным эксплуатационным сценариям без изменения её архитектуры. В совокупности с правилами модификации, представленными в таблице 1, это позволяет реализовать формализованный процесс оптимизации транзакционной разметки в прикладном коде.

Заключение

В работе представлены результаты статистического анализа зависимости между характером расстановки инструкций управления транзакциями в Java-приложениях и показателем плотности дефектов (Defect Density). Эмпирические данные подтвердили наличие нелинейной зависимости между долей методов, покрытых транзакционными инструкциями, и значением DD, а также продемонстрировали различную чувствительность архитектурных слоёв к изменению конфигурации транзакционности.

На основе сформированного набора параметров, характеризующих структурную и логическую сложность кода, была разработана многопараметрическая предиктивная модель с использованием метода Long Short-Term Memory. Полученное значение коэффициента детерминации (R² = 0,98) свидетельствует о высокой объясняющей способности модели в рамках рассматриваемой выборки проектов. Разработанная модель позволила формализовать процедуру оптимизации состава инструкций управления транзакциями с использованием пороговых параметров TA и TR и механизма what-if-анализа. В рамках предложенного подхода оптимизация может осуществляться как в направлении снижения плотности дефектов при фиксированных эксплуатационных затратах, так и в направлении минимизации затрат при контролируемом изменении показателя DD.

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

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

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

1. Gray J., Reuter A. Transaction Processing: Concepts and Techniques. San Francisco: Morgan Kaufmann, 1992. 1070 p. ISBN 1558601902.
2. Alonso G., Agrawal D., El Abbadi A., Kamath M., Günthör R., Mohan C. Advanced transaction models in workflow contexts // Proceedings of the Twelfth International Conference on Data Engineering. 26 Feb. 1996.
3. Gilbert S., Lynch N. Brewer's conjecture and the feasibility of consistent, available, partition-tolerant web services // ACM SIGACT News. 2002. Vol. 33, № 2. P. 51–59. DOI: 10.1145/564585.564601.
4. Bailis P., Davidson A., Feketer A., Ghodsi A., Hellerstein J. M., Stoica I. Highly Available Transactions: Virtues and Limitations // Proceedings of the VLDB Endowment. 2013. Vol. 7, № 3. P. 181–192.
5. Kleppmann M. Please stop calling databases CP or AP [Электронный ресурс]. 2015. URL: https://martin.kleppmann.com/2015/05/11/please-stop-calling-databases-cp-or-ap.html (дата обращения: 24.11.2019).
6. Hassan S., Bahsoon R., Kazman R. Microservice Transition and its Granularity Problem: A Systematic Mapping Study // Software: Practice and Experience. 2020. Vol. 50, № 9. P. 1651–1681. DOI: 10.1002/spe.2869.
7. Baeldung. Transactions with Spring and JPA [Электронный ресурс]. 2026. URL: https://www.baeldung.com/transaction-configuration-with-jpa-and-spring (дата обращения: 11.02.2026).
8. Tansey W., Tilevich E. Annotation Refactoring: Inferring Upgrade Transformations for Legacy Applications // Proceedings of the 23rd ACM SIGPLAN Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA ’08). New York: ACM, 2008. P. 295–312.
9. Perin F., Gîrba T., Nierstrasz O. Recovery and Analysis of Transaction Scope from Scattered Information in Java Enterprise Applications // Proceedings of the 26th IEEE International Conference on Software Maintenance (ICSM 2010). Timisoara, 2010. P. 1–10. DOI: 10.1109/ICSM.2010.5609572.
10. Chen T.-H., Shang W., Hassan A. E., Nasser M., Flora P. Detecting Problems in the Database Access Code of Large-Scale Systems: An Industrial Experience Report // Proceedings of the 38th International Conference on Software Engineering Companion (ICSE ’16). 2016. P. 71–80. DOI: 10.1145/2889160.2889228.
11. Слекеничс А. Я. Реализация AI-агентов для разработки ПО, объединяющих предиктивные и языковые модели // Universum: Технические науки. 2025. № 10 (139). DOI: 10.32743/UniTech.2025.139.10.21091.
12. Hochreiter S., Schmidhuber J. Long short-term memory // Neural Computation. 1997. Vol. 9, № 8. P. 1735–1780. DOI: 10.1162/neco.1997.9.8.1735.
13. Интегрированная среда разработки GIGA IDE [Электронный ресурс]. URL: https://gigaide.ru/ (дата обращения: 13.02.2026).
14. Слекеничс А. Я. Реализация AI-агента для управления объёмом логирования в программном обеспечении // Universum: Технические науки. 2025. № 11 (140). DOI: 10.32743/UniTech.2025.140.11.21332.
15. Слекеничс А. Я. Опыт использования предиктивных ML-моделей при автоматизации тестирования ПО // Universum: Технические науки. 2025. № 12 (141). DOI: 10.32743/UniTech.2025.141.12.21599.