Кознов Дмитрий Владимирович — доктор технических наук, доцент, профессор
sc 8885649400
Санкт-Петербург, 199034
Dmitry V. Koznov — D.Sc., Associate Professor, Professor
Saint Petersburg, 199034
Введение. Современные компании, имеющие в составе своих продуктов и технологий сложное программное обеспечение, заинтересованы в технологической независимости по его разработке. Более того, поскольку такое программное обеспечение часто оказывается очень объёмным (речь идёт о миллионах строк кода), то для его тестирования, сопровождения и трансформации требуются многофункциональные инструменты, которые невозможно получить готовыми из-за труднорешаемости многих базовых задач анализа кода (при этом часто эти задачи оказываются неразрешимыми, например, анализ указателей и сборка мусора в С/С++). Вместе с тем такие кодовые базы используют возможности языков программирования не полностью, поэтому классические задачи по анализу кода для этих частных случаев могут оказаться разрешимыми. Метод. Предложен подход для разработки предметно-ориентированных решений по анализу программного кода, предназначенных для конкретных больших кодовых баз. Такие решения оказываются востребованными для задач фаззинга, символьного исполнения и генерации тестов, а также для автоматических трансформаций/оптимизаций кода, поиска уязвимостей и т. д. Создание собственных предметно-ориентированных решений, работающих с конкретной кодовой базой, возможно, если компании имеют ресурсы для использования открытых проектов (Eclipse, Low Level Virtual Machine, Microsoft Visual Studio Code и др.), а высокая стоимость целевого проекта оправдывает такие затраты (эффективные решения помогают экономить большие средства, значительно повышая качество). Основные результаты. Разработанный метод состоит из следующих шагов: анализ проблемы и идей, проектирование решения, разработка требований, разработка самого решения, апробация, внедрение и передача решения. Требования включают создание шаблонов кода, на которых решение должно работать и которые ограничивают использование целевого языка программирования в рамках текущей кодовой базы. При этом разработка требований, решения и апробация выполняются параллельно, тестирование совмещено с разработкой. С помощью предложенного метода созданы инструменты для статического анализа С-приложений для нужд фаззинга, средство поиска клонов и рефакторинга большой кодовой базы программного обеспечения сетевых устройств и другие решения. В реализованных проектах было задействовано от одного до трех разработчиков, длительность проектов составляла от одного до двух лет. Обсуждение. Представленный метод оказался ресурсозатратным. Анализ реализованных проектов показал, что при исходном наличии готового технического задания можно в несколько раз снизить ресурсы по реализации решений по анализу кода. Метод направлен на итеративное выявление требований к решению в ситуации, когда готовое техническое задание невозможно создать, а также существенно понижает риски по разработке невостребованных решений.
Modern companies that incorporate complex software systems as part of their market products are increasingly seeking technological independence in the development and maintenance of these systems. Such companies typically manage very large codebases, often comprising millions of lines of code. Testing, maintaining, and transforming these codebases requires multi-functional analysis and development tools, which cannot simply be obtained off the shelf. This is largely due to the inherent difficulty of many fundamental program analysis problems — indeed, several of these problems are formally undecidable (for example, pointer analysis and garbage collection for C programs). At the same time, large industrial codebases often use only a limited subset of the features available in their respective programming languages. Consequently, program analysis problems that are undecidable in the general case may become tractable for these restricted, domain-specific subsets. This observation creates opportunities for specialized approaches. This article proposes an approach for developing domain-specific program analysis solutions tailored to particular large industrial codebases. Such solutions are in high demand for tasks including fuzzing, symbolic execution, automated test generation, static analysis, code transformation and optimization, and vulnerability detection. The development of such custom domain-specific analysis tools becomes feasible because code-owning companies typically possess substantial engineering resources. These resources can be leveraged in combination with open-source frameworks and ecosystems such as Eclipse, Low Level Virtual Machine, and Microsoft Visual Studio Code. Furthermore, the economic impact is often significant: effective analysis solutions lead to substantial cost savings and quality improvements, which justifies the investment in specialized tool development. The proposed method consists of the following key stages: problem and idea analysis, solution design, requirements development, implementation, testing and validation, deployment and transfer. A central element of this method is the development of code templates that define the subset of the basic programming language used within the codebase. These templates provide a formal foundation for analysis and constrain the variability that tools must support. Notably, requirements development, tool implementation, and validation proceed in parallel, with testing tightly integrated into the development process. Using this method, several tools have been successfully developed, including a static analysis tool for C applications tailored for fuzzing, a clone detection and refactoring tool for a large network device software codebase, and other domain-specific solutions. Each project typically involved between one and three developers and lasted one to two years. While effective, the proposed method is resource-intensive. Analysis of completed projects shows that when a fully specified technical assignment is available from the outset, the required resources for implementing program analysis solutions can be reduced by several times. However, the strength of the method lies in situations where no detailed technical specification can be produced in advance. In such cases, the method enables iterative elicitation of requirements, reducing the risk of developing tools that do not meet real project needs.
The authors declare that there are no conflicts of interest present.