Object Flow Analysis - Taking an Object-Centric View on Dynamic Analys

http://scg.unibe.ch/archive/papers/Lien07c-ObjectFlowAnalysis.pdf

Object Flow Analysis - Taking an Object-Centric View on Dynamic Analysis

논문에서는 object의 흐름을 추적하는 view를 제시한다.

Fig. 4.gif

Fig. 4에서 node는 class를 나타내고 괄호 안의 숫자는 가지고 있는 class의 수를 나타낸다. arc는 object들을 주고 받는 관계를 가리킨다. 굵을 수록 많은 object를 주고 받는 횟수가 많다는 것을 나타낸다. 예를 들어 Scanner와 Parser, AST와 AST-Transistor는 주고 받는 object의 수가 많은 것을 알 수 있다.

Fig. 5.gifFig. 5는 시간에 따른 flow상태를 보여준다. 

Fig. 7.gifFig. 7은 특정 class에서 어떠한 object들이 참조되었는지에 대한 정보를 보여준다. orange색은 object가 해당 class로 들어온 것을 나타내며 blue색은 나간 것을 나타낸다.

무언가 새로운 view는 분명한 것 같다. 논문에서는 기존의 method call관계에 비해서 object flow는 보다 간단하게 표현할 수 있기 때문에 프로그램의 흐름을 이해하는데 보다 효과적일 것이라고 설명한다.(실제로 dynamic 분석 결과를 보면 그 자료가 너무 많아서 어디에 집중해야할지부터 헷갈릴 때가 많다.) 

논문에서는 분석을 위한 resource가 다소 많이 소요된다고 설명하지만(약 2.5배) 이는 개선될 수 있는 사항이라고 생각을 한다.

사실 내가 읽으면서 계속 생각한 것은 so what? 이었다. 사실 과거 개발한 software를 생각하면서 당시 필요했을까 생각을 해 보았다. 이전에 legacy software를 대상으로 socket address를 가지고 있는 object를 얻어와야 하는데 어떻게 접근할 수 있을지 고민을 한 적이 있었다. 새로 생성을 하는 것은 바람직하지 않았기에 기존의 object를 가져다가 사용을 해야했다. 그런데 문제는 socket object가 매우 많았다는 것이고 그 가운데 어느 것을 사용할지 몰랐다는 것이다. 그리고 해당 object의 life cycle을 잘 모르고 있었기 때문에 선뜻 가져다가 사용하기에도 부담이 있었다. 많이 논문에서 제시하는 view를 적용할 수 있었다면 보다 내부 흐름을 쉽게 이해할 수 있었을 것이다. 당시에는 eclipse 기반 debugging으로 이해를 시도했는데 쉽지 않았던 듯 하다.

view라는 것이 좋다/나쁘다라고 규정을 할 것은 아닌 듯 하다. 개발자가 훗날 필요한 view가 있는데 마침 있다면 매우 유용할 것이다. 물론 해당 view가 없다고 해도 우회적으로 분석할 방법은 많을 것이다. 

따라서 본 논문에서 제시하는 object flow 도 하나의 좋은 view가 될 수 있을 것 같다는 생각을 해 본다. 

* 논문에서는 해당 view를 만들기 위한 analysis logic에 대해서도 설명을 하는데 생략한다. (잘 모르겠다. ㅡ.ㅡ)

Fig. 7.gif

0.01MB

Fig. 4.gif

0.01MB

Fig. 5.gif

0.01MB