A critique of cyclomatic complexity as a software metric


꽤 오래된 논문이지만, ,,

 

Cyclomatic complexity에 대한 비판 – 2011년 작성 자료

[19] Myers, G. J, “An Extension to the cyclomatic measures of program complexity”

IF (X<1 AND Y<2) THEN stmt_A ELSE stmt_B라는 구문에 대한 cyclomatic complexity를 구할 때, condition을 어떻게 처리하느냐에 따라 complexity가 달라질 수 있다. 사실 이건 그리 큰 문제가 아닐 수 있다.

 

 cc2
v(G) = 4 – 3 + 1 = 2 v(G) = 6 – 4 + 1 = 3

 

No Source Code Cyclomatic Complexity Myers
1 IF X=0 THEN …

ELSE …;

v(G) = 2 Myers = (2;2)
2 IF X=0 AND Y>1 THEN …

ELSE …

v(G) = 3 Myers = (2;3)
3 IF X=0 THEN

IF Y>1 THEN …

ELSE …

ELSE …

v(G) = 3 Myers = (3;3)

No2, No3의 source code에서 v(G)는 모두 3이다. Myers의 주장은 3번이 2번보다 더 복잡하지만, cyclomatic complexity로 산출한 값은 동일하다고 나오므로, 이 부분에서 cyclomatic complexity에 약점이 있음을 지적하였다.

switch-Case문에 대한 Cyclomatic complexity의 비판

[15] Hansen, W.J, “Measurement of program complexity by the pair(cyclomatic number, operator count)”

[28] BASILI, V.R., and REITER, R.W.: ‘Evaluating automatable measures of s/w development’

중첩 if문보다 switch-Case가 더 깔끔하기 때문에 [15]에서는 switch-case에 대한 복잡도는 1로 해야 한다고 제안, 반면 [28]에서는 log2(n)으로 표현할 것을 제안하였는데 n은 case의 개수다.

나의 의견으로는 이 문제는 predicate complexity로 처리하는 것이 맞을 것 같고, predicate complexity에 대한 자료를 찾아보고 이를 cyclomatic complexity에 접목하는 것이 좋을 것 같음.

Programming style에 대한 cyclomatic complexity의 비판

[30] BAKER, A.L., and ZWEBEN, S.: ’A comparison of measures of control flow complexity

[31] OULSNAM, G.: ‘Cyclomatic numbers do not measure complexity of unstructured programs’,

[32] PRATHER, R.E.: ’An axiomatic theory of software complexity metrics’

[33] SINHA, P.K., JAYAPRAKASH, S., and LAKSHMANAN, K.B.: ‘A new look at the control flow complexity of computer programs’

Program structure를 개선하려고 할 때, 오히려 cyclomatic complexity가 증가하는 문제를 보임. [30]의 예에서 아래 그림은 k개의 exit point가 있는 code를 1개의 exit point가 있는 코드로 re-strecturing했을 때 cyclomatic complexity를 구하면 언제나 re-structuring한 후의 복잡도가 더 높다. (1 차이가 난다. [30]에서 이를 증명했다.) 프로그램의 구조를 개선했기 때문에 (b)가 더 복잡도가 낮아야 함에도 불구하고 이런 문제가 발생하게 되었다.

 cc3  cc4
(a) loop with k exits (b) (a)-structured using Boolean variables

Nesting level에 대한 복잡도의 개선 – 아직 확인하지 못함

[18] MAGEL, K.: ‘Regular expressions in a program complexity metric

[32] PRATHER, R.E.: ’An axiomatic theory of software complexity metrics’

[36] PIOWARSKI, P.: ‘A nesting level complexity measure’

 

3가지 비판

1) v(G)는 decision counting 방식이다. 프로그램의 복잡도가 decision에 의해 좌우되지는 않는다. 게다가 모든 decision은 constant weighting방식이다.

2) 일반적으로 받아들여지는 프로그램 구조화 기술을 사용하면 복잡도가 내려가야만 하는데, v(G)는 이 기술들과는 전혀 관계가 없는 듯 하다. (관계가 있어야만 한다. 프로그램 구조화 기술이 어떤 것들이 있는지 찾아봐야 할 필요가 있다.)

3) 전체 프로그램의 복잡도에 모듈화는 거의 영향을 미치지 못한다.

 

[15], [19]는 complexity measure가 가져야 하는 criteria를 제시하였음

[15] Hansen, W.J, “Measurement of program complexity by the pair(cyclomatic number, operator count)”

[19] Myers, G. J, “An Extension to the cyclomatic measures of program complexity”

 

데이터, 제어 복잡도에 대해 고려하지 않았음

 

[41, 47, 48, 53, 55] LOC가 CC(cyclomatic complexity)보다 outperform한다.

 

[56] control flow와 data structure complexity사이는 trade-off관계이다. 예를 들어서 multiple IF혹은 CASE를 decision table을 사용하여 대체할 수 있는데, multiple IF를 사용하게 되면 CC가 증가하고, decision table을 사용하게 되면 CC가 감소하는 문제가 발생하게 된다. 그렇기 때문에 testing difficulty와 CC와의 관계는 희박하다고 주장함

Advertisements

답글 남기기

아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Google+ photo

Google+의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

%s에 연결하는 중