Static program analysis: Difference between revisions

Revision as of 13:20, 28 December 2021

Revision as of 04:48, 6 May 2022

Line 1:

{{Short description|Establishing properties of computer programs without executing them}}

{{Software development process}}

'''Static program analysis''' is the [[program analysis (computer science)|analysis of computer software]] performed without executing any programs, in contrast with [[dynamic program analysis|dynamic analysis]], which is performed on programs during their execution.<ref>{{cite journal |archive-url=https://web.archive.org/web/20110927010304/http://www.ida.liu.se/~TDDC90/papers/industrial95.pdf |archive-date=2011-09-27 | title=Industrial Perspective on Static Analysis. |journal=Software Engineering Journal |date=Mar 1995 |pages=69–75 |last1=Wichmann |first1=B. A. |first2=A. A. |last2=Canning |first3=D. L. |last3=Clutterbuck |first4=L. A. |last4=Winsbarrow |first5=N. J. |last5=Ward |first6=D. W. R. |last6=Marsh |volume=10 |issue=2 |doi=10.1049/sej.1995.0010 |url=http://www.ida.liu.se/~TDDC90/papers/industrial95.pdf}}</ref><ref>{{Cite journal|lastlast1=Egele|firstfirst1=Manuel|last2=Scholte|first2=Theodoor|last3=Kirda|first3=Engin|last4=Kruegel|first4=Christopher|date=2008-03-05|title=A survey on automated dynamic malware-analysis techniques and tools|url=https://doi.org/10.1145/2089125.2089126|journal=ACM Computing Surveys|volume=44|issue=2|pages=6:1–6:42|doi=10.1145/2089125.2089126| s2cid=1863333 |issn=0360-0300}}</ref>

The term is usually applied to analysis performed by an [[List of tools for static code analysis|automated tool]], with human analysis typically being called "program understanding", [[program comprehension]], or [[code review]]. In the last of these, [[software inspection]] and [[software walkthrough]]s are also used. In most cases the analysis is performed on some version of a program's [[source code]], and, in other cases, on some form of its [[object code]].

== Rationale ==

The sophistication of the analysis performed by tools varies from those that only consider the behaviour of individual statements and declarations,<ref>{{Cite journal|lastlast1=Khatiwada|firstfirst1=Saket|last2=Tushev|first2=Miroslav|last3=Mahmoud|first3=Anas|date=2018-01-01|title=Just enough semantics: An information theoretic approach for IR-based software bug localization|url=https://linkinghub.elsevier.com/retrieve/pii/S0950584916302269|journal=Information and Software Technology|language=en|volume=93|pages=45–57|doi=10.1016/j.infsof.2017.08.012}}</ref> to those that include the complete [[source code]] of a program in their analysis. The uses of the information obtained from the analysis vary from highlighting possible coding errors (e.g., the [[lint programming tool|lint]] tool) to [[formal methods]] that mathematically prove properties about a given program (e.g., its behaviour matches that of its specification).

[[Software metric]]s and [[reverse engineering]] can be described as forms of static analysis. Deriving software metrics and static analysis are increasingly deployed together, especially in creation of embedded systems, by defining so-called ''software quality objectives''.<ref>[http://web1.see.asso.fr/erts2010/Site/0ANDGY78/Fichier/PAPIERS%20ERTS%202010/ERTS2010_0035_final.pdf "Software Quality Objectives for Source Code"] {{webarchive|url=https://web.archive.org/web/20150604203133/http://web1.see.asso.fr/erts2010/Site/0ANDGY78/Fichier/PAPIERS%20ERTS%202010/ERTS2010_0035_final.pdf |date=2015-06-04 }} (PDF). ''Proceedings: Embedded Real Time Software and Systems 2010 Conference'', ERTS2010.org, Toulouse, France: Patrick Briand, Martin Brochet, Thierry Cambois, Emmanuel Coutenceau, Olivier Guetta, Daniel Mainberte, Frederic Mondot, Patrick Munier, Loic Noury, Philippe Spozio, Frederic Retailleau.</ref>

Line 26:

== Tool types==

The OMG ([[Object Management Group]]) published a study regarding the types of software analysis required for [[software quality]] measurement and assessment. This document on "How to Deliver Resilient, Secure, Efficient, and Easily Changed IT Systems in Line with CISQ Recommendations" describes three levels of software analysis.<ref>{{cite web |url=http://www.omg.org/CISQ_compliant_IT_Systemsv.4-3.pdf |title=ArchivedOMG copyWhitepaper &#124; CISQ - Consortium for Information & Software Quality |access-date=2013-10-18 |url-status=live |archive-url=https://web.archive.org/web/20131228132152/http://www.omg.org/CISQ_compliant_IT_Systemsv.4-3.pdf |archive-date=2013-12-28 }}</ref>

; Unit Level: Analysis that takes place within a specific program or subroutine, without connecting to the context of that program.

Line 52:

== Data-driven static analysis ==

Data-driven static analysis uses large amounts of code to infer coding rules.<ref name="dewes">{{cite web |title=Learning from other's mistakes: Data-driven code analysis. |url=https://www.slideshare.net/japh44/talk-handout-46938511 |website=www.slideshare.net |date=13 April 2015 |language=en}}</ref>{{Better source needed|date=September 2020}} For instance, one can use all Java open-source packages on GitHub to learn a good analysis strategy. The rule inference can use machine learning techniques.<ref name="OhYang2015">{{cite book|last1=Oh|first1=Hakjoo|title=Proceedings of the 2015 ACM SIGPLAN International Conference on Object-Oriented Programming, Systems, Languages, and Applications - OOPSLA 2015|last2=Yang|first2=Hongseok|last3=Yi|first3=Kwangkeun|chapter=Learning a strategy for adapting a program analysis via bayesian optimisation|year=2015|pages=572–588|doi=10.1145/2814270.2814309|isbn=9781450336895|s2cid=13940725|url=https://ora.ox.ac.uk/objects/uuid:f656bcfd-ec1b-477c-9185-ff2c7490a207}}</ref> For instance, it has been shown that when one deviates too much in the way one uses an object-oriented API, it is likely to be a bug.<ref name="MonperrusMezini2013">{{cite journal|last1=Monperrus|first1=Martin|last2=Mezini|first2=Mira|title=Detecting missing method calls as violations of the majority rule|journal=ACM Transactions on Software Engineering and Methodology|volume=22|issue=1|year=2013|pages=1–25|url=https://hal.archives-ouvertes.fr/hal-00702196/document|doi=10.1145/2430536.2430541|arxiv=1306.0762|s2cid=1212778}}</ref> It is also possible to learn from a large amount of past fixes and warnings.<ref name="dewes"/>{{Better source needed|date=September 2020}}

== See also ==