Introduction to Static Analysis Dependable Software Laboratory
Static Analysis Static analysis is the process of examining source code prior to compilation Without executing Static analysis can diagnose for: Quality aspects such as maintainability, reliability, understandability and complexity Testing issues Coding standard compliance issues Best programming practices and unsafe programming constructs and coding defects 2
Static Analysis Analyze the program without executing it Doesn t depend on having good test cases or even any test cases Generally, doesn t know what your software is supposed to do Looks for violations of reasonable programming Not a replacement for testing Very good at finding problems on untested paths But many defects can t be found with static analysis False alarm occurs Generally 30% 3
A position of the Static Analysis in Verification Verification Trade-off Dimensions 4
Static Analysis Static analysis can be divided 3 levels Level 1: syntax checking of the source code Rule checking, coding style checking Level 2: quality analysis with translated source code to CFG/DFG form Sematic analysis, complexity analysis Level 3: static analysis, analyzing critical errors which can be issued during execution Divided by zero, NULL pointer, Etc. 5
Level 1 Rule checking, coding style checking Syntax checking by IDE (e.g. eclipse, visual studio) is a kind of static analysis Several kinds of rules Simple rule checking E.g. Brace location, tab, Etc. Safe coding rule checking T. A., R.W. WITTY, SAFE PROGRAMMING, 1978 Safe specification and programming(coding) is the simplest way to improve software reliability Proposing several rules for safe software (safe programming) E.g. infinite loop checking with counter, protecting buffer overflow code It is useful for coding style checking when working as a team Readability Maintainability 6
Level 2 Kinds of complexity, coverage, depend metrics Using CFG (Control Flow Graph), DFD (Data Flow Graph), Etc. 7
Level 2 Source code information and dependency graph E.g. Cyclomatic Complexity 8
Cyclomatic Complexity Cyclomatic complexity is a software metric (measurement), used to indicate the complexity of a program. It is a quantitative measure of the number of linearly independent paths through a program's source code. It was developed by Thomas J. McCabe, Sr. in 1976. Cyclomatic complexity is computed using the control flow graph of the program: the nodes of the graph correspond to indivisible groups of commands of a program, and a directed edge connects two nodes if the second command might be executed immediately after the first command. Cyclomatic complexity may also be applied to individual functions, modules, methods or classes within a program. One testing strategy, called basis path testing by McCabe who first proposed it, is to test each linearly independent path through the program; in this case, the number of test cases will equal the cyclomatic complexity of the program. 9
Cyclomatic Complexity Lower is better. A McCabe complexity under 5 is good, from 5-10 is OK, and over 10 is too complex. A high flow complexity may be a symptom of a function which does too much or has low cohesion (does to many different things). But don't take these numbers too seriously -- you may have comprehensible control flow despite high numbers. For example, one large switch statement can be clear to understand, but can dramatically increase the count. 23 is too high 10
Level 3 Static analysis analyzing critical errors which can be issued during execution Without execution(compile) 11
Automated Static Analysis There are several tools for static analysis of source codes Commercial Powerful tool is too expensive Open source Several open source tools exist also 12
Tools 13
Tools 14
Tools 15
Eclipse Metrics Plugin Level 2 Install Help -> Install New Software -> Add -> input the location (http://metrics2.sourceforge.net/update/) 16
Eclipse Metrics Plugin 17
Eclipse Metrics Plugin 각 project -> properties -> Metrics -> enable 18
Eclipse Metrics Plugin Window -> Show View -> Metrics -> Metrics View 19
Eclipse Metrics Plugin 20
Eclipse Metrics Plugin Complexity, code line, 상속관계등 21
Eclipse Metrics Plugin Dependency Graph 22
PMD Level 1+Level 3 (part of) PMD is a source code analyzer. It finds common programming flaws like unused variables, empty catch blocks, unnecessary object creation, and so forth. It supports Java, JavaScript, Salesforce.com Apex and Visualforce, PLSQL, Apache Velocity, XML, XSL. Additionally it includes CPD, the copy-paste-detector. CPD finds duplicated code in Java, C, C++, C#, Groovy, PHP, Ruby, Fortran, JavaScript, PLSQL, Apache Velocity, Scala, Objective C, Matlab, Python, Go, Swift and Salesforce.com Apex and Visualforce. 23
PMD Install Install new software -> https://dl.bintray.com/pmd/pmd-eclipse-plugin/updates/ 24
PMD Violations Violations with code overview Priority filtering 25
PMD 이외에도 dataflow, CPD (Finding duplicated code) 가가능 26
PMD Method 별 data flow 27
PMD Report example User can select the form of the report 28
PMD Window -> Preference -> PMD -> Rule Configuration 사용할 rule set 설정 새로운 rule 추가가능 29
Checkstyle Level 1 Checkstyle is a development tool to help programmers write Java code that adheres to a coding standard. It automates the process of checking Java code to spare humans of this boring (but important) task. This makes it ideal for projects that want to enforce a coding standard. Checkstyle is highly configurable and can be made to support almost any coding standard. An example configuration files are supplied supporting the Sun Code Conventions, Google Java Style. 30
Checkstyle Install Install New Software -> http://eclipse-cs.sf.net/update/ Properties Activation Rule configuration 31
Checkstyle Rule configuration 기본적으로 google, sun의 coding style 제공 여러 style을선택가능 User define rule also available 32
Checkstyle Naming Convention example 33
Checkstyle Other rule example 34
Checkstyle Activate example Violation 부분을표시 35
FindBugs Level 3 It is an open source program which looks for bugs in Java code Operates on Java bytecode, rather than source code Source code also available 36
FindBugs Install Install new software -> http://findbugs.cs.umd.edu/eclipse project -> properties -> Findbugs -> enable 37
FindBugs Detector configuration Searching rule setting Enable/disable 38
FindBugs Example - InfiniteLoop 39
FindBugs Report setting Report 로생성할항목들설정등 40
FindBugs Execution Find Bugs click XML generation is possible 41
FindBugs Explorer 42
JDepend Level 2 Help -> Eclipse Marketplace -> jdepend 입력후검색 43
JDepend Source code 가있는폴더선택후 JDepend run 44
JDepend CC :: Concrete Class 인터페이스나추상클래스가아닌 Concrete Class 의수를나타냄 AC :: Abstract Class 추상클래스나인터페이스의수를나타내며확장성의척도가됨 Ca :: Afferent Couplings 현재패키지의클래스에의존하고있는패키지의수를나타내며책임의척도가됨 Ce :: Efferent Couplings 현재패키지의클래스들이의존하고있는패키지의수를나타내며독립성의척도가됨 A :: Abstractness ( A = AC/CC+AC ) 추상화정도를나타내며, 0 은구체적인패키지를, 1 은추상적인패키지를나타냄 I :: Instability ( I = Ce(Ce+Ca) ) 변화에대한안정성을나타내며 0 부터 1 사이의값을가짐, 0 은외부변화에도끄떡없는패키지이며 1 은작은변화에도쉽게흔들릴수있는패키지를나타냄 D :: Distance to Main Sequence Main Sequence 로부터의거리를나타내며, 0 은 Main Sequence 와완전가깝고 1 은완전먼상태임, Main Sequence 란이상적인패키지로완전추상적이면서안정적이거나완전구체적이면서불안정한패키지를나타냄 Cycle :: Package dependency cycles 패키지들상호간에의존성을가지고있을때발생함, 안좋은상황이기때문에경고아이콘으로보여짐 45
SonarQube 이것도한번사용해보세요 46
발표 Static Analysis 각자서로 team의 source code를대상으로 static analysis를수행, 결과발표 3개의도구선택 ( 복잡도 or 의존성분석도구 1개반드시포함 ) 설명한도구를포함해많은도구들중자유롭게선택 분석결과중 critical 한부분들에대한분석발표 1 4, 3 2 4, 1 3 1, 2 4 2, 3 5 8, 7 6 8, 5 7 5, 6 8 6, 7 47