방대한 프로그램을 분석하고 싶을때 어떻게 접근을 해야할까요
글쓴이: oilsok / 작성시간: 화, 2014/02/18 - 7:52오후
오픈소스로 만들어진 프로그램이 있는데
과연 이게 제대로 된 알고리즘으로 작성되었는지 궁금하여
샅샅이 뜯어 보고 싶습니다.
하지만 그 프로그램은 소스코드만 수백개에 헤더파일도 수백개...
물고물리는 #include
예를 들어 이 프로그램을 파이썬으로 포팅을 하고 싶다면
어디부터 접근을 해야할지 궁금하네요.
Namespace와 클래스도 막 뒤섞여 있는데말이에요. 막그림을 그리면서 접근을 해야할지...막막하네요.
생각해본 방법은 최상단 헤더파일부터 내려가면서 분석을 해야하는 것이 좋을지
이런 종류의 작업을 해보신분 있으시면 조언 부탁드립니다.감사합니다.
Forums:
디버깅....
어떤 프로그램인진 모르겠으나 입출력이 있거나 화면상의 인터랙션이 있거나 기타등등 어디선가 브레이크해볼 여지가 있다면 라이브 디버깅을 통해 브레이크를 걸어서 보시면 됩니다.
--
doxygen 으로 다이어그램 그려
doxygen 으로 다이어그램 그려 보시거나
cscope 로 main 부터 따라가 보시거나.
---------
간디가 말한 우리를 파괴시키는 7가지 요소
첫째, 노동 없는 부(富)/둘째, 양심 없는 쾌락
셋째, 인격 없는 지! 식/넷째, 윤리 없는 비지니스
이익추구를 위해서라면..
다섯째, 인성(人性)없는 과학
여섯째, 희생 없는 종교/일곱째, 신념 없는 정치
분석하는 방법은 많습니다. kldp에서도 분석
분석하는 방법은 많습니다.
kldp에서도 분석 검색어만 쳐도 줄줄이 나오죠
1. dependency graph
파일별, 클래스별 다 만든다음에, 필요없는 부분 제거하고 나면 핵심만 남습니다.
doxygen 문서가 있으면 이 단계는 뛰어넘기가 쉽습니다.
2. inheritance graph
OOP인 경우 dependency와 generalization, realization을 구분해서 그립니다. 역시 먼저 다 그린 다음 따로 핵심만 남깁니다.
주의할 점은 class diagram이 아니라는겁니다. 어느 세월에 association, aggregation, composition 같은 건 이름만 보고는 구분 못합니다.
3. call graph
OOP가 아닌 경우 호출 경로를 따라서 그립니다. 역시 다 그리고 다시 핵심만 남깁니다.
이 정도면 뭘 하는지, 어떻게 하는지는, 어디에 뭐가 있는지 정도는 다 나옵니다.
물론 분석 하는 기본 지식은 있어아죠.
저 같은 경우 그리는 툴은 graphviz를 쓰고, pdf로 출력하면 왠만한 걸 찾아보는데는 문제없습니다.
오해할까봐 그러는데 번호 붙인 건 제가 쓰는 방법을
오해할까봐 그러는데 번호 붙인 건 제가 쓰는 방법을 말하는 겁니다.
댓글 달기