Static & Dynamic Analysis

Static analysis는 code를 verify해주는 기능을 제공한다. 즉, code rule을 확인해주거나 혹은 memory leak과 같은 오류도 확인해준다. 일부 도구에서는 design pattern등을 자동으로 감지하여 적용을 권하기도 한다고 한다. 

그리고 static analysis가 제공하는 중요한 기능이 dynamic analysis를 지원한다는 것이다. 대표적인 것이 function, class, component들 간의 call graph이다. 

static analysis는 dynamic analysis에 비해서 자세하게 분석을 하지는 못하다. 실제로 수행을 해 보지 않고 분석한 것이기에 당연스런 제약일 것이다. 예를 들면 특정 모듈이 여러 다른 모듈들로부터 호출된다는 정보를 확인해 줄 수는 있겠으나 단위 시간당 얼마나 자주 호출되는지에 대한 정보는 제공하지 못한다.

또한 모든 dependency관계를 분석하지도 못한다는 제약이 있다. 가장 쉽게 생각할 수 있는 것이 event기반의 callback function호출이다. 즉, 하나의 함수가 direct로 다른 함수를 호출하는 관계는 보여줄 수 있겠으나 platform 혹은 kernel level의 event handler까지 분석을 하지 못하는 이상 event기반의 함수 혹은 모듈호출에 따른 의존관계를 보여주지 못한다.

(혹자는 도구의 기능이 발전하면 callback function의 pointer 정보 등을 분석하여 의존 관계를 파악할 수 있을 것이라고 설명할 수도 있을 것이다. 그러나 pointer연산이 들어간다면 사실 더욱 문제는 복잡해질 것이다. 예를 들어서 특정 function의 pointer address가 0x1234라고 가정을 해보겠다. 만일 event handler가 특정 event를 받아서 0x1230 + counter_value라는 위치를 호출한다고 가정했을 때 이 주소가 0x1234가 될지 아닐지의 정보를 계산한다는 것은 어렵기도 하거니와 많은 false alarm을 발생할 소지를 남긴다.)

하지만 dynamic analysis에 비해서 전체적인 관계를 파악할 수 있다는 장점이 있다. dynamic analysis의 장점은 실제 수행을 기반으로 하기에 정보가 정확하다는 이점이 있지만 모든 case를 수행하기란 불가능하다. 수천수만가지의 경우를 모두 수행할 수 없기에 결국 일부 경우에 국한되어 분석을 할 수 밖에 없다. 

때문에 많은 연구들이 static analysis를 기반으로 dynamic analysis를 위한 사전작업을 할 것을 제안한다. 예를 들면 usecase간의 dependency관계를 일단 static analysis를 기반으로 분석할 수 있을 것이다. 만일 특정 usecase가 다른 여러 usecase들로부터 호출을 당하게 된다면 실제 단위 시간당 호출되는 횟수를 dyanmic analysis로 확인할 수 있을 것이다. usecase level이 상위 레벨이라면 세부적으로는 class, function과 같은 단위로도 이러한 분석이 가능할 것이다.

그렇다면 이렇게 static & dynamic analysis를 통해서 궁극적으로 무엇을 할 수 있는 것인가? 우선 s/w의 유지/보수성을 높일 수 있을 것이다. 유지/보수를 위해서는 가능한 modularity가 높은 것이 좋을 것이다. 만일 static analysis에만 의존을 하게 된다면 다른 모듈들에 dependency가 높은 모듈을 별도의 component로 분리하는 작업을 하기 어려울 것이다. 왜냐하면 이러한 dependency들이 하나의 task수행을 위해서인지 혹은 별도의 개개별 task별로 하나씩의 dependency들이 존재하는 것인지조차 알 수 없기 때문이다. 만일 후자라면 각각의 task별로 module을 분류하여 dependency level을 낮추어볼 수도 있을 것이다. 그리고 이러한 작업은 dynamic analysis로 접근하는 것이 용이하다. 

두번째는 performance를 향상시킬 수 있을 것이다. 만일 특정 module이 다른 여러 module 다수로부터 사용된다고 하여 해당 module에 부하가 많다고는 할 수 없다. 왜냐하면 각기 다른 시간에 service를 제공한다면 전혀 문제될 것이 없을 것이기 때문이다. 그러나 동시간에 service를 제공해야한다면 issue가 있을 것이다. 바로 이러한 정보들이 dynamic analysis를 기반으로 제공될 수 있을 것이다.

자, 그렇다면 기존의 연구에서 좀더 발전시켜 볼 것은 어떠한 것들이 있을까? 현재 대다수 analysis tool들은 class, function단위의 dependency 분석 내역을 제공한다. 하지만 의존관계는 usecase, logical module, physical module, class, function, component 등 매우 많고 다양할 것이다. 만일 별도의 DB를 구축하여 logical module 과 physical module간의 관계를 mapping시킬 수 있다면 이러한 문제는 어느정도 해결이 될 것으로 생각한다. 현재는 아마도 사람이 이러한 작업을 수행해야할 듯 하며 다각적인 관점에서 분석을 하고자 할 때에는 많은 시간적 비용이 소요될 것이다.

p.s) 많은 dynamic analysis 도구들은 실제 time별 function, class, event간의 호출관계를 보여주지는 못하는 듯 하다. netbeans profiler, jprofiler 등 모두 direct call tree만을 제공하는 듯 하다. 반면 Rational TestRT는 이러한 기능을 제공한다. instrumentation이 가능하다면 크게 어려운 이슈는 아닐 듯 하기에 시간에 따른 dependency관계를 보여주지 못하는 도구들에 대해서는 의문이 생긴다.