Abstract
The static program analysis is gradually adopting advanced use cases, and integration with programming tools becomes more necessary than ever. However, each integration requires a different kind of functionality implemented within an analyzer. For example, continuous integration tools typically analyze projects from scratch, while doing the same for code querying is not efficient performance-wise. The code behind such use cases makes «service models», and it tends to differ significantly between them. In this paper, we analyze the models which might be used by the static analyzer to provide its services based on aspects of security, performance, long-term storage. All models are assigned to one of the groups: logical presence (where the actual computation is performed), resource acquisition, input/output, change accounting and historic data tracking. The usage recommendations, advantages and disadvantages are listed for each reviewed model. Input/output models are tested for actual network throughput. We also describe the model which might aggregate all these use cases. The model is partially evaluated within the work-in-progress static analyzer Equid, and the observations are presented.
Highlights
Static analyzers are widely used in the industry for different purposes: defect search, verification, linting, quality assurance, code refactoring [1]
The considerations for service model agnostic analyzers were used as a basis for our project – Equid static analyzer [27]
After finishing all jobs related to a specific run, the user might obtain the result of the analysis in all requested forms
Summary
Static analyzers are widely used in the industry for different purposes: defect search, verification, linting, quality assurance, code refactoring [1]. Most of these use cases can be implemented via a standard sequential model. We believe that analysis tools have the potential to be used by a larger audience comprising engineers and architects, technical management, quality assurance staff This extended audience uses analyzers nowadays, but mostly to understand code quality, while analyzers may provide more kinds of information. Working out a way to support all models contributes to developing a more unified analyzer structure, improving user experience [4], and, may lead to wider adoption of static analysis tools.
Sign-in/Register to view highlights & summary Sign-in/Register to access full text options 
Talk to us
Join us for a 30 min session where you can share your feedback and ask us any queries you have
Schedule a callMore From: Proceedings of the Institute for System Programming of the RAS
Disclaimer: All third-party content on this website/platform is and will remain the property of their respective owners and is provided on "as is" basis without any warranties, express or implied. Use of third-party content does not indicate any affiliation, sponsorship with or endorsement by them. Any references to third-party content is to identify the corresponding services and shall be considered fair use under The CopyrightLaw.
