Программные продукты и системы

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

Вопросы тестирования программных продуктов вызывают высокий интерес у исследователей и разработчиков по причине сильного влияния данного этапа на результат разработки ПО в целом. В частности, в работе [1] описывается исследование данного процесса при использовании непрерывной интеграции в инфраструктуре DevOps, для успешного применения которой критически важна автоматизация тестирования. В работе [2] анализируется время тестирования ПО, рассматриваются планиро- вание и подготовка тестового примера, тестиро- вание конфигурации среды, выполнение и отладка тестов, а также регрессионное тестирование. В [3] выполнен анализ затрат на данный процесс у крупных разработчиков, таких как Boeing, IBM, Snapchat. Рассматриваются различные модели жизненного цикла, оценивается влияние сложности проекта и квалификации разработчиков на затраты, связанные с тестированием ПО.

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

Анализ подходов  к решению задачи

Тестирование ПО оказывает сильное влияние на весь процесс разработки программных продуктов, повышение его значимости носит объективный характер и связано с ростом слож- ности разрабатываемых систем. В работе [4] оценивается влияние автоматизированного тестирования на стоимость, качество и время разработки программы, приводится его сравнение с ручным на примере различных программ.

Рассмотрим подходы, применяемые для ус- корения процесса автоматизированного тестирования ПО. Для этого был выполнен поиск  на сайте dimensions.ai по запросу «continuous integration», «multi-agent system», «testing»  в предметной области Software Engineering (код 4612), а также на сайте elibrary.ru по запросу «непрерывная интеграция», «многоагент- ный», «тестирование». Были отобраны публикации по теме тестирования и непрерывной  интеграции, а также по выборочному запуску регрессионных тестов (Regression Test Selection, RTS).

В работе [5] рассматривается ускорение тестирования за счет применения автоматизированной системы для составления тест-планов. В работе [6] анализируется возможность применения инструментов Vite, Storybook и Vitest для оптимизации процесса модульного и интеграционного тестирования, а также для тестирования пользовательского интерфейса. В рабо- те [7] рассматривается ускорение тестирования пользовательского интерфейса web-приложения за счет параллельного запуска тестов с использованием надстройки Selenide над системой тестирования Selenium WebDriver. Отмечается, что существенное увеличение времени этого этапа (до нескольких часов) связано с ростом проекта. Для успешного параллельного запуска автоматизированных тестов они должны быть изолированы друг от друга, чтобы избежать состояния гонки, когда результат зависит от очередности выполнения тестов. В [8] предлагается применить технологии контейнеризации, такие как Docker и Kubernetes для ускорения процесса тестирования ПО на примере финансовой организации. В работе отмечаются такие преимущества подхода, как увеличение гибкости и масштабируемости системы.

Ускорение рассматриваемого процесса может также достигаться за счет применения выборочного тестирования, при котором запускается часть тестов, ориентированная на про- верку внесенных в код изменений. При таком подходе тесты ассоциируются с участками программного кода, а их запускаемый набор зависит от изменений в конкретных участках. Поиск зависимостей между тестами и кодом может выполняться статически [9], динамически [10] либо благодаря комбинированию этих методов [11]. За счет выборочного тестирования, основанного на анализе связей тестов  и программного кода, решается задача сокращения времени на эту процедуру.

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

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

Существует множество методов тестирования ПО, первоочередные – тестирование функциональности, базы данных, API и контента. Они подтверждают работоспособность функционала приложения и соответствие требований документации. Следующим шагом проводится тестирование совместимости, подтверждающее правильную загрузку и корректную работу приложения на различных операционных системах и аппаратных платформах. Далее выполняется тестирование безопасности, обеспечивающее защищенность веб-приложения. Данный метод может использоваться совместно с тестированием БД. После чего следует тестирование производительности, проверяющее ста- бильность, надежность и скорость работы системы. Затем проводится тестирование удобства использования, позволяющее определить, насколько веб-сайт привлекателен, комфортен и полезен для пользователя. Регрессионное тестирование обеспечивает отсутствие дефектов в системе, связанных с внесением исправлений и реализацией нового функционала.

Рассмотрим последовательность этапов тестирования нового функционала (доработки) веб-приложений на примере информационной системы в сфере закупок. Работа с тест-кейсами осуществляется в системе Jira с использованием плагина Jira Zephyr.

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

Вторым этапом является подготовка тестовой документации для тестирования доработки.

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

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

в) Осуществляется подготовка старых тестовых данных на стенде develop до реализации доработки с целью проверки корректности работы нового функционала с ранее размещенными данными.

г) Проводится оценка трудозатрат, в ходе которой выполняется подсчет времени, затраченного на тестирование. Учет времени осуществляется до и после оптимизации. Итоговым результатом является оптимизированная оценка. Оценка трудозатрат включает в себя подготовку старых и новых данных, планируемое время на выполнение проверок, создание/изменение тест-кейсов, оценку времени на валидацию дефектов, создание итогового от- чета. Подсчет трудозатрат ведется в тест-дизайне.

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

По итогам тестирования вычисляется качество доработки в процентах и формируется отчет. Качество доработки вычисляется с учетом наличия дефектов в статусе «Open» – в ожидании, «Reopened» – открыты повторно, «In progress» – на исправлении, «Resolved» – в ожидании проверки и уточнения. Не учитываются  дефекты, находящиеся в статусе «Closed» – исправлен, а также дефекты, найденные при проверке доработки, но не относящиеся к ней. Оценки качества доработки: «Низкое» для значений [0–65 %), «Ниже среднего» для значений [65–75 %), «Среднее» для значений [75–85 %), «Выше среднего» для значений [85–95 %)  и «Высокое» для значений [95–100 %]. Отчет по итогам тестирования включает тестовое покрытие, информацию по проблемам, статистику по выявленным и актуальным дефектам.

Для ускорения тестирования применяется автоматизация запуска тестов. В рабочем процессе задействуется связка Docker + Jenkins. Тесты разбиты по подсистемам и запускаются вручную, происходит настройка их запуска. Возможен запуск ограниченного набора тест-кейсов, полное smoke-тестирование и полный запуск тестов в Jira Zephyr. Все настройки  выбираются перед запуском тестирования  в Jenkins, создается эффективный набор тестов. В проекте существуют тестовые smoke-прогоны подсистем, в которых отобраны наиболее приоритетные для проверки покрывающие основной функционал тест-кейсы. При их помощи возможно обнаружить критические и блокирующие дефекты, осуществляется параллельный запуск тестов. Возможен одновременный запуск тестов по нескольким подсистемам, которые не связаны друг с другом.

Многоагентная система

Рассмотрим многоагентный подход для управления процессом непрерывной интеграции и метод выборочного запуска тестов, основанный на истории тестирования. Данный метод должен обеспечить уменьшение времени тестирования и снижение нагрузки на вычислительные ресурсы в ходе разработки ПО. Многоагентный подход может применяться для разработки сложных технических и программных систем со множеством элементов  и связей. Многоагентные системы имеют обширную сферу применения, в частности они активно используются при разработке ПО для распределения данных и программного кода [12] или для его автоматической генерации на основе онтологий предметной области [13].

Опишем представленные на схеме (рис. 1) виды агентов.

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

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

Агент-субординатор осуществляет общее управление процессом непрерывной интеграции, выполняя функции наблюдения, контроля и оценки эффективности деятельности многоагентной системы.

Агент-координатор осуществляет согласованное управление агентами-тестировщиками, выбирает режим тестирования, организует параллельное выполнение тестов.

Рассмотрим формальное описание многоагентной системы MASCI, осуществляющей управление процессом непрерывной интеграции:

MASCI = {A, AT, IE, BR, ORG, ACT, CP, CISt},

где A = {a1, a2, ..., am} – множество неоднородных агентов различных типов; AT = {AT1, AT2, AT3, AT4} – множество типов агентов (AT1 – агент-тестировщик, AT2 – агент-анализатор, AT3 – агент-субординатор, AT4 – агент-координатор); IE – информационная среда, в которой функционируют агенты; BR – семейство базовых отношений между агентами; ORG – организационная структура агентов, включающая их роли и установленные отношения; ACT – множество действий агентов; CP – множество коммуникативных актов, образующих протокол коммуникации в многоагентной системе; CISt – упорядоченное множество этапов процесса  непрерывной интеграции.

Множество IE состоит из следующих элементов:

IE = {TG, T, TS, TSE},

где TG – множество групп требований TG = {tg1,  tg2, ... tgn}, |TG| = N, в нее входят отдельные требования, связанные с разработкой крупных функций системы, а также с оптимизацией, безопасностью, кроссплатформенностью и проч.;  T – множество всех тестов, разработанных для тестирования системы в целом T = {t1, t2, ... , tk}, |T| = K; TS – семейство множеств тестов TSi ⸦ T, соответствующих группам требований (покрытие множества S) TS = {TSi}i∈I (отдельный тест может входить в состав нескольких семейств); TSE = {TSE1, TSE2, …, TSEn}, |TSE| = N. После завершения этапа тестирования для каждой группы формируется множество тестов, завершившихся с ошибкой TSEi ⸦ TSi, множество TSEi соответствует i-й группе тестов TSi.

На основе множеств TSEi и TSi рассчитывается коэффициент дефектов EFi для i-й группы тестов по формуле

где BMem – количество последних сборок, для которых осуществляется анализ выявленных дефектов и расчет соответствующего коэффициента дефектов EFi; TSij – количество  тестов в i-й группе в ходе выполнения сборки  с номером BNum-j (с номером текущей сборки продукта, после завершения которой BNum увеличивается на 1); TSEij – количество тестов, завершившихся с ошибкой среди тестов в i-й группе в ходе выполнения сборки с номером BNum-j. Значение коэффициента EFi, рассчитанное для группы тестов TSi, может использоваться при выборе тестов, которые будут выполняться на очередном этапе тестирования процесса непрерывной интеграции.

Выбор тестов для запуска происходит при условии, что коэффициент дефектов EFi для i-й группы меньше либо равен выбранному граничному значению. Формирование тестового набора для группы TSi осуществляется следующим образом:

-   упорядочить тесты в i-й группе по возрастанию числа запусков;

-   перемешать случайным образом подпоследовательности тестов с одинаковым количеством запусков;

-   выбрать для запуска N первых тестов.  N = |TSi|(1 – DF), где DF – доля тестов [0…1], которые будут проигнорированы при запуске.

Результаты

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

С имитационной моделью было проведено четыре эксперимента, в них изменялись значение параметра BMem и количество последних сборок, для которых накапливалась статистика по выполнению тестов и вероятность выполнения теста с ошибкой. Первый эксперимент ВМem = 15, вероятность ошибки 1 % (рис. 3а); второй эксперимент ВМem = 25, вероятность ошибки 1 % (рис. 3б); третий эксперимент ВМem = 15, вероятность ошибки 2 % (рис. 4а); четвертый эксперимент ВМem = 25, вероятность ошибки 2 % (рис. 4б). В каждом эксперименте было создано по 245 тестов (TestCount), разделенных на 35 групп (GroupCount). Запись результатов моделирования проводилась на протяжении 150 сборок (BuildCount). Перед ее началом было выполнено BMem первых сборок для правильного расчета коэффициента EF (значение сборки 1 соответствует первой сборке, для которой выполнялась запись результатов эксперимента). После выполнения всех тестов в группе рассчитывался коэффициент EF.

На графиках изображены три линии: общее количество тестов (верхняя), суммарное коли- чество тестов в группах со значением коэффициента EF – 0 (средняя) и со значением коэффициента EF ≤ 0.05 (нижняя). За счет снижения частоты выполнения тестов из указанных групп можно достичь уменьшения общего времени выполнения тестов.

Обсуждение результатов

Рассмотрим результаты моделирования.  В каждом эксперименте подсчитывалось количество тестов в группах со значением EF ≤ 0.05 и EF = 0. Снижение вычислительных ресурсов, затраченных на тестирование, рассчитывалось исходя из снижения вероятности выполнения тестов в данных группах на 50 %. Предполагается, что время выполнения всех тестов одинаковое. Результаты моделирования представлены в таблице.

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

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

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

Рассмотрим полученные результаты в сравнении с другими методами выборочного запуска тестов. В работе [9], использующей статический анализ кода для выявления зависимостей между кодом и тестами, время выборочного тестирования составляет в среднем 81 % от полного. В работе [10], использующей динамический анализ зависимостей кода и тестов, время тестирования снижается на 32 %, а для больших тестовых наборов – на 54 %. При комбинировании статических и динамических методов в работе [11] получены результаты времени выборочного тестирования от 69 % до 91 % от полного. Таким образом, можно сделать вывод о том, что результаты моделирования в данной работе сопоставимы с результатами, полученными в работах, посвященных решению аналогичной задачи.

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

Заключение

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

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

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

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

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

1. Pando B.A, Dávila A.A. Systematic mapping study on software testing in the DevOps context. Proc. ISP RAS, 2023, vol. 35, no. 1, pp. 163–188. doi: 10.15514/ISPRAS-2023-35(1)-11.

2. Амиров А.Ж., Динмухаммедулы Д. Оценка времени для тестирования программного обеспечения // E-Scio. 2020. № 5. С. 428–437.

3. Shaikhulov E. Estimation and assessment of software testing efforts. JARiTS, 2024, no. 42, pp. 42–49.

4. Феденева Е.С. Влияние автоматизации тестирования на стоимость, качество и время выхода программного обеспечения на рынок // Цифровая трансформация общества и информационная безопасность: матер. II Всерос. науч.-практич. конф. 2023. С. 155–159.

5. Тютюных А.А., Полевщиков И.С. Автоматизация процесса составления тест-планов при тестировании программного обеспечения // ИнноТех: теория, инструменты, практика. 2018. Т. 1. С. 50–55.

6. Дудак А.А. Оптимизация процессов разработки и тестирования с помощью Vite, Storybook и Vitest // Инновационная наука. 2024. № 9-1. С. 21–25.

7. Кириллов С.С. Ускорение автоматизированных тестов на базе Selenium WebDriver за счет внедрения системы параллельного запуска // Перспективы науки. 2022. № 7. С. 34–39.

8. Бобунов A. Использование контейнеризации для упрощения и ускорения процессов тестирования в финансовых организациях // Int. J. Humanities and Natural Sci., 2024, vol. 8-1, no. 85, pp. 113–117 (на англ.).

9. Legunsen O., Shi A., Marinov D. STARTS: STAtic regression test selection. Proc. 32nd IEEE/ACM Int. Conf. ASE, 2017, pp. 949–954. doi: 10.1109/ASE.2017.8115710.

10. Gligoric M., Eloussi L., Marinov D. Practical regression test selection with dynamic file dependencies. Proc. Conf. ISSTA, 2015, pp. 211–222. doi: 10.1145/2771783.2771784.

11. Shi A., Hadzi-Tanovic M., Zhang L. et al. Reflection-aware static regression test selection. Proc. ACM on Programming Languages, 2019, vol. 3, art. 187. doi: 10.1145/3360613.

12. Балабанов А.И., Воронкин Е.Ю. Исследование возможности использования мультиагентных систем для распределения кода и данных // Интерэкспо Гео-Сибирь. 2023. Т. 6. № 1. С. 11–14. doi: 10.33764/2618-981X-2023-6-11-14.

13. Нагорных М.Э., Быков А.Н., Чернышев С.А. Программное обеспечение формирования онтологии предметной области и ее кодогенерации // Вестн. РосНОУ. Сер. Сложные системы: модели, анализ и управление. 2022. № 4. С. 149–157. doi: 10.18137/RNU.V9187.22.04.P.149.

References

1. Pando, B., Dávila, A.A. (2023) ‘Systematic mapping study on software testing in the DevOps context’, Proc. ISP RAS, 35(1), pp. 163–188. doi: 10.15514/ISPRAS-2023-35(1)-11.

2. Amirov, A.Zh., Dinmuhammeduly, D. (2020) ‘Time estimation for software testing’, E-Scio, (5), pp. 428–437 (in Russ.).

3. Shaikhulov, E. (2024) ‘Estimation and assessment of software testing efforts’, JARiTS, (42), pp. 42–49.

4. Fedeneva, E.S. (2023) ‘The impact of test automation on the cost, quality, and time-to-market of software’, Proc. II All-Russ. Sci-Pract. Conf. Tsifrovaya Transformatsiya Obshchestva i Informatsionnaya Bezopasnost, pp. 155–159 (in Russ.).

5. Tyutyunykh, A.A., Polevshchikov, I.S. (2018) ‘Automation of the process of drawing up test plans for software testing’, Innovative Technologies: Theory, Tools, Practice, 1, pp. 50–55 (in Russ.).

6. Dudak, A.A. (2024) ‘Optimize development and testing processes with vite, storybook and vitest’, Innovative Sci., (9-1), pp. 21–25 (in Russ.).

7. Kirillov, S.S. (2022) ‘Acceleration of automated tests based on the Selenium WebDriver by implementating a parallel launch system’, Sci. Prospects, (7), pp. 34–39 (in Russ.).

8. Bobunov, A. (2024) ‘Using containerization to simplify and accelerate testing processes in financial organizations’, Int. J. Humanities and Natural Sci., 8-1(85), pp. 113–117.

9. Legunsen, O., Shi, A., Marinov, D. (2017) ‘STARTS: STAtic regression test selection’, Proc. 32nd IEEE/ACM Int. Conf. ASE, pp. 949–954. doi: 10.1109/ASE.2017.8115710.

10. Gligoric, M., Eloussi, L., Marinov, D. (2015) ‘Practical regression test selection with dynamic file dependencies’, Proc. Conf. ISSTA, pp. 211–222. doi: 10.1145/2771783.2771784.

11. Shi, A., Hadzi-Tanovic, M., Zhang, L. et al. (2019) ‘Reflection-aware static regression test selection’, Proc. ACM on Programming Languages, 3, art. 187. doi: 10.1145/3360613.

12. Balabanov, A.I., Voronkin, E.Yu. (2023) ‘Research of the possibility of using Multi-Agent systems for the distribution of code and data’, Interexpo Geo-Siberia, 6(1), pp. 11–14 (in Russ.). doi: 10.33764/2618-981X-2023-6-11-14.

13. Nagornykh, M.E., Bykov, A.N., Chernyshev, S.A. (2022) ‘Software for domain ontology formation and code generation’, Vestn. of RosNOU. Ser. Complex Systems: Models, Analysis, Management, (4), pp. 149–157 (in Russ.). doi: 10.18137/RNU.V9187.22.04.P.149.