JP2014112326A - ソフトウェア複雑度測定装置及び方法並びにプログラム - Google Patents

Abstract

【課題】 ソフトウェアの全階層に亘る全体バランスを定量的に評価すること。
【解決手段】ソフトウェア複雑度測定装置は、階層構造を持つソフトウェア内の複数のコンポーネント間の依存関係の複雑度を表す第１指標値と、前記コンポーネント内の複数のモジュール間の依存関係の複雑度を表す第２指標値と、前記モジュール内の複数の関数間の依存関係の複雑度を表す第３指標値と、前記関数内における経路複雑度を表す第４指標値のうちの少なくともいずれか３つを算出し、該算出した前記少なくともいずれか３つの指標値のうちの最大値を出力する。
【選択図】図９

Description

本発明は、ソフトウェア複雑度測定装置及びソフトウェア複雑度測定方法並びにプログラムに関する。

近年のソフトウェアの巨大化、複雑化は著しく、ソフトウェアに含まれるモジュール数も膨大となり、またモジュール間の依存関係も著しく複雑化してきている。しかし、モジュール間の依存関係がスパゲティ状に複雑になるほど、ソフトウェアの保守性は低くなる。

そこで、モジュール間の依存関係の複雑さを表す指標によって、保守性に問題のあるモジュール構造を定量的に判断し、改善につなげることが試みられてきた。モジュール間の依存関係の複雑さを表す従来の一般的な指標として、以下の指標が提案されている。Inter-Module Complexity（Henry-Kafura）は、モジュールのfan-in数とfan-out数に着目し、(fan-in * fan-out)^2 をモジュールの複雑さとして評価する指標である。

特開２００１−３２５１００号公報 特開２０００−２１５０４５号公報 特開２００８−０８３９１２号公報

ところで、保守性の良いソフトウェア構造の一指標としては、ソフトウェアが全階層に亘ってバランスが良いことが挙げられる。例えば、コンポーネント間を単純化すると、その中のモジュール間が複雑になりすぎ、バランスが良くなくなるという問題が生じうる。この点、既存の指標は、ソフトウェアの全階層に亘るバランスを評価するのには不適である。

そこで、本発明は、ソフトウェアの全階層に亘る全体バランスを定量的に評価することができるソフトウェア複雑度測定装置等の提供を目的とする。

上記目的を達成するため、本発明の一局面によれば、階層構造を持つソフトウェア内の複数のコンポーネント間の依存関係の複雑度を表す第１指標値と、前記コンポーネント内の複数のモジュール間の依存関係の複雑度を表す第２指標値と、前記モジュール内の複数の関数間の依存関係の複雑度を表す第３指標値と、前記関数内における経路複雑度を表す第４指標値のうちの少なくともいずれか３つを算出し、該算出した前記少なくともいずれか３つの指標値のうちの最大値を出力する、ソフトウェア複雑度測定装置が提供される。

本発明によれば、ソフトウェアの全階層に亘る全体バランスを定量的に評価することができるソフトウェア複雑度測定装置等が得られる。

ソフトウェア複雑度測定装置１の一例を示す構成図である。 測定対象の１つのソフトウェアの概略構造の一例を示す図である。 モジュール間における依存関係の一例を示す図である。 図４（Ａ）は、図３のモジュールＸのソースコードの一部を示す図であり、図４（Ｂ）は、図３のモジュールＹのソースコードの一部を示す図である。 依存関係の他の一例を示す図である。 図６（Ａ）は、図５のモジュールＸのソースコードの一部を示す図であり、図６（Ｂ）は、図５のモジュールＹのソースコードの一部を示す図である。 依存関係の更なる他の一例を示す図である。 図８（Ａ）は、図７のモジュールＸのソースコードの一部を示す図であり、図８（Ｂ）は、図７のモジュールＹのソースコードの一部を示す図である。 ソフトウェア複雑度測定装置１の処理装置１０により実行される処理の一例を示すフローチャートである。 第１乃至第４指標値の算出結果の出力例を示す図である。 多対多関係の一例の説明図である。 多対多関係の他の例の説明図である。 逆方向経路及び順方向経路の決定方法（その１）の説明図である。 逆方向経路及び順方向経路の決定方法（その２）の説明図である。 ＤＳＭを用いた逆方向経路率の算出方法の流れの一例を示す図である。

以下、図面を参照して、本発明を実施するための最良の形態の説明を行う。

図１は、ソフトウェア複雑度測定装置１の一例を示す構成図である。ソフトウェア複雑度測定装置１は、処理装置１０を含む。処理装置１０は、典型的には、コンピューターから構成される。コンピューターは、任意のコンピューターであり、汎用性のあるコンピューターであってもよい。

処理装置１０は、ＣＰＵ１２と、記憶部１４とを含んでよい。記憶部１４は、ＲＯＭ（Read Only Memory）やＲＡＭ（Random Access Memory）、ＨＤＤ（Hard Disk Drive）等を含んでよい。以下で説明する処理装置１０の機能は、例えばＣＰＵ１２が記憶部１４内のプログラムを読み出して実行することにより実現されてよい。尚、記憶部１４内には、外部との有線又は無線通信を介してプログラムがダウンロードされ若しくは記録媒体を介してプログラムが格納されてもよい。尚、プログラムは、以下で説明する処理（例えば図９に示す処理）を実現するためのプログラムを含む。尚、記録媒体は、ＣＤ−ＲＯＭ、フレキシブルディスク、光磁気ディスク等の様に情報を光学的，電気的或いは磁気的に記録する記録媒体、ＲＯＭ、フラッシュメモリ等の様に情報を電気的に記録する半導体メモリ等を含んでよい。

処理装置１０には、表示装置１６が接続されてもよい。表示装置１６は、コンピューターのディスプレイに相当してよい。表示装置１６は、液晶ディスプレイであってもよいし、他のタイプのディスプレイであってもよい。表示装置１６には、処理装置１０によるソフトウェアの複雑度の測定結果（例えば、後述の全体バランス指標値等）が表示されてよい。尚、処理装置１０と表示装置１６との間の接続は、有線又は無線若しくはそれらの組合せで実現されてよく、また、表示装置１６は、処理装置１０に対して遠隔位置に存在してもよい。例えば、処理装置１０は、ホストコンピューターであり、表示装置１６は、クライアントコンピューターのディスプレイであってもよい。

ソフトウェア複雑度測定装置１は、ソフトウェアの複雑度を測定する。測定対象のソフトウェアは任意である。例えば、測定対象のソフトウェアは、設計段階（開発段階）のソフトウェアであってもよいし、開発済み（実装済み）のソフトウェアであってもよい。

図２は、測定対象の１つのソフトウェアの概略構造の一例を示す図である。１つのソフトウェアは、図２に示すように、複数のコンポーネントを含んでよい。１つのコンポーネントは、複数のモジュールを含んでよい。１つのモジュールは、複数の関数を含んでよい。このようにソフトウェアの構造は、関数（及び共有変数）、モジュール、コンポーネントなどの構成単位と、構成単位間の依存関係とで定義することができる。尚、構成単位を"箱"、依存関係を方向のついた線とみなすと、ソフトウェア構造は箱と線との組合せで表現することができる。一般的には、コンポーネント内部には複数のモジュールが含まれ、モジュール内部には複数の関数が含まれる。従って、ソフトウェア全体は、大きな粒度（例えばコンポーネント）の箱の中に、より小さい粒度（例えばモジュール）の箱と線が含まれる階層的な構造として表現することができる。尚、以下では、一例として、ソフトウェア全体がコンポーネントに分割され、コンポーネントがモジュールに分割され、モジュールが関数に分割された３階層のソフトウェア構造を前提として説明を続ける。

尚、図２に示す例では、１つのソフトウェアは、３つのコンポーネントを含み、１つのコンポーネントは、３つのモジュールを含み、１つのモジュールは、３つの関数を含んでいるが、これらの数は任意であり、多様となりうる。

尚、モジュールとは、関数や変数といったソフトウェアの構成要素のうち、関係（例えば依存関係）がある構成要素をまとめたものをいう。なお、関係がある構成要素をまとめたものであれば、どのようなものでも「モジュール」に相当し、例えばファイル、クラス、オブジェクトなども「モジュール」に含まれる概念である。

ソフトウェア複雑度測定装置１は、ソフトウェアの複雑度について、コンポーネント粒度（コンポーネント間）、モジュール粒度（モジュール間）、関数粒度（関数・共有変数間）及び関数内で、それぞれ算出する。ソフトウェアの複雑度は、依存関係に基づいて算出されてもよい。例えば、コンポーネント粒度における複雑度は、コンポーネント間の依存関係に基づいて算出されてよく、同様に、モジュール粒度における複雑度は、コンポーネント毎に、コンポーネント内におけるモジュール間の依存関係に基づいて算出されてよい。

ここで、「依存関係」とは、例えばモジュール粒度の場合、あるモジュールに含まれる関数が、別モジュールに含まれる関数を呼び出したり、別モジュールに含まれる変数を読み書きたりする関係にあることをいう。

図３は、モジュール間における依存関係の一例を示す図である。図３では、モジュールＸの関数がモジュールＹの関数を呼び出すタイプの依存関係が模式的に示される。即ち、図３に示す例では、モジュールＸの関数がモジュールＹの関数を呼び出す関係にある。また、このモジュールＸのソースコードの一部を図４（Ａ）に示し、モジュールＹのソースコードの一部を図４（Ｂ）に示す。図３及び図４に示すように、モジュールＸ内の関数「funcA(void)」は、内部にモジュールＹに含まれる関数「funcB()」の呼び出しが記述されている。尚、この場合、モジュールＸからモジュールＹへの依存が存在することとしてよい。

図５は、モジュール間における依存関係の他の一例を示す図である。図５では、モジュールＸの関数がモジュールＹの変数を呼び出すタイプの依存関係が模式的に示される。即ち、図５に示す例では、モジュールＸの関数がモジュールＹの変数を呼び出す関係にある。また、このモジュールＸのソースコードの一部を図６（Ａ）に示し、モジュールＹのソースコードの一部を図６（Ｂ）に示す。図５及び図６に示すように、モジュールＸ内の関数「funcA(void)」は、内部にモジュールＹに含まれる変数（共有変数）「verC」を参照することが記述されている。尚、この場合、モジュールＸからモジュールＹへの依存が存在することとしてよい。

図７は、モジュール間における依存関係の更なる他の一例を示す図である。図７では、モジュールＸの関数がモジュールＹの変数を更新するタイプの依存関係が模式的に示される。即ち、図７に示す例では、モジュールＸの関数がモジュールＹの変数を更新する関係にある。また、このモジュールＸのソースコードの一部を図８（Ａ）に示し、モジュールＹのソースコードの一部を図８（Ｂ）に示す。図７及び図８に示すように、モジュールＸ内の関数「funcA(void)」は、内部にモジュールＹに含まれる変数（共有変数）「verC」を更新することが記述されている。尚、この場合、モジュールＹからモジュールＸへの依存が存在することとしてよい。

尚、図３乃至図８では、モジュール間における依存関係について説明したが、コンポーネント間、関数・共有変数間、関数内においても実質的に同様である。例えば、あるコンポーネント内のモジュールの関数が、他のコンポーネント内のモジュールの関数を呼び出す場合、或いは、あるコンポーネント内のモジュールの関数が、他のコンポーネント内のモジュールの変数を呼び出す又は更新する場合は、コンポーネント間に依存関係が存在する。同様に、ある関数が、他の関数を呼び出す場合、或いは、ある関数が、共有変数を呼び出す又は更新する場合は、関数・共有変数間に依存関係が存在する。

尚、図３乃至図６に示す例では、モジュールＸからモジュールＹへの依存が存在し、図７乃至図８に示す例では、モジュールＹからモジュールＸへの依存が存在するとしているが、このような依存の方向（依存元と依存先との関係）については、用途に応じて自由に定義してよい。

図９は、ソフトウェア複雑度測定装置１の処理装置１０により実行される処理の一例を示すフローチャートである。図９に示す処理は、測定対象のソフトウェアが指定されることで実行されてよい。或いは、測定対象のソフトウェアを入力データ（例えば、Ｃソースコード）として入力して実行されてよい。

ステップ９００では、測定対象のソフトウェア内のコンポーネント間の依存関係の複雑度を表す第１指標値が算出される。

ステップ９０２では、モジュール間の依存関係の複雑度を表す第２指標値が算出される。第２指標値は、測定対象のソフトウェア全体に対して算出されてもよいが、典型的には、測定対象のソフトウェア内のコンポーネント毎に算出される。尚、コンポーネント毎の第２指標値は、そのうちの最大値が代表値として採用されてもよい。

ステップ９０４では、測定対象のソフトウェア内の各関数・共有変数間の依存関係の複雑度を表す第３指標値が算出される。第３指標値は、測定対象のソフトウェア全体に対して算出されてもよいが、典型的には、モジュール毎に、モジュール内の各関数・共有変数に基づいて算出される。この場合、モジュール毎の第３指標値は、そのうちの最大値が代表値として採用されてもよい。

ステップ９０６では、関数内における経路複雑度を表す第４指標値が算出される。第４指標値は、関数の基本的な指標として知られるMcCabe複雑度であってよい。関数毎の第４指標値は、そのうちの最大値が代表値として採用されてよい。

ステップ９０８では、上記ステップ９００乃至９０６で算出された各指標値のうちの最大値が抽出される。尚、各指標値（特に第４指標値）は正規化された後、最大値が抽出されてもよい。

ステップ９１０では、上記ステップ９０８で得られた最大値が所定基準値を超えるか否かが判定される。所定基準値は、全体のバランスの良いソフトウェアで得られる各指標値の上限値に対応し、適合された固定値であってもよいし、可変値であってもよい。例えば、可変値の場合、所定基準値は、第１乃至第４指標値の平均値に応じて可変されてもよい。また、所定基準値は、指標値の種類毎に設定されてもよい。例えば、第１乃至第３指標値に対してと、第４指標値に対してとで、別の所定基準値が用意されてもよい。最大値が所定基準値を超える場合は、ステップ９１２に進み、最大値が所定基準値以下である場合は、ステップ９１４に進む。

ステップ９１２では、全体バランスを表す指標値（以下、全体バランス指標値という）として、上記ステップ９０８で得られた最大値が第１出力態様で表示装置１６に出力される。第１出力態様は、ユーザに注意喚起を促す態様であってよい。例えば、全体バランス指標値が赤色等で表示されてもよいし、点滅等する態様で表示されてもよい。また、第１出力態様は、全体バランスが悪い旨のメッセージの出力を伴ってもよい。

ステップ９１４では、全体バランス指標値として、上記ステップ９０８で得られた最大値が第２出力態様で表示装置１６に出力される。第２出力態様は、第１出力態様よりも注意喚起度の低い通常態様であってよい。

図９に示す処理によれば、ソフトウェア全体として複雑度のバランスを表す指標値（全体バランス指標値）を得ることができる。尚、図９に示す処理において、ステップ９１０乃至ステップ９１４の処理は省略されてもよい。この場合、ステップ９０８で抽出された最大値が単に全体バランス指標値として出力されてよい。

次に、上述の第１乃至第３指標値の算出方法の例について説明する。

第１乃至第３指標値は、それぞれ、例えば、経路複雑度に関する指標値（以下、単に「経路複雑度」という）であってよい。経路複雑度は、例えば、以下の式で算出されてもよい。
（経路複雑度）＝（経路数）−（箱数）＋２×（連結成分数） 式（１）
この式（１）は、関数の基本的な指標として知られるMcCabe複雑度と同様の考え方に基づくものである。

ここで、式（１）において、経路数とは、依存関係を表す経路（線）の数である。例えば箱Ａから箱Ｂへの依存が存在するとき、これを箱Ａから箱Ｂへの依存の経路が存在する。このとき、箱Ａから箱Ｂへの依存が何本あったとしても（例えば、箱Ａに対応するモジュール内の関数が、箱Ｂに対応するモジュール内の関数を呼び出す関係が、複数本あったとしても）、経路数は"１"と数える。但し、箱Ａから箱Ｂへの依存と、箱Ｂから箱Ａへの依存は別の依存経路であると考え、双方向の依存が存在する場合、経路数は"２"と数える。尚、第１指標値の算出時は、箱はコンポーネントであり、第２指標値の算出時は、箱はモジュールであり、第３指標値の算出時は、箱は関数である。

また、式（１）において、箱数は、箱（構成要素）の数であり、粒度に依存する。例えば、コンポーネント粒度では箱数はコンポーネント数であり、モジュール粒度では箱数はモジュール数であり、関数粒度では箱数は関数と共有変数の合計数である。

また、式（１）において、連結成分とは、依存関係で連結されたひとつながりの箱の集合を指す。従って、連結成分数とは、依存関係で連結されたひとつながりの箱の集合の数となる。例えば、１０個の箱全てが依存関係で互いにつながっている場合は、連結成分数は"１"である。他方、１０個の箱全てが互いに依存せずに、ばらばらに存在する場合は、連結成分数は"１０"である。

図１０は、第１乃至第４指標値の算出結果の出力例を示す図である。図１０では、縦軸に経路複雑度（第４指標値についてはMcCabe複雑度、以下同じ）が示され、横軸に第１乃至第４指標値が示されている。図１０に示す例では、５つのコンポーネントＸ１乃至Ｘ５が測定対象として、それぞれ、第１乃至第４指標値が算出されている。また、図１０には、所定基準値Ｔｈ１（図９のステップ９１０参照）が示されている。尚、第１指標値については、５つのコンポーネントＸ１乃至Ｘ５で共通となる。また、第２指標値については、コンポーネント毎の値がそのまま使用される。

図１０に示すように、第１乃至第４指標値は、折れ線グラフで表すことによって、どの指標値（どの階層の複雑さ）がバランスを乱しているかを容易に把握することができる。図１０に示す例では、コンポーネントＸ２は、第３指標値（モジュール内の経路複雑度、即ち関数間の経路複雑度）のみが所定基準値Ｔｈ１を超えている。また、コンポーネントＸ１は、第３指標値及び第４指標値（関数内の経路複雑度）のみが所定基準値Ｔｈ１を超えている。他のコンポーネントＸ３，Ｘ４，Ｘ５は、全ての指標値が所定基準値Ｔｈ１以下となっており、バランスが良好であると判断することができる。

ここで、問題のあるソフトウェア構造の多くは、どこかの階層が極端に単純であるため、そのしわ寄せとして別の階層が極端に複雑になっていることが多い。全ての階層に亘って適度な複雑さに抑えられたバランスの良い構造が、保守性の高い良いソフトウェア構造ということができる。尚、保守性が高いソフトウェア構造とは、保守作業（変更時の内容理解、修正、テストなど）に必要な努力（工数）が少なくて済む構造を指す。

従って、第１乃至第３指標値として経路複雑度を使用し、全体バランス指標値を得ることで、ソフトウェア構造の全体のバランス（全ての階層に亘って適度な複雑さに抑えられたバランスの良さの有無）を定量的に評価することができる。

尚、図１０に示す例では、コンポーネント毎に、第１乃至第４指標値が折れ線グラフで表されているが、ソフトウェア毎に第１乃至第４指標値が折れ線グラフで表されてもよいし、モジュール毎に第１乃至第４指標値が折れ線グラフで表されてもよい。尚、ソフトウェア毎に第１乃至第４指標値が折れ線グラフで表される場合、第２指標値については、ソフトウェア毎に、コンポーネント毎の各第２指標値のうちの最大値が使用されてよい。

次に、第１乃至第３指標値の算出方法の他の例について説明する。

第１乃至第３指標値は、それぞれ、例えば、多対多関係強度を表す値であってよい。多対多関係強度は、例えば、以下の式で定義されてもよい。
（多対多関係強度）＝（多対多経路数）／（多対多関係箱数） 式（２）
ここで、箱Ａから箱Ｂへの依存のみが存在するとき、ＡとＢは１対１関係にあるとし、Ｍ個の依存元からＮ個の依存先への経路が全て存在するとき、これをＭ対Ｎ関係にあるとする。Ｍ，Ｎが２以上であるとき、即ち複数の依存元から複数の依存先への経路が全て存在するとき、これを多対多関係にあるとする。複数の依存元から複数の依存先への経路が全て存在するとき（即ち多対多関係が存在するとき）、これらの経路を多対多経路と称する。従って、多対多経路数とは、複数の依存元から複数の依存先への経路が全て存在するとき、これらの多対多経路の数である。また、多対多関係箱とは、多対多関係を構成する箱であり、多対多関係箱数は、多対多関係箱の数である。

尚、複数の多対多関係が存在する場合、及び、その加えて複数の多対多関係が重複している場合には、多対多関係を構成する全ての経路は全て、多対多経路数として数え、多対多関係を構成する箱は全て多対多関係箱として数える。即ち、重複はダブルカウントしない。

図１１は、多対多関係の一例の説明図である。図１１に示す例では、箱Ａ，Ｂと箱Ｃ乃至Ｆについては、箱Ａから箱Ｃ乃至Ｆへの各経路が全て存在し、箱Ｂから箱Ｃ乃至Ｆへの各経路が全て存在するので、２対４関係であり、多対多関係を構成する。同様に、箱Ｃ乃至Ｆと箱Ｇ，Ｈは、４対２関係であり、多対多関係を構成する。この場合は、複数の多対多関係が存在する場合に当たり、また、複数の多対多関係が重複している場合に当たる（箱Ｃ乃至Ｆで重複する）。この場合、多対多経路数は、"１６"であり、多対多関係箱数は、"８"であり、従って、多対多関係強度は"２"である。

図１２は、多対多関係の他の例の説明図である。図１２（Ａ）は、２対２関係が４つある構成を示し、図１２（Ｂ）は、４対４関係が１つある構成を示す。図１２（Ａ）に示す構成では、多対多経路数は、"１６"であり、多対多関係箱数は、"１６"であり、従って、多対多関係強度は"１"である。他方、図１２（Ｂ）に示す構成では、多対多経路数は、"１６"であり、多対多関係箱数は、"８"であり、従って、多対多関係強度は"２"である。このように、多対多経路数が同じでも、多対多関係強度が大きいほど経路が絡み合っているといえる。

ところで、保守性の高いソフトウェア構造は、依存関係がスパゲティでないという特徴がある。即ち、依存の経路が特定の箱間に集中しすぎて絡み合っていないという特徴がある。従って、第１乃至第３指標値として多対多関係強度を使用し、全体バランス指標値を得ることで、ソフトウェア構造の全体のバランス（全ての階層に亘って適度な複雑さに抑えられたバランスの良さの有無）を定量的に評価することができる。

次に、第１乃至第３指標値の算出方法の更なる他の例について説明する。

第１乃至第３指標値は、それぞれ、例えば、逆方向経路率を表す値であってよい。逆方向経路率は、例えば、以下の式で定義されてもよい。
（逆方向経路率）＝（逆方向経路数）／（順方向経路数） 式（３）
ここで、上述の如く、箱Ａから箱Ｂへの依存が存在するとき、これを箱Ａから箱Ｂへの依存の経路が存在する。このとき、箱Ａから箱Ｂへの依存が何本あったとしても（例えば、箱Ａに対応するモジュール内の関数が、箱Ｂに対応するモジュール内の関数を呼び出す関係が、複数本あったとしても）、経路数は"１"と数える。但し、箱Ａから箱Ｂへの依存と、箱Ｂから箱Ａへの依存は別の依存経路であると考え、双方向の依存が存在する場合、経路数は"２"と数える。逆方向とは、ある２つの箱間において、依存の本数が少ない方向に対応し、順方向は、依存の本数が多い方向に対応する。

図１３は、逆方向経路及び順方向経路の決定方法（その１）の説明図である。

図１３（Ａ）に示す例では、箱Ａから箱Ｂへ３本の依存があり、箱Ｂから箱Ａへ２本の依存がある。この場合、依存の本数が少ない方向の経路、即ち箱Ｂから箱Ａへの経路が逆方向経路となり、依存の本数が多い方向の経路、即ち箱Ａから箱Ｂへの経路が順方向経路となる。

図１３（Ｂ）に示す例では、箱Ａから箱Ｂへ１本の依存があり、箱Ｂから箱Ａへ１本の依存がある。このように依存の最小本数が同数である場合は、ランダムにいずれか一方が逆方向とされてよい。例えば、箱Ｂから箱Ａへの経路が逆方向経路となり、箱Ａから箱Ｂへの経路が順方向経路となってもよい。

図１４は、逆方向経路及び順方向経路の決定方法（その２）の説明図である。

図１４（Ａ）に示す例では、３つの箱Ａ，Ｂ，Ｃ間で依存が循環している。この場合、循環全体の中で最も本数の少ない依存の経路が逆方向となる。図１４（Ａ）に示す例では、箱から箱Ｂへの依存の本数が"２"であり、箱Ｂから箱Ｃへの依存の本数が"２"であり、箱Ｃから箱Ａへの依存の本数が"１"である。従って、この場合、箱Ｃから箱Ａへの経路が逆方向経路となり、箱Ａから箱Ｂへの経路、及び、箱Ｂから箱Ｃへの経路が順方向経路となる。

図１４（Ｂ）に示す例では、図１４（Ａ）に示す例と同様、３つの箱Ａ，Ｂ，Ｃ間で依存が循環しているが、箱から箱Ｂへの依存の本数が"２"であり、箱Ｂから箱Ｃへの依存の本数が"１"であり、箱Ｃから箱Ａへの依存の本数が"１"である。このように依存の最小本数が同数である場合は、ランダムにいずれか一方が逆方向とされてよい。例えば、箱Ｃから箱Ａへの経路が逆方向経路とされ、箱Ａから箱Ｂへの経路、及び、箱Ｂから箱Ｃへの経路が順方向経路とされてよい。

尚、図１３及び図１４に示したように、最も少ない依存本数の経路を切ることで双方向依存（図１３）や循環依存（図１４）を解消できるような経路が逆方向経路ということができる。

逆方向経路数及び順方向経路数は、例えば以下の方法で算出されてもよい。先ず、ＤＳＭ（Dependency Structure Matrix）によって箱間の依存関係を表現する。ＤＳＭとは、列と行の交差するセルに依存元から依存先への依存関係の本数（依存の数）を記述した行列である。ＤＳＭの項目は、各箱を表す。従って、例えばモジュール粒度の場合（即ち第２指標値の場合）は、ＤＳＭの各項目は、あるコンポーネント内の各モジュールであってよい。また、関数粒度の場合（即ち第３指標値の場合）は、ＤＳＭの各項目は、各関数及び各共有変数であってよい。ＤＳＭにおける箱の並び方は、対角線より上のセル内の数字の合計（逆方向の依存数）が最小となるように最適化される。かかる最適化を行ったＤＳＭにおいて、対角線より上の各セルのうち、"１"以上の数字が入っているセルの数が、逆方向経路数となり、対角線より下の各セルのうち、"１"以上の数字が入っているセルの数が、順方向経路数となる。

図１５は、ＤＳＭを用いた逆方向経路率の算出方法の流れの一例を示す図である。図１５（Ａ）に示す例では、箱Ａから箱Ｂへの依存の本数が"１０"であり、箱Ｂから箱Ｃへの依存の本数が"１"であり、箱Ｃから箱Ａへの依存の本数が"２０"である構成が示される。このような構成について、先ず、箱Ａ，Ｂ，Ｃの並びにてＤＳＭで表現すると、図１５（Ｂ）に示すＤＳＭが得られる。このＤＳＭでは、対角線より上のセル内の数字の合計が"２０"である。対角線より上のセル内の数字の合計が最小となるように、箱Ａ，Ｂ，Ｃの並びを最適化すると、図１５（Ｃ）に示すＤＳＭが得られる。このＤＳＭによれば、図１５（Ｄ）に示すような箱Ｃ，Ａ，Ｂの並びで対角線より上のセル内の数字の合計が最小値"１"となり、最適な並びであることが分かる。従って、この例では、箱Ｂから箱Ｃへの経路が逆方向経路となり、箱Ｃから箱Ａへの経路、及び、箱Ａから箱Ｂへの経路が順方向経路となる。従って、逆方向経路数は、"１"であり、順方向経路数は、"２"であり、逆方向経路率は、"１／２"となる。

ところで、保守性の高いソフトウェア構造は、依存の方向がそろっているという特徴がある。即ち、逆方向経路数が少ないという特徴がある。従って、第１乃至第３指標値として逆方向経路率を使用し、全体バランス指標値を得ることで、ソフトウェア構造の全体のバランス（全ての階層に亘って適度な複雑さに抑えられたバランスの良さの有無）を定量的に評価することができる。

以上、本発明の好ましい実施例について詳説したが、本発明は、上述した実施例に制限されることはなく、本発明の範囲を逸脱することなく、上述した実施例に種々の変形及び置換を加えることができる。

例えば、上述した実施例では、第１乃至第３指標値の算出方法のいくつかを説明したが、これらは組み合わせて使用することも可能である。例えば、第１乃至第３指標値は、それぞれ、経路複雑度、多対多関係強度を表す値、及び、逆方向経路率を表す値のうちの任意の２つ又は３つの組合せで表されてもよい。

また、上述した実施例では、第１乃至第４指標値のうちの最大値を全体バランス指標値としているが、第１乃至第４指標値のうちのいずれか任意の３つの指標値の組合せのみを用い、当該３つの指標値のうちの最大値を全体バランス指標値として用いてもよい。

また、上述した実施例では、測定対象のソフトウェアは、コンポーネント、モジュール、関数・共有変数の構成単位で階層構造を有しているが、階層構造における階層数は任意である。また、同一階層における各構成単位の区分け、例えばコンポーネント間の区分け（例えば、どのモジュールがどのコンポーネントに含まれるか）についても任意である。但し、典型的には、モジュールは、ソースファイル毎に存在し、コンポーネントは、ソースファイルを格納するフォルダ毎に存在する。

１ ソフトウェア複雑度測定装置
１０ 処理装置
１２ ＣＰＵ
１４ 記憶部
１６ 表示装置

Claims (5)

1. 階層構造を持つソフトウェア内の複数のコンポーネント間の依存関係の複雑度を表す第１指標値と、前記コンポーネント内の複数のモジュール間の依存関係の複雑度を表す第２指標値と、前記モジュール内の複数の関数間の依存関係の複雑度を表す第３指標値と、前記関数内における経路複雑度を表す第４指標値のうちの少なくともいずれか３つを算出し、該算出した前記少なくともいずれか３つの指標値のうちの最大値を出力する、ソフトウェア複雑度測定装置。
2. 前記最大値が所定基準値を超えたか否かを判定する、請求項１に記載のソフトウェア複雑度測定装置。
3. 算出した前記少なくともいずれか３つの指標値を折れ線グラフで出力する、請求項１又は２に記載のソフトウェア複雑度測定装置。
4. 階層構造を持つソフトウェア内の複数のコンポーネント間の依存関係の複雑度を表す第１指標値と、前記コンポーネント内の複数のモジュール間の依存関係の複雑度を表す第２指標値と、前記モジュール内の複数の関数間の依存関係の複雑度を表す第３指標値と、前記関数内における経路複雑度を表す第４指標値のうちの少なくともいずれか３つを算出し、
   該算出した前記少なくともいずれか３つの指標値のうちの最大値を出力する、ソフトウェア複雑度測定方法。
5. 階層構造を持つソフトウェア内の複数のコンポーネント間の依存関係の複雑度を表す第１指標値と、前記コンポーネント内の複数のモジュール間の依存関係の複雑度を表す第２指標値と、前記モジュール内の複数の関数間の依存関係の複雑度を表す第３指標値と、前記関数内における経路複雑度を表す第４指標値のうちの少なくともいずれか３つを算出し、
   該算出した前記少なくともいずれか３つの指標値のうちの最大値を出力する、
   処理をコンピューターに実行させるプログラム。

Images