2012-11-26 5 views
5

Javaプロジェクト全体のcyclomatic complexityを計算するには?私はすべてのメソッドに複雑さがありますが、それらをすべて1つの数値メトリックに集約する方法はありますか?任意のアイデアや既存の方法?プロジェクトの循環複雑度を計算するには(クラス/関数ではありません)?

私はツールを探しているのではなく、アルゴリズムを探しています。

複雑な方法はほとんどありませんが、ほとんどの場合、コードベースの重要性は低い1 - 複雑な方法が多いため、単純な平均はほとんど機能しません。

答えて

2

私はその式が見つかりました:

TCC = Sum(CC) - Count(CC) + 1 
TCC: Total CC 
Sum(CC): Sum of CC of all functions 
Count(CC): Number of functions 

出典:http://www.aivosto.com/project/help/pm-complexity.html

しかし、おそらくそれはあまりにも限られているが。

もう1つの考え方は、プログラムのコールグラフをプログラムそのものとみなし、コールグラフのCCを計算することです。ノードはCCによって重み付けされる。 (実現可能かどうかは分かりませんが、それは単なるアイデアです)

0

これが役立つかどうかはわかりませんが、私は思ったことを伝えたいと思います。グローバル深度カウンターを使用すると、メソッド呼び出し深度を取得し、すべてのメソッド呼び出しで更新することができます。 ここではすべてのメソッドに同じスニペットが手動で注入されていますが、コードをすべてのメソッドに自動注入するソリューションがあります。スタックトレースの長さでは、集約された複雑さを計算できます。

public class Cyclomatic 
{ 
    public static int max = Integer.MIN_VALUE; 

    static void a() 
    { 
     b(); 
     int temp = Thread.currentThread().getStackTrace().length; 
     if (temp > max) 
      max = temp; 
    } 

    static void b() 
    { 
     c(); 
     int temp = Thread.currentThread().getStackTrace().length; 
     if (temp > max) 
      max = temp; 
    } 

    static void c() 
    { 
     int temp = Thread.currentThread().getStackTrace().length; 
     if (temp > max) 
      max = temp; 
    } 

    public static void main(String[] args) 
    { 
     a(); 
     System.out.println(max); 
    } 
} 

出力:

5 
3

全体の本は、コードメトリクスに書かれているので、あなたは、あなたがより具体的な質問をしていることを幸運です。 Javaの循環型複雑さの場合、循環型の複雑さ5または6を超えるメソッドの数を見つけることができます(ここで数を選択します)。この数がメソッドの数の一定割合を超えると、サイクロマティック全体の複雑さが低くなります。パーセンテージの良い数値は、プロジェクトのサイズに完全に依存します。したがって、メソッドの数だけではなく、メソッドの数を減らすことができます。プロジェクトが成長するにつれてそれをより安定にするための平方根または対数。

たぶん、このような何か:

public double evaluateCyclomaticComplexity(List<MethodStat> methodStats) { 
    int bad = 0; 
    for (MethodStat methodStat : methodStats) 
     if (methodStat.getCyclomaticComplexity() >= 6) 
      bad++; 

    double denominator = Math.sqrt(methodStats.size()); 
    return bad * 100.0/denominator; 
} 

数がここで返さ小さく、より良いです。 の場合、実際にはが悪いプロジェクトの場合は、100より大きい何かが返されます。

分母関数は、コードベースが成長するにつれて複雑さがどのくらい速いかを表す必要があります。一般的に、コードが拡張されて保守可能な状態になるにつれて、CCが関数ごとに低くなるようにしたいので、プロジェクトサイズが大きくなるにつれて成長が遅くなるものが最適です。

最終的には、コードメトリクスは正当化するのが難しく、数字を使って「保守性」を表すオープンソースソフトウェアに関するいくつかのジャーナル論文を読んだ後で証明することができます。十分な時間が費やされれば、ここで思いつくことができます。